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

161–167 of 167 posts

Re: The Costs of Programming Language Fragmentation

#161

Post by tabtab »

nescoiquid wrote: post #151
tabtab wrote: post #130

Earlier quoted context omitted.

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…

Lisp is arguably too abstract for rank-and-file use. For more on this hypothesis, search below (Ctrl F) for "Domain-specific languages tend to herd people into certain styles and idioms, making cross-staff reading easier, even if it's more typing. Standardization often trumps linguistic parsimony in real-world work."

Re: The Costs of Programming Language Fragmentation

#162

Post by lispm »

tabtab wrote: post #161
nescoiquid wrote: post #151

Earlier quoted context omitted.

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…

Lisp is arguably too abstract for rank-and-file use. For more on this hypothesis, search below (Ctrl F) for "Domain-specific languages tend to herd people into certain styles and idioms, making cross-staff reading easier, even if it's more typing. Standardization often trumps linguistic parsimony in real-world work."

Domain specific languages are everywhere. If you ever worked in the Java Enterprise Domain: just see the zillions of XML or other configuration languages. Take any 1MLOC Java project and it will have all kinds of languages and extensions.

From my personal view, very descriptive Lisp programs are actually quite easy to read - but they can be harder to maintain: there is this meta-level.

Lisp has a bunch of 'problems':

1) it has this meta-level where code is data and where programs transform code. This adds added complexity and increases the distance of the executing code from the written code. The machine is possibly transforming a statement before executing it, then the new code will be executed and can also be possibly transformed.

2) the code as data feature adds a layer of confusion: what is code and what is data exactly when?

3) the amount for programmer freedom makes it possible to write extremely hard to understand code. Especially the code might only be understandable while it is running (because then introspection and reflection can be used).

4) much of Lisp was developed at a time when more people knew how to use it. A lot of that practical knowledge is lost and thus it's difficult to educate new programmers. In the 'open source'/'free software' domain SBCL

OTOH, the fear of application/domain specific constructs is overblown. Sometimes groups report that Lisp code for large applications is much smaller and more readable than the equivalent, say, C++. If the code is full of low-level operators, repeating code, etc., then often the usual answers are configuration systems, extensive meta-architecture, added languages, an added scripting level, code generators, lots of manual labor, user-interface-level automation tools, ... this is no better or even worse than Lisp-level code generation/transformation.

Re: The Costs of Programming Language Fragmentation

#163

Post by nescoiquid »

tomjakubowski wrote: post #117
jcelerier wrote: post #78

Earlier quoted context omitted.

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

> their wildly varying build/metabuild processes.

Boost? I'm sure there's good reason for the -- sui generis -- build system. Always been too underwater to spend much time wondering about why that's a yak I'm shaving.

Re: The Costs of Programming Language Fragmentation

#165

Post by burntsushi »

tabtab wrote: post #158
burntsushi wrote: post #152

Earlier quoted context omitted.

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…

> And I'm not against SOME parallelism support in app languages.

Once again, you said:

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

So, what's your point? Every time someone talks about parallelism---whether it's legitimate or not---you see it as your duty to pontificate on the "fad" that is parallelism? You've completely and utterly missed my point, which had nothing at all to do with debating the legitimate use of paralleism in a specific case. That there are legitimate uses of parallelism is enough to make my point.

> It's just my experience that if you "need" to do it A LOT in applications, you are probably doing something wrong.

Again, so what? This has literally nothing to do with anything I've said in this thread.

So, umm, thanks for derailing the conversation into your own pet cause?

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

Again, so what? This seems like a useless academic point. At no point did I invite such navel gazing.

Re: The Costs of Programming Language Fragmentation

#166

Post by tabtab »

burntsushi wrote: post #165
tabtab wrote: post #158

Earlier quoted context omitted.

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…

> And I'm not against SOME parallelism support in app languages. Once again, you said: > I'm sorry, but the need for parallelism is exaggerated; it's mostly a fad. So, what's your point? Every time someone talks about parallelism---whether it's legitimate or not---you see it as your duty to pontificate on the "fad" that is parallelism? You've completely and utterly missed my point, which had nothing at all to do with…

Re: "That there are legitimate uses of parallelism is enough to make my point." -- Yes, there are niches that need such; I don't dispute that. "Faddism" is a matter of degree. Every big language shoehorning in lots of X because niche Y needs X is probably a case of faddism. Again, we'd probably have to examine specific instances. English by itself won't settle this.

Re: The Costs of Programming Language Fragmentation

#167

Post by mike_hearn »

mpweiher wrote: post #155
mike_hearn wrote: post #142

Earlier quoted context omitted.

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.

I wouldn't describe it like that. There's no super-language. That's not how Truffle works at all. Rather, Truffle is a way to express language semantics through writing interpreters, such that interpreted ASTs are then compiled into native code blocks.
Post reply on HN