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

131–140 of 167 posts

Re: The Costs of Programming Language Fragmentation

#131

Post by tabtab »

burntsushi wrote: post #68
empath75 wrote: post #62

Earlier quoted context omitted.

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, refactore…

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). If language designers don't learn to say no to fads, the language becomes a bloated mess that only a mother can love. Let other suckers test fads for viability, and only add features that are relevant and time-tested for the target audience.

Re: The Costs of Programming Language Fragmentation

#132

Post by honkycat »

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…

Honestly I would just ignore this person @burntsushi .

I actually KNOW who you are from your really consistently excellent work on useful libraries, whereas I have no idea who "pron" is and I suspect he is a troll

Re: The Costs of Programming Language Fragmentation

#133

Post by PeterisP »

flohofwoe wrote: post #107
alexhutcheson wrote: post #99

Earlier quoted context omitted.

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

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 operate directly on the other language's data in memory without at least copying it and often requires a performance-killing transformation of the whole data.

You see that in all kinds of interfaces across language boundaries. Memory layouts, thread safety, (im)mutability, structure ownership or reference counting, handles to external/OS resources, etc, etc.

Every language is an abstraction that relies on certain assumptions, and those particular assumptions are what makes the language good for it's niche. Different languages rely on different, often incompatible assumptions. It's possible to build a wrappers that ensure that the assumptions of the other language are met and interaction with native data structures is possible and convenient (e.g. like Numpy does for Python), but that wrapper needs to be different for different languages and assumptions, it can't be the same library, it needs to behave differently in other languages to meet their expectations.

Re: The Costs of Programming Language Fragmentation

#136

Post by burntsushi »

tabtab wrote: post #131
burntsushi wrote: post #68

Earlier quoted context omitted.

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, refactore…

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.

Re: The Costs of Programming Language Fragmentation

#137

Post by burntsushi »

honkycat wrote: post #132
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…

Honestly I would just ignore this person @burntsushi . I actually KNOW who you are from your really consistently excellent work on useful libraries, whereas I have no idea who "pron" is and I suspect he is a troll

pron isn't a troll. They comment pretty frequently on HN and other places. I generally disagree with their perspective on software development; but we likely have very different experiences.

Re: The Costs of Programming Language Fragmentation

#138

Post by zsck »

casper345 wrote: post #135

Points to the author, just because one can create doesn't mean one should. Should there not be more intentional thought in creating and creations ramifications? "Now I am become Death, the destroyer of worlds."

You can’t seriously be comparing rebuilding arbitrary software to building an atomic weapon.

Re: The Costs of Programming Language Fragmentation

#139

Post by mike_hearn »

elcritch wrote: post #125
amelius wrote: post #123

Earlier quoted context omitted.

You forget that every language has its own ABI, and runtime quirks. Sending a string to a function works differently in C vs Java vs Python vs ... Sending objects with references to other objects (which may need to be GC'ed) is even more difficult.

The Truffle VM stuff takes an interesting approach by (afaik) executing the languages getter/setters and then having a common data format (I presume?). What if someone could make a LLVM version of that?

They already did:

https://github.com/oracle/graal/tree/master/sulong

It's a part of Graal itself now. It runs C, C++, Rust, etc.

Re: The Costs of Programming Language Fragmentation

#140

Post by mike_hearn »

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.

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 never really happened.

And in the more mainstream world, Java 8 invested heavily in parallel streams, but I've never seen an actual parallel stream in real code. I see threads all the time, despite everyone agreeing how awful they are. Parallel streams? Auto-parallelised FP code? No, doesn't happen. The level of parallelism is too small for programmers to think about. Most datasets are too small and most loops too unimportant to even take the risk of a bug creeping in through attempting to use parallelism, regardless of how convenient.

Post reply on HN