Live data from Hacker News

The Costs of Programming Language Fragmentation

robert.ocallahan.org

91–100 of 167 posts

Re: The Costs of Programming Language Fragmentation

#91

Earlier quoted context omitted.

You introduced B: >if you are going to let other people run their production systems on what you throw into the world But in fact, if we talking about "production systems", it's usually companies, rather than people.

I introduced 'B', but not as the second arm of a binary choice. Note that lots of the companies that deploy open source also contribute to that open source, in fact, if you removed such paid contributions to the open source world then you likely would not have much to run in the first place. But that doesn't mean that there isn't a cost to fielding a new programming language due to fragmentation, which is the subject…

>but not as the second arm of a binary choice

There very clearly are two parties in a binary situation, and it is implicit in what you wrote:

A. The unpaid programmer who created the new language. Apparently, because she/he negligently "let other people run their production systems" on the new language, somehow she/he has a moral obligation to support this commercial use of the new language until her/his dying day.

B. The people and companies (in fact mainly companies) using the new programming language in production who are not just "some people playing around". These entities presumably chose to use some hot new language in production, because it might solve some business problem. Apparently, they don't have any moral responsibility whatsoever to have a plan in place for what to do if the apparently critical individual who created the new language walks away - for example contracting or employing either the original programmer, or suitable substitutes perhaps.

>if you removed such paid contributions to the open source world then you likely would not have much to run in the first place

That's very true, but also completely irrelevant to the case under discussion. We're talking about new programming languages created by an unpaid programmers, and still critically dependent on unpaid programmers.

>But that doesn't mean that there isn't a cost to fielding a new programming language due to fragmentation

Sure there is cost - I don't disagree. Though, there is also a loss-of-innovation cost of not creating new programming languages.

My objection is that both you and the author of the article are being coercive, invoking morality in an attempt to control unpaid programmers who are not obligated to you, or to society, and certainly not obligated at all to people/companies that chose freely to use their work in production.

Re: The Costs of Programming Language Fragmentation

#92

Earlier quoted context omitted.

> There's absolutely nothing wrong with either of these things Sure. But note the OP used the word "irresponsible," so I'd say you're actually disagreeing with the OP, and not me. :-) > I think there is a strong tendency of people programming in new languages to be overly convinced of the elegance and superiority of their new language as a result of (a) getting to rewrite software without the burden of those fussy, i…

Richard Hamming had a pithy line about this (I believe this is the origin of the phrase "In computer science, we stand on each others feet"): Indeed, one of my major complaints about the computer field is that whereas Newton could say, "If I have seen a little farther than others, it is because I have stood on the shoulders of giants," I am forced to say, "Today we stand on each other's feet." Perhaps the central pro…

There's just as much wasted effort, not-invented-here attitude, and standing on each others' feet in the hard sciences as there is in computer science. The reason why it's so much more visible in this field, is that the financial barrier to entry is so incredibly low – all you need is a cheap computer, which you already have anyway. If doing physics experiments was as cheap as programming, a lot more people would build fusion devices for fun in their garage [1]. They also wouldn't advance actual fusion research, nor would they hinder it, and yet some distinguished physicists would lament that "in physics, we stand on each others feet".

[1] https://en.wikipedia.org/wiki/Fusor

Re: The Costs of Programming Language Fragmentation

#93
He‘s right about the cost, but it‘s surely smaller than the cost of bloated protocols, specifications, reference implementations. Nobody except large corporations is able to implement a competitive web browser, for example, regardless of the language. New languages would be much less of an issue with clean API designs and specifications.

Re: The Costs of Programming Language Fragmentation

#94
post #25

How about the reverse problem? The cost of mindshare. Everyone grouping up on a major programming language or framework. It's a bit irritating when people often choose their language or framework because of the size of the community rather than actually evaluating alternative languages or frameworks first. Take React for example. There are some great alternatives to it, especially inspired by react but simpler & clea…

I can't speak to React, but I definitely see this happening with Java. To the point where I've watched people make conscious decisions to the effect of, "Sure, I do think Kotlin is a superior language that will allow us to work better and faster, but everyone already knows Java, and we feel more comfortable sticking with the mainstream."

