I'm sure there are other factors that contributed to them falling out of use, or being forgotten. What little I know about what affected this comes from some historical commentary I've read from someone who was a computer science researcher during this period that Victor discusses.

Computer science was a small field of research that began as an aspirational goal in the 1960s. Electrical engineers, mathematicians, even psychologists were invited to explore the possibilities of it, wherever their curiosity would take them. It started within an academic community, and it pretty much remained the province of academics for 15 years. That began to change with the popularization of personal computing in the late 1970s, and early 1980s. More and more, computing and computer science became the province of a lower quality outlook, of hobbyists who hadn't read much, if any, of the computer science research that had already been done; who were more interested in what they could show their friends, or could sell quickly into a market that saw the computing phenomenon more as magic than as a medium for discussing powerful ideas.

The main reason this popularization effect shut out these other languages is the computing power in the early microcomputers was so small that they couldn't accommodate what these more powerful languages could do. A lot of the programming that was done on them was in assembly language, because that was the only way to get any computing power out of them. One of the researchers I read about, who worked at Xerox PARC when microcomputers were first becoming popular, said that, for example, the Apple II used a chip for its CPU, the 6502, that they used at Xerox for the keyboard controller on one of their systems. One of the personal computer systems they designed at Xerox, using just semiconductors, had 4 Intel microprocessors, which they considered "barely enough" to run it. The system they started out with for their research in 1970 was a Data General Nova minicomputer. You could run the kind of languages Victor talked about on that back then.

The people who grew up with a microcomputer as their first computer experience could not be exposed to most of these languages on those machines, even if they wanted it. They didn't have the processing power, and they didn't have enough memory. The educational materials published for those machines didn't talk about these languages, except perhaps to mention them by name. When the schools started setting up their own computer labs, they bought these same microcomputers, and the educational materials were of the same quality. By the time a small proportion of these kids got interested in computer science, they had a concept in their heads about what programming was that didn't include these languages, much less these ideas.

I don't know what decisions universities made that also tended to exclude these languages and ideas from discussion, but it seems to be the case that most CS students didn't work with them. I speculate that the popularization of computing, through the expansion of the microcomputer market into the economy likely drove the decision on the part of universities to not put much emphasis on these languages, if they bothered to mention them at all, because industry, with rare exception, also didn't have an understanding of why these alternate programming models would be worth pursuing.

So I am thankful that Victor brought these ideas to public attention, now that we have powerful personal computers that can run these programming models easily.

Because many kinds of experimentation are aimed at finding out things, not to produce tools for others to use. This is especially true in the user interface area, where a large number of different experiments are required with different kinds of users, and there is often never a complete system actually built.

The results of these experiments can be summarized in both writings and videoed talks showing demos. There is almost always enough public information available to allow replication of the experiments.

And, in most cases, every few years, something major and public is released, or put on public view.

A question is often asked, “well why not make the code public anyway?” In practice this is generally completely impractical for many reasons, including just dealing with detailed questions and bug complaints about many obsolete versions, and that the kind of research that e.g. VPRI did is not at all incremental. Quite of bit of the work of this group over the years has been to start from scratch as often as possible. For example, there were 5 complete Smalltalk systems done at Xerox Parc at about 2 year intervals — each one tried different design ideas and required major implementations.

Squeak Smalltalk used the “Blue Book” definitions (which were public and open), but did a completely new “bottom” (which was also made public and open). The tooling needed for others to be able to use the open sources was done carefully enough so this was successful.

The “Etoys” system for children was done in Squeak and also made open source. The Croquet system was done in Squeak and one of the spinoffs was “Open Cobalt” a non-profit open foundation.

Basically, seasoned researchers, especially on the fringes of knowledge, have to decide how to use their limited amount of time on the planet to best advance the research, while still holding to the scientific ideals of sharing what is powerful and interesting about the results. I think Bret Victor, VPRI and many other deep research efforts have done well at finding good balances for this.

