Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why engineers can't be rational about programming languages

spf13.com

Post reply on HN
Print view View original

151–160 of 206 posts

Re: Why engineers can't be rational about programming languages

#151

Post by imtringued »

OkayPhysicist wrote: post #55
bri3d wrote: post #20

I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…

In my experience, a language switch rewrite can be a benefit only when switching from a dead ecosystem to a living one. For example, migrating a web app from a language that predates Unicode to something that won't require a bunch of scaffolding around every user input sometimes is worth it. Moving from LABVIEW to a real programming language that integrated with remotely modern development tooling was worth it. Switc…

Your final example feels wrong. Rust provides features that are basically unmatched by the fast majority of C++ and Rust competitors. I've also been soured enough on C++ to the point where rewriting an entire ecosystem in Rust seems like less effort than to figure out how to make the decrepit C++ one work for my purposes. You spend weeks trying to install a C++ library only to realize that it is not fit for purpose and then you spend another week on the next one, until you've tried most of them and realized they are all kind of bad in one way or another. Even if they worked as advertised, you're already going far beyond the intended use cases of the existing libraries so why limit yourself by the past?

Re: Why engineers can't be rational about programming languages

#152

Post by bdangubic »

jll29 wrote: post #108
jerf wrote: post #67

Earlier quoted context omitted.

The great team would not have written the Amazon clone in Fortran. There is no engineering justification for such a choice, and "we are swaggeringly awesome engineers who can conquer anything" is not even remotely an engineering justification.

The parent article's point, though, is that choice of programming language is often NOT driven by justified choices, but is a foregone conclusion because it is part of the identity ("I am/want to be a XY developer.") of someone influential (e.g. tech lead, CTO, VP Eng). One argument I would like to add to this original debate is that I have observed two types of developers: one type tries to stick to one programming…

keep in mind though that size of the organization/team/... matters greatly. I have been involved with tens of projects over the course of my career (3 decades) and have encountered numerous scenarios where the choice of languages/technologies/... is already made, company-wide. I have seen this especially in companies that do a lot of contracting work. If apps are built say on top of springboot services and angular front-ends and we have 200 developers that specifically learned and know those technologies (along with myriad of internal libraries etc built on top of those technologies) swapping people between the projects becomes a non-event (or even adding few bodies to meet deliverables).

Re: Why engineers can't be rational about programming languages

#153

Post by bdangubic »

bluGill wrote: post #88
jerf wrote: post #67

Earlier quoted context omitted.

The great team would not have written the Amazon clone in Fortran. There is no engineering justification for such a choice, and "we are swaggeringly awesome engineers who can conquer anything" is not even remotely an engineering justification.

If you are starting from scratch fortran is a bad choice. However if you have a fortran project that keeps getting more features you may become an amazon clone along the way

I was of course being facetious mentioning fortran but given a choice between working with an amazing group of people on a project which has a completely wrong tech/frameworks/... stack for the job at hand (e.g. fortran to built an e-commerce website) vs. working with average/subpar team utilizing some amazing stack, I'd choose the former any day of the week and twice on Sunday

Re: Why engineers can't be rational about programming languages

#155

Post by dzonga »

> “which language is best?” we need to ask “what is this language going to cost us?” Not just in salaries, but in velocity, in technical debt, in hiring difficulty, in operational complexity, in every dimension that actually determines whether you survive.

then boom suddenly php, ruby & java are pragmatic choices in economic sense for business systems. same as c++ for hedge funds & video games etc.

Re: Why engineers can't be rational about programming languages

#156

Post by lproven »

jerf wrote: post #34
bri3d wrote: post #20

I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…

"I cannot agree that programming language choice is a primary driver in a product's success or failure" I've seen it. There are definitely incorrect language choices for certain projects. It would be fair to say that these cases are themselves often exceptions. Many projects can be equally well accomplished by teams skilled in any language. But there is definitely a set of problems for which you can make incorrect la…

> There are definitely incorrect language choices for certain projects.

There is an entire book about it which documents the problems in lavish detail, and it's generally hailed as a classic and a must-read.

https://www.dreamingincode.com/

Re: Why engineers can't be rational about programming languages

#157

Post by lproven »

DevelopingElk wrote: post #89
jerf wrote: post #34

Earlier quoted context omitted.

"I cannot agree that programming language choice is a primary driver in a product's success or failure" I've seen it. There are definitely incorrect language choices for certain projects. It would be fair to say that these cases are themselves often exceptions. Many projects can be equally well accomplished by teams skilled in any language. But there is definitely a set of problems for which you can make incorrect la…

I would say, though, that for most programs any one of the most popular languages would do the trick. By this I mean Java, Go, C#. Javascript, Python, C++. All of those are general purpose multi-paradigm languages that you can code almost anything in. That being said, some programs can only be written in one of those. Browser code is JS exclusive, low-level needs C++, secure code needs not C++. Machine Learning needs…

> I would say, though, that for most programs any one of the most popular languages would do the trick

Which of course ignores and contradicts the primary lesson of the chap who founded this company and pays for this website.

https://paulgraham.com/avg.html

Re: Why engineers can't be rational about programming languages

#158

Post by lproven »

tyleo wrote: post #36
jerf wrote: post #34

Earlier quoted context omitted.

"I cannot agree that programming language choice is a primary driver in a product's success or failure" I've seen it. There are definitely incorrect language choices for certain projects. It would be fair to say that these cases are themselves often exceptions. Many projects can be equally well accomplished by teams skilled in any language. But there is definitely a set of problems for which you can make incorrect la…

While I’ve seen bad technology chosen for projects, it seemed at root more a problem with the people choosing it than the technology itself.

> a problem with the people choosing it than the technology itself.

Which is, I think, the key point of the OP's article.

And my response to this is:

We need objective, scientific, real-world measurements of PL efficiency, so that informed judgements can be made free of cognitive bias.

This is how science works. Especially medicine. But programmers seem to feel that they are above this stuff.

Re: Why engineers can't be rational about programming languages

#159

Post by lproven »

levodelellis wrote: post #42

Isn't this what Joel wrote 25 years ago? Don't rewrite your software? I wrote a compiler/language, and I was expecting something different from the article after my experiences Like many of the other commenters, I didn't like the article

That is not what the article is about.

The subject is right there in the title:

Engineers Can't Be Rational About Programming Languages

Re: Why engineers can't be rational about programming languages

#160

Post by lproven »

bobx17 wrote: post #2

We see the "we need to rewrite in X" conversation play out all the time here on HN. Love this take on it.

Yes, we do, but that is not the subject the article is talking about.

From the way so many commentators are refusing to engage with the point expressed in the title I think there is collective denial of the core point, so instead, people are discussing the symptoms rather than the disease that is the subject here.

Post reply on HN