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

101–110 of 167 posts

Re: The Costs of Programming Language Fragmentation

#101

Post by BeetleB »

zimbatm wrote: post #82

How much of the new languages are supported by a new fresh wave of engineers that want to learn things? To become a good engineer I had to go through implementing my own container types, play with my own little databases and network libraries, implement a build system, ... I published a few of those experiments in Ruby, the new/hip language at the time. Picking a fresh language seems the obvious playground to do this…

That was my first thought when I read the post: He's discounting the fact that by doing this, many programmers are gaining in expertise. It's not a given that those programmers would grow their skill set as much otherwise. Advancing the state of the art in a well established language requires a lot more skills than implementing simple libraries for a new language.

Re: The Costs of Programming Language Fragmentation

#102

Post by repolfx »

bunderbunder wrote: post #94
fouc wrote: post #25

How about the reverse problem? The cost of mindshare. Everyone grouping up on a major programming language or framework. It's a bit irritating when people often choose their language or framework because of the size of the community rather than actually evaluating alternative languages or frameworks first. Take React for example. There are some great alternatives to it, especially inspired by react but simpler & clea…

I can't speak to React, but I definitely see this happening with Java. To the point where I've watched people make conscious decisions to the effect of, "Sure, I do think Kotlin is a superior language that will allow us to work better and faster, but everyone already knows Java, and we feel more comfortable sticking with the mainstream." :shrug: I like to be a bit more flexible than that, but I suppose there is somet…

It's probably a small disagreement in your case. Language decisions are hard to undo. JetBrains doesn't (yet) have the reputation of long term support for developer platforms that Sun, Microsoft, the open source community etc have. Also judging the ROI is hard - the decision makers who will be held accountable don't benefit from the use of the better tool.

Re: The Costs of Programming Language Fragmentation

#103

Post by repolfx »

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…

There's no particular reason you have to use C to write Linux. Linux is written in C because when the project started, that was the most reasonable choice. It persists today because of inertia and because introducing something better, like C++, would cause big flamewars.

People have written perfectly functional and competent kernels in C#, Java and C++ after all. There's no technical reason why you can't do it.

Re: The Costs of Programming Language Fragmentation

#104

Post by honkycat »

The opinions expressed in this blog post are one of those uninteresting, infinitely parroted idioms that people like to assert to seem smart and pragmatic, but are completely idiotic upon further reflection.

It's similar to "If you rent you are throwing your money away" completely ignoring the realities of how DUMB that statement is. Paying for a house which you must mortgage, pay taxes on, and maintain, but cannot rent out or sell is much more expensive than renting someone else's house, and historically the stock market gives greater yields for many investors.

First of all, we have not yet written the perfect programming language, and every single language written has pros and cons for various different tasks.

Choosing the right language can lead to writing abstractions that make you ABSURDLY more productive than alternative choices. Write RabbitMQ in Javascript instead of Erlang and tell me we only need one language to rule them all.

Off the top of my head, I can think of 5 languages that have MASSIVELY improved the software ecosystem over the last 10 years: Golang, Rust, Elixir, Typescript, Elm.

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

Unsurprising a self-proclaimed christian programmer takes the moral high ground, and asserts writing a new programming language out of passion, love, or an actual need for a new language to allow for cleaner abstractions for your particular use case can POSSIBLY be unethical.

I have a different suggestion: Consider the social costs of parroting idiotic drivel you heard one time and trying to pass it off as actually interesting insight.

Re: The Costs of Programming Language Fragmentation

#105

Post by brightball »

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…

"It's easier to birth a baby than to resurrect the dead."

There's the weight of an existing community that also might make "improvements" more difficult. It's the same reason people leave large companies to go start smaller companies. Could they have stayed and made that company better? Maybe. Maybe not.

There's often a lot invested in the status quo.

Re: The Costs of Programming Language Fragmentation

#106

Post by platz »

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…

there is always a myth that someone with absolute control of resources could more efficiently re-allocate those efforts.

But first you have to obtain absolute top down control in order to do so.

Very similar to how command-and-control politics schemes could be in theory more efficient than messy democracies, but those messy democracies, while inefficient, produce variety that guard against the much larger errors of mis-allocation, ineptitude, or corruption.

Also the person with the vision of absolute top down control typically selects their vision as the correct one. If only we implemented my vision, since it is the correct one.

If we did what the OP suggests we'd be communicating with CORBA across the net, have artifacts such as "car" and "cdr" x10.

Re: The Costs of Programming Language Fragmentation

#107

Post by flohofwoe »

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…

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.

Re: The Costs of Programming Language Fragmentation

#109

Post by burntsushi »

pron wrote: post #97
PopeDotNinja wrote: post #90

Earlier quoted context omitted.

Most new things suck. But every now & then something new AND cool comes along, making all of the old stuff less relevant. For me, Elixir was yet another language to learn, and was just a reimplementation of another language. But when I used it, I was like "whoa, this is sweet!" You gotta build something new when you can't find something old that does what you wanna do.

My point has nothing at all to do with what sucks and what's cool, but with the fact that transitioning to new languages does have a non-trivial cost, for individual organizations as well as to the industry as a whole. Moreover, productivity gains from new languages seem to have plateaued a couple of decades ago (except from some niches, such as system programming, that have seen little change in the past 20-30 years…

> but with the fact that transitioning to new languages does have a non-trivial cost

But this is completely uninteresting. Nobody has claimed that transitioning to a new programming languages doesn't have a non-trivial cost.

You're countering a non-existent argument. I mentioned this in my initial reply to you: you're debating a point that is easy to refute. I don't know why, or where the source of confusion is, but you are.

> Moreover, productivity gains from new languages seem to have plateaued a couple of decades ago (except from some niches, such as system programming, that have seen little change in the past 20-30 years). I.e., we no longer see the same productivity boosts as we did going from Assembly -> FORTRAN, from FORTRAN -> C, or from C -> Java (and even then, the gains were smaller with each jump). Fred Brooks predicted in the '80s this would happen, and reality has shown even smaller gains than he had predicted.

This just sounds like a lot of opinion expressed as if it were a fact.

Re: The Costs of Programming Language Fragmentation

#110

Post by burntsushi »

platz wrote: post #106
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…

there is always a myth that someone with absolute control of resources could more efficiently re-allocate those efforts. But first you have to obtain absolute top down control in order to do so. Very similar to how command-and-control politics schemes could be in theory more efficient than messy democracies, but those messy democracies, while inefficient, produce variety that guard against the much larger errors of m…

It sounds interesting, but I don't really agree with the idea that we can analogize software development with socio-political organization. There are certainly a lot of interesting similarities, but I would be super careful about drawing any conclusions from it.
Post reply on HN