Many of the underlying problems and solutions exist for decades. Database systems you mention are a good example of this.
While there are some key concepts to things like databases, the fact remains that your 1985 database would not be considered sufficient in todays world: It would have too many limitations, lack features we now take for granted, would not scale to modern data requirements, etc. Supporting all that "modern" functionality is non-trivial and requires a huge amount of effort. You can't just say "Well, we figured out space and computationally-efficient hashing, so relational databases are well on their way to being feature-complete"
There's a reason we haven't stuck with 1.0 on our platforms, and it's not just security or a desire for a bigger version number: New demands required new functionality and new ways of building things.
iOS was basically AppKit, so anyone already developing for the Mac knew most of what they needed to know to develop for iPhone.
Pretty much every programming innovation is incremental, and doesn't require throwing out all of your previous knowledge and starting over.
Maybe. But AppKit was not the Mac Toolbox.
When my career began being good at memory management was a skill to be proud of. I would say now, being good at concurrency is a skill to be proud of.
I don't really have to worry about memory management any longer but didn't worry about threading when I started my career.
As I see the younger generation entering the programming field I wonder in what ways the craft will be different when they've had a few decades under their belt.
Will parameter tuning datasets for machine learning be the coveted skill? Who knows.
But the demand for developing in AppKit suddenly increased by orders of magnitude.
That's the sort of shift in the environment that the grandparent is talking about. Fundamental CS tech was arguably better in the 1970s and 1980s, because it moved more slowly and you had time to get the details right. That doesn't matter if you're building say a mobile Ethereum wallet in 2018, because you're building for the user expectations of today, they don't care about data integrity or security as long as it doesn't fail during the period where they're deciding which tech to use, and software that solves the problem (poorly) now is better than software that doesn't exist.
I believe you are a victim of survivorship bias.
There was plenty of shitty software in the 70s and 80s. The difference between then and now is that we haven't been able to wait for 4 decades, to see what software of 2018 stood the test of time.
In the 1980s there was a lot of "foundational research" (poorly re-inventing the wheel) for microcomputer people who did not know about the work done on large computers in the 1960s. Move fast and break things was also very much a thing for microcomputer manufacturers and most microcomputer software vendors. Look at how many releases software packages went through, and at what rate.
That has always been the case and is about as good a one-line summary of the software industry as I can think of.
The "modern" database systems are now going back to the exact design principles that the books you refer to solved long time ago. There is tons of research, dissertations,.. that focuses on this from decades ago.
Its just now that the new systems realize that these problems actually exist.
If you dont know the history of a certain field and what came out, you repeat and make the same mistakes again. This seems to also apply to software engineering.
A great example of this is the evolution of FB/Google/Amazon. Portions of their core tech have been completely re-written over the years for marginal gain, but there is a large premium to being the best in tech.
In other parts of the industry every new cycle enables some new area of tech, and those marginal gains become the minimum bar for entry. e.g. Deep Learning and Computer Vision, distributed systems and cloud computing/SaaS.
Haha in 1985 Amiga had a multitasking GUI desktop in 512k and 7Mhz. Now we have millions of times more computational power and struggle to deliver an experience as crisp and satisfying.
I wish people still made software like it was 1985, that actually used the full power of the hardware for something useful...
- No process or kernel security (processes could rewrite kernel code)
- Processes could effectively disable the scheduler
- Supported only a single, fixed address space: both a massive limitation and a performance hack that made the system bearable to use
- Single-user
- No security model
There are embedded applications these days where not having these features are deak-breakers. Let me assure you: if you re-implemented the original Amiga OS feature set it too will be screaming fast. The tricky part is keeping it fast once you start adding protection and additional functionality on top of it.
And largely what happened when you tried to implement more complicated applications on top of these primitive systems is that they would crash the entire system, constantly.
Well the PC wasn’t backward compatible with CP/M so that’s an odd critique to level at the Amiga.
Backwards compatible didn't matter in the mobile world, or for those screaming for ARM laptops.
Sometimes we can't just have nice things.
That’s chicken-and-egg. Why do modern apps with actually quite simple functionality need all this vast power, the GHz and Gb? Because it’s there. Why does software crash? Because the OS let’s it with nothing more than inconvenience to the user.
Amigas were actually quite usable, they were stable enough for complex software to be developed and real work done. Same for ST’s.
so, your software concepts from 85 would be overkill today, not lacking.
Today I'm working on systems with memory latencies from l0 cache all the way to tape storage. And it's getting worse.
Edit:typo
Also modern non-indie games are orders of magnitude larger and intricate than 80's games, and have about the same distrubution of quality/bugs. They're now made by teams of size 10-1000 rather than 1-10 though.
There was one variation of Windows in 1985. (And I remember installing it!)
Still, in 1985, even DOS apps had to target varied environments: mono, CGA, EGA, Tandy graphics, different memory configurations, 8088 or 286, printer drivers...
I wish it inched upward... So much software now-days is bloated crap.
Our industry has its share of cycles, but this, in my view, is largely wishful thinking on the part of people. Nothing wrong with optimism but...
Every 5-10 years there's a "technical shift" that forces everyone to reevaluate how they build software or more importantly what they build, and the race starts all over again. The ice block is removed from the hot plate is replaced by a bigger, colder block of ice. And when these technical shifts aren't taking place, the bar for what constitutes as "good software" inches upward.
If your standards for acceptable software were frozen in time in 1985: using modern hardware and software toolchains, you could accomplish in one day what used to take a small team an entire month. But if I delivered, say, what passed for a "good enough" database in 1985, it would resemble someone's 200-level CS final project rather than a commercially-viable piece of software.