Live data from Hacker News

The Costs of Programming Language Fragmentation

robert.ocallahan.org

111–120 of 167 posts

Re: The Costs of Programming Language Fragmentation

#111
post #73

Earlier quoted context omitted.

And the flaw with your perspective is that if we all followed this advice, we might have a few highly polished bullet proof C libraries to use, but we'd still be stuck writing C and following all of its paradigms.

That's the interesting part. We're better off because of some but not all new languages having been invented.

Sure, but you have to have the bad attempts to learn things that don't work or we won't end up with the good ones. We fall into a local maximum instead of exploring farther and potentially going higher. Every dead end is another bit of the map explored when it comes to creating expressive languages.

Now, is there an argument we'd be better off doing that exploration in a space designed to make DSLs easier than in building entirely new languages? That I dunno but it is worth considering.

Re: The Costs of Programming Language Fragmentation

#112
post #38

So, if we follow the authors logic we should abandon all science because we don't know what they might cause. Innovation is pure by nature. Judgment is done empirical evidence after innovation. You can't change the order.

No. Languages are also, of course, languages, i.e., notation.

If every chemist changed notation every 3 years, there's an off chance that one might develop something better than Hill notation, but it would also make it unbearable to try to read the literature. I don't think it's controversial to suggest that this would be a net loss for the field.

Computer science is young enough that we don't have any universal notation yet, but I've learned a couple dozen programming languages and my conclusion is that maybe 1 new language per decade is worth using. We're churning notation way faster than is productive.

Re: The Costs of Programming Language Fragmentation

#113

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 e…

you just gave me a great idea for a new language, Well actually a big library of ASM code that every other language could write wrappers to to get low level gains on all the boilerplate. Then we could all focus on making that really fast.

Re: The Costs of Programming Language Fragmentation

#114
post #97

Earlier quoted context omitted.

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…

> but with the fact that transitioning to new languages does have a non-trivial cost But this is completely uninteresting. Nobody has claimed that transitioning to a new programming languages doesn't have a non-trivial cost. You're countering a non-existent argument. I mentioned this in my initial reply to you: you're debating a point that is easy to refute. I don't know why, or where the source of confusion is, but…

> This just sounds like a lot of opinion expressed as if it were a fact

It's arguably overstated, but I'm curious if you would argue that there are languages created in the past 15 years that create as big of a productivity boost as Assembly -> C or C -> something with a GC?

Re: The Costs of Programming Language Fragmentation

#115
post #97

Earlier quoted context omitted.

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…

> but with the fact that transitioning to new languages does have a non-trivial cost But this is completely uninteresting. Nobody has claimed that transitioning to a new programming languages doesn't have a non-trivial cost. You're countering a non-existent argument. I mentioned this in my initial reply to you: you're debating a point that is easy to refute. I don't know why, or where the source of confusion is, but…

> Nobody has claimed that transitioning to a new programming languages doesn't have a non-trivial cost.

I was replying to the argument that the work is not at the expense of anything else because it wouldn't happen otherwise.

> This just sounds like a lot of opinion expressed as if it were a fact.

I think it's pretty well supported. The cost of developing software from scratch has not decreased significantly since ~2000 (there have been gains due to the availability of lots of open source libraries). In the mid eighties, Brooks claimed that no single language improvement would give us a 10x productivity gain over a single decade. While at the time his prediction was seen as overly pessimistic, it's been three decadades and we still haven't gained a 10x boost with all improvements combined (barring, maybe, the availability of open source libraries, which has nothing to do with language improvements). You can see clearly that companies are not migrating en-masse to some new language (as they did with assembly->C or C->Java/C#). Instead, many languages are being used, none so far seems to have a definitive advantage that encourages the majority of the industry to migrate. You do see plenty of claims, but no major bottom-line impact that causes decision-makers to say, "we must use that!" as was the case with previous generations, where, BTW, significant advantages became apparent quite quickly.

Re: The Costs of Programming Language Fragmentation

#116
post #106

Earlier quoted context omitted.