As others on this thread have pointed out, you can’t consistently & accurately predict the future. However, I spend a lot of time identifying and analyzing growing trends in order to keep up with demand in the industry (it’s my job to make sure my company has the necessary skills in our developer network). From what I gather, the future of computer programming might look like this:

Artificial Intelligence: AI is becoming a catch-all term (in the way ‘algorithm’ has been for the last few years) but overuse (and often inaccurate use) of the term does not mean its impact is not real! I am also bundling machine learning under this heading, as it is simply a way of achieving AI.

Artificial Intelligence will continue drip feeding into everything we do. One area I am fascinated by is how it is likely to get good enough that you will be able to ‘speak’ a loosely defined design idea to a UI tool, and it will generate the mock designed screens from those requests.

What you should learn to develop AI:

• Python
• R
• Lisp
• Prolog
• Java

Augmented Reality: Talking about the UX/UI space, this has actually been static for a long time. Since the touchscreen revolution really. But the near future should be fascinating for user interface designers as AR is successfully navigating the move from Sci-Fi to reality. This is happening partly because the costs are dropping, which is generally a sign that we are near wider adoption. We are likely to see mobile adopting AR more and more since the two mesh naturally together. This is why I see AR becoming more popular ahead of VR (see next section) - end users don’t need new tech. That and both Apple and Google have released their own AR developer.

What you should learn to develop AR:

• ARCore framework with Java
• ARKit Framework with Swift or Objective C

VR: While we are not seeing many VR projects yet, it is, without doubt, a fascinating area. If it catches on with the wider public, this tech could drive some wildly innovative changes to our daily life. Predicting such change is fraught with difficulty, of course. Like AR, we can’t imagine where it will take us, nor do we know if/how it will mature. What we do know is that it will start with headsets. Now lighter in weight and lower in cost (less than $200), headsets are priced to become mainstream. With the assumption that they don’t suffer the same fate as Google Glass, we may be only a few years away from similar societal changes the iPhone/app store brought.

What you should learn to develop VR:

• JavaScript
• Java
• C++
• C#

IoT is only just starting to come into common parlance. It aims to create a network of connected devices, from keyrings to home appliances, that collect and analyze data so they behave in a smarter manner. Nest is a common example of an IoT device. The roll-out has been slower than expected because of issues with commercializing IoT data. But as these hurdles are cleared, I expect to see the technology used in many Jetsons-like ways. For example:

• Doors that recognize you and unlock.
• Fridges that order your favorite food before you run out, or encourage you to eat healthier.
• Gardens that water themselves
• Devices that won’t let you forget them

The 1st gen devices like Alexa are going to evolve and become ubiquitous. But they will certainly extend beyond the home into:

• Cars
• Cities and Public Spaces
• Healthcare

It’s definitely a growing sector. We don’t see many IoT projects at Scalable Path but I think this is because a lot of it is sitting within Google and Amazon and there is little startup work out there.

What you should learn to develop AoT:

• Python
• JavaScript

Blockchain: Whether or not you buy into the long-term blockchain and crypto space, there is no denying it is a huge and growing sector. You just need to look at the $100 million VC’s just pumped into CoinBase to know there are a lot more developer roles in this area. This is, without doubt, the fastest growing space for us.

What you should learn to develop on the Blockchain:

• Python
• C++
• JavaScript
• Solidity

Not all changes will be as visible as AR and VR though. Much of the ‘magic’ will happen behind the scenes.

Big Data: It’s not all Python and JavaScript. Another skill shortage lies with Hadoop developers. Again this is due to the rapid increase in demand for it. Which in turn indicates it will play a big part in the next few years. It’s closely linked to the increase in big data analysis trends. Businesses will want to analyze more and analyze faster. So these trends will continue to grow as pretty much everything I am discussing in this answer is trying to collect and analyze data to better sell your goods and services.

Quantum Developers: While fascinating, the development in the quantum computing world are unlikely to result in many roles for ‘quantum algorithm developers’ in the near term. That being said, both Google and IBM believe they will hit the ‘quantum supremacy’ milestone this year. This is where a quantum computer processes an algorithm that a traditional computer could not within a human lifetime. How long it will take to bridge the gap between that achievement and full error correction is still very uncertain.

