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

151–160 of 167 posts

Re: The Costs of Programming Language Fragmentation

#151

Post by nescoiquid »

tabtab wrote: post #130
ken wrote: post #119

Earlier quoted context omitted.

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…

If agree. Our industry is subject to poorly-vetted fads. For example, a few years ago everyone was talking about functional programming and lambdas: the yet another newest "magic Legos". Most of the examples given to justify it were either unrealistic to the real world ("lab toys"), or could have been done with OOP if the OOP engine of the language were better. Lambda's were essentially patching bad OOP, per attachin…

Or, new languages and language features just steal and adapt from Common Lisp (it's okay, that was just a joke, geeze). I never felt the availability of nearly any programming paradigm ever marred my experience in working in Lisp or made the language any less coherent.

If a fad is just a rediscovery (renewed interest in) some programming paradigm, they will all be familiar to you when they come back around. Hopefully your language incorporates it gracefully. I'm a little circumspect about how Java's lambdas turned out, but I'm not certain it could have actually been otherwise.

So, I don't think it is the inclusion of multiple programming paradigms in your language that is troubling, but rather how it incorporates them. One of the first pieces of advice (and very good advice) in Effective C++ is something to the effect of a) acknowledge that C++ is really a federation of smaller languages, and b) at the outset of a project, explicitly decide which parts the project will use, and which parts it won't.

Re: The Costs of Programming Language Fragmentation

#152

Post by burntsushi »

tabtab wrote: post #150
burntsushi wrote: post #149

Earlier quoted context omitted.

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

You've pretty drastically changed topics. I have no interest in a language design debate with someone who thinks of lambdas as "magic Legos." As I said before, our conceptions of reality are so drastically different that it would be a gratuitous waste of my time.

You've gone from "parallelism is a fad" to "let's subjectively evaluate language design based on my ideas of parsimony." Parallelism isn't some kind of language feature I'm touting. It's an implementation tactic that can be used to make certain programs faster. Before such tactics were common, it was easy to write programs that were blissfully unaware of it in such a way that it is difficult to bolt on later. I used parallelism as one possible example of something that would be incredibly difficult to add to older programs to combat the notion that we should stop re-inventing the world and instead improve older stuff.

Like most things in this world, parallelism can be misused. This is hardly interesting and really doesn't need to be pointed out. Moreover, the degree to which parallelism can be wielded effectively will, in part, depend on your tools. Some tools make parallelism easier to use or reason about than other tools do. With that said, even that was immaterial to my point, because I wasn't doing a comparative analysis of parallelism across programming languages. I was just using it as an example of a concrete improvement that one could make to older programs that is often not practical to do, precisely because they are older programs that are widely used. Parallelism isn't the only example of this kind of improvement; jerf provided other examples in this thread. But parallelism is an easy one to grasp because most programmers with a few years of experience can appreciate what it's like to refactor a large program that is deeply coupled to unsynchronized shared global mutable state to a program that isn't---which is generally a good idea if you want to add parallelism to it.

Your initial response to this was:

> I'm sorry, but the need for parallelism is exaggerated; it's mostly a fad.

But this is completely pointless. That parallelism is a useful way to make a program faster is taken as axiomatic in my comment. There is enough of my code (and others) out in the wild that uses parallelism to achieve some concrete measurable improvement that I feel it is obviously true and really doesn't need any further explanation. But here you are, nitpicking at an axiom with a bunch of nonsense about "fads," and completely missing my point in the process.

Re: The Costs of Programming Language Fragmentation

#153

Post by glangdale »

BeetleB wrote: post #100
glangdale wrote: post #83

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…

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

Welp, people can choose what they want to work on. You could invest your time in building something new (computer science?) or working on reimplementing things in the One True Language (implementation details).

Re: The Costs of Programming Language Fragmentation

#154

Post by glangdale »

My "side" take on this is that as long as reimplementation is considered an urgent activity with each new language, we may be privileging languages that are actually better for rebuilding things that are already well understood over languages that are better for "feeling our way through problems".

I'm not 100% sure of this point, but it feels at least possible that features that make a language good for reimplementing a problem with the structure known in advance might be awkward for exploratory work. I've built a bunch of stuff recently where I had NFI what I was doing as I went along and had to tear up vast tracts of the data structures as I went; it was good to have the fairly loosey-goosey typing of a mix of C/C++ and (effectively) asm to do it (while still being able to see performance levels of aggressive optimization, which was also part of the goal).

Re: The Costs of Programming Language Fragmentation

#155

Post by mpweiher »

mike_hearn wrote: post #142
PeterisP wrote: post #133

Earlier quoted context omitted.

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.

Well, for an interesting definition of "solves". As far as I can tell, it effectively introduce a new (implementation-)language, the Truffle language and then adds implementations of language front-ends that compile to this Truffle language.

Which can be functionally adequate for some, maybe many use-cases, but is not the same as actual interoperability.

Re: The Costs of Programming Language Fragmentation

#156

Post by mpweiher »

reacweb wrote: post #11

IMHO, the author is completely wrong and the sentence "C is the desert island language" is closer to reality (see http://www-cs-students.stanford.edu/~blynn/c/intro.html ). The fact that such a poor language remains the single sane choice to build the kernel of Linux is a proof of the lack of languages. C++ was already a mess in 98. Python started as simple but has added more and more complex syntaxes. Java is in the…

> The fact that such a poor language remains the single sane choice to build the kernel of Linux is a proof of the lack of languages.

Or a deep lack of understanding in our field as to what actually makes a good programming language?

Re: The Costs of Programming Language Fragmentation

#158

Post by tabtab »

burntsushi wrote: post #152
tabtab wrote: post #150

Earlier quoted context omitted.

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

You've pretty drastically changed topics. I have no interest in a language design debate with someone who thinks of lambdas as "magic Legos." As I said before, our conceptions of reality are so drastically different that it would be a gratuitous waste of my time. You've gone from "parallelism is a fad" to "let's subjectively evaluate language design based on my ideas of parsimony." Parallelism isn't some kind of lang…

Re: "let's subjectively evaluate language design based on my ideas of parsimony." -- I didn't claim that. I don't know where you got it. Note that "less code to do X" is often the claim made, and "code size" is probably the most objective metric available to compare techniques (but still imperfect). "Number of lines needing changes per change request X" is another. Other claim types such as "elegant" is often in the eye of the beholder. There is no universally accepted ruler (metric) for "elegant".

And I'm not against SOME parallelism support in app languages. It's just my experience that if you "need" to do it A LOT in applications, you are probably doing something wrong.

Re: "Like most things in this world, parallelism can be misused. This is hardly interesting and really doesn't need to be pointed out." -- Fads tend to greatly increase the % of misuse.

And lambdas and OOP do fight over similar territory, or at least can if the language has certain features. For example, Java coders may say, "I need lambdas here because OOP can't do what I need." But it turns out Java's OOP can't do what's needed, not something inherent in OOP.

Anyhow, English is often not sufficient by itself to clarify such debates; we'd need specific code samples and scenarios to explore.

Re: The Costs of Programming Language Fragmentation

#159

Post by tabtab »

alexhutcheson wrote: post #99
flohofwoe wrote: post #31

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

Php took the approach of implementing many of its libraries using existing C libraries. They may change the parameters and packaging, but they are only reinventing the interfaces, not the implementation. It's one of the reasons for Php's early success, despite being a somewhat clunky language.

Therefore if anyone out there wants to invent Yet Another Language, try to piggyback on existing C libraries to speed up library creation.

Re: The Costs of Programming Language Fragmentation

#160

Post by tabtab »

glangdale wrote: post #153
BeetleB wrote: post #100

Earlier quoted context omitted.

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

Welp, people can choose what they want to work on. You could invest your time in building something new (computer science?) or working on reimplementing things in the One True Language (implementation details).

The industry doesn't seem to perfect any one thing; instead flickers off for the next shiney fad. For example, both OOP and FP offer (or can offer [1]) "abstraction". One can perfect their skills in OOP to solve similar abstraction problems that somebody who perfected their FP skills can solve in FP. If the industry stuck with or the other, people could use them more effectively by shere experience (including language improvements). But mixing them together in random and different ways just confuses more than it helps. (I'm talking average programmer here, not Sheldon Coopers.) It's collective Attention Deficit Disorder.

[1] Languages can and do implement one or the other poorly.

Post reply on HN