there is always a myth that someone with absolute control of resources could more efficiently re-allocate those efforts. But first you have to obtain absolute top down control in order to do so. Very similar to how command-and-control politics schemes could be in theory more efficient than messy democracies, but those messy democracies, while inefficient, produce variety that guard against the much larger errors of m…

It sounds interesting, but I don't really agree with the idea that we can analogize software development with socio-political organization. There are certainly a lot of interesting similarities, but I would be super careful about drawing any conclusions from it.

true, i would offer it more an 'interesting similarities' kind of comment than a call to action.

Re: The Costs of Programming Language Fragmentation

#117
post #39

Earlier quoted context omitted.

Yes, I know that. C++ is also very much used for game development. C++ allows to build very impressive abstractions that are very handy. The main drawback is that this flexibility has a huge impact on the language. When you switch between two projects writen in C++, it is almost as if they were using a different language. I have understood that this language was a mess in 98 when I have bought the standard and read i…

> When you switch between two projects writen in C++, it is almost as if they were using a different language. I strongly disagree. This may have been the case 20 years ago, but most current projects use C++, not some weird -fno-rtti -no-stdinc -fno-whatever sub-language. Maybe they don't use all the features of the standard library, but which project in Java or Python would ?

Well, to me it's like the way Shakespeare, e e cummings, and Kool Keith all write in the same language.

Context switching between working on work codebase, Chromium code base, and various third party C++ codebases is a headache as much for their basic differences in coding style (use of whitespace, capitalization, naming, etc.) as for their wildly varying build/metabuild processes.

And of course, each implements and then extensively uses their own library features like reference-counted pointers, managed GC pointers, collection data structures, iterator-like abstractions, etc.

Re: The Costs of Programming Language Fragmentation

#118

Earlier quoted context omitted.

> but with the fact that transitioning to new languages does have a non-trivial cost But this is completely uninteresting. Nobody has claimed that transitioning to a new programming languages doesn't have a non-trivial cost. You're countering a non-existent argument. I mentioned this in my initial reply to you: you're debating a point that is easy to refute. I don't know why, or where the source of confusion is, but…

> This just sounds like a lot of opinion expressed as if it were a fact It's arguably overstated, but I'm curious if you would argue that there are languages created in the past 15 years that create as big of a productivity boost as Assembly -> C or C -> something with a GC?

I would not argue that, no. I could relate my own personal experiences over the last 15 years, but they wouldn't generalize and might not even be coherent themselves (because I am human and therefore haven't remained immutable).

Re: The Costs of Programming Language Fragmentation

#119

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…

So once Newton figured out the equation for gravity, Einstein should have left it well enough alone? Science rewrites itself all the time, too. That's the point.

What kills me about programming is the ugliness. In natural science, there's an "I know it when I see it" factor of essential simplicity and beauty. We may not know what to work towards, but we know when we've found it. It's hard to improve on F=ma, and it looks it.

In programming, we just keep endlessly tweaking. (Recently I commented here about a non-software job where I had no deadline, and the programmers here were legitimately concerned that lacking a deadline would cause me to "gold-plate" it.) Writing software, I'm having to use a language with 100 reserved words. There's no essential beauty here. It's a million little committee decisions, layered on the legacy systems of today. I guarantee that in 10 years it's going to be replaced by another language which has 100 reserved words, which will make slightly different design decisions, based on the legacy systems of that time.

Programming language design today is almost a random walk. I don't see it converging at all. Everybody takes a slightly different starting point, and then adds all the features from every other popular language. There's no science happening here.

Re: The Costs of Programming Language Fragmentation

#120
post #119

Earlier quoted context omitted.

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…

So once Newton figured out the equation for gravity, Einstein should have left it well enough alone? Science rewrites itself all the time, too. That's the point. What kills me about programming is the ugliness. In natural science, there's an "I know it when I see it" factor of essential simplicity and beauty. We may not know what to work towards, but we know when we've found it. It's hard to improve on F=ma, and it l…

Einstein should not have spent his time endlessly reordering and rephrasing the three laws of motion in pursuit of elegance. He should not have tirelessly advocated for replacing F=ma with F/m=a. And he didn't.
Post reply on HN