Posted by obscurette 2 days ago
In the late 19th and early 20th Gilded Age era, every industry was dominated by trusts, collusions of manufacturers who set up anti-compete systems to ensure such disruption of their industry by independent innovation wouldn't succeed. This is now being replayed in the tech industry for similar reasons.
There are two solutions to this problem that go together: anti-trust law and open-source hardware and software models - but for that to work, you need an educated population with and understanding of legal and scientific concepts, which is why the education system in the USA has been so deliberately degraded over the past few decades.
That's what happens when you let investment capitalists control everything, isn't it?
>Edge computing? That’s just distributed processing with better marketing.
Edge computing is not "just" distributed processing. That fails to recognize the point of minimizing latency.
>Microservices? Welcome to the return of modular programming, now with 300% more YAML configuration files.
Not all modules are microservices. It's again term to a more specific practice.
>Serverless? Congratulations, you’ve rediscovered time-sharing, except now you pay by the millisecond.
Those are somewhat related concepts but they still don't have the same meaning.
>Compare that to today’s black-box system-on-chip designs, where a single failure means the entire device becomes e-waste
If you really wanted to, you could fix the system-on-chip.
>We’ve mistaken complexity for sophistication and abstraction for advancement.
People are not adding complexity and abstractions just for fun.
>We’ve created a tower of dependencies so precarious that updating a single package can break an entire application
This has always been the case. Bugs still existed in the 1900s.
>What started as a legitimate return to hands-on engineering has been co-opted by influencer culture, where the goal isn’t to build something useful but to generate content about building something photogenic.
Social media being dominated by people good at social media and not by the top makers will happen in every endeavor. Accessibility has allowed many more people to be able to create basic things.
>We’re creating a generation of developers and engineers who can use tools brilliantly but can't explain how those tools work
They don't need to. And this has always been the case. There is too much to know and having different people specialize in different things is effective. Additionally there is great value in making software accessible making people with less knowledge to be able to make things. It allows for more things to be created that deliver value to people.
>The best engineering solutions are often elegantly simple. They work reliably, fail predictably, and can be understood by the people who use them. They don't require constant updates or cloud connectivity or subscription services.
Sure, but many people want a solution that can be delivered now and for cheap.
Title misses the mark and hand waves shitload of progress we have.
Nagging about consumer electronics is fine because a lot of stuff has its issues. But compared to 20 or even 10 years ago everything on average works much better.
edit: lol
But it wasn't straightforward twenty years ago. Maybe it was to you, but it wasn't to others. There's a reason the world moved away from command line interfaces and it's not just to bully the nerds.
Same reason many Americans don't know how to use a clutch, and why chopping down trees for your own house has fallen out of fashion. As society specialises and technology advances, responsibilities are divided.
> The VHS player in my basement could be fixed with a screwdriver and a service manual (OK, sometimes an oscilloscope). Meanwhile, my Wi-Fi router requires a PhD in reverse engineering just to figure out why it won’t connect to the internet. We’ve mistaken complexity for sophistication and abstraction for advancement.
A VHS player is built on top of tons of abstractions. There's a component somewhere in the middle that will take electric pulses and turn them into subtitles you can turn on or off. Just like that WiFi router still has its analog pins you could hook your oscilloscope up to if you want to troubleshoot it.
We have lost service manuals for many electronics indeed, but that's because servicing these devices no longer earns anyone a living. Electronics as complex as VHS players have dropped in price from a month or two's wage for a whole family to the price of eating out. Spending half a year teaching yourself electrical engineering to maintain your TV isn't worth the time investment anymore, unless you're doing it out of personal interest.
You can repair the failed electronics on WiFi routers. You don't need to, though, because the electronics no longer constantly fail like they used to. The skills electrical engineers from the last century have proudly honed just aren't as relevant as they used to be. The "old man yells at cloud" complaint that kids these days don't even know assembly is just as relevant as it was in the days when assembly was commonplace, when kids those days didn't even know how to program spinning drums or knit magnetic core memory without the help of an assembler.
Billions of people drive cars every day. Most of those people have no idea how their car works beyond the ignition, yet the world relies on that technology and it's working just fine. Cars do break down sometimes, and that's when you call in the experts. The people who know the ins and outs of assembly, machine code, and CPU microcode, still exist. The difference between back then and now is that, like cars, you don't need years of education before you can comfortably use the devices anymore.
I too lament the overly complex software ecosystem of today, the simple apps that have grown to hundreds of megabytes, the Javascriptification of our world, but that's not a failure of society. It's what you get when you go for the cost-optimised computing approach that has lead to supercomputers in our pocket rather than the quality-over-features approach that you needed back when people spent more than a year's worth of meals on relatively simple electronic devices.
But it's not specifically about assembly, it's about software design. You can take a modern programming language (say Swift or Rust) and look at how software written with those languages is architected, and the points still stand: abstractions above abstractions above abstractions because people don't understand the lower levels.
People routinely write completely wrong CMakeLists and then complain about CMake being "sooo bad". But give them Meson and they will make a mess as well. People have no clue about packaging and distribution, so they will say "it sucks sooo badly" and will distribute their code as a docker container, embedded in a 6GB Ubuntu image. Most emails you receive just contain a couple lines of useful information, yet they are generated by higher-level systems, full of HTML and bullshit and it's impossible to read in a simple client. Etc.
Software quality is going down year after year, it is a fact. Probably because it is becoming more and more accessible, but the fact remains.
No matter how many times I do it, I'm always re-shocked by the sheer size of email headers from mainstream email providers. Maybe it's a non-issue but just holy god that's a lot of crap that means absolutely nothing to me.
> [...] and then complain about CMake being "sooo bad"
OoOh yeah I'm one of those. I gave the whole heck up on C++ years ago because of the many many interlocking compilers and compiler-compilers and meta-compilers and makers and whatever else is going on. SOOOOO confusing. Like dude I just want to take this code I have right here... and compile it. Such a simple task but first I have to learn 3 layers of compilers and builder and uggggghhhh.
And don't even get me started on "projects" (i.e. in Visual Studio or whatever). "Project" is not inherent to the language, but they don't teach that to beginners. Everything is taught so anti-agnostically.
I just write a few lines in a CMakeLists and compile C++ code, I don't see where you need "3 layers of compilers and builder and ugggggghhhh".
But I see a lot of C++ projects out there that have a mess of CMakeLists and are impossible to compile. When that happens inside my company, I just rewrite the CMakeLists and remove all the mess, and voila. Then guess what? Some other developer suddenly needs to add a dependency, doesn't take 10s to see how I dealt with dependencies and adds 200 lines of mess for their own dependency. And then they complain about CMake.
And I have actually seen that: I "fixed" a project to bring it down to something like 40 lines of CMakeLists for 10 dependencies. The next dev changed that to 250 lines by adding an 11th dependency and complained about CMake. I changed it back to 43 lines for 11 dependencies. I did it in 3 lines, they did it in 210 and didn't even realised they were wrong. You could say "sure, but they learned from the next time". Nope, they did the same mess in other projects.
Bear in mind I was adamant about not using some fancy I-dont-know-whats-happening IDE with their fancy "projects" and "run buttons". Those are just more confusing. I wanted to WRITE CODE, and then COMPILE THAT CODE, and then RUN THE RESULTING EXECUTABLE. With commands.
I found a Reddit post I made [1] when I was trying to learn C++. Maybe it sheds more light on what I was confused about?
- [1]: https://www.reddit.com/r/AskProgramming/comments/uc2p5q/i_kn...
edit: I'm famously (among friends) bad at the beginner stage. I get angry at things that are obviously more confusing than they need to be. Current thing is CloudFlare tunnels. Just like why does it need to be this hard? I have server. I have domain. Just dammit let me slap a pipe between them.
This is not specific to C++, that's just how computers work.
I think it's important to understand that at the lowest level, different hardware works differently. A bit like if you take the pedals from your car and put them on your bike, your bike won't suddenly accelerate when you press the gas pedal. For instance, different CPU architectures have different sets of instructions; machine code compiled for one just doesn't fit in the other.
The programming language is an abstraction. You can write code in C (which can be seen as a standardised set of instructions, I guess) and "compile" it for the CPU architecture you want. The "compiler" is the thing that understands C and translates it to machine code. It is an abstraction itself: you could write the machine code (the bits) manually, but it's easier to write C. The abstraction is here to make it "easier", but it's usually not perfect. When you need very very high performance, it's not uncommon to look at the assembly level.
So yeah, if you want to compile for ARM, you need a compiler that knows how to translate your C into the ARM set of instructions. Now there are "families" of architectures, I guess that's what you mean by "groupings"? Say you build parts for cars. If you build pedals that fit in one car model A, they won't necessarily fit in car model B. But there can be variants of car A: automatic or manual. They have different sets of pedals: the manual one has a clutch pedal that does not exist in automatic. If you build the whole set of pedals for car model A, you have to know about that and provide a set for the automatic flavour and another set for the manual flavour. But if you only build gas pedals, you don't have to care: all the flavours of A have the same gas pedal. Some CPUs share a lot of instructions, but not all of them. Maybe there is a flavour of CPU that provides new instructions that are more efficient for some computations. If you don't care about performance, you can just use the "basic set of instructions", but if you actually want to leverage those efficient instructions specific to that particular CPU... well you have to use a compiler that knows about them.
In C/C++, you can't "make this for all computers". It's not possible to make one binary that works everywhere, just because there are very different systems (be it different CPU architectures, but also just the file format between Windows and Linux for instance). But there are ways to abstract that, for instance that's what the JVM does. Instead of compiling your Java (or Kotlin, Scala, etc) to machine code, your compiler compiles it to JVM bytecode. That's an abstraction again. Bytecode is just code that the JVM can run with. And this "works everywhere" in the sense that "it works as long as you have a JVM that can run it". But there are tons of different JVM binaries, because you can't just make one that runs everywhere. It's just that someone built a JVM for your machine, so that now you can run any JVM program on it. But the JVM itself is very much not portable.
It's all about abstraction. If you work in Javascript or Python, you may never have to know about anything that's happening below, because you live in your nice abstraction level. But as soon as you want to compile a native binary, you have to go down the abstraction layers and start understanding more of what's happening. It's not a C++ problem: you can compile Kotlin code to a native binary and you'll have the same problems. Same for any language that compiles to a native binary.
> I get angry at things that are obviously more confusing than they need to be.
Are they obviously more confusing than they need to be, or is the world just more complicated than one might expect? Computer are extremely complex machines. If something is easy, that's because you're staying at a comfortable abstraction level (with all the limitations that come with it).
I hope this helps.
I think this conflates a few issues.
I believe you that some people have problems with both CMake and Meson.
But in my opinion CMake's scripting language really is pretty poorly suited for it's role, e.g. because of its blurry distinction between strings and lists.
The vast majority of projects only need a handful of features from CMake. Sure, it's a weird language and there is enough to criticise. The fact remains that 99% of the complaints I see are from people who write very bad CMakeLists. First learn how to not make a big mess with it, and then you can start complaining, IMHO.
I have had that with other technologies that "everybody hates but is forced to use". The technology is never perfect, so there are always reasons for criticism. But I see a lot more invalid criticisms from people who don't use the technology correctly than valid ones.
Because Javascript is not perfect does not mean that the developers can't possibly be responsible for a bad Javascript codebase.
As a software engineer in his mid-30s now, I can assure you many "older people" will have little-to-no memory of messing around with assembly and electronics. When I was getting started, my boss told me about an engineer who had a deep knowledge of how to lay out data to efficiently read and process it. My response? "I just stick it in Postgres and it does it all for me!" No shade to that engineer but I do believe he was in his 50s/60s at the time, so it's quite likely he's retired on a decent pension by now!
My point is that because the author uses assembly as an example does not mean that their points are not valid.
I just think it's a reductionist view and one that's not necessary. Practical example: beyond reading SQL ANALYZE, I have no idea how Postgres organises and queries data beyond a rough understanding of the model that it exposes. I guess I'm not a "real engineer" because I couldn't tell you how that data is laid out on the disk for efficiency. Yet I'm generally able to write pretty performant data models and query it.
I know engineers who can't even do that, yet their knowledge of DOM and browser logic is so fucking insane, they fixed a shitload of longstanding issues in our product. Where is the line on them being "real engineers?" Is that good enough, or do they need to go deeper into the browser?
I know engineers who don't have that level of depth in either, yet they're consistently able to write bug-free code that's extremely well tested. Do they understand how Python bytecode works? No, they don't have a clue (frankly, neither do I). Yet they solve every problem in their space.
- You have enough experience to agree with the post but feel like writing such a post won't change anything, or
- You are more of a junior and don't understand what the author means because you've grown up with the engineering quality we have today.
Given that you consider this to be "so-so-so many words", I would bet it is the second option. Older people wouldn't consider that this is a huge text.
Am I right? :-)
I wish there was a somewhat rigorous way to quantify reliability of tech products so that we could conclude if tech on average was about as buggy in the past.
I mean I also feel that things are more buggy and unreliable, but I don't know if there's any good way to measure it.
Another thing is that today, you receive updates. So bugs get fixed, new bugs get introduced, it makes it harder to track other than "well, there are always bugs". Back then, a bug was there for life, burnt on your CD-ROM. I'm pretty sure software shipped on CD-ROM was a lot more tested than what we deploy now. You probably wouldn't burn thousands of CD-ROM with a "beta" version. Now the norm is to ship beta stuff and use 0-based versioning [1] because we can't make anything stable.
Lastly, hardware today is a lot cheaper than 25 years ago. So now you buy a smartphone, it breaks after a year, you complain for 5min and you buy a new one. Those devices are almost disposable. 25 years ago you had to spend a lot of money on a PC, so it had to last for a while and be repairable.
[1]: https://0ver.org/
Flash forward to today. I can't remember the last time I replaced an ignition system component. I still don't know how they work. I can guarantee that the techs who do occasionally replace them at the dealer don't know how they work. But the whole system is so much more reliable.
That said, I do wonder how young people are supposed to learn and gain understanding in a world where they cannot possibly understand the components in complex systems. Back in the day (I know, yelling at a cloud), I could actually understand how a set of points and a distributor -- or a even a three-transistor radio -- worked.
My comparison points: Fallout 3 being a shitshow of bugs on release vs Final Fantasy 7 Remake & Rebirth feeling practically bug-free on release. In fact, I don't think I hit any bugs in Final Fantasy 16 either.
Same for "you haven't touched your game console? here's 200 gigabytes of updates at 200kb/s"
This... This is quite quantifiable
I've been thinking about this; I suspect that a lot but not all of "planned obsolescence" comes down to not acting on a flaw, that aligns with your interest, as it appears. Can that be thought of as deliberate?
It's a trolley problem kind of question I guess.