Live data from Hacker News

The Costs of Programming Language Fragmentation

robert.ocallahan.org

61–70 of 167 posts

Re: The Costs of Programming Language Fragmentation

#61

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…

> why we still don't have a widely adopted approach to sharing libraries across languages

We have C, lots of languages use C libraries. Pick a random language and it probably has OpenSSL bindings.

Re: The Costs of Programming Language Fragmentation

#62

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…

There’s a low-hanging fruit element to new languages as well. Reimplementing is a lot easier than improving, since improving a well understood algorithm requires invention and redoing something only requires research.

Re: The Costs of Programming Language Fragmentation

#63

Earlier quoted context omitted.

Which is more immoral, A or B? A. An unpaid programmer choosing to walk away from their open-source project. B. The world's richest companies running their production systems on open-source, but failing to adequately fund development. Here's the best example: OpenSSL and HeartBleed up until 2014 [0]. >Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL > IBM, Intel, Microsoft, Facebook, Google, and ot…

I think there are quite a few more choices available than your 'A' and 'B'.

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.

Re: The Costs of Programming Language Fragmentation

#64
Thankfully most of the comments here on HN argue:

a) Your advice on how I spend my free time is not welcome,

b) Same ideas that apply to science apply to FLOSS code. You can do and share you research.

And completely disagree with the idea that if I publish some code I do a commitment to maintain that code. That's written in most (all?) FLOSS license: this software comes with no warranty.

Re: The Costs of Programming Language Fragmentation

#65
post #24

I don't agree. With times languages become obsolete, so from one side they try to "upgrade" their syntax, semantic and internal, from the other side they keep backward compatibility. Keep adding features on top of something that was not designed for those features will simply create a huge mess to work with. And arguably the oldest languages are the one where you need to follow "best practise", where there are thousa…

I don't think languages progress evolutionary like species. None will probably succeed, but we will have a lot more variety of languages for anything we can think of.

Re: The Costs of Programming Language Fragmentation

#66
post #44

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…

There are a couple of problems with your perspective: 1. Even if re-implementation of libraries in new languages were free due to an excitement factor, real software is not built this way. New languages become old, and software needs maintenance. So what you get for free (supposing you're right) is not worth very much and not what counts, anyway. Most of the cost and value is in prolonged maintenance, which has to be…

I don't really appreciate the debate tactic of pretending that I made a stronger claim that I actually did. In particular, I didn't claim or imply that re-implementation of things was "free." It is much much easier to demonstrate that claim as ridiculous as opposed to the more measured perspective that I actually expressed.

> real software is not built this way

This is a bullshit say-nothing phrase. You're using "real software" to presumably denote some dichotomy of software that doesn't exist. If you asked 10 people to define what "real software" actually meant, you'd get 10 different definitions. They might agree on the extremes; but there's a whole mess of crap in the middle that we could endlessly debate about.

> New languages become old, and software needs maintenance. So what you get for free (supposing you're right) is not worth very much and not what counts, anyway. Most of the cost and value is in prolonged maintenance, which has to be done for multiple implementations in parallel.

This isn't clearly true at all.

I mean, if you're going to talk about maintenance, then you also need to consider the impact of improved tools on the costs of maintenance. If a tool makes maintenance easier or less costly, then it's pretty hard to say anything definitive about long term costs. New tools can and do impact the usage of old tools, which in turn can have a direct impact on long term maintenance costs.

> It's reasonable to assume that work is never really free. But if we're hypothesizing about alternate realities, you may as well imagine that instead of new languages something else is invented to motivate you to do free work.

Absolutely! But that's not the argument I'm countering. I'm specifically countering the notion that new language development can be "irresponsible" because it "could" divert work away from other projects. What I'm saying is that it is not necessarily true at all.

There is a more measured argument to be made here, but the OP did not make it.

New ideas should be born and die in accordance with the resources of folks willing to keep them alive. We don't need some grand notion of "responsibility" to control the ebb and flow of ideas.

Re: The Costs of Programming Language Fragmentation

#67
post #58

Programming languages and libraries are not universally expressive or useful and are not of universally good quality. New independent languages and reimplementations are necessary to better express problems and therefore reduce defects and maintenance costs. They are also necessary for anything of quality to emerge, for all the right people to make all the right choices. Incidentally this is one of the reasons that p…

Im not sure where javascript falls along this.

A painful language that I can use everywhere exists.

Re: The Costs of Programming Language Fragmentation

#68

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…

There’s a low-hanging fruit element to new languages as well. Reimplementing is a lot easier than improving, since improving a well understood algorithm requires invention and redoing something only requires research.

Definitely. Also, there can be flaws in the actual implementation of older tools as well. I'm going to avoid diving into specifics because it would be a distraction, but I know more than a few older tools that would benefit from parallelism. They were written in a time where parallelism wasn't as ubiquitously supported as it is today, and thus, the entire implementation would need to be carefully rethought, refactored and possibly rewritten to grow that benefit. We're talking shared global mutable state, everywhere.

Even if you had the person with the expertise, time and motivation to do the work to improve the implementation, you still aren't even guaranteed that the enterprise will succeed. You'll need immense social capital to even convince others that it's actually the right thing to do. Just think of all the new bugs that will be introduced. The angry users. The headache. The added maintenance burden and the pressure from trying to fix the new bugs quickly. It's an absolute nightmare and it's why it doesn't happen, IMO. It's also why starting anew is so much easier and so much more enticing. When you don't have any users, that's when you can really innovate.

Post reply on HN