To reiterate, these are ideas based off of what trends seem to be taking off. Who knows what other technological innovations will bring!

I answered something related to this a while back, and tried guessing at the reason that VPRI didn’t release source code, beyond several tools that were developed in the process. I might’ve been in the ballpark in what I said, but something that Adele Goldberg said in a fairly recent interview occurred to me later. She said that Alan Kay used to tell her and others in his research team that the worst thing was to release a product, or be part of a product team, because then you have to spend time supporting it. Kay indicated this in his answer here. She mentioned this in relation to starting ParcPlace Systems (she decided to go into product development).

If your goal is research, then the main thrust is to advance and prove your ideas, not look back and essentially provide “help desk” support as people try to use what you’ve created. That’s for people who want to develop and support products to do. As in a scientific discipline, if others want to replicate the work, based on what has been published, they can do that. It makes for quite a learning experience, which I think is the point. If you’re not learning something new in a scientific pursuit, then there’s something wrong.

I think it’s fair to say programming will be much more automated: programmers will become more creative and powerful because then they will have more time.

At the same time, newer languages will spring that will make the older ones obsolete. Rust, Go, Scala, Swift, Zig, Nim, V etc. are merely indicators of this drive towards creating much better languages.

Job-wise, what is true today, will hold: better programmers will be in demand, mediocre ones will struggle.

More developers will launch their own games, but not solo—they will form groups, small ones like the team behind The Forest (there were four or five people, all partners). So, entrepreneurial game developers will thrive.

The general outlook is very positive.

It's one of the best presentations on the possibilities of programming that I've seen.

Victor talked about languages that I had heard about for years, but I wasn't clear on what they did (with one exception), or were capable of. The idea of programming to goals sounds exciting to me. I'm struck that computer scientists were thinking about that back then, and I never heard about it, even while I was getting my CS degree many years after this. Perhaps it would have been discussed if I had chosen to study AI.

I agree that programming models need to be developed for distributed computing. They exist, but they're not used much.

I suggest you look at a language designed to be readable and designed to support self-documentation. That language is Ada.

Ada was designed to support the development and maintenance of military software. Military systems often have very long lifetimes. In fact fielded military systems have a lifetime averaging 30 years. An extreme example of this is the B-52 bomber. This weapon system first entered active service in 1955. It has undergone many updates and is still actively in service today.

An introduction to Ada provides some background on how and why the language was developed. Note that the goals of the Ada language include ease of reading and ease of learning.

Ada supports a robust implementation of generic programming, which in turn supports the concept in “Learnable Programming” of “create by abstracting”. See Stack Abstract Data Type using Ada for an example. This example uses preconditions and post-conditions to specify the required behavior of functions and procedures, making the starting and end state of each function or procedure visible to the programmer applying the program interface.

How about: The need for security.

Ok, a bit more detail the Insecure Internet of Things will need security measures, leading to home firewall routers gaining multiple zones. It is a bit inconvenient if your remote controlled lights are compromised, but it they are uses a a stage point to turn of alarms and unlock all doors then it becomes a serious problem.

Javascript/node JS is single threaded, the language has many misfeatures, so perhaps this will be replaced by a real language with proper security and zone separation to prevent system compromises via the browser.

Maybe programmes will have to have training in security practices; or at least non-secure by design languages can be retired.

The above are probably not good predictions, so I’ll make this: The Security Now will still be talking about security failures for the forseable future.

Today on hackernews:

http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/

Despite the dramatic shift toward simplification in software interfaces, the world of development tools continues to shrink our workspace with feature after feature in every release. Even with all of these things at our disposal, we're stuck in a world of files and forced organization - why are we still looking all over the place for the things we need when we're coding? Why is everything just static text?
Bret Victor hinted at the idea that we can do much better than we are now - we can provide instant feedback, we can show you how your changes affect a system. And Idiscovered he was right.