3 ms·
I believe the pace of change has actually increased recently. As Hague himself has noted, we have a lot of computing power to throw around now. 30 years ago, se
by chipsy 14y ago
I believe the pace of change has actually increased recently. As Hague himself has noted, we have a lot of computing power to throw around now. 30 years ago, serious usage of academic languages was still restricted to "big iron" environments; today you can expect any language to do some useful work even on a smartphone. As a result we can make "softerware" that benchmarks less well, but is massively cheaper to make and maintain.
As well, there's been a cultural shift related to the hardware changes. In webdev it's become routine in some circles to make polyglot systems, or to cross-compile between different languages or runtimes. DSLs are increasingly slipping into "everyday" environments. There's a mindshare war going on there, but architecting against one language, one environment, and one toolchain is increasingly seen as the "old way". Similarly, developers who don't know how to architect towards performance increasingly get away with it - it goes hand in hand with the idea of software becoming softer, since that process moves the optimization burden towards the people making runtimes or libraries, rather than the app dev.
All of this favors a faster transition from academia.
- jacquesm 14y ago> There's a mindshare war going on there, but architecting against one language, one environment, and one toolchain is increasingly seen as the "old way". That old way is there for a reason: maintenance. If you write throw-away software (and most websites, especially the front end stuff are) then this is not a problem. But if you're supposed to support your creation for the next 15 years then having a stable toolset really pays off. The smaller the project and the shorter lived it is the more corners you can cut.
- betterunix 14y agoAt this point, there are better technologies that are stable. My language of choice, for example: https://en.wikipedia.org/wiki/Common_lisp https://en.wikipedia.org/wiki/Common_lisp
- chipsy 14y agoNo, that's still making the assumption that all worthwhile solutions are balls of mud, leading to "freeze it in time" as the only sane option for preservation. That's cultural, not inherent to the technology. If every part of the stack is tiny and connected via common, documented protocols you have ample room for maintenance. That's easily validated by the Internet as a whole (and not the Web, which was burdened by its early design). A present-day "throw-away" that can do more than in the past is, more likely than not, leveraging a bigger and more decomposed software ecosystem, where bits of infrastructure can get remixed more readily. Pooh-poohing the results by saying "they solved a trivial problem" dismisses this underlying trend - tools and services that are currently "weekend hack" or "prototype only" have a habit of turning into tomorrow's "production-grade" if they gain substantial adoption. There's no particular reason we can't achieve Internet-scale maintainability for all problems, other than it taking time to build protocols of the right size/complexity for every problem domain.