3 ms·
> It's mind boggling that they are just now waking up It's nothing unusual. Software engineering as a field moves at a glacial pace. I see two reasons for this
by klibertp 4y ago
> It's mind boggling that they are just now waking up
It's nothing unusual. Software engineering as a field moves at a glacial pace. I see two reasons for this: one is that people don't want to learn anything radically different from what they know already, so you need generational change for new ideas to have a chance to come to fruition. It's a 10-20 years cycle. Then the other reason is that we basically don't know what we're doing, and so some of the new ideas are terrible in practice, reinforcing the first reason. How long did it take for mainstream languages to start seeing `null` as a problem and getting Option types? Depending on who you ask, it'll be 20-30 years; Haskell and other MLs had it either from day 1 or after inventing monads and Maybe (I'm not sure here), and Haskell introduced monads in early '90s. So it's at least 20 years since then, and yet we still have NullPointerExceptions here and there...
- maccard 4y ago> Software engineering as a field moves at a glacial pace. What other industries have you worked in that move faster than software? My experience is that the rate of change is so high and fast in so many areas it's impossible to keep up. Meanwhile in other industries version control still hasn't even gotten as far as track changes in word!
- klibertp 4y ago> My experience is that the rate of change is so high and fast in so many areas Yes. The rate of change is very high. Real, actual improvements, however, are very rare. Most of the code written today in Python - my field of expertise - is written almost exactly the same way it was since 2.4, when I started using it. C10k problem[1] is known for 20+ years already, yet Python only recently got async/await - a proven, very old technique often used for addressing the problem. I learned Rust earlier this year, and they also introduced async/await very recently. pg wrote about the technique in his "On Lisp" sometime in the '90s, so it probably was well known way before that. Scheme and Smalltalk, having reified call stacks in their respective ways, supported concurrency with lightweight threads since '80s. Now you hear about Crystal introducing fibers and how great they are. Yes, they are - and were, for the past 40 years. Rediscovered, and reimplemented, again, because nobody cares about the history of the field, everyone just wants to build their own thing, and solving puzzles is more fun than studying and then standing on the giants' shoulders. Yes, git is a nice VCS, but to be honest - Subversion wasn't that bad, either. NetBSD still uses CVS for versioning and developing its packages. Yes, being able to work without a central server is an improvement, but then again: everything is hosted on Github, a central server, anyway. Some terminal emulators experiment with displaying inline images. The new ones, Kitty and its ilk. First, they try to improve the protocol designed for teletypes in the '60s (IIRC), then they give up and introduce non-standard extensions, which limits their reach and usefulness. But then again, Kitty is hardly the first attempt - IPython qtconsole is also ~15 years old, and a decade before that TCL tried the same thing (with some success I hear). One possible solution to the expression problem, namely multiple dispatch / multimethods, is a selling point of some new languages, like Raku, Nim, Clojure, and of course Julia. Multimethods are known since the '70s, too, yet not even one mainstream language has them as a feature. There's a lot to be said about the churn on the Web, and I don't want to go there, but from the outside perspective, the only real change that happened sometime in the last decade was Let's Encrypt becoming CA. IPv6 adoption is the same as always, and we still need NAT traversal techniques that we used in the '90s. Other than that, everything people do with JavaScript was already done and tested decades ago. I mean, virtual DOM? That's basically what X windows are, and every other GUI out there does it, with invalidating objects and redrawing only obscured/damaged parts of an object, with double buffering to avoid flickering. The shadow DOM and web components - though I've no idea how widely they are used - make the same promise that vendors made when shipping widgets as DLLs to Object Pascal, later renamed Delphi. The only real progress, other than adopting HTTPS everywhere, was ditching Flash, ActiveX and Java applets. It really tells a lot that the most impressive progress happened because of removing something instead of adding. There's a lot more. I don't want to dismiss the great work of a great many fabulous programmers. The progress is happening at all thanks to them. The average developer, however, is average, and does not have knowledge and skills to write something actually game-changing. They try all the time, though, because it's fun, and then the hype and mob mentality takes over on social media. You could say that machine learning was a great development, but then again - neural networks were described in the '70s. It just so happened that massively parallel GPUs were a good way to speed up otherwise very demanding computations. Computation, might I add, mostly done in Fortran (blas, lapack), to this day. I don't want to dismiss the progress we're seeing. I just wish programmers would actually, seriously study the history of our field before going off to create yet another framework. Despite being short, the history of our field is littered with incredible amounts of prior art, and improving upon that should be the goal, I think, not "rethinking and reimplementing" everything from scratch every 10 years. EDIT: I forgot to answer your question: I only worked with software for all my life, I can't say anything about any other field. Most of them, though, have centuries or millennia of history, and they seem to efficiently manage that legacy, turning it into productivity. Maybe there's less objective need for change there, or in some cases the change is impossible due to regulations? Fields that came into being due to the IT revolution seem to be similarly stuck in change-without-progress cycles. Some social activities are like this, too. It might be simply a feature all young fields have. I'm guessing a lot of early airplanes crashed, some of them because of problems that were solved already elsewhere, but without anyone else knowing. The number/rate of failed software projects is staggering, just as a lot of early flying ended with a crash. I'm not sure there's a meaningful correlation, and I'm way outside of my expertise when talking about planes, but I can't help seeing our field as immature and moving very slowly forward. The blessing in disguise is that this time around, failed project doesn't often mean someone died. [1] https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem