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

51–60 of 167 posts

Re: The Costs of Programming Language Fragmentation

#51

Post by delhanty »

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.

Which is more immoral, A or B?

A. An unpaid programmer choosing to walk away from their open-source project.

B. The world's richest companies running their production systems on open-source, but failing to adequately fund development.

Here's the best example: OpenSSL and HeartBleed up until 2014 [0].

  >Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL
  >
  IBM, Intel, Microsoft, Facebook, Google, and others pledge millions to open source.
  >
  >...
  >
  >Steve Marquess wrote in a blog post last week that OpenSSL typically receives about $2,000 in donations a year and has just one employee who works full time on the open source code.Given that, perhaps we shouldn’t be surprised by the existence of Heartbleed, a security flaw in OpenSSL that can expose user passwords and the private encryption keys needed to protect websites.
[0] https://arstechnica.com/information-technology/2014/04/tech-...

Re: The Costs of Programming Language Fragmentation

#52

Post by jasode »

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…

> I would not dismiss an article without at least trying to make a genuine effort to understand the point an article makes.

And likewise, you didn't seem to understand michaelmrose's points and your reply didn't address his specific criticisms of the article and how it has 2 flaws.

To me, your restatement has repeated the same 2 flaws:

>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

It's not a solid argument and the 2 flaws in O'Callahan's essay are:

(1) Post hoc analysis flaw: Judging what moves us "forward" vs "backwards" is post hoc analysis. It requires a time machine. In reality, we always live in the present moment, and therefore, we can't know what inconsequential things today will eventually be a net benefit to society tomorrow.

(2) Fungible & zero sum flaw. That a human interest level in any given activity is fungible and therefore zero-sum which supposedly takes away from other more worthy things.

To apply the flawed thinking to the C Language, we would have to transport ourselves back to 1972 and O'Callahan would then criticize Dennis Ritchie for "inventing yet another language and fragmenting the landscape". Instead, D.R. should have focused his effort on languages that already existed like Cobol (1959) and Lisp (1958). Well, if Dennis Ritchie was not intellectually interested in enhancing the older ecosystems of Cobol and Lisp, it's a moot point.

Imagine taking all those "Shown HN" posts of new programming languages[1] and lecturing people that they should have focusd their energy on existing "more important" things such as the broken C code in Heartbleed OpenSSL. That advice would be naive about human nature. Many people aren't interested in working on the OpenSSL codebase.

If one believes that "video games" are a waste of time, it's flawed to assume that a programmer's 1000 hours on a "useless" game engine could have been redirected on developing algorithms for DNA analysis or writing code for a government healthcare portal to help the nation's citizens. Motivations matter.

Similar arguments can be made for scientists choosing to working on particular problems in physics, math, and engineering. E.g. It was a "waste of time" for Andrew Wiles to work on Fermat's Last Theorem when "P=NP" is the "more important" problem. Well, the he worked on it because Fermat's problem fascinated him since he was a little boy and "P!=NP" didn't grip him in the same passionate way.

> and the long term commitment should be there if you [...] , 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.

I just wanted to note that this particular opinion of "language inventor's ongoing commitment required" was not stated in O'Callahan's essay.

[1] https://hn.algolia.com/?query=show%20hn%20programming%20lang...

Re: The Costs of Programming Language Fragmentation

#53

Post by yxhuvud »

alexpw wrote: post #23

"If the new language did not exist, that effort could have been spent on improving existing libraries or some other useful endeavour." This ignores the value and usefulness of learning for the sake of learning, and to allow other people to hone their skills.

Not to mention legacy inertia - things get harder to change in existing libraries when they have loads of users. Even if the change make sense in a vacuum.

Re: The Costs of Programming Language Fragmentation

#55

Post by lassejansen »

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…

Not sure if "recent" is the correct attribute for DSLs in Ruby.

https://www.infoq.com/news/2007/06/dsl-or-not

Re: The Costs of Programming Language Fragmentation

#56

Post by jacquesm »

delhanty wrote: post #51
jacquesm wrote: post #47

Earlier quoted context omitted.

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

Which is more immoral, A or B? A. An unpaid programmer choosing to walk away from their open-source project. B. The world's richest companies running their production systems on open-source, but failing to adequately fund development. Here's the best example: OpenSSL and HeartBleed up until 2014 [0]. >Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL > IBM, Intel, Microsoft, Facebook, Google, and ot…

I think there are quite a few more choices available than your 'A' and 'B'.

Re: The Costs of Programming Language Fragmentation

#57

Post by stellalo »

When exactly have diversity and choice become problems?

It’s a blessing that so many new languages are popping up. Those that have a reason to exist, will succeed, and the time spent on them will be an investment; those that will fail will do so for a reason. And that’s ok. Some people will have wasted their time. But not the community as a whole.

Failures are part of evolution. Thanks to failures we have Rust and Julia and Nim and who knows how many other new interesting languages.

Re: The Costs of Programming Language Fragmentation

#58

Post by zzzcpan »

Programming languages and libraries are not universally expressive or useful and are not of universally good quality. New independent languages and reimplementations are necessary to better express problems and therefore reduce defects and maintenance costs. They are also necessary for anything of quality to emerge, for all the right people to make all the right choices. Incidentally this is one of the reasons that prevents large projects from achieving good quality and large organizations from producing quality software.

Re: The Costs of Programming Language Fragmentation

#59

Post by [deleted] »

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…

[deleted]

Re: The Costs of Programming Language Fragmentation

#60

Post by pythonaut_16 »

pron wrote: post #44
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 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.
Post reply on HN