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

131–140 of 206 posts

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

#131

Post by FuckButtons »

asveikau wrote: post #124
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…

> rewriting a product only to change programming language is _always_ a bad idea, There are of course a few scenarios where changing the programming language is a more defensible, less "always wrong" kind of thing. An extreme case would be something like a COBOL system that needs maintenance and you have trouble finding people who can do it.

Or if you’ve written the mvp in python and realize you have to meet some performance metric that is 100x what your system is capable of.

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

#132

Post by bri3d »

bmitc wrote: post #120
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…

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

> Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets.

Do you have examples of working version control for non-text programs, including the ability to combine work from two parallel workstreams (aka, merge)? I worked for a long time at probably one of the largest companies using non-text based programming and version control was never even close to solved, and my subsequent forays into the literature when I worked in the "no code workflow" space still came up empty handed for working solutions here. We always fell back to "try to represent the structure of the change in some text-based way."

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

#133

Post by bri3d »

zzrrt wrote: post #125
bri3d wrote: post #39

Earlier quoted context omitted.

> they hired what I would term language specific technicians instead of engineers. I have seen this too, and I really like the way you phrased it - I think I'll use that in the future! I do think it's an easier trap to fall into with some languages, but I still don't think the language really drives it. I worked on a large-scale Rust project that could probably have been a Go project a while ago and while Language Te…

How is a language technician in Rust even born? I imagine C, Java, Python technicians come from school or other educational materials, but there’s no significant number of people with Rust as a first language, right? Were they just Rust fanatics unwilling to consider other languages?

I'm not even sure "fanatic" was the right word, as most of them actually had a pretty measured take on the state of Rust and were not the sort of aggressive evangelists that people sometimes associate with the language. They were just way more interested in exploring/iterating on/consuming the programming language itself, rather than using it to actually solve business problems. I suppose depending on the connotation of the word "technician" we might be discussing separate people, although it's almost a horseshoe effect where they both loop around into not moving a project forward.

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

#134

Post by [deleted] »

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…

[deleted]

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

#135

Post by beachy »

jolt42 wrote: post #126
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…

Java didn't exist when I originally wrote C++ code. When it did come around it was easily 4x improvement for a good amount of development (eg. enterprise software). I think you need like 4x+ to be worth switching, and I don't see that between many languages. I do see it between libraries/frameworks though. I think a lot of the problem of switching isn't so much the language, but relearning all the undocumented lesson…

I had the same experience. I was put in charge of a large ERP rewrite in C++. Being woefully unprepared we dived in and, based on the issues the existing C codes had, the first thing we built was a memory management framework - what I realized much later was basically garbage collection. It worked very well.

When Java came along its garbage collection blew my mind. I agree with the 4x factor.

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

#136

Post by insane_dreamer »

> “Everyone’s talking about Rust.” There it was: a 50 million dollar decision made on hype, about to be green lit.

I've seen this with React. You might have a great website working with some solid MVC framework + good'ol jQuery or equivalent, but no, the whole thing has to be rewritten from scratch to be an SPA in React, to "keep up".

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

#138

Post by js-j »

For some time now, I've come to the conclusion that the choice of a programming language is of crucial importance to the success of a project: programmers are inspired by beautiful tech solutions, that's what motivates them to give the best of themselves. PHP has never been such a piece of technology for me, whereas Perl used to be...

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

#139

Post by trenchpilgrim »

jolt42 wrote: post #126
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…

Java didn't exist when I originally wrote C++ code. When it did come around it was easily 4x improvement for a good amount of development (eg. enterprise software). I think you need like 4x+ to be worth switching, and I don't see that between many languages. I do see it between libraries/frameworks though. I think a lot of the problem of switching isn't so much the language, but relearning all the undocumented lesson…

In my experience so far most languages I've encountered have been similar enough that language choice mostly comes down to "Does it have the APIs I need" and "Do I like the tooling." There are a handful of exceptions where the capabilities of the language are fundamentally different enough to provide a competitive edge.

- Systems languages with manual memory management, like C or Zig, where real-time/low-latency performance is important.

- Rust and its borrow checker, as an alternative to manual memory management.

- A strongly FP influenced language such as a Lisp or Haskell. Especially Lisp macros. Exceptionally good for working with structured data in cases where purity is more important than performance.

- The BEAM/OTP architecture for distributed systems (Erlang/Elixir).

- Languages with good CUDA/PTX/Vulkan support, for programs that need the GPU.

- Assembly. This was a much bigger deal in the past before compilers got good. Today good mostly for educational purposes.

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

#140

Post by morshu9001 »

jjmarr wrote: post #35

C++ feels like a counterexample. There's zero or arguably negative hype behind the language and everyone I know hates it. However, we continue to write new code in C++ due to libraries and because people know it. These are all factors that the OP considers to be negligible.

I've been in situations where we use C++ for no good reason, and it's just cause the others hate the "noob" ones like Python or JS.
Post reply on HN