Live data from Hacker News

The cloudy layers of modern-day programming

vickiboykis.com

111–120 of 177 posts

Re: The cloudy layers of modern-day programming

#111
post #28

Good article, great points. The Knuth quote on lack of creativity is right on the money. It's why I've been drifting away from hands-on programming even though I'd rather not. I still love programming as much as I ever did as a teenager. Late at night when everyone is asleep and I can work on my own code, it's as much joy as it ever was. What's different is that at $DAYJOB back in the 90s and 00s it used to be just a…

> Nowadays when it's just gluing frameworks together and configuring AWS services... it doesn't really feel any different intellectually than cleaning toilets. Comparing your six figure white collar job to basic janitorial work is pretty damn cringe and pretty objectively untrue.

They're not saying the pay is the same. They're saying the intellectual aspect of the work is not terribly different.

Re: The cloudy layers of modern-day programming

#112

I agree with the sentiment in the article, but I also believe this kind of development is inevitable. How else are you going to to create increasingly complex high-level software if not by gluing together pieces that have already been written? Are you going to create your data layer from scratch every time? I just don't see how you can arrive at today's productivity without running into this issue. Sure, it's not fun…

> How else are you going to to create increasingly complex high-level software if not by gluing together pieces that have already been written? Are you going to create your data layer from scratch every time?

No, but I understand why you’d think that. Both the author and commenters make strange conclusions about the situation.

The problem is much easier to phrase than that. We don’t have good building blocks and tools. What does good mean? It means reliable and performant implementations, predictable behavior, well designed API surfaces (does one thing well), ability to debug and inspect, among other things.

The basic tools are already like this. Standard libraries, compilers, unix tools, file systems, certain battle tested databases. They’re all open source & move very slowly.

However, we also have countless proprietary cloud services, dependency hell in languages like JS and Rust, services scattered over different networks, regions and vendors.

So.. how did we end up here? I think it’s a combination of different reasons:

- More data both in total and per time unit. Much more people online. The world also developed towards ad tech, ML and video which demands a lot more than text and images.

- Horizontal scaling is the most cost-effective (due to physics) which prompts orders of magnitude more complex distributed systems.

- Cloud is the only option for many and gets pioneered by massive rent-seeking cynical corporations, so we lost both FOSS and any serious opportunities for standardization and simplicity. The IBM years are back.

- Money is so heavily involved, so ad-tech giants slurp up the talent and use them for market dominance, tech contributions become a side effect.

- Package managers and GitHub makes distribution easy, but results in a ginormous amount of dependencies and vendors.

So how do we fix it? We need to change culture and attitudes. A couple of tricks: Choose your deps carefully. Prefer FOSS, check issues – are these good authors? Is the API surface good? Well documented? Only use what you need, don’t let trendy blog posts FOMO you into using anything. You probably don’t need click metrics, A/B testing frameworks, minification, uglification, code splitting. You probably don’t need microservices either, or 99.999% uptime. Chances are you don’t even need multiple machines, or more than basic monitoring.

Re: The cloudy layers of modern-day programming

#113
post #17

Do architects reinvent the I-beam every time they design a new building? No, of course not. The reason society works is because you can reuse abstractions that other people have already invented . It allows you to scale. Without economies of scale, you end up with Baumol's cost disease, which is extremely obvious in the US in industries like child and elderly care. We don't want most software devs to be doing anythin…

Except the I-beam isn't only owned by a single company and is interoperable. (Unlike modern clouds and SaaS, which are neither of these things.)

Re: The cloudy layers of modern-day programming

#115
post #95

Earlier quoted context omitted.

I'd rather re-invent some wheels. The problem with VendorOps as I see it is that quite often the vendored "solutions" aren't solutions: they do not meet the requirements! Yet … they sort of get like 20% of the way there, so they get adopted nonetheless, and the devs toil away on trying to get glue code to push it the remaining 80% of the way. But if we had a system that we owned , then it could be adjusted to fit the…

We got random failures on our API gateway to lambda connections, and the answer we got back from the support agent was something like “automatically retrying on failure is industry best practice”. I just wanted to shout at them to fix their damn system, but of course we ended up implementing retries instead…

For a while AWS Glue had an issue where the running job counter would permanently increment. This was a problem if you only wanted one copy of a job running. The advice support gave us was to increase the allowed count by one. I saw references to this issue that were years old. I think it is fixed now because I haven't seen it happen in months.

