Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Costs of Programming Language Fragmentation

robert.ocallahan.org

Post reply on HN
Print view View original

11–20 of 167 posts

Re: The Costs of Programming Language Fragmentation

#11

Post by reacweb »

IMHO, the author is completely wrong and the sentence "C is the desert island language" is closer to reality (see http://www-cs-students.stanford.edu/~blynn/c/intro.html). The fact that such a poor language remains the single sane choice to build the kernel of Linux is a proof of the lack of languages. C++ was already a mess in 98. Python started as simple but has added more and more complex syntaxes. Java is in the hands of Satan, Ada is too verbose, nobody takes the effort to learn it, Haskell and SCALA are niche languages not so easy to learn...

IMHO, there is a need for a polyvalent language that would enable development of Linux kernel (low level and performance), that would be easy to learn and that would enable quick development (dynamic typing, syntactic sugar, ...).

Re: The Costs of Programming Language Fragmentation

#12

Post by chubot »

It's hard to do, but I would like to see more overhauls of existing languages. I wrote a relevant comment about the approach of Checked C vs. Rust here:

https://news.ycombinator.com/item?id=17944310 (tl;dr Software gets rewritten much less frequently than you think. Rust is going to add to the existing ecosystem in C++ and C, not replace it.)

Facebook's Hack is another example of this approach -- an overhaul of PHP. Although I guess it led to 2 languages and not one -- it's not replacing PHP! Like I said, it's hard :)

Re: The Costs of Programming Language Fragmentation

#14

Post by eecc »

Vendorization. For every language out there there is a consulting firm or corporation selling tooling and support. This allows business strategies aimed at market capture and monopolization.

To business, you’re not a general purpose plumber, you’re just a specially trained installer of a particular brand of water boiler.

Re: The Costs of Programming Language Fragmentation

#15

Post by flukus »

DarkWiiPlayer wrote: post #2

That reflects rather well how I feel about the recent DSL craze, specially in the ruby community. It's also how I feel about libraries and frameworks. Programming languages probably suffer the least from this phenomenon due to how difficult it is to create a complete language, with compilers and all. In contrast, languages that just extend others often do benefit from existing communities. Take moonscript¹ for exampl…

Is the DSL craze really new? Look at a lot of the early history of unix and you'll see sh, sed, awk, tex and probably a heap of others that didn't survive. Not to mentions lex/yacc, two DSL's to make DSLs. The idea of specialized languages for specialized tasks has been around for decades.

Re: The Costs of Programming Language Fragmentation

#16

Post by burntsushi »

I also disagree with the premise of this article, and I do not think the argument presented here is compelling at all. The motivations that spur people to do work are complex and diverse, and this article seems to pretend otherwise. For example:

> but it's common for new languages to trigger reimplementation of, e.g., container data structures, HTTP clients, and random number generators. If the new language did not exist, that effort could have been spent on improving existing libraries or some other useful endeavour.

Yes, it could have, but would it? Speaking as someone who has done some of this reimplementation work in a newer language, I can unequivocally say that it would not in my case. I'm just one data point, but I don't think I'm unusual. There is an aspect of greenfield development that is appealing to me. It is a somewhat unique opportunity to execute a vision with a lot of freedom. There is also the benefit of new forms of expression that new tools give you. I'm painting with broad strokes here, but I'm generally a believer in the idea that tools themselves can both limit and empower the expression of ideas.

If it weren't for the new language, I surely would have done something else with my time. I don't know what it would be, but I know it would not be trying to expend the social capital required to make small incremental improvements to existing software using tools that I find too limited. As another commenter mentioned, I might have just watched more Netflix.

Re: The Costs of Programming Language Fragmentation

#17

Post by jacquesm »

hvidgaard wrote: post #7
jacquesm wrote: post #4

Earlier quoted context omitted.

> it's difficult to separate ahead of time which efforts will move us forward in some small or large ways. That's the point: most efforts do not move us forward but instead move us backwards because fewer people are working on the things that matter. It's a solid argument and it applies to far more of the open source community than just to programming languages, in fact programming languages are the smaller part of t…

> the long term commitment should be there if you are going to let other people run their production systems on what you throw into the world If you adopted a language that is not mature for production, then you knew the risk when you made that choice. Innovation in PL happens with these small languages, and it's a good thing.

> If you adopted a language that is not mature for production, then you knew the risk when you made that choice.

True, but at the same time I can't help but think that a few hundred programming languages are all equally useful and all equally deserving of their continued existence.

> Innovation in PL happens with these small languages, and it's a good thing.

I do not see the author as having any beef whatsoever with 'small languages used for innovation', I think he has a beef with small languages that pretend to have staying power behind them when in fact they do not.

Quite a bit of this stuff is people experimenting and making a 'me-too' version of something, and I have done this many times myself. But once you release a thing like that into the world you should be ready to step up and commit to it. If not then you might as well keep it to yourself.

Re: The Costs of Programming Language Fragmentation

#18

Post by smadge »

DarkWiiPlayer wrote: post #2

That reflects rather well how I feel about the recent DSL craze, specially in the ruby community. It's also how I feel about libraries and frameworks. Programming languages probably suffer the least from this phenomenon due to how difficult it is to create a complete language, with compilers and all. In contrast, languages that just extend others often do benefit from existing communities. Take moonscript¹ for exampl…

An example that comes up often for me are EDSLs for database queries. I do see the value of them, but on the other hand it causes you to move away from a “lingua Franca” of database querying to a programming environment specific one. What probably makes sense is 1) evolving SQL or SQL tooling to support more features that people think they need (an example that comes to mind is type safe queries) and 2) better support for binding these queries to different languages.

