Research into software and programming languages.
The software industry is currently going through the “disposable plastic” crisis the physical world went through in the mid-20th century (and is still paying down the debt for). You can run software from 1980 or 2005 on a modern desktop without too much hassle, but anything between there and 2-3 years ago? Black hole of fad frameworks and brittle dependencies. Computer Archaeology is going to become a full-time job.- flussence comment on lwn
The abstraction problem
Modern software has an overgeneralization and overabstraction problem. In order facilitate speed of delivery, most aspects of the machine/OS/programming language have been engulfed in abstractions. This has been done under the driving idea that the abstraction/compiler/garbage collector can handle all of this messy stuff and often do it better than programmers. All this abstraction has produced a split between people who want to do increasingly sophisticated things with abstractions (virtual regime) and people who want to do increasingly sophisticated things with actual machines (actual regime).
The virtual regime is the current popular approach to developing software. This is evident in the focus most introductory courses place on learning about languages rather than about machines. Most methodologies related to programming are similarly abstraction focused rather than runtime execution focused. If you think software under the virtual regime has been getting slower, there's plenty of evidence you're right. The abstraction fueled disconnect between programmers and their environments seems to be producing bloat. Some examples:
- The Facebook application has over 18,000 classes and weighs in at ~100MB, a large portion of which is executable binary not assets
- Slack made news by being less bloated and slow.
- Unity has a whole team working on a tech stack to fix language/abstraction induced issues.
Game developers notice the problem
Game developers seem to have been the first to notice many of these issues since they are usually the folks tasked with maximally leveraging existing hardware. Mike Acton gives an early exasperated expression to these ideas here:
Jonathan Blow solidifies some of these insights:
Last update on 7E4B15, edited 1 times. 1/1thh