I have found this article to be extremely thought provoking and informative! Though I have yet to build a knowledge base as in-depth as one necessary to construct an article on topics such as the development of a language built onto the Java Virtual Machine to navigate around the constrains of another language, I still found everything within this article to be intriguing, and I will be sure to do some of my own research into the topics covered!
I did however find myself nodding in agreement with the (in my opinion) valid arguments against JavaScript, in fact I have made it a personal aim to utilise the language when engaged with web development as little as possible purely out of some tribal spite I have for it.
Though I have a question. Just out of curiosity, I read that you have tried languages like Rust (which I personally see the appeal with, especially now that it is being included in the development of the Linux kernel) but I haven't read about your experience with languages such as C or C++? Are these languages not capable of what you want to achieve?
Thanks in advance, I have thoroughly enjoyed reading this article and I hope to learn from it!
Thank you for the comment! I do not have significant experience with either C nor C++, so my impression of these languages is mainly second-hand.
These are very old languages, and it is certain that throughout the decades that have passed, things have been learned about how to design a good programming language. Often, I see C/C++ associated with the word "footgun" or the phase "shoot oneself in the foot", because of things like the implicit type conversions rules and manual memory management. It seems like no matter how good of a programmer you are, memory management errors are inevitable in these languages. It makes terrible things easy. Furthermore, the macro system sounds nuts. Also, I have read about people complaining about the C ABI.
Recently, I have done a very small amount of C++ programming. From what I have read, C++ is a horribly complex language, and this is consistent with my limited experience. With Rust, you can at least say that the complexity of the language gives you a lot more benefits—it helps achieve the goals of the language effectively. By contrast, C is simpler, and so I would favour it over C++.
However, nowadays you have languages like Zig, which can replace C, leaving behind many of the nasty things about C. For example, while not as 'safe' as Rust, Zig provides features to help you with good memory managment (like the 'defer' keyword). Support for generics is another feature. Therefore, I if I needed to do something where C/C++ would be appropriate, I would rather use Zig instead.
Although, like I've said, I have barely used any of these languges. One reason is the notation of Lisp/Clojure is orders of magnitude better. Another significant reason for this is because they are not dynamic (unlike the JVM); you edit, compile and run. Without dynamism, you lose the ability to explore the program interactively and efficiently—a huge loss for both productivity and enjoyment. I want to be able to have a live conversation with the program. So, I would love to see more work going into being able to dynamically modify and interact with high-performance langauges like these.
This is a good recent talk that describes the importance of dynamic programs, amongst other fascinating ideas:
"Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022)
I've already struggled trying to convey the full extent of the ideas in this article, despite being a long article—so, on the topic of the problems of JavaScript, I wouldn't be able to give a complete description that would satisfy me, especially since I am not the most qualified person to do so.
That said, I will mention a few brief points. JavaScript's language and ecosystem are a pain to work with. It does not have good support for multi-core multithreading. The language is complex. The language behaves in surprising ways. It is terribly slow and heavy (leading to a poor experience for the user). There are no integer types?!??! It is closely linked to HTML and CSS, which aren't great. It is coupled to web browsers. The ecosystem is incredibly divided, and generally a mess. Libraries often don't like to work with each other. And the memes speak for themselves.
Even ClojureScript doesn't fully soothe the pain—the quirks of JavaScript still leak through.
However, the unpleasantness of JavaScript isn't inherently a problem; there are countless programming languages that you could call 'terrible'. The problem is the absurd popularity of JavaScript, and the extent to which it has taken over the world of software. It runs the web, and now it is invading the space of desktop and mobile apps with libraries such as Electron. (How did we end up with a world where JavaScript is the best most available solution?) Because of this, there is no escape from JavaScript/HTML/CSS if you want to do anything with the web. There's basically no competition. Does it not seem wrong that a language designed in ten days is now the most popular one, and the foundation for an enormous proportion of critical applications?
Of course, we need to be careful when we call a programming language (or any other tool) good or bad; it needs to be considered in the context of a practical use-case. For instance, assembly language is not suitable for most software nowadays, but it certainly has its place.
So, we should consider the context in which JavaScript was developed. JavaScript, HTML and CSS were initially developed in the 1990s. That's a long time ago—and the internet was much different then than it is now. JavaScript was not designed to power sophisticated web apps, and, yet, here we are! The technologies of the present were designed for the problems of the past. In other words, we have far outgrown what JS/HTML/CSS can reasonably handle. It's like using cheap, blunt, plastic scissors to cut through thick cardboard: it may just about handle the job, but far from perfectly, and with a lot more inconvenience compared to using a more sensible tool.
We have the ability to create tools that are sane—tools that are a pleasure to work with and are a reasonable fit for modern demands. It just takes people to stop feeding the gargantuan JS/HTML/CSS machine, and instead pour energy into something worthwhile.
I have found this article to be extremely thought provoking and informative! Though I have yet to build a knowledge base as in-depth as one necessary to construct an article on topics such as the development of a language built onto the Java Virtual Machine to navigate around the constrains of another language, I still found everything within this article to be intriguing, and I will be sure to do some of my own research into the topics covered!
I did however find myself nodding in agreement with the (in my opinion) valid arguments against JavaScript, in fact I have made it a personal aim to utilise the language when engaged with web development as little as possible purely out of some tribal spite I have for it.
Though I have a question. Just out of curiosity, I read that you have tried languages like Rust (which I personally see the appeal with, especially now that it is being included in the development of the Linux kernel) but I haven't read about your experience with languages such as C or C++? Are these languages not capable of what you want to achieve?
Thanks in advance, I have thoroughly enjoyed reading this article and I hope to learn from it!
Thank you for the comment! I do not have significant experience with either C nor C++, so my impression of these languages is mainly second-hand.
These are very old languages, and it is certain that throughout the decades that have passed, things have been learned about how to design a good programming language. Often, I see C/C++ associated with the word "footgun" or the phase "shoot oneself in the foot", because of things like the implicit type conversions rules and manual memory management. It seems like no matter how good of a programmer you are, memory management errors are inevitable in these languages. It makes terrible things easy. Furthermore, the macro system sounds nuts. Also, I have read about people complaining about the C ABI.
Recently, I have done a very small amount of C++ programming. From what I have read, C++ is a horribly complex language, and this is consistent with my limited experience. With Rust, you can at least say that the complexity of the language gives you a lot more benefits—it helps achieve the goals of the language effectively. By contrast, C is simpler, and so I would favour it over C++.
However, nowadays you have languages like Zig, which can replace C, leaving behind many of the nasty things about C. For example, while not as 'safe' as Rust, Zig provides features to help you with good memory managment (like the 'defer' keyword). Support for generics is another feature. Therefore, I if I needed to do something where C/C++ would be appropriate, I would rather use Zig instead.
Although, like I've said, I have barely used any of these languges. One reason is the notation of Lisp/Clojure is orders of magnitude better. Another significant reason for this is because they are not dynamic (unlike the JVM); you edit, compile and run. Without dynamism, you lose the ability to explore the program interactively and efficiently—a huge loss for both productivity and enjoyment. I want to be able to have a live conversation with the program. So, I would love to see more work going into being able to dynamically modify and interact with high-performance langauges like these.
This is a good recent talk that describes the importance of dynamic programs, amongst other fascinating ideas:
"Stop Writing Dead Programs" by Jack Rusher (Strange Loop 2022)
https://www.youtube.com/watch?v=8Ab3ArE8W3s
Genuinely curious, can you elaborate on the 'Javascript nightmare!' stuff?
I've already struggled trying to convey the full extent of the ideas in this article, despite being a long article—so, on the topic of the problems of JavaScript, I wouldn't be able to give a complete description that would satisfy me, especially since I am not the most qualified person to do so.
That said, I will mention a few brief points. JavaScript's language and ecosystem are a pain to work with. It does not have good support for multi-core multithreading. The language is complex. The language behaves in surprising ways. It is terribly slow and heavy (leading to a poor experience for the user). There are no integer types?!??! It is closely linked to HTML and CSS, which aren't great. It is coupled to web browsers. The ecosystem is incredibly divided, and generally a mess. Libraries often don't like to work with each other. And the memes speak for themselves.
Even ClojureScript doesn't fully soothe the pain—the quirks of JavaScript still leak through.
However, the unpleasantness of JavaScript isn't inherently a problem; there are countless programming languages that you could call 'terrible'. The problem is the absurd popularity of JavaScript, and the extent to which it has taken over the world of software. It runs the web, and now it is invading the space of desktop and mobile apps with libraries such as Electron. (How did we end up with a world where JavaScript is the best most available solution?) Because of this, there is no escape from JavaScript/HTML/CSS if you want to do anything with the web. There's basically no competition. Does it not seem wrong that a language designed in ten days is now the most popular one, and the foundation for an enormous proportion of critical applications?
Of course, we need to be careful when we call a programming language (or any other tool) good or bad; it needs to be considered in the context of a practical use-case. For instance, assembly language is not suitable for most software nowadays, but it certainly has its place.
So, we should consider the context in which JavaScript was developed. JavaScript, HTML and CSS were initially developed in the 1990s. That's a long time ago—and the internet was much different then than it is now. JavaScript was not designed to power sophisticated web apps, and, yet, here we are! The technologies of the present were designed for the problems of the past. In other words, we have far outgrown what JS/HTML/CSS can reasonably handle. It's like using cheap, blunt, plastic scissors to cut through thick cardboard: it may just about handle the job, but far from perfectly, and with a lot more inconvenience compared to using a more sensible tool.
We have the ability to create tools that are sane—tools that are a pleasure to work with and are a reasonable fit for modern demands. It just takes people to stop feeding the gargantuan JS/HTML/CSS machine, and instead pour energy into something worthwhile.
Also see:
"The HTML Tax" https://blog.phronemophobic.com/html-tax/html-tax.html