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.
https://x.com/WallStreetApes/status/1940924371255939236
Our software is like that. A small system will have a crazy number of packages and dependencies. It's not healthy and it's expensive and it's stupid.
Culture tends to drive drunk, swinging wide to extremes and then over-correcting. We're already fully in the wrong lane when we start to have discussions about thinking about the possibility of change.
https://www.youtube.com/watch?v=5ODzO7Lz_pw
It's not a software thing, it's just how humanity works.
The physical world is bound by rules that are unchanging (more-or-less). Above this layer we’ve also devised and agreed upon standards that remain unchanging, though it’s regional: Voltage, screw/bolt sizes, tolerance levels, materials, material measurements, etc.
At this layer, we’ve commoditized and standardized because it’s useful: It makes the components cost-effective and predictable.
In software and computing, I can only think of the low-level networking standard that remain stable. And even that has to be reinvented somewhat for each OS or each nee language.
Everything else seems to be reinvented or rewritten, and then versioned.
Imagine having to upgrade your nuts and bolts in your car to v3.01 or lose support?
Ingredients in the cookies? Yes. 100? No.
There's an education gap that needs to be addressed, but I don't know how it will get addressed. A lot of the web in the past few decades came from industry so industry had a way of training up people. Most of this ML stuff is coming from academia, and they aren't really the best at training up an army at all.
It's hard to know who to blame for all of this because it's kind of like not having an early warning asteroid detection system. HN or various communities did not have discussions even five years prior to GPT about the impending doom (no early warning at all). If you just take HN, we sat around here discussing a million worthless things across Rust/Javascript/startup b.s for years like headless chickens (right here on the frontpage) without realizing what was really to come.
Makes me wonder if the places I go for tech news are enough to be prepared. Which brings me back to what I quoted:
We’re creating a generation of developers and engineers who can use tools brilliantly but can't explain how those tools work.
We aren't creating them. They are the existing devs that had no idea AI was going to be a thing. Had anyone known it was to be such a thing, everyone would have ditched going to web development bootcamps in the mid 2010s.
edit: lol
My Vectrex still worked last I checked.
Kind of a weird opposite meaning of book-burning.
This is like saying old software is so simple that updating a line of code can break an entire application. It's a silly thing to say. No matter how complex or how simple a piece of software is, you can easily break it. If you have a program that prints out "hello world", guess what? Updating a single character can break the entire application!
The world is more complex now. We've stood on the shoulders of giants who stood on the shoulders of giants. A few centuries ago a renaissance man could make advances in multiple fields. Now people are specialized. It's the same thing with software. Of course, people take it to an extreme. However, you go ahead and write your own crypto library, I'll use a vetted one created by experts.
Now if npm breaks it, or Claude breaks it, a developer might not even know what was broken.
He's talking about that kind of thing, not the resilience of code to take random character deletions.
IT is very much non-specialized compared to older disciplines. It's so young. Every single one of us is still a jack of all trades in some degree.
You're relying on the "don't roll your own crypto" popular quote to drop the mic. That's misguided. This advice comes from an argument of strength by numbers, not anything related to abstractions. It tells me you don't understand it.
To lend some credence to other folks points of view, there are arguments I can agree with that are adjacent:
- "We don't need that complex framework for our needs, we stick to a simpler, older library."
- "We decided to not use <shiniest_new_toolkit> it had performance issues that the maintainers are still sorting out."
- "Working with the new framework showed a lot of promise, but there is still a lot of instability in the API since it's so new. We couldn't commit to using a toolkit that hasn't been nailed down yet."
These are actual concerns and shows caution towards adopting new things until they match your use-case, dev-timelines, and performance requirements.
“I don’t have time to learn a new framework, I have things to do.” Everybody’s cool new abstraction is a cognitive burden for someone else.
Slightly OT: It's interesting how many (smart!) people in tech like the author of this article still can't conceptualize the difference between training objective and learned capability. I wonder at this point if it's a sort of willful ignorance adopted as a psychological protection mechanism. I wonder if they're going to experience a moment of severe shock, just gradually forget that they held these opinions, or take on a sort of delusional belief that AI can't do XYZ despite all mounting evidence to the contrary.
LLMs' initial training is specifically for token-prediction.
However, this doesn't mean that what they end up doing is specifically token-prediction (except in the sense that anything that generates textual output can be described as doing token-prediction). Nor does it mean that the only things they can do are tasks most naturally described in terms of token-prediction.
For instance, suppose you successfully train something to predict the next token given input of the form "[lengthy number] x [lengthy number] = ", where "successfully" means that the system ends up able to predict correctly almost all the time even when the numbers are ones it hasn't seen before. How could it do that? Only by, in some sense, "learning to multiply". (I haven't checked but my hazy recollection is that somewhere around GPT-3.5 or GPT-4 LLMs went from not being able to do this at all to being able to do it fairly well on moderate-sized numbers.)
Or suppose you successfully train something to complete things of the form "The SHA256 hash of [lengthy string] is "; again, a system that could do that correctly would have to have, in some sense, "learned to implement SHA256". (I am pretty sure that today's LLMs cannot do this, though of course they might have learned to call out to a tool that can.)
If you successfully train something to complete things of the form "One grammatical English sentence whose SHA256 hash is [value] is " then that thing has to have "learned to break SHA256". (I am very sure that today's LLMs cannot do this and I think it enormously unlikely that any ever will be able to.)
If you successfully train something to complete things of the form "The complete source code for a program written in idiomatic Rust that does [difficult task] is " then that thing has to have "learned to write code in Rust". (Today's LLMs can kinda do some tasks like this, and there are a lot of people yelling at one another about just how much they can do.)
That is: some token-prediction tasks can only be accomplished by doing things that we would not normally think of as being about token prediction. This is essentially the point of the "Turing test".
For the avoidance of doubt, I am making no particular claims (beyond the illustrative ones explicitly made above) about what if anything today's LLMs, or plausible near-future LLMs, or other further-future AI systems, are able to do that goes beyond what we would normally think of as token prediction. The point is that whether or not today's LLMs are "just stochastic parrots" in some useful sense, it doesn't follow from the fact that they are trained on token-prediction that that's all they are.
If the thesis is that we should understand the systems we work on, then sure, I can get behind that. At the same time, I wouldn't expect a mechanic to know how to process iron ore into an ingot.
They definitely don't "vibe machine" without thinking about underlying concepts.
The methods and algorithms powering advances in modern science, medicine, communications, entertainment, etc. would be impossible to develop, much less run, on something so rudimentary as a TI-99/4A. The applications we harness our technology for have become much more sophisticated, and so too must the technology stacks underpinning them, to the point that no single individual can understand everything. Take something as simple as real time video communication, something we take for granted today. There is no single person in the world who deeply understands every single aspect, from the semiconductor engineering involved in the manufacture of display and image sensors, to the electronics engineering behind the communication to/from the display/sensor, to the signal processing and compression algorithms used to encode the video, to the network protocols used to actually transmit the video, to the operating system kernel's scheduler capable of performing at sufficiently low-latency to run the videochat app.
By analogy, one can understand and construct every component of a mud hut or log cabin, but no single person is capable of understanding, much less constructing, every single component of a modern skyscraper.
He's criticizing the act of _not building_ on previous learnings. _It's in the damn title_.
Repeating mistakes from the past leads to a slow down in such advancements.
This has nothing to do with learning everything by yourself (which, by the way, is a worthy goal and every single person that tries knows by heart that it cannot be done, it's not about doing it).
And the ones who can design a op-amp circuit can't manufacture the laminate their circuit is going to be printed on. And the ones who know how to manufacture the laminate probably doesn't know how to refine or synthesize the material from the minerals. And probably none of them knows how to grow and fertilize the crop to feed themselves.
No one knows everything. Collaboration has been how we manage complexity since we were biologically a different species than H. sapiens.
https://www.youtube.com/@AppliedScience
If he can, what's stopping you?
There are extraordinary people doing extraordinary things all around you. Aiming for these things is important, and we need those kinds of people with ambitious learning goals.
Before, you said people _can't_ (in general, anyone that knows how to code cannot possibly learn how circuits work).
Now, you're saying that _you don't want to learn_. That's on you, buddy. Don't project your insecurities on the whole IT field. People can, and will, learn across many layers of abstraction.
I think I made an excellent counterpoint that is not against specialization, but complementary.
This counterpoint is particularly important in an age where specialization is being oversold and mixed with snake oil.
People can learn across layers of abstraction, but specialisation is generally a good thing and creates wealth, a Scottish guy wrote a good book on it.
> That is because you are replying to two different people.
He chose to follow the argument of the previous dude, so, it's all the same for me. Everything I said still applies.
The Little House on the Prairie books fictionalize the childhoods of Laura Ingalls Wilder and Almanzo Wilder in the US in the late 19th century. They expected their readers, whose grandparents had grown up in similar conditions, to believe that one or more of their parents knew how to shoot a bear, build a house, dig a well, poultice wasp stings, cast bullets, fertilize and grow crops, make cheese, whitewash walls, drive horses, run a business, read a book, play the fiddle, dance a jig, sing, keep bees, clear fields in forests, harvest honey, spin thread, weave cloth, thresh wheat, and many other activities. There were "store-bought" goods produced by the kind of specialization you're talking about, but Laura's family had a few durable goods of that sort (Pa's rifle and ax, the family Bible) and mostly they just did without.
More recently the Lykov family survived 40 years of total isolation from society, missing World War II completely, but did suffer some heartbreaking losses in material standard of living because they didn't know, for example, how to make ceramic or iron. Agafia Lykova is still living there on her parents' homestead, nearly a century later.
Specialization is indeed very efficient, but that answers the questions, "What can I do for others?" and "How can we survive?" Historical answers bespeaking specialization are archived in many of our surnames in the West: Cooper, Fuller, Goldschmidt, Herrero, Nailer, Roper, Molnar, and, of course, Potter.
But for those questions to matter, we also need to answer the questions, "How can I be happy?" and "How can we be happy?", and for thousands of years it has been at least widely believed that devoting your entire self to specialization runs counter to those goals—among other things, because it can open doors to the kinds of exploitation, unfreedom, and insecurity the article is lamenting. And sometimes regional specialization leads not to prosperity for every region but to impoverishment, and regaining the lost skills is the path out of the kind of abysmal poverty that produces regular famines; that's why there's a charkha on the Indian flag.
TI was no exemplar here; you can't even write your own machine code to run on the TI-99/4A, but the situation with Nest is in many ways far worse. I think it's worth distinguishing between situations where someone chooses not to learn about, modify, or repair artifacts, and situations like these where they are not permitted to learn, especially when the prohibition is established in order to exploit them economically, as in both the TI case and the Nest case, or as in medieval guilds.
Some specializations are thousands of years old; tin mining in Cornwall supported much of the Bronze Age, and silicosis was already known as an occupational disease of potters in Classical times. But 80 hours a week breaking rocks in a tin mine is not a path to human flourishing, nor to economic prosperity for the person doing it. Neither is buying thermostats you aren't allowed to understand. We shouldn't idealize it just because it's profitable.
Economic productivity is an important means to happiness, because it sucks to go blind or subsist on soft foods because you can't get the necessary medical and dental treatments. And it's terrible to never see your parents again because you don't have the material means to visit them. But there's a point of diminishing returns beyond which sacrificing more of your happiness for continued economic gains amounts to cutting off your nose to spite your face.
For a mechanical approach to this, see the "Gingery" books which start with the basics of investment casting in the first volume, then using castings to make a lathe in the second (operating on the premise that a lathe is the only tool in a machine shop which can replicate itself), then using the lathe to make the balance of tools needed in a machine shop.
Well no, civilizations like the Maori are the exception, not the norm. Rigid class roles and specialization have featured prominently in essentially every Eurasian civilization from Egypt to Han China, which held the bulk of humanity and uts developments. Nor did questions of individual happiness matter, what concerned people at the times were questions of martial duty or religious worship.
And most people lived outside civilization entirely. They had very diverse lifestyles, but we can make some generalizations. Even when they didnt leave diaries for us to read, we can infer that they had much less specialization, both from economic principles and from archaeological evidence.
It's certainly true that people in civilizations are, and have always been, focused on martial duty, and everyone everywhere is concerned with religious worship, though they may call it something else for social reasons. But people have always been strongly interested in individual happiness, even in civilizations. The Buddha founded one of the most important religions 2500 years ago on the basis of individual happiness, to the point that after he died, one of the most contentious issues among his followers was whether holy people had any duty to help other people achieve happiness as well, the origin of the Mahayana bodhisattva vows. Epicurus's philosophy and Marcus Aurelius's writings are also centered on the pursuit of individual happiness, as is much of Plato and of course the Mohists. Even religions and philosophies that preached lifelong duty and sacrifice above all else, like Christianity and Islam, offer it as a path to individual happiness in the afterlife.
It doesn't work in practice. CS graduates from my school are trained on git and Linux command lines. CE teaches none of this and students discover in 3rd year they cannot get an internship because they share all their code as IDE screenshots in Google Docs.
But we do know how the entire process of building a computer works, from quantum physics, semiconductor doping, npn junctions, CMOS logic, logic gates, hardware design languages, assembly, C, and Java.
If only all of this "important" knowledge didn't crowd out basic skills.
* the EE’s need to learn matlab or numpy, to use as a tool
* so do the computer engineering students, probably
* the computer engineering students also need to learn low level stuff, because they might reasonably end up writing drivers or embedded code
* separating out what should be in which classes is kind of tricky; keeping in mind that the students don’t necessarily know anything about programming at all, you probably need some kind of “intro to the general idea of programming” class
* realistically when they start the program they don’t know much about what the jobs look like, so it is good if they are able to switch paths, for the first couple years
* realistically a lot of people just want to get a stem degree and then go be a programmer anyway
https://ocw.mit.edu/courses/6-001-structure-and-interpretati...
but they've since switched to Python for reasons:
Which CE program did you study at? I've worked with Waterloo, UBC, and UT ECE grads and they have similar levels of knowledge of programming fundamentals as their CS grads. I would be shocked if a first or second year BS ECE cannot use Git or some alternative VCS - that means there are more fundamental issues with your university's engineering curriculum.
> I can design a simple op-amp circuit and deploy to a Kubernetes cluster because Canada has a "Computer Engineering" degree that's a hybrid between CS/Electrical Engineering.
Same in the States, ECE and EECS programs tend to teach both fairly equally, and there are plenty of top programs with a strong reputation in this (Cal, MIT, CMU, UIUC, UT Austin, UW, UCSD, UCLA, GT, etc)
The issue I have noticed though is the decline of "CSE" programs - CS programs with an added CompArch or OS internals focus. CS programs are increasingly making OS internals and CompArch optional at the undergrad level, and it is having an impact on the pipeline for adjacent fields like Cybersecurity, Distributed Systems, Database Internals, etc.
I've harped about this skills gap multiple times on HN.
As a farmer and software developer, with a electronics hobby (and it being a part of the job of being a farming these days), I can check off growing crops, op-amp circuits, and Kubernetes deployments.
I don't own, or have reasonable access to, the necessary capital for laminating circuit boards and synthesizing minerals.
> No one knows everything.
But, really, access to capital is the real limiting factor. Getting to know something isn't usually all that difficult in and of itself, but if you have no way to do it then you're never going to get to know it. Collaboration is less important to efficiency than optimizing use of capital. Its just that we don't have many good ideas about how to optimize use of capital without also introducing collaboration.
You don't have to know everything but BASIC understanding about the what is underneath would be nice.
> To take an example, therefore, from a very trifling manufacture, but one in which the division of labour has been very often taken notice of, the trade of a pin-maker...a workman not educated to this business...could scarce, perhaps..make one pin in a day, and certainly could not make twenty. I have seen a small manufactory...where ten men only were employed...Those ten persons, therefore, could make among them upwards of forty-eight thousand pins in a day.
- An Inquiry into the Nature and Causes of the Wealth of Nations, Adam Smith, 1776
When you divide and specialize design, you get design by commitee.
If you design a desk lamp, it wasn't designed by a committee just because a person designed the screws, another designed the plate stamping machine, another designed the bulb socket and etc.
In your counter-example, the design was not divided, and thus it is not a counter-example at all.
The lamp design clearly was divided -- the final designer did not design the screws, lightbulb, wiring, and perhaps many other components. Someone had to design those components that were then combined creatively into a lamp.
Dividing design into components that can be effectively reused is tricky, but it remains essential.
Last week I was learning about Itanium. It was a processor designed specifically for HP. Its goal was to replace both x86 and PowerPC.
HP would design the new systems to run on Itanium, and Intel would design the chip.
There was an attempt at specializing design here, with both companies running on design constraints from another. They formed a design comittee.
This was like the screw company making screws _specifically_ for one kind of desk lamp. It's division and specialization of design.
A natural specialization (one company gets very good at designing some stuff) is not divided, or orchestrated by a central authority.
In manufacture, it's the other way around. If you already have a good design, the more divisions alongside a main central figure, the better. You can get tighter tolerances, timing benefits, etc.
My argument is that these aspects are not transferrable from one concept to another. Design is different from manufacturing, and it gets worse if we try to apply the optimizations we often do with manufacturing to it.
If you start designing hardware for AI, together with AI designed to run just on that hardware, and tie those design cycles together, you'll get a design by commitee. It is very likely that requirements will make an overall bad hardware (but slightly better for AI), and an overall bad AI (but slightly better in some hardware).
Eventually, these shortcuts lead to huge commitees. Sometimes they're not even formally defined.
The screw company should make good screws, not good screws for a specific desk lamp model. A good designer then _chooses_ to use those screws _because they are good_, not because they can make specific design requirements to the screw company.
>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.
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?
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.
This is called “good journalism”. It would be great if Elektor tried practicing it.
This UI trend of denying access to under-the-hood complexity is deeply unsettling. It creates a cliff edge failure mechanism where the system (which often is essential) works and then suddenly doesn't. No warning approaching the failure state, no recourse on the far side, completely baffling how this became an industry standard.
now we are actually employing large numbers of people just to babysit these half-assed things, and everyone is fine with it because we all used 'industry standard' components, and thats really the best we can do isn't it. armies of on-call system resetters are just part of the picture now.
Just yesterday I used an LLM to write some docs for me, and for a little bit where I mistakenly thought the docs were fine as they were (they weren't, but I had to read them closely to see this) it felt like, "wow if the LLM just writes all my docs now, I'm pretty much going to forget how to write docs. Is that something I should worry about?" The LLM almost fooled me. The docs sounded good. It's because they were documenting something I myself was too lazy to re-familiarize with, hoping the LLM would just do it for me. Fortunately the little bit of my brain that still wanted to be able to do things decided to really read the docs deeply, and they were wrong. I think this "the LLM made it convincing, we're done let's go watch TV" mentality is a big danger spot at scale.
There's an actual problem forming here and it's that human society is becoming idiocracy all the way down. It might be completely unavoidable. It might be the reason for the Fermi paradox.
This seems like a pretty weird example, right? WiFi routers don’t connect to the internet. If your modem can’t connect to the internet, something has probably broken outside your house. That’s the sort of locally-unsolvable problem that everybody last century was familiar with; the crappy copper telephone wire that was never designed to let the Internet blast through it and it will eventually rebel and start giving you noise.
If your router doesn’t work, I don’t know. Cheap routers are not a new invention or sign of the times, I think.
VHS players, if I remember correctly, often died in mysterious ways (they have all sorts of little motors and finicky sensors in them).
When I used to use Google Wifi, it regularly struggled to connect or establish/maintain connectivity to the outside world, even though my modem was successfully connected. Similar to nest devices, you often have to power cycle them several times to get them into a good state
This idea that we don’t understand the internals of anything anymore and nothing is reliable is a mix of nostalgic cherry-picking and willful ignorance of a lot of counter-examples.
Sure, a bunch of consumer appliances are nebulous, but they are designed for those tradeoffs. It’s not like your old VHS player was designed specifically to be easy to repair either.
The author is complaining about their of advanced networking feature breaking on a router intended for consumers. Why they haven’t upgraded to a prosumer setup is a mystery - OpnSense on a mini PC combined with some wireless access points is one way to go that offers a lot more configurablility and control.
Complaining that not everyone can understand low level hardware is ignorant of all the really cool low level hardware and maker communities that have exploded in recent years, and it’s ignorant of the fact that specialization existed back in the “good old days” as well. For example, we had separate transmission and body shop specialists in the mid-century, you couldn’t just go to any mechanic to fix any problem with your car.
I’d like to see someone in the VHS era design a printed circuit board using CAD software and get it printed on-demand, then design an enclosure and 3D print it in their house for pennies. You can design your own keyboards and other electronic gadgets and basically own a little factory in your own home these days. You can share designs with ease and many of the tools are open source. The amount of sophistication accessible to the average person is incredible these days.
Romans tremendously progressed, despite using inferior "math" compared to the Greeks, and Americans compared to the English & French. Note how willingly China ships its top mathys to the US grad school while retaining its best engineers at all costs.
Only technologies that make it into tools/hardware (realware) will survive, the rest are destined to be e-wasted.
But the ~1980s corporation is no longer and it was driven by the hype cycle too, it's just not a recognizable one. You can google the adverts or read Soul of a New Machine.
floppyd•3h ago
worldsayshi•3h ago
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.
troupo•3h ago
This... This is quite quantifiable
ipcress_file•3h ago
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.
palata•2h ago
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/
scott_w•2h ago
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.
zargon•58m ago
troupo•43m ago
Same for "you haven't touched your game console? here's 200 gigabytes of updates at 200kb/s"
torlok•3h ago
palata•3h ago
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.
scott_w•2h ago
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!
CoastalCoder•2h ago
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.
MountainMan1312•1h ago
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.
palata•3h ago
- 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? :-)