Re: The Costs of Programming Language Fragmentation

#19

Post by fnord123 »

a_imho wrote: post #6
jacquesm wrote: post #4

Earlier quoted context omitted.

> it's difficult to separate ahead of time which efforts will move us forward in some small or large ways. That's the point: most efforts do not move us forward but instead move us backwards because fewer people are working on the things that matter. It's a solid argument and it applies to far more of the open source community than just to programming languages, in fact programming languages are the smaller part of t…

The fact is that it takes effort to launch a new programming language beyond just writing some code and the long term commitment should be there if you are going to let other people run their production systems on what you throw into the world. From my admittedly limited knowledge JavaScript seems to contradict this claim. I don't agree with the article either, one could make the same argument for every piece of new…

>I don't agree with the article either, one could make the same argument for every piece of new code written.

No you can't. The issue is that languages generally have their own runtime and object linkage system. If you create a new one that doesn't play nicely with C linkage/runtime, JVM, .Net, or compiles down to javascript (or wasm) then you are creating an entirely new platform and this creates the fragmentation.

For example, Python and Rust play nicely with C linkage. Scala runs on the JVM. These play nicely with other systems. You can have Python code that calls Rust code that calls C code and it all fits together. But you may struggle to have Python code calling Lua code calling Julia code.

"every piece of code written" doesn't have this problem at all. If you write something in an existing language then you are contributing to that ecosystem instead of making a new ecosystem. And if you are making a new ecosystem, for pity's sake please consider making that ecosystem play nicely with at least one existing ecosystem.

Re: The Costs of Programming Language Fragmentation

#20

Post by jacquesm »

a_imho wrote: post #6
jacquesm wrote: post #4

Earlier quoted context omitted.

> it's difficult to separate ahead of time which efforts will move us forward in some small or large ways. That's the point: most efforts do not move us forward but instead move us backwards because fewer people are working on the things that matter. It's a solid argument and it applies to far more of the open source community than just to programming languages, in fact programming languages are the smaller part of t…

The fact is that it takes effort to launch a new programming language beyond just writing some code and the long term commitment should be there if you are going to let other people run their production systems on what you throw into the world. From my admittedly limited knowledge JavaScript seems to contradict this claim. I don't agree with the article either, one could make the same argument for every piece of new…

JavaScript is a pretty good example of a language that overshot its goal and that would have benefited from evaluating the cost of its release. It was put together in a hurry, without much in terms of forethought and we're paying the price every day.

> I don't agree with the article either, one could make the same argument for every piece of new code written.

So you do agree. Yes, you could make the same argument for every piece of code, and that's precisely the point, the author chose to use programming languages where the problem is the the least visible. But that does not invalidate the point, it strengthens it.

Post reply on HN