Mostly I've found myself agreeing with your thoughts in previous posts. But there are two major ideas in this post that I'd like to offer a different perspective on.

First, I've heard a number of people recently suggesting that text files are not the way that programs should be represented. I can understand some of this, but if you've ever used a programming system that *doesn't* store the programs as a simple text file, you'll understand why that is a Really Bad Idea. You suggest, for example, Dion as a better programming model. Pray that this doesn't happen, but what if Dion gets Our Machinery'd, and you didn't save a text copy of your programs?

You suggest "there is a strong argument for the creation of a common format that can encode the aforementioned common structures," yet about the languages themselves say "I am not willing to spend a decade or two playing catchup, just to, in the end, obtain an experience that matches or slightly beats that of C." Any new format to store programs in is going to need at least *several* decades before I would trust my programs to be stored in that format rather than a text file. I learned this the hard way.

The most important thing about plain text is that it is one of the few file formats that will be readable, basically forever (as long as a machine readable copy of the file exists). I've been using computers since the late 70s. There are so many programs I've had that created files for me from which I can no longer access MY content. The programs no longer exist, even the OSs the programs used no longer exist. And had I been diligent to copy the content from one media to the replacement media, every time a new one came along, I *still* wouldn't be able to access much of that content because it used proprietary data formats. What I *can* still access are files that used the simplest of formats out there. Plain text. Or simple .BMP files, for example. There are video formats/codecs from as little as 20 years ago that are difficult to find current products that will recognize them.

So, in this case, sorry, you are wrong. Text is by far the best format for now, at least if you want to be able to still look at and use your code any distance into the future.

Oddly, what could change this is the second thing I have a different perspective on. I say, let programming languages be fruitful and multiply. The VAST majority of languages will wither and die. But occasionally one will have a new concept, or simplify something, or be vastly more powerful in some way, and that idea might catch on a little. Maybe it's that language, or maybe another even newer one that just borrows that concept, that might gain some popularity. Only the very strongest will survive, though.

As with any new tool, if you aren't willing to risk the likely situation that the programming language become unsupported, or worse, will vanish completely, you should not be using it. Most new programming languages seem to me to be toys to experiment with some idea or another. Sadly, most of those ideas are simply a different syntax, but I encourage even that exploration because if you don't, you eventually are stuck with the atrocities of C++ syntax.

If you don't support the testing out of new languages, would you apply the same logic to any other tool you use? Imagine if you had to use something like MSPaint to edit your photos because someone said we shouldn't waste decades in producing marginal improvements to the graphical editor world. (Or imagine if you still had to use the original implementations of FORTRAN, COBOL, PL/1, and Lisp, because someone made your argument in the 60's instead of the 2020s.)

People having religious wars over programming languages (or editors, etc.) is just something that happens when they are heavily invested in them. You can ignore such fanaticism for what it is. Any arguments over new languages are like that too. They help create the environments that eventually survive (someone has to champion for a thing for it to become popular), but are otherwise meaningless.

Maybe at some point, some new language will take off that uses a new, non-text, format to store its programs in, and an entire ecosystem pops up to support that new format, not just for that language, but for others that decide to imitate it. After a few decades, and hundreds or even thousands of programs written that support this new file format (editors, debuggers, etc.), maybe I would be willing to risk writing something important in this language, having finally become convinced that my own work won't disappear because the format won't vanish, became outdated, or be replaced by something ostensibly newer or better with only nominal support of backwards compatibility.

But this will only happen if many new languages are tried, and the good ideas from them, like genes that provide a survival benefit, are allowed to survive and become fitter.

Even though I had some disagreements, thank you for writing your thoughts on the topic. I always enjoy reading them.

Expand full comment

I agree with a lot of this article and unfortunately I just have to accept that there will never be the perfect language, platform, or libraries. Making new languages all the time just seems naive, after all if they are Turing complete they will always have the same capabilities, but have the downside of not supporting prior libraries natively. And the new languages either "solve" usage issues of earlier languages by automating tasks and preventing the programmer from making those specific mistakes, or they add more features, which developers get frustrated with because more features gives more ways to shoot themselves in the foot.

It seems like at this point languages have been expanded upon to the point that there is no need to make new ones because you already have all the functionality in the existing ones. There is usually a simpler default language (like C, Js), and a backwards compatible expansion to them (C++, Typescript). According to developers, the simple languages are too verbose and hard to manage in large projects (ie C), but the expanded languages give too many features that allows them to shoot themselves in the foot (ie C++). It's always a grass is greener on the other side situation, there will never be a perfect language that matches everyone's way of thinking and reading and use cases. So then they make a "safe" language that takes years to develop (you know which one I'm talking about) that isn't actually safe (you can never really protect a bad programmer from themselves, in the same way that you can never make a UI simple enough for Grandma to understand), so why not just focus on improving IDE's or programming styles instead of making non-backwards compatible languages with poor support?

Expand full comment

I agree with your the main point that there are other things to focus on besides new languages, and that these other things are also incredibly important. I could also understand why you might argue that these tools and other parts of an "ecosystem" might be more important than a new language.

But I do feel you've undervalued new programming languages. It is definitely something that can improved upon, and so we should. Computing will probably be around for a while, so if it takes decades, it takes decades.

I would say that more languages won't fix the computing world *on their own*, but are still an important aspect we can improve upon.

Expand full comment
Comment deleted
Expand full comment

This is certainly fair, and is a wonderful articulation of the reason why I have so much respect for those who worked on computing tooling several decades ago, and why I have so little respect for most of the work that happens on computing tooling now.

I love all of the Bret Victor stuff I've seen, but I'll refresh my memory on this one now.

Expand full comment