The Costs of Programming Language Fragmentation • Hacker News Board

Re: The Costs of Programming Language Fragmentation

#141

Post by mike_hearn » Tue, Oct 02, 2018, 9:41 PM UTC

BeetleB wrote: post #101

zimbatm wrote: post #82

How much of the new languages are supported by a new fresh wave of engineers that want to learn things? To become a good engineer I had to go through implementing my own container types, play with my own little databases and network libraries, implement a build system, ... I published a few of those experiments in Ruby, the new/hip language at the time. Picking a fresh language seems the obvious playground to do this…

That was my first thought when I read the post: He's discounting the fact that by doing this, many programmers are gaining in expertise. It's not a given that those programmers would grow their skill set as much otherwise. Advancing the state of the art in a well established language requires a lot more skills than implementing simple libraries for a new language.

Yeah, but they could write potentially useful apps or features, instead of badly re-writing libraries that already exist.

Re: The Costs of Programming Language Fragmentation

#142

Post by mike_hearn » Tue, Oct 02, 2018, 9:43 PM UTC

PeterisP wrote: post #133

flohofwoe wrote: post #107

Earlier quoted context omitted.

Agreed, but I think those problems should be solved, the same way LLVM solved the N:M frontend:backend problem :) It's very likely that interacting with such a generic library interface doesn't feel native to the language, but I think it doesn't have to be a monstrosity like DOM or CORBA.

IMHO these problems are fundamentally unsolvable, often because the data models are incompatible (the fundamental behavior and benefits of language A relies on their data structures having trait X; and the fundamental behavior and benefits of language B relies on their data structures not having trait X), so a library written in one language can't just accept nontrivial data from the other, it can't be allowed to ope…

Truffle solves these problems. Accessing foreign data layouts results in the access patterns of the foreign language being inlined and compiled into the accessing language. In other words data adaptation is done just-in-time and at the read site, rather than by copying entire data structures ahead of time.

Re: The Costs of Programming Language Fragmentation

#143

Post by michaelmrose » Tue, Oct 02, 2018, 9:45 PM UTC

delhanty wrote: post #91

jacquesm wrote: post #81

Earlier quoted context omitted.

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…

People are somehow obligated by what I perceive as the groups interests but are really my interests is an argument I see regarding linux distributions.

Perceptibly insert distro here which I use would be better off if it had more labor. Therefore people should all focus their efforts on fewer distros including the one I use.

Therefore people are harming the ecosystem by making yet another Ubuntu derivative with a slightly different graphical environment/default set of packages/settings.

Scratch the surface and they are annoyed by things like hardware support or long unfixed bugs/feature requests because the guys making Ubuntu knock offs are totally going to be capable AND willing to learn how to hack on drivers for insert hardware or fix insert project here before they rewrite it again or add features that the underlying project wontfix

Re: The Costs of Programming Language Fragmentation

#144

Post by roca » Tue, Oct 02, 2018, 10:04 PM UTC

burntsushi wrote: post #66

pron wrote: post #44

Earlier quoted context omitted.

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 "rea…

> I don't really appreciate the debate tactic of pretending that I made a stronger claim that I actually did.

Ahem.

> 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.

I (OP) agree that it is "not necessarily true", and my post deliberately made the very weak claim that "in some cases" "it could be irresponsible". I don't see how I could have made the argument "more measured" without eliding it completely.

Re: The Costs of Programming Language Fragmentation

#145

Post by burntsushi » Tue, Oct 02, 2018, 10:16 PM UTC

roca wrote: post #144

burntsushi wrote: post #66

Earlier quoted context omitted.

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 "rea…

> I don't really appreciate the debate tactic of pretending that I made a stronger claim that I actually did. Ahem. > 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. I (OP) agree that it is "not necessarily true", and my post deliberately made the very weak cl…

Your OP makes several generalizations, and I disagree with almost every single one of them. So no, from my perspective, your position really isn't measured at all.

> I don't see how I could have made the argument "more measured" without eliding it completely.

Exactly.

Re: The Costs of Programming Language Fragmentation

#146

Post by tabtab » Tue, Oct 02, 2018, 10:18 PM UTC

burntsushi wrote: post #136

tabtab wrote: post #131

Earlier quoted context omitted.

I'm sorry, but the need for parallelism is exaggerated; it's mostly a fad. It greatly complicates language design and debugging such that it should be added and used with care. Systems software (OS, networking, database engines, etc.) do indeed need good support for it, but the majority of domain applications only need basic support for parallelism (unless you are doing something silly, like reinventing a database).…

Parallelism is certainly not a fad. We have such different conceptions of the reality around us that it's not even worth arguing with you (in particular, after seeing your other comment about the Evils of Lambdas). I'll happily play your role of the "sucker." Moreover, you missed my point, unless you're genuinely making an argument for radical ludditism.

