This is the transcript of the video talk Better programming tools, ep01 - Design philosophy
<< Back to index

Have you ever been frustrated by an unhelpful programming tool?

This is a series of short talks for programmers who are open to ideas for new and better tools. By tools, I mean things like text editors, compilers, build systems, version control systems, integrated development environments and so on. During my 20 years in this field, I've imagined many possible improvements, and now it's time to share them!

After this introductory episode, the following episodes will explain one main idea each, with sketches and prototypes. Since you're probably eager to get to the good stuff, here's a quick sneak peek of some upcoming ideas, sorted roughly from simple to advanced.

A mode in which the font size of the code varies from line to line, based on the syntax tree and your current caret position, so you can see more on screen at the same time, and get a better sense of location. We could call it a stretchy code map.

A good call graph navigator. See which functions call which other functions, but in a way that's not an overwhelming tangled mess, even if your code is.

Visualizer of conditionals and loops. This one is probably more for beginners. When I explain ifs and whiles to beginners, I draw diagrams with arrows. There is no reason to not have such diagrams built in to our programming tools.

Quicker navigation with keyboard and eye tracking.

Sometimes you want to get a high level overview, sometimes you need all the details in front of you at the same time. Sometimes you want to see how something works in the abstract general case, sometimes in a concrete specific case. Why not have the best of both worlds? I think we can! With expand/collapsible blocks and function calls.

Causal tree for debugging runtime exceptions or asserts. When your program fails at runtime because of a bug, you often want to trace the bad values backwards to their source, and a good tool could make this process more automatic.

Better version control. I think we could have something which is even more powerful than the industry standard Git, while also being much easier for people to understand.

Refactoring mode with semi-automatic unit testing. The computer could help you ensure that some types of refactorings don't break things, based on recorded data or fuzzing.

For the rest of this introduction, let's zoom out and talk about context, my motivation and overall philosophy behind this project.

Most programmers use the tools we're given. Some small fraction build the tools that others use. And these tools can have a very large impact on the productivity of other programmers, and their quality of life. In my career, I've experienced countless situations where a tool was less helpful than it could have been. For example, error messages that don't explain what's actually wrong.

And I'm not seeing enough progress! There is progress, but there's also a lot of regression. Sometimes a tool that was used 30 years ago had great features that are missing in new tools today. But just complaining about this probably won't help, so I won't do that. Let's try to be constructive here.

I'm definitely not the only person thinking about this stuff. The best index of such projects that I know of is at the Future of Coding website at futureofcoding.org, which is also a podcast with interviews with other people who all try to re-imagine programming in some way.

There seems to be pretty good progress on so-called "low code" environments where you give up some amount of control to get more productivity. They are often a bit more drag-and-droppy, often inside a closed ecosystem like a cloud service with easier deployment. I applaud all these projects and I have nothing to add.

I also think there's pretty good progress on the programming language front. The most exciting ones on my personal watch list are jai and zig. There are many smart people making new programming languages better than I ever could.

But I don't see a lot of progress in the area of tools for the most common kind of programming languages already used by professionals like myself. And I think that's a niche where I can do some good, especially to the user interface and interaction design. And design here doesn't mean selection of fonts and colors, it goes much deeper.

Others have already explained this better than I ever could, so I warmly recommend checking out the book "The Design of Everyday Things" by Don Norman,

and the work of Bret Victor. Start with the talk "Inventing on Principle" or the essay "Up and Down the Ladder of Abstraction". His website is at worrydream.com and I've put links in the video description.

Another great read is on the Light Table blog. Light table is a discontinued project, but this blog post is still a brilliant summary of everything that's wrong with programming today.

So why isn't there a lot of progress in tools for coders like myself? My guess is that we get so used to the existing tools that we come to see their limitations as just the natural state of things. There is of course good reason why text editors and compilers were originally so minimalistic. The paradigms were invented many decades ago when computers were much weaker than today.

Computers today are incredibly powerful, so now there is room for much more advanced tools.

What should we do with all this new power? We could automate more things. Some tasks in programming are deeply creative, so those are of course very hard to automate, but other tasks in programming are just repetitive and mechanical and repetitive, and those are prime candidates for automation.

I think we learned to read code in in plain text format and then reconstruct all these elaborate structures as abstract maps in our minds. But even though we can do it in our minds, I think it would be better if our tools did more of that job for us. What do I mean? As an example, code forms a syntax tree where things are nested inside other things, and sometimes it would be nicer to interact with that tree structure instead of interacting with its serialized format in plain text.

Another example: code in most languages are made of functions that call other functions, forming a call graph. And there's data structures, data flow, scopes, etc. All these are structures which tools could visualize and let us interact with. Many tools already do this to some small degree, but in my opinion they don't go far enough. They are too limited, or they're not well integrated, or their design isn't very usable, so I think there is lots of room for improvement.

Here's another part of my approach to design. If you've spent any time reading discussions about the best way to write code, you know that people disagree. A lot.

• For example: tabs vs spaces.
• Where do you put your curly braces?
• Small functions vs large functions.
• Maintainable code vs high performance code.
• Do it all yourself, vs depending on a third party library.
• Command line vs graphical user interfaces.

I think of these as false dilemmas. Whenever there's two strong sides, there's usually good arguments on both sides. I always ask myself: does this trade-off even need to exist? I think the way forward is to list all the pros and cons of both sides, and try to invent a new system that has the best of both worlds, so that the dilemma just... disappears. Of course it's sometimes too hard, but I think it's a good thing to aim for.

I think that summarizes my approach. Now let me try to preempt some questions or concerns you might have.

Question: Everyone has ideas, but they are useless until realized - why are you just sharing ideas?

Answer: Yes. I hope to build these tools myself, ideally for use with many different programming languages, but that's too much work for one person, even in a lifetime. So these videos are to check which ideas people get most excited about, so I can build those first. Another purpose is to inspire more programmers to start imagining tools they would like.

Question: Isn't it a waste of time to build new advanced tools? What happened to "keep it simple, stupid"?

Answer: Sure, if you're in a hurry, it's better to just use the tools we already have and get the actual work done. I disagree, of course, if we are thinking long term and globally. Even a meager 5% improvement of productivity or quality or any other axis is huge when multiplied by the number of users a popular tool can have.

Question: It's common knowledge that attempts at visual programming have never struck gold. What makes you think your approach will succeed?

Answer: I understand this skepticism if you're thinking about so-called visual programming languages, like in the Unreal engine there's this visual programming language called Blueprints, which I hear is popular among non-programmers, but becomes really messy past a certain scale. But that's not really what I mean when I say "visualize structures".

Any tool that completely departs from the plain text file model makes it hard for people to switch. But there are actually certain types of visualizations that have become ubiquitous. For example, if we look here in Visual Studio, we can see that we're not really dealing with just plain text anymore.

For one thing, the text editor has syntax highlighting, which can change the color or boldness of the text based on the words in the programming language. This can be called a kind of visualization, even though it's a very lightweight and unintrusive kind. It also has highlighting of errors with this red squiggly line.

And it has all these other panels you can choose to open. They mostly contain text, but not text file contents. Rather, they extract certain information from the text files, and search, filter, slice and dice and present it in various ways.

So if visualizations are either complementary views beside the text, or if they overlay info on top of the text, then I think it's going to be ok. This avoids the problem of Blueprints. Let's call this part of the design philosophy "never worse than text".

Question: Do I have any suggestions for tools that already exist?

Answer: Yes, one that's similar to my ideas is Sourcetrail, at sourcetrail.com

If you found this interesting, please let me know, it will motivate me to make more episodes. I'll try to release the next one after two weeks. Thanks for watching.