The way our editor presents code is not the way we read it. When we see a variable we usually go to their definition to know their type. Or when we receive an error message we have to find the line of code that contains it. This goes against the way our editor wants us to read code.
Why? Why am I forced to read code in such awkward way? I’m aware of the existence of things like “Jump to definition,” but those feel like hacks. It’s like if the editor is unwilling to admit their defeat and is just trying to make up excuses.
Our development environment just refuses to accept each human needs to read the code differently. For example, the maintainer of a large codebase isn’t going to read the code in the same way as someone trying to get started. The worst part is that development on our DEs has been practically non-existent, and one reason for this is because the progress on programming languages has been incredibly stagnant. These modern languages keep reinventing the wheel and end up becoming worse than LISP or Smalltalk.
When you accept your language is finished, only then, you can focus on the development environment. These modern Non-LISP languages must be in a constant cycle of modding in order to accomodate to the needs of the developers which means they will never be finished.
Let’s take as an example C: This language seems to oppose totally to the idea of a comfy developer experience with heart-breakingly long compile times and practically no interactivity with our program once it’s compiled. The language is so frustratingly primitive it doesn’t even have a REPL.
Another reason of why the progress has been slow is because editors just keep treating the source code as text, when it has a more complicated structure. On a typical editor you probably don’t operate by saying “editor. next if statement” but instead by saying “editor. one line down please.” Why? Stop telling me my code isn’t code! Even when editors provide tools to operate on the AST, visual representation of it is poor. Is syntax highlighting the best we can do to improve readability? or can we employ other visual techniques to better the experience?
— Hey! What about Scratch? In it, AST is visually represented by blocks. And editing is done in a super visually way. Isn’t that good enough?
Hmm.
While Scratch tries to change the paradigm, it underutilized the medium of visual programming languages. It feels like a half-assed solution which barely received any thought at all.
One clear example where Scratch lacks is in representing the program’s data-flow, as in, all your variables are global. Ew, why is that? That’s so dumb! In a visual medium, lexically-scoped variables would be easier to visualize, there’s no reason for all variables to be global.
Even while being very flawed, Scratch does ONE thing that puts it above the majority of programming environments.
Composing code in Scratch is done by drag and dropping from a panel that contains everything you could possibly need. if statement? Sure, the panel has it. while loop? Gotcha! Not only that, but every variable and function you declare will also show up on that panel. You never have to type anything other than variable names and function names!
This radically different way of composing code removes the need of documentation having to be presented top to bottom. Using a typical language, for example, you would have to read the entire program top to bottom in order to know all the defined variables. Presenting code that way is a mistake. Let’s take a look at GOTO statements, everyone has negative opinions about them because reading them is difficult, but that is because the editor does no work in ensuring they’re readable.
I want to use the medium of visual programming to enhance programming in ways that not even LISP have been able to. It’s time to focus on the area of research we have been ignoring for the past few years. It’s time to empower kids and hackers alike. This is only possible when we accept that our editor should assist us in reading code.