4 ms·
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-imple
by burntsushi 8y ago
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 "real software" to presumably denote some dichotomy of software that doesn't exist. If you asked 10 people to define what "real software" actually meant, you'd get 10 different definitions. They might agree on the extremes; but there's a whole mess of crap in the middle that we could endlessly debate about.
> 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 done for multiple implementations in parallel.
This isn't clearly true at all.
I mean, if you're going to talk about maintenance, then you also need to consider the impact of improved tools on the costs of maintenance. If a tool makes maintenance easier or less costly, then it's pretty hard to say anything definitive about long term costs. New tools can and do impact the usage of old tools, which in turn can have a direct impact on long term maintenance costs.
> It's reasonable to assume that work is never really free. But if we're hypothesizing about alternate realities, you may as well imagine that instead of new languages something else is invented to motivate you to do free work.
Absolutely! But that's not the argument I'm countering. I'm specifically countering the notion that new language development can be "irresponsible" because it "could" divert work away from other projects. What I'm saying is that it is not necessarily true at all.
There is a more measured argument to be made here, but the OP did not make it.
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.
- pron 8y ago> 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.
- PopeDotNinja 8y agoMost 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.
- pron 8y agoMy 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). 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. Part of the reason for the growing fragmentation is precisely because no language has stood out as a clear leader.
- burntsushi 8y ago> 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.
- honkycat 8y agoHonestly I would just ignore this person @burntsushi . I actually KNOW who you are from your really consistently excellent work on useful libraries, whereas I have no idea who "pron" is and I suspect he is a troll
- burntsushi 8y agopron isn't a troll. They comment pretty frequently on HN and other places. I generally disagree with their perspective on software development; but we likely have very different experiences.
- roca 8y ago> I don't really appreciate the debate tactic of pretending that I made a stronger claim that I actually did. Ahem. > I'm specifically countering the notion that new language development can be "irresponsible" because it "could" divert work away from other projects. What I'm saying is that it is not necessarily true at all. I (OP) agree that it is "not necessarily true", and my post deliberately made the very weak claim that "in some cases" "it could be irresponsible". I don't see how I could have made the argument "more measured" without eliding it completely.
- burntsushi 8y agoYour OP makes several generalizations, and I disagree with almost every single one of them. So no, from my perspective, your position really isn't measured at all. > I don't see how I could have made the argument "more measured" without eliding it completely. Exactly.
- roca 8y agoFWIW an example of behaviour I would consider irresponsible would be if a large company liked Rust but didn't like not controlling it, so decided to clone or fork Rust and use their resources to popularize that (instead of just putting those resources into Rust itself).