The Costs of Programming Language Fragmentation • Hacker News Board

Re: The Costs of Programming Language Fragmentation

#121

Post by michaelmrose » Tue, Oct 02, 2018, 5:03 PM UTC

jacquesm wrote: post #17

hvidgaard wrote: post #7

Earlier quoted context omitted.

> the long term commitment should be there if you are going to let other people run their production systems on what you throw into the world If you adopted a language that is not mature for production, then you knew the risk when you made that choice. Innovation in PL happens with these small languages, and it's a good thing.

> If you adopted a language that is not mature for production, then you knew the risk when you made that choice. True, but at the same time I can't help but think that a few hundred programming languages are all equally useful and all equally deserving of their continued existence. > Innovation in PL happens with these small languages, and it's a good thing. I do not see the author as having any beef whatsoever with…

The best test of staying power would be longevity and engagement by a large community. If a new language lacks either it is obviously far more likely to cease to exist a few years from now.

It's hard to pick unproven future winners fortunately you don't have to do this. Use what you know works.

Re: The Costs of Programming Language Fragmentation

#122

Post by onemoresoop » Tue, Oct 02, 2018, 5:04 PM UTC

cntlzw wrote: post #38

So, if we follow the authors logic we should abandon all science because we don't know what they might cause. Innovation is pure by nature. Judgment is done empirical evidence after innovation. You can't change the order.

I disagree with your statement. It would in fact be: scientists create unnecessary new notations and that causes a lot of fragmentation in the science community. They all try to solve one thing which is do science. On the other hand I would agree that some new notation could create new ways to see things that were not possible with the old notation. I think in the long run we're ok with many programming languages. Whatever is useful will survive and what isn't will die out.

Re: The Costs of Programming Language Fragmentation

#123

Post by amelius » Tue, Oct 02, 2018, 5:06 PM UTC

gonzo41 wrote: post #113

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…

you just gave me a great idea for a new language, Well actually a big library of ASM code that every other language could write wrappers to to get low level gains on all the boilerplate. Then we could all focus on making that really fast.

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.

Re: The Costs of Programming Language Fragmentation

#124

Post by Technetium_Hat » Tue, Oct 02, 2018, 5:06 PM UTC

ttty wrote: post #48

madmaniak wrote: post #43

Earlier quoted context omitted.

Using React you just have no idea what efficiency is.

Can you further explain what you mean?

React recently decreased in size... To 10 megabytes. This could be helped by the use of CDN and caching, but react discourages this in favor of webpack bundles.

Re: The Costs of Programming Language Fragmentation

#125

Post by elcritch » Tue, Oct 02, 2018, 5:13 PM UTC

amelius wrote: post #123

gonzo41 wrote: post #113

Earlier quoted context omitted.

you just gave me a great idea for a new language, Well actually a big library of ASM code that every other language could write wrappers to to get low level gains on all the boilerplate. Then we could all focus on making that really fast.

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?

Re: The Costs of Programming Language Fragmentation

#126

Post by michaelmrose » Tue, Oct 02, 2018, 5:22 PM UTC

jacquesm wrote: post #4

michaelmrose wrote: post #3

"However, I hope people consider carefully the social costs of creating a new programming language especially if it becomes popular, and understand that in some cases creating a popular new language could actually be irresponsible." Passion isn't fungible and there is zero gauruntee that the person who creates an interesting new language wouldn't have chosen to binge watch Netflix instead. Furthermore without a cryst…

> it's difficult to separate ahead of time which efforts will move us forward in some small or large ways. That's the point: most efforts do not move us forward but instead move us backwards because fewer people are working on the things that matter. It's a solid argument and it applies to far more of the open source community than just to programming languages, in fact programming languages are the smaller part of t…

> This doesn't mean you don't get to scratch your itch, it means that once your programming language gains adoption beyond some people playing around with it you can't just walk off and say that it isn't your problem.

Why not? You display a lack of perspective that is similar to the author of the article you confuse what would be convenient and useful for you personally with a universal good.

If would be good for you if people who gave you free tools acquired a commitment to continue to support and grow these tools without a contract or cash but there is no particular reason this ought to be so. Even if you want to pay there is even no reason why anyone has to be willing to take your cash if they aren't inclined to sell you their labor.

Try going to walmart and seeing if you can buy the cash register.

Similarly the original author believes that if more people just worked on fewer projects that he prefers these projects would be better. This ignores the fact that historical progress including the projects he prefers have benefited from a chaotic environment where people work on what they not the author prefer.

Re: The Costs of Programming Language Fragmentation

#127

Post by michaelmrose » Tue, Oct 02, 2018, 5:27 PM UTC

jacquesm wrote: post #47

delhanty wrote: post #46

Earlier quoted context omitted.

>it means that once your programming language gains adoption beyond some people playing around with it you can't just walk off and say that it isn't your problem Assuming that you don't work for them and that you don't have a contract for support with them, then why can't you just walk away? In fact I'd go further: it would be healthy if people that needed support for open-source got used to the idea of paying for it…

> Assuming that you don't work for them and that you don't have a contract for support with them, then why can't you just walk away? The ability to do something does not always correlate with morality.

How do you have a moral obligation to someone using your work for free?

Re: The Costs of Programming Language Fragmentation

#128

Post by tabtab » Tue, Oct 02, 2018, 5:54 PM UTC

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…

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

This has always been the two-edged sword of high abstraction: people use high abstraction to invent idioms that match their OWN head, and other heads have difficultly reading it. I've been in long debates with Lisp fans over the commercial practicality of Lisp. Lisp and its variations have had almost 60 years to "catch on" in the mainstream, and keeps failing, staying a niche. If you keep losing beauty pageants for 60 years, it's time to admit you may be ugly. Just because YOU like it and/or YOU can read a certain style does NOT mean others can.

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. I'm just the messenger. (I'm talking general domains here, not necessarily specific industries.)

Re: The Costs of Programming Language Fragmentation

#129

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

eecc wrote: post #14

Vendorization. For every language out there there is a consulting firm or corporation selling tooling and support. This allows business strategies aimed at market capture and monopolization. To business, you’re not a general purpose plumber, you’re just a specially trained installer of a particular brand of water boiler.

I suspect the Razor engine/language is a case of vendorization. (Razor is a markup templating language which is part of MS Visual Studio.) I suspect MS promoted it because it complicates IDE design (parsing) so as to keep other IDE's out of their turf.

The prior templating syntax ("") was simple to learn, simple to use, easy to read, easy to debug, and easy to parse (per IDE vendor). Razor didn't add much in practical features to justify the huge leap in complexity it caused.

It may save 2% of key-strokes but complicated syntax and parsing by a factor of roughly 30. It would have to save at least 25% of keystrokes to justify 30x complexity in my opinion. Let alone debugging and parsing error headaches. Bad deal.

Re: The Costs of Programming Language Fragmentation

#130

Post by tabtab » Tue, Oct 02, 2018, 6:23 PM UTC

ken wrote: post #119

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…

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 attaching behavior to objects. Now readers have to deal with 2 paradigms and syntaxes: FP and OOP, whereas if you fixed the lame OOP; they'd only have to deal with one. Sorry, the language did NOT need lambdas.