Systems Past: the only 8 software innovations we actually use

Systems Past: the only 8 software innovations we actually use

Interesting post and he makes a good point:

I find that all the significant concepts in software systems were invented/discovered in the 15 years between 1955 and 1970. What have we been doing since then? Mostly making things faster, cheaper, more memory-consuming, smaller, cheaper, dramatically less efficient, more secure8, and worryingly glitchy. And we’ve been rehashing the same ideas over and over again. Interactivity is now “event-driven programming”. Transactions are now “concurrency”. Internetworking is now “mesh networking”. Also, we have tabbed browsing now, because overlapping windows were a bad skeuomorphism from the start, and desktop notifications, because whatever is all the way in the corner of your screen is probably not very important. “Flexible view control” is relegated to the few and the proud who run something like xmonad or herbstluftwm on their custom-compiled GNU/Linux.

in particular, maybe it’s time to bring more of what academia is doing out into the industry. For example, all the benefits of Haskell and type inference should be in mainstream languages (Rust is trying to do that, Go kinda failed). Another example is modeling, people are still modeling by either drawing boxes and sticks or by coding up small prototypes. Why not try out a modeling language like Alloy? Why not have more contract-based programming?

I think what we need is software devs looking at the bigger picture whenever they’re on a project. I don’t mean trying to bundle everything into a framework (which we see happening with front-end JavaScript development), but keeping in mind that some of the concepts can be used to solve harder problems. If the enterprise is building CRUD apps or transforming data from one format to another, there must be some other problem in there that needs solving, a deeper problem that can’t be solved with yet another framework but needs a new way of thinking or a new algorithm or data structure. Maybe it’s time to clamp down on the other parts of the dev process, like poor management or poor business practices that lead to failure in the development process. Or maybe we just need people to work on better projects where their talents can be harnessed, let the junior devs worry about yet another CRUD app and let the senior devs and chief architects bridge the gap between academia and industry.

Comments are Closed