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

181–190 of 206 posts

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

#181

Post by balder1991 »

thomasmg wrote: post #46
tracker1 wrote: post #10

More often than not, preference should be given to the language most of the team know the best. The only exception is when everyone on the team feels a different language is a better fit for the need or there are underlying reasons for a language shift. Personally, my bias is towards the languages I'm most comfortable with. I recognize this and will make other suggestions and if I'm not responsible for the code, I'm…

> the language most of the team know the best I fully agree. The challenge is, some will want to use the latest languages and technologies because they want to learn it (personal development, meaning: the next job). Sometimes the "new thing" can be limited to (non-critical) testing and utilities. But having many languages and technologies just increases the friction, complicates things, and prevents refactoring. Even…

> This is a bit related to external dependencies vs build yourself (AKA reinvent the wheel). Quite often the external library, long term, causes more issues than building it yourself (assuming you _can_ build a competent implementation).

I feel like this happens mostly because simpler is better, and most of these dependencies don’t follow a good “UNIX” philosophy of modularity, being generic etc. something that you’d notice the standard libraries try to achieve.

Most of these third party dependencies are just a very specific feature that starts to add more use cases until it becomes bloated to support multiple users with slightly different needs.

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

#182

Post by JuniperMesos »

binary132 wrote: post #101
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’m having a hard time envisioning a project that could be killed by choosing Scala that wasn’t actually killed by bad engineering. Scala is pretty easy to write Just Simpler Java in….

I would say that Scala is more complicated than Java because it introduces a number of useful new features to a JVM language.

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

#183

Post by fragmede »

skydhash wrote: post #92
Ocerge wrote: post #80

Earlier quoted context omitted.

My team ships with a multi-hour CI pipeline that works 50% of the time and effectively zero local development. It's awful in almost every way developer experience-wise, but rock bottom is deeper than you think!

I had local development in a previous job, but you had to start a whole Kubernetes cluster. No unit tests, but a whole suite of e2e tests. And forget about debuggers as it was all microservices.

They may not have existed back then, but between kind, and either Tilt or Skaffold, it's at least not as bad as it once was.

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

#184

Post by bmitc »

jack_tripper wrote: post #146
bmitc wrote: post #123

Earlier quoted context omitted.

Engineers are also part of the problem, as not every engineer avoids myopia.

Feel free to speak for yourself. This is not representative of me or anyone I know.

Case in point.

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

#185

Post by bmitc »

OkayPhysicist wrote: post #173
bmitc wrote: post #120

Earlier quoted context omitted.

> Moving from LABVIEW to a real programming language ... Switching from C++ to Rust? Probably not. Weird. LabVIEW is a real programming language. And both LabVIEW and Rust make entire classes of bugs that you often hit in C++ go away, especially for concurrent programs. > remotely modern development tooling I would make the argument that it is the tooling, i.e., Git and Diff, that is ancient and not remotely modern.…

Spoken like someone who's never worked on a large-scale LABVIEW system. A moderately sized codebase (equivalent to a project with a million-odd lines of code) ends up with a project containing tens if not hundreds of thousands of files. Each file opens up two windows, so if you're working on anything nontrivial you're going to have dozens and dozens of windows open at a time. Compiling such a project takes upwards of…

> Spoken like someone who's never worked on a large-scale LABVIEW system.

That's exactly false. I've single-handedly developed multi-thousand VI projects on different systems, including heavily using the OOP system and actor frameworks.

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

#187

Post by tpoacher »

lproven wrote: post #167
tpoacher wrote: post #154

Bulverism

https://en.wikipedia.org/wiki/Bulverism Hardly, no. The entire point of the article is pointing out an entirely different cognitive fallacy.

It's Bulverism because first you need to defend and establish that your proposition is true before you can start explaining "why" it is true.

At the very least the title is clear Bulverism.

Admittedly, I did enjoy the article, even if I was initially a bit predisposed not to from the title. And I think the quote "if you hire a rust evangelist to choose your programming language, you've already chosen rust" is very insightful. But the author still goes into zero depth to asses to what extent rationality of language choice is a widespread problem, as opposed to isolated cases they've seen during their career.

Which is ironic given that their thesis is that people go into topics emotionally without weighing them factually against the ground truth.

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

#188

Post by pjmlp »

imtringued wrote: post #151
OkayPhysicist wrote: post #55

Earlier quoted context omitted.

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 a…

Sure, if we forget about the ecosystem in industry standards, IDE tooling, libraries, and training costs in existing industries where C++ is the standard.

Comparing language grammars on their own isn't enough any longer.

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

#189

Post by pjmlp »

Very well put article, every single time I see a session like that I also ask about the business cost evaluation, especially regarding rewrites.

Have they done in math in FTE salaries, times the estimated effort in days, mappend into money, and what is the expectation of ROI in that investment.

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

#190

Post by pjmlp »

skydhash wrote: post #92
Ocerge wrote: post #80

Earlier quoted context omitted.

My team ships with a multi-hour CI pipeline that works 50% of the time and effectively zero local development. It's awful in almost every way developer experience-wise, but rock bottom is deeper than you think!

I had local development in a previous job, but you had to start a whole Kubernetes cluster. No unit tests, but a whole suite of e2e tests. And forget about debuggers as it was all microservices.

When using Java or .NET, it is possible to plug debuggers into microservices, but that needs to be taken into account when designing their Dockerfiles.

Just as heads up for others.

Post reply on HN