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.

In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme -- it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that's all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.
But programming now isn't so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.

I have learned a lot of programming languages and techniques over the last 40 years or so, but it’s become almost impossible to learn how to make things with computers, no matter how much you already know, unless you spend all your time doing so.

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:

incoming(4): webhardwareengineeringresearch

• disposable plastic crisis
• spectre and the end of langsec
• international lisp conference day two

Last update on 7E540A, edited 2 times. 2/2thh