Yes, this sound like it is true. But is it good? I mean, if I accept this idea, I start feeling more like a pet living in the house that is my platform then as a human who creates things. Also, it can be inefficient in that the same program or algorithm ends up being implemented in every language. Also, the article does mention that there is some pain in between programming language, e.g., when writing language bindings. I would push this point a bit further and note that we have too many tools and it is extremely painful to have to know all of them. Nowadays with AI it gets a bit more easy because it can help a lot with unfamiliar tools, but still that sounds like a problem that would not need to be solved if it was not created in the first place. Multiple programming languages tend to multiply the number of tools needed. I have been feeling for decades that C++ is a good language because it can be both low level and high level and can therefore take away the need for multiple programming languages. The world seems to be taking a different course, obviously, and in my opinion it makes people less free and less powerful than they otherwise could be.
Reminds me a bit of a "Comparative Programming Language" class from college. Nice overview!
As noted by sublinear elsethread, surprised that JavaScript didn't get more discussion (though quite interested to read the 189 page PDF: https://www.wirfs-brock.com/allen/jshopl.pdf ), and also surprised that Domain Specific Languages and specialty tools/environments such as Processing didn't come up since they seem one of the obvious end-games of this premise.
I really like very much this essay, and clearly shows my point of view regarding programming language adoption.
While as language geek I consume everything to learn about what is out there, new approaches to programming, paradigms, mindsets, ways to solve problems, in the end work is driven by platforms.
Going in the direction of using languages not embraced by platforms, means one needs to be willing to do yak shaving adding platform support for the given language.
Python is a good example of characteristics that create an 'ecosystem gravity'. If you want to do any data crunching, natural language processing etc you might as well use Python even as as sidecar rather than wrangling with whatever libs are available in another language
On the contrary, language code is what is "authored". The authoring tools are the IDEs, editors, compilers, etc. that we use to produce the executable application.
I'm disappointed there wasn't more written here about Javascript, and more broadly, the web browser. The browser is the platform of the modern era, and Javascript is the strongest example of a programming language being an "authoring tool".
Web apps carry the weight of ecommerce, entertainment, social media, etc. The fact that those apps are frequently at the center of political debate and pop culture underscores their broader success far beyond the discussions that only developers understand.
Along with the HTML and CSS, the code written for the corporate web is not up to the developers alone. You can't ship anything until it's been through far more review by non-technical stakeholders than the devs using other languages may get away with. Yes the quality can vary, but when it's bad it reveals the dysfunction of the organization in a very public way. There's so much cross-discipline human involvement that the developers are in roles that resemble a bureaucrat more than a programmer.
I completely agree with your premise. JavaScript and the browser represent the quintessential modern authoring platform.
I actually wanted to write more about JavaScript, but the problem was that there were fewer cohesive, codified sources to cite than I expected. When writing about this kind of historical narrative, the first issue is always whether there are books you can cite.
JS has undergone organic changes along with the turbulent history of the web itself, but there's no clearly organized history of those changes.(To be more precise, it's not that there are none, but rather that the web environment was so fragmented in its early days, and each piece had its own history. Describing all of it would have required too much time)
There is Allen Wirfs-Brock and Brendan Eich's 'JavaScript: The First 20 Years,' but it's so lengthy that I couldn't read all of it, so I had to cite only what I had actually read. That's why I ended up cutting a lot of the JS content. I completely agree with your point, but I hope you understand it was a matter of length constraints.
To me, what makes this so obvious with the web platform is the bureacratic nature of developing for it. To do anything meaningful, you have to bring three departments together (html, css, and javascript). Each is a very different language designed for a different guild of practitioners. You even have the interdepartment turf wars, even if one single person is manning all 3 departments, of which department should accomplish any given task. And each department/platform/language has exteded their capabilities over time to give them more reach to participate in problem solving formerly left to others.
Thanks for your paper btw. I did 20 years of Smalltalk. I came to view Smalltalk programming more like biological culture manipulation (you had a dish of live objects that you morphed into the result you wanted), whereas the conventional file->syntax->executable employed by most development systems is more akin to the industrial factory pipeline of assembling products from raw goods.
During those younger years, money mattered. Tools were sold on the premise that they reduced or mitigated the various costs inherint with employing programmers. And then... around the late 90s, that just kind of dropped from the discussion. As quantitave easing made money available to speculate with and hitting it big with the software that was "eating the world", things like web programming burgeoned with very little thought about "does this make it cheaper".
The web is merely a small interface substrate. Spread wide sure, but the bulk of the work is shouldered by the backend. I think if there’s a true winner of the web era, it is languages like Java, C#, Ruby, PHP, and Python. There are many codebases tied to those more than they are tied to the UI written in JavaScript.
That's like saying the bulk of all writing ever printed to page was shouldered by the ink (or what about the felled trees; maybe the logging company?). It completely misses the point.
Hmm. That section about "costs a language must reduce" is interesting when read in light of AI.
Implementation time? AI is a huge win, at least in the small. For a multi-year project, I'm not sure yet. (It is, literally, too soon to tell.)
But for new developer onboarding and team maintenance, I'm not sure whether AI is more of a handicap. Yeah, AI can digest a huge mass of code and give you a summary. It can also create a more indigestible mass of code. Is it reducing that cost, or increasing it? (Again, too soon to tell.)
Yes, this sound like it is true. But is it good? I mean, if I accept this idea, I start feeling more like a pet living in the house that is my platform then as a human who creates things. Also, it can be inefficient in that the same program or algorithm ends up being implemented in every language. Also, the article does mention that there is some pain in between programming language, e.g., when writing language bindings. I would push this point a bit further and note that we have too many tools and it is extremely painful to have to know all of them. Nowadays with AI it gets a bit more easy because it can help a lot with unfamiliar tools, but still that sounds like a problem that would not need to be solved if it was not created in the first place. Multiple programming languages tend to multiply the number of tools needed. I have been feeling for decades that C++ is a good language because it can be both low level and high level and can therefore take away the need for multiple programming languages. The world seems to be taking a different course, obviously, and in my opinion it makes people less free and less powerful than they otherwise could be.
Reminds me a bit of a "Comparative Programming Language" class from college. Nice overview!
As noted by sublinear elsethread, surprised that JavaScript didn't get more discussion (though quite interested to read the 189 page PDF: https://www.wirfs-brock.com/allen/jshopl.pdf ), and also surprised that Domain Specific Languages and specialty tools/environments such as Processing didn't come up since they seem one of the obvious end-games of this premise.
I really like very much this essay, and clearly shows my point of view regarding programming language adoption.
While as language geek I consume everything to learn about what is out there, new approaches to programming, paradigms, mindsets, ways to solve problems, in the end work is driven by platforms.
Going in the direction of using languages not embraced by platforms, means one needs to be willing to do yak shaving adding platform support for the given language.
Python is a good example of characteristics that create an 'ecosystem gravity'. If you want to do any data crunching, natural language processing etc you might as well use Python even as as sidecar rather than wrangling with whatever libs are available in another language
On the contrary, language code is what is "authored". The authoring tools are the IDEs, editors, compilers, etc. that we use to produce the executable application.
I'm disappointed there wasn't more written here about Javascript, and more broadly, the web browser. The browser is the platform of the modern era, and Javascript is the strongest example of a programming language being an "authoring tool".
Web apps carry the weight of ecommerce, entertainment, social media, etc. The fact that those apps are frequently at the center of political debate and pop culture underscores their broader success far beyond the discussions that only developers understand.
Along with the HTML and CSS, the code written for the corporate web is not up to the developers alone. You can't ship anything until it's been through far more review by non-technical stakeholders than the devs using other languages may get away with. Yes the quality can vary, but when it's bad it reveals the dysfunction of the organization in a very public way. There's so much cross-discipline human involvement that the developers are in roles that resemble a bureaucrat more than a programmer.
I'm the author. Thanks for pointing this out.
I completely agree with your premise. JavaScript and the browser represent the quintessential modern authoring platform.
I actually wanted to write more about JavaScript, but the problem was that there were fewer cohesive, codified sources to cite than I expected. When writing about this kind of historical narrative, the first issue is always whether there are books you can cite.
JS has undergone organic changes along with the turbulent history of the web itself, but there's no clearly organized history of those changes.(To be more precise, it's not that there are none, but rather that the web environment was so fragmented in its early days, and each piece had its own history. Describing all of it would have required too much time) There is Allen Wirfs-Brock and Brendan Eich's 'JavaScript: The First 20 Years,' but it's so lengthy that I couldn't read all of it, so I had to cite only what I had actually read. That's why I ended up cutting a lot of the JS content. I completely agree with your point, but I hope you understand it was a matter of length constraints.
To me, what makes this so obvious with the web platform is the bureacratic nature of developing for it. To do anything meaningful, you have to bring three departments together (html, css, and javascript). Each is a very different language designed for a different guild of practitioners. You even have the interdepartment turf wars, even if one single person is manning all 3 departments, of which department should accomplish any given task. And each department/platform/language has exteded their capabilities over time to give them more reach to participate in problem solving formerly left to others.
Thanks for your paper btw. I did 20 years of Smalltalk. I came to view Smalltalk programming more like biological culture manipulation (you had a dish of live objects that you morphed into the result you wanted), whereas the conventional file->syntax->executable employed by most development systems is more akin to the industrial factory pipeline of assembling products from raw goods.
During those younger years, money mattered. Tools were sold on the premise that they reduced or mitigated the various costs inherint with employing programmers. And then... around the late 90s, that just kind of dropped from the discussion. As quantitave easing made money available to speculate with and hitting it big with the software that was "eating the world", things like web programming burgeoned with very little thought about "does this make it cheaper".
You can still get Dreamweaver today. :)
https://www.adobe.com/products/dreamweaver.html
The web is merely a small interface substrate. Spread wide sure, but the bulk of the work is shouldered by the backend. I think if there’s a true winner of the web era, it is languages like Java, C#, Ruby, PHP, and Python. There are many codebases tied to those more than they are tied to the UI written in JavaScript.
That's like saying the bulk of all writing ever printed to page was shouldered by the ink (or what about the felled trees; maybe the logging company?). It completely misses the point.
Hmm. That section about "costs a language must reduce" is interesting when read in light of AI.
Implementation time? AI is a huge win, at least in the small. For a multi-year project, I'm not sure yet. (It is, literally, too soon to tell.)
But for new developer onboarding and team maintenance, I'm not sure whether AI is more of a handicap. Yeah, AI can digest a huge mass of code and give you a summary. It can also create a more indigestible mass of code. Is it reducing that cost, or increasing it? (Again, too soon to tell.)
[flagged]