:shrug: I like to be a bit more flexible than that, but I suppose there is something to be said for consistency.

Re: The Costs of Programming Language Fragmentation

#97
post #77

Earlier quoted context omitted.

> You're using "real software" to presumably denote some dichotomy of software that doesn't exist. I think that what I meant was clear from context: software that has a long-term, significant impact. > then you also need to consider the impact of improved tools on the costs of maintenance Sure, but however much maintenance costs, it still needs to be done. It cannot be carried long by a novelty factor. > New ideas sh…

Most new things suck. But every now & then something new AND cool comes along, making all of the old stuff less relevant. For me, Elixir was yet another language to learn, and was just a reimplementation of another language. But when I used it, I was like "whoa, this is sweet!" You gotta build something new when you can't find something old that does what you wanna do.

My point has nothing at all to do with what sucks and what's cool, but with the fact that transitioning to new languages does have a non-trivial cost, for individual organizations as well as to the industry as a whole. Moreover, productivity gains from new languages seem to have plateaued a couple of decades ago (except from some niches, such as system programming, that have seen little change in the past 20-30 years). I.e., we no longer see the same productivity boosts as we did going from Assembly -> FORTRAN, from FORTRAN -> C, or from C -> Java (and even then, the gains were smaller with each jump). Fred Brooks predicted in the '80s this would happen, and reality has shown even smaller gains than he had predicted. Part of the reason for the growing fragmentation is precisely because no language has stood out as a clear leader.

Re: The Costs of Programming Language Fragmentation

#98

Isn't this a pretty trivial case of exploration vs exploitation? Clearly we need both. The more interesting question for me is why we still don't have a widely adopted approach to sharing libraries across languages. The most promising approach I have seen in recent decades was Microsoft's COM. But it has declined along with Microsoft's clout. Unfortunately, current industry leaders don't seem to be interested in this…

> widely adopted approach to sharing libraries across languages

For platform libraries we do; it's called FFI. Your language can use openssl or libxml or whatever, so can mine. It is more general than COM; COM is a specific ABI (that we can target with FFI).

Language-specific libraries are tied to language semantics, because language-specific objects pass across language-specific calling boundaries. We don't think about using Python dictionaries from Guile Scheme and such.

Re: The Costs of Programming Language Fragmentation

#99

I really believe that it is better to have many small 'throw-away' programming languages that can interoperate with each other, than having a few huge languages that are isolated in their own ecosystem. A language shouldn't be complex nor should it take more than a few days to learn, and it should be easy to abandon when another language is better suited for a problem. What actually makes many languages useful is the…

Function calls between languages are typically expensive and difficult to implement. Each language generally has its own expectations about the layout of data in memory, which means that for language A to call a function written in language B, it needs to set up a block of memory in the layout expected by language B. This normally involves a lot of copying, which adds overhead to the function call.

There also needs to be some code that does this copying, and this code needs to be implemented for every pair of languages. Alternatively, all the languages can agree on a common interface level (C, JVM, .NET, etc.), but in this case most languages won't get a function interface that feels native to the language.

Re: The Costs of Programming Language Fragmentation

#100

Earlier quoted context omitted.

> There's absolutely nothing wrong with either of these things Sure. But note the OP used the word "irresponsible," so I'd say you're actually disagreeing with the OP, and not me. :-) > I think there is a strong tendency of people programming in new languages to be overly convinced of the elegance and superiority of their new language as a result of (a) getting to rewrite software without the burden of those fussy, i…

Richard Hamming had a pithy line about this (I believe this is the origin of the phrase "In computer science, we stand on each others feet"): Indeed, one of my major complaints about the computer field is that whereas Newton could say, "If I have seen a little farther than others, it is because I have stood on the shoulders of giants," I am forced to say, "Today we stand on each other's feet." Perhaps the central pro…

>Science is supposed to be cumulative, not almost endless duplication of the same kind of things.

Yes, but inventing new languages and building libraries for them has nothing to do with science. Nor is science even a motivator for these endeavours.

We're not talking computer science here. We're talking implementation details.

Post reply on HN