I've been in a good many debates about the practically of lambdas and parallelism for typical application development[1], and I stand by my claim. My opponents failed to give sufficient practical examples that stood up to scrutiny. Granted, some of it is subjective, but the fact it's subjective means it's not a necessity.

True, sometimes it's good to have more than one way to do something, but sometimes it also creates a bigger and unnecessary learning curve. In the cases I looked at, making better OOP would result in a simpler language than adding lambdas, at least in my judgement. I'd be glad to debate it further, but this is not the best forum for such.

[1] Some argue the same languages should be used for systems software and applications development. I don't agree.

Re: The Costs of Programming Language Fragmentation

#147

Post by roca » Tue, Oct 02, 2018, 10:22 PM UTC

burntsushi wrote: post #66

pron wrote: post #44

Earlier quoted context omitted.

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 "rea…

FWIW an example of behaviour I would consider irresponsible would be if a large company liked Rust but didn't like not controlling it, so decided to clone or fork Rust and use their resources to popularize that (instead of just putting those resources into Rust itself).

Re: The Costs of Programming Language Fragmentation

#148

Post by burntsushi » Tue, Oct 02, 2018, 10:23 PM UTC

mike_hearn wrote: post #140

burntsushi wrote: post #136

Earlier quoted context omitted.

Parallelism is certainly not a fad. We have such different conceptions of the reality around us that it's not even worth arguing with you (in particular, after seeing your other comment about the Evils of Lambdas). I'll happily play your role of the "sucker." Moreover, you missed my point, unless you're genuinely making an argument for radical ludditism.

He said it's mostly a fad, not entirely. Obviously parallelism is frequently very useful. I think what he was getting at is that the idea of languages integrating parallelism such that almost all code would be parallel all the time has proven to be a dead end. For the functional language research world promised for a long time that the main benefit for FP was automatic parallelism (no mutable states, you see). But it…

> I think what he was getting at is that the idea of languages integrating parallelism such that almost all code would be parallel all the time has proven to be a dead end.

But that's obviously not what I was talking about. I wasn't even talking about parallelism in the context of language design. If an old tool is written in C and uses shared global mutable state so extensively as to make a performance boost from parallelism so impractical as to require a rewrite, then that's exactly the thing stopping people from "just" redirecting their efforts to improving old software. Because sometimes small incremental improvements aren't enough, and getting the buy-in to do a full rethink of an old tool takes tremendous social capital. And this is just about improving the old tool using its existing language---this isn't about going and using a new language with better support for parallelism. (Which, by the way, comes in many flavors.)

At no point did I talk about fancy parallelism related language features. At no point did I say that we should just go and add parallelism to an old program because that's what all the cool kids are doing. I framed it as a specific solution to a specific problem: making the old program faster. People like faster programs and speed ain't a fad. If you want to bring in examples of adding parallelism that don't improve performance, then great, but leave me out of it, because at no point did I advocate that.

I think your interpretation of tabtab's comment is a real reach, but whatever. Particularly given their other comments denouncing the evils of lambdas. Really? Give me a break.

Re: The Costs of Programming Language Fragmentation

#149

Post by burntsushi » Tue, Oct 02, 2018, 10:29 PM UTC

tabtab wrote: post #146

burntsushi wrote: post #136

Earlier quoted context omitted.

Parallelism is certainly not a fad. We have such different conceptions of the reality around us that it's not even worth arguing with you (in particular, after seeing your other comment about the Evils of Lambdas). I'll happily play your role of the "sucker." Moreover, you missed my point, unless you're genuinely making an argument for radical ludditism.

I've been in a good many debates about the practically of lambdas and parallelism for typical application development[1], and I stand by my claim. My opponents failed to give sufficient practical examples that stood up to scrutiny. Granted, some of it is subjective, but the fact it's subjective means it's not a necessity. True, sometimes it's good to have more than one way to do something, but sometimes it also creat…

I see your debates and raise you practice. I've done plenty of typical application development that makes practical use of lambdas and parallelism for great benefit.

Re: The Costs of Programming Language Fragmentation

#150

Post by tabtab » Tue, Oct 02, 2018, 11:12 PM UTC

burntsushi wrote: post #149

tabtab wrote: post #146

Earlier quoted context omitted.

I've been in a good many debates about the practically of lambdas and parallelism for typical application development[1], and I stand by my claim. My opponents failed to give sufficient practical examples that stood up to scrutiny. Granted, some of it is subjective, but the fact it's subjective means it's not a necessity. True, sometimes it's good to have more than one way to do something, but sometimes it also creat…

I see your debates and raise you practice. I've done plenty of typical application development that makes practical use of lambdas and parallelism for great benefit.

I'm not saying they "don't work", only that other features/designs can often do them also without using/adding new constructs: parsimony of language features. Can you suggest a forum to continue such debates? If not, I'll see what I can find. (My past favorite forums died.)