> Lots of people are reinventing Smalltalk on a Mac.
(See Bret Victor and Eve).
At last, someone noticed! ;-)
Though from that expression, what the author doesn't seem to grok is why having a Smalltalk-like environment is desirable; maybe not as the primary way to program computers but certainly as a tool alongside.
It's a shame that a family of programming languages that build on and expanded that model hasn't gained more traction in the industry (not necessarily for people who dedicate their lives to build complex software with a highly general programming language, but for the rest of us).
I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the opposite of what this one-liner implies). His focus is on better interface design, not formal language design; why criticize someone for something they're not trying to do?
And it's not useless; we probably wouldn't have had Elm without Bret Victor's Inventing on Principle[1][2]. And there has been some progress in that direction of interface design of, for a lack of a better term, "programmable environments": look at Apparatus, for example[3]. Where would you even fit that on these slides?
Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet.
End-User Development has lots of under-explored ideas on how to build software automatisms that don't require the end user to learn a hard formalism (even if such formalism exists as the basis for the system). Though I understand that programming language theorists are not interested in that angle of the evolution of PLs.
There is a dichotomy between sealed programs and evolving programs. Evolving programs like Smalltalk or REPLs are great for exploratory work. Almost everyone wants sealed programs for systems to work reliably. This runs along the lines of Ousterhout's dichotomy as well - scripting vs systems languages.
The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application.
IMO, TDD and BDD could be seen as attempts to do exactly this.
I do find it a useful dichotomy because I work with people who evolve their code and wonder why I get my back up about monkey patching (because it's often my job to turn research or prototype quality code into reliable code).
If you've ever had to make another person's research or prototype quality code more robust it can be easy to wonder how on Earth they work the way they do. Having this dichotomy in mind makes it easier to have more sympathy.
It works both ways. Researchers need to understand why platform development moves so slow. This dichotomy helps reason about it.
But you're right, between evolution steps the system is not sealed. That's a concern and why projects like Debian are keen to have reproducible builds. It's also a big part of why containerization is becoming so popular.
Ah I see. So with 'sealed' you mean things like reproducible builds and being able to determine the exact set of sources, etc?
The containerization movement is interesting - while having these 'sealed' virtual environments and reproducible system builds is the right direction, I'm amazed at the size and weight of each of these.
Sure. By sealed I mean you compiled the program, you might have a turing incomplete configuration (e.g. ini, toml, json) and you can reason about the program. And by evolving (or, I guess unsealed) you are in the process of editing the program. Or you monkey patch it when you run it.
But with things like LD_PRELOAD, different .so minor versions, etc, a compiled program suddenly straddles the categories. Hence my comment about reproducible builds and containerization.
> The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application.
Yeah, I see that as a likely evolution as well.
In some ways, an IDE is already an exploratory system with a focus on delivering a sealed system - the final compiled software represented by the source code. I believe this combination is what made IDEs so successful and universally desirable, and future programmable environments should share these traits.
Auto-completion, refactoring and code-browsing tools support the exploratory work. The problem is that IDEs are not so good at exploration as a REPL because they're unable to store intermediate results and states. TDD could then be seen as an ad-hoc way to store such intermediate state.
Agree on the benefits of IDEs and REPLs. An IDE/language with integrated notebook-style REPLs might be useful too. Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact.
The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes - instead of only showing what is directly modified (i.e. a line of code) and leaving the simulation up to the human.
> Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact.
Yes, exactly. You get that with a REPL (e.g. Lisp or Python) and copy-pasting to the source code files, but it's far from ideal.
> The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes
So, sort like explorable explanations[1][2], but aimed at developing a new model and not just exploring one that has been already made? That's what I'd like to see, too.
Yes, somewhat like these, but having the ability to inspect and simulate effects on intermediate forms and systems. So something along the lines of light table but being able to show more than just the immediate program.
Copying something I wrote in another thread:
I want to see not just the immediate program I'm manipulating (text or otherwise) but also the implications - the affected parts of various other intermediate representations all the way to the running, live system that will be affected.
Yes, but they are only available for a few languages, and they're not a tool that is recognized as beneficial to programming in the large, like for example IDEs are.
Moreover, having direct introspection of a model stored in a local notebook is still quite limited with respect to having it in the whole environment like Smalltalk or HyperCard did. There are a few systems trying to explore that "structure of the project" approach, like Leo Editor or the Smallest Federated Wiki which could be a better basis for a "Inventing on principle" tool.
At last, someone noticed! ;-)
Though from that expression, what the author doesn't seem to grok is why having a Smalltalk-like environment is desirable; maybe not as the primary way to program computers but certainly as a tool alongside.
It's a shame that a family of programming languages that build on and expanded that model hasn't gained more traction in the industry (not necessarily for people who dedicate their lives to build complex software with a highly general programming language, but for the rest of us).