Re: The cloudy layers of modern-day programming

#116
post #23
post #17

Do architects reinvent the I-beam every time they design a new building? No, of course not. The reason society works is because you can reuse abstractions that other people have already invented . It allows you to scale. Without economies of scale, you end up with Baumol's cost disease, which is extremely obvious in the US in industries like child and elderly care. We don't want most software devs to be doing anythin…

I like this allegory because it puts the complexity into a visual mindset and brings to light an interesting question about the nature of our abstractions.. For example: Are our abstractions I-beams or Pre-Fabs[0]? We all know that the rise of pre-fabs is, at its heart, the story of cheap developments all lazily (and hastily) thrown together in arrangements that are of low quality, mid-to-low beauty and do not last f…

I-beams are programming languages, libraries, and compilers.

Pre-fabs are massive frameworks where mixing them always looks hack-glued together. Same as if you glue two prefabs from different vendors.

That said, industrial plants aren't gothic cathedrals. They are a collection of buildings plopped together.

Re: The cloudy layers of modern-day programming

#117
post #23

Earlier quoted context omitted.

I like this allegory because it puts the complexity into a visual mindset and brings to light an interesting question about the nature of our abstractions.. For example: Are our abstractions I-beams or Pre-Fabs[0]? We all know that the rise of pre-fabs is, at its heart, the story of cheap developments all lazily (and hastily) thrown together in arrangements that are of low quality, mid-to-low beauty and do not last f…

I-beams are programming languages, libraries, and compilers. Pre-fabs are massive frameworks where mixing them always looks hack-glued together. Same as if you glue two prefabs from different vendors. That said, industrial plants aren't gothic cathedrals. They are a collection of buildings plopped together.

I think that's a pretty good categorisation that I could definitely agree with.

So I guess with that allegory you have to ask: Am I building a factory, an office, a home or a cathedral.

You can then plan your architecture accordingly.

Re: The cloudy layers of modern-day programming

#118
post #109

Like many other commenters (of a certain age?), I too have this unsatisfied feeling about a particular kind of modern software development. The kind where you never really dig down and design anything, you just plumb a bunch of stuff together with best practices you find on stack overflow. Many commenters are attributing this problem to the modern high-level tools we now have access to. But I don't think this is the…

I came to this same conclusion last week when I started writing my own webgpu renderer. I went into it with no knowledge of graphics and without using libraries. Having to create my own generic abstractions for pipelines, passes and buffers has been a massive creative and educational experience. I haven't felt this satisfaction from programming in years from my day job.

[deleted]

Re: The cloudy layers of modern-day programming

#119
post #72

What scares me about ChatGPT is less so that I’ll lose my job (though it’s possible), but more so that I’ll be using language models to work at higher and higher levels of abstraction doing mainly configuration tweaking. Some of the particular pain points expressed in the article should be removed with AI in the loop development, but it’s another step away from “real programming”, which is what attracted most of us t…

How much joy do we really get from day-to-day work if we are really honest? I am using ChatGPT to help me get things done (Node.js programming) for my startup. It's getting me closer to having this client project done so I will have more time for my own internal AI thing I am adding to the main service. No one is stopping you from writing 6502 assembly code in your spare time. That's actually still a somewhat popular…

Well, as a matter of fact my current job is embedded, so I admit I’m being a bit whingy.

Re: The cloudy layers of modern-day programming

#120
post #83

Like many other commenters (of a certain age?), I too have this unsatisfied feeling about a particular kind of modern software development. The kind where you never really dig down and design anything, you just plumb a bunch of stuff together with best practices you find on stack overflow. Many commenters are attributing this problem to the modern high-level tools we now have access to. But I don't think this is the…

Challenge yourself to use stdlib only for a while, or the future. It sounds unrealistic and I'm going to get flamed, but hear me out. It works. Most of my development these days is in reasonably complete languages like go, rust, zig, and various scripting languages, so your mileage may vary if you're writing in something like rune, hare or carbon that is still taking shape. If you think I'm crazy but have a lingering…

Going one step further, challenge yourself to _not_ use stdlib, just raw language constructs.

Need a hashtable? Write one.

You won't come out with a celebrity HN presence, but you may gain enlightened samurai monk status.

Post reply on HN