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

71–80 of 167 posts

Re: The Costs of Programming Language Fragmentation

#71

Post by lmm »

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…

ML family languages are already the "polyvalent languages" you describe and have been a better choice than C for at least 20 years now. If your goal is seeing adoption of such a language, your time would be better spent fixing the things that lead you to dismiss Haskell and Scala - any new language would certainly be even more of a "niche language" than they are.

Re: The Costs of Programming Language Fragmentation

#72

Post by lmm »

smadge wrote: post #18
DarkWiiPlayer wrote: post #2

That reflects rather well how I feel about the recent DSL craze, specially in the ruby community. It's also how I feel about libraries and frameworks. Programming languages probably suffer the least from this phenomenon due to how difficult it is to create a complete language, with compilers and all. In contrast, languages that just extend others often do benefit from existing communities. Take moonscript¹ for exampl…

An example that comes up often for me are EDSLs for database queries. I do see the value of them, but on the other hand it causes you to move away from a “lingua Franca” of database querying to a programming environment specific one. What probably makes sense is 1) evolving SQL or SQL tooling to support more features that people think they need (an example that comes to mind is type safe queries) and 2) better suppor…

External DSLs (even with "cross-language bindings") are much worse to work with than than internal ones and SQL is no exception. IMO what's really needed is a willingness for databases to step away from SQL and expose an API that's more friendly to modern programming languages (or better yet, make the database embeddable as a library rather than a framework you have to build your application into). The eDSLs help a little, but as long as they're obliged to compile into SQL strings there's a limit to how effective they can be.

Re: The Costs of Programming Language Fragmentation

#73

Post by jfoster »

pythonaut_16 wrote: post #60
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…

And the flaw with your perspective is that if we all followed this advice, we might have a few highly polished bullet proof C libraries to use, but we'd still be stuck writing C and following all of its paradigms.

That's the interesting part. We're better off because of some but not all new languages having been invented.

Re: The Costs of Programming Language Fragmentation

#74

Post by glangdale »

burntsushi wrote: post #16

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…

Speaking as someone who was the "re-implementee" in some cases (i.e. our mixed C/C++ regex library Hyperscan has had some ideas borrowed for your regex library in Rust) I'd say things aren't 100% simple here.

I think there is a strong tendency of people programming in new languages to be overly convinced of the elegance and superiority of their new language as a result of (a) getting to rewrite software without the burden of those fussy, irritating existing users and (b) getting to 'rebuild' software without the rather exhausting process of feeling your way to an algorithm or system that never existed before.

There's absolutely nothing wrong with either of these things, but sometimes I think people working in hip new languages tend to mistake the elegance and superiority of their new language for the advantages conferred by a "rework". I bet I could build a pretty elegant regular expression system in C/C++ if I got to start from scratch, too!

This isn't a statement about one language being better than another, and I'm aware of how vexed a problem it is to compare new languages with old. If you built a pile of nonesuch systems in your new language people would complain that they can't compare these systems with stuff that they're familiar with. :-)

I'd just call for a bit of caution in assessing new languages being pressed into service for old, familiar tasks.

Re: The Costs of Programming Language Fragmentation

#75

Post by codr4 »

jcelerier wrote: post #41
digitalzombie wrote: post #32

I disagree. They can do whatever they want because it's passion driven. If people finds the new language wonderful they'll choose to spend their time there and to create their own community around it. It's their free time and they have every right to choose how to spend it. Also with RPC, the apache project arrow, etc... there'll always be people out there will bridge community. Also is this really a problem? Program…

> I've seen front end javascript frameworks fragmentation everywhere and they're fine with it just because they're fine with it does not mean that everyone is fine with it

And that's fine too, it's perfectly ok to disagree with the choices others make. But that's as far as it goes, you wouldn't like someone else telling you how to spend your time without getting anything in return either.

I'd bet most developers would be fine with supporting and incrementally improving if they made enough money from that to do what they really want to do on the side.

I would take a minute or two to reflect on all the time and energy that hundreds of thousands of individuals give away for free. It's easy to forget how far we've come by standing on their shoulders.

Re: The Costs of Programming Language Fragmentation

#76

Post by [deleted] »

pythonaut_16 wrote: post #60
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…

And the flaw with your perspective is that if we all followed this advice, we might have a few highly polished bullet proof C libraries to use, but we'd still be stuck writing C and following all of its paradigms.

[deleted]

Re: The Costs of Programming Language Fragmentation

#77

Post by pron »

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…

> You're using "real software" to presumably denote some dichotomy of software that doesn't exist.

I think that what I meant was clear from context: software that has a long-term, significant impact.

> then you also need to consider the impact of improved tools on the costs of maintenance

Sure, but however much maintenance costs, it still needs to be done. It cannot be carried long by a novelty factor.

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

I agree. Anyone should work on whatever they find interesting, and that (normally) doesn't make the choice irresponsible. But I still think that empirically new languages, on average, increasingly cost more and contribute less.

Re: The Costs of Programming Language Fragmentation

#78

Post by jcelerier »

reacweb wrote: post #39
nineteen999 wrote: post #33

Earlier quoted context omitted.

I'm not sure how old that article is, but parts of gcc suite have been rewritten in a subset of C++ for several years now ( https://lwn.net/Articles/542457/ ), starting from over 10 years ago.

Yes, I know that. C++ is also very much used for game development. C++ allows to build very impressive abstractions that are very handy. The main drawback is that this flexibility has a huge impact on the language. When you switch between two projects writen in C++, it is almost as if they were using a different language. I have understood that this language was a mess in 98 when I have bought the standard and read i…

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

Re: The Costs of Programming Language Fragmentation

#79

Post by fauigerzigerk »

zzzcpan wrote: post #61
fauigerzigerk wrote: post #50

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.

That's great for sharing libraries written in C. It doesn't generally solve the problem of reusing libraries across languages though.

Re: The Costs of Programming Language Fragmentation

#80

Post by burntsushi »

glangdale wrote: post #74
burntsushi wrote: post #16

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…

Speaking as someone who was the "re-implementee" in some cases (i.e. our mixed C/C++ regex library Hyperscan has had some ideas borrowed for your regex library in Rust) I'd say things aren't 100% simple here. I think there is a strong tendency of people programming in new languages to be overly convinced of the elegance and superiority of their new language as a result of (a) getting to rewrite software without the b…

> There's absolutely nothing wrong with either of these things

Sure. But note the OP used the word "irresponsible," so I'd say you're actually disagreeing with the OP, and not me. :-)

> I think there is a strong tendency of people programming in new languages to be overly convinced of the elegance and superiority of their new language as a result of (a) getting to rewrite software without the burden of those fussy, irritating existing users and (b) getting to 'rebuild' software without the rather exhausting process of feeling your way to an algorithm or system that never existed before.

Yes. But there must also be room for folks to seriously argue the benefits of one tool over another without simultaneously being dismissed as the zealotry of the newly converted, which is a feeling that I am all too familiar with!

Overall, I basically agree with you.

Post reply on HN