6 Ways Programming Needs to Evolve
David Buck
It’s now 2022. I look around at the state of computer programming and think that we really haven’t changed much in the past 50 years. By 1972, we had Fortran, Cobol, Algol, Pascal, C and other programming languages. Take a quick glance at code written in Java, Javascript, Rust, Python, Dart and Ruby and you’d be hard pressed to tell them apart from C.
We’ve become stuck in a rut. We’ve convinced ourselves that programs must be written in text using text editors (sometimes with fancy features), translated into binary files (usually) and transferred to a runtime environment to execute. Once in the runtime environment, it’s hard for us to see what the program is doing. We depend on log files and, sometimes, poor debuggers to understand our programs. We have little ability to stop the program, look around, change data, change code, step forward a bit, and look around again. It’s very hard, therefore, to understand how the program works or why it’s not working the way we expect it to work.
But programming doesn’t have to work that way. Why do programs need to be based on text with all the restrictions and limitations of a compiler? Why can’t we make tools that help show us what our code is doing as it runs under our control? Why can’t we make changes as it runs? This is all possible if we can get past 6 things that are holding us back.
- Programming needs to be graphical, not text based
We’re starting to see graphical programming for kids with languages like Scratch and Google Blockly.
Program elements aren’t text but blocks that can be dragged and dropped into the program. Programming graphically provides several advantages. Variable names and method names can be normal words separated by spaces rather than needing camelCaseIdentifiers or underscore_delimited_identifiers. Graphical programming eliminates bracket matching problems since the blocks themselves show the grouping of operations. It allows us to use graphical elements to represent assignments to variables rather than having the confusion between =, == and, in some languages, :=. It frees us to focus on the program and its structure rather than the text representation of it that a compiler will understand. In fact, in a true graphical programming environment, the compiler isn’t needed and the editor directly manipulates a parse tree that the compiler would normally produce as part of its operation.
2) Programming environments need to be immersive and interactive
There’s no excuse for a modern programming environment to depend on log files to understand what the program is doing. Admittedly logs are one possible tool, but in most cases other tools would work better.
This is an aspect of computing that Lisp, Smalltalk and other languages pioneered in the 1960’s and 1970’s but was largely lost since then. Yes, we have debuggers for some modern programming languages, but Smalltalk had that and more in 1980.
Imagine being able to stop your program at some point (a breakpoint, perhaps). Once stopped, you can look at the variables in your environment — many modern debuggers can do this. Now imagine talking to those objects and calling methods and seeing the results even while your program is paused. Imagine changing the code of the method you’re in and starting the method again from the start. Imagine selecting an expression in your method source code and opening a separate debugger window to step through it while your original debugger remains paused. Imagine entering an arbitrary piece of code and executing it in the current context. Smalltalk could do all of that in 1980 and few modern languages can even come close to it. We need to return this immersive feeling that you can change, examine and manipulate the data and code while the system runs.
3) Programs need to offer better visualization
We need better tools to show us what the program is doing and what the data looks like. Suppose I stop my program at a breakpoint and open the debugger. If I have a variable containing an image, I should be able to see the image. If the variable contains an array of numbers, let me see it as a graph or a table. If the variable holds a rich text document, let me see the document. Let me see class hierarchy diagrams of the classes. For every class of object, let me define my own ways of being able to visualize that object.
The Glamorous Toolkit by Tudor Girba explores this kind of environment. It expands our ability to understand our program and the data that it uses.
4) Programming can’t be specific to one spoken language
Most programs use libraries and reserved words that are in English. If you’re a French speaking person or a Japanese speaking person, you still need to program in English. You’re free to use your own names for variables and methods within the restrictions of your compiler. This makes non-English programs difficult to follow since they switch back and forth between English and non-English words. I saw this while programming for a company in Quebec where everyone spoke French. The mix of English and French throughout the program was distracting and hard to follow.
Programs need to be internationalized — or at least have the ability to internationalize them. Programming language reserved words, method names and variable names could be represented as translatable symbols. Each translatable symbol could have translations into other languages. If a translation doesn’t exist in the language you want, you can add one or ask Google Translate for a suggestion.
I would love to see a world where Chinese-speaking programmers can share code with German-speaking programmers and each would understand what the other wrote. You should be able to use any printable unicode text for any identifier. You should be able to provide a name for that identifier in your own language if the translation isn’t available. If a language is written right to left, the order of the receiver and the arguments should be able to reflect that change. If one language reads better if argument 3 comes before argument 2, you should be able to write the translation to show the arguments in a different order. We shouldn’t make English the one and only language for programming.
5) Hide the weeds
When we’re programming in a high level language, we’re building on top of many layers of abstraction, libraries and frameworks. Often, the details of those lower layers are presented to us in the form of tracebacks in stack dumps or in debuggers.
Programmers learn to ignore the irrelevant levels of the tracebacks but it’s confusing for beginners. When we’re writing our code, we should be able to focus on the level of abstraction we’re working in and ignore lower levels.
6) Show me the weeds if I need to see the weeds
There are times when I really need to understand what’s going on under the covers in my program. In that case, please let me see that if I ask for it. I would like full source code for all of my frameworks and libraries. I want to have that code instantly visible without effort whenever I want to see it. If my code is being called from a web framework, I’d like to be able to trace the execution right back to the point where it was received from a socket. Don’t hide away parts of my program in black-box libraries that I can’t see. Again, this is one area where Smalltalk does better than most other environments. All of the code in Smalltalk is visible right down to basic numbers and strings. If you really need to understand details on how your program works, you should be able to see those details.
Wrap up
These are the advances I’d like to see in new programming languages. The Smalltalk team of the 1970’s and 1980’s was famous for the expression “burn the disk packs”. By that they meant that they would throw out all the code they had and start again from scratch with the benefit of the experience they acquired from the previous attempts. That’s what we need to do with programming languages today. Learn from the past but “burn the disk packs” and start fresh.
I’m starting a project to move in that direction. I’m developing an environment which I’m (currently) calling PigeonTalk. This is a Smalltalk environment for now and I have plans to evolve it into a graphical environment.
I’m running a Kickstarter on this project, so if you’re interested in it, check it out at:
https://www.kickstarter.com/projects/pigeontalk/pigeontalk-a-programming-environment-to-explore-computing