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

121–130 of 206 posts

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

#121

Post by bmitc »

Animats wrote: post #63

I dunno. I take the position that language designers have blind spots around the weaknesses of their languages. Python: Python is almost a hard-compiled language. Most of the dynamic stuff that's really hard to compile isn't all that useful. But Guido and his enablers love the dynamism, and the CPython implementation. So instead of PyPy taking over, we have CPython with hacks to call C. Go: The "share by communicatin…

I generally agree with your sentiment.

> Rust: The "traits" system is an overreaction to Objects Are Bad.

It's interesting. Interfaces, traits, and mixins are all OOP concepts.

> "Async" is a nightmare

In what way? I do agree though, that it's annoying to yet again have a new language not have concurrency baked into the language. In some ways, Rust has excuses, because they want their concurrency primitives to support microcontroller, real-time Linux, and general purpose programming.

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

#122

Post by etothet »

getnormality wrote: post #117

Maybe the Perl CTO wanted the product in Perl and not PHP because he knew Perl and didn't know PHP? Do we really need all this psychoanalysis and identity stuff to explain that?

This is often the real driver in these decisions. A previous company I worked at had an API written in modern PHP with Laravel. Traffic wasn’t very heavy on most days and we could autoscale when it was required. It worked great and we hadn’t encountered business problems that couldn’t be fairly easily solved within the ecosystem. However, one of the execs on the business side knew some other exec at a big tech company who told our guy that “PHP can’t scale”. So then we get questions if we should we consider rewriting, if we’re using the “best” language for our needs, etc. They wanted to plan for some theoretical future that they couldn’t even define from a business sense.

Sure, it’s good to be aware of future business needs so that we, as technical people, can be asking the right questions to prepare for what that future may look like, but that almost never means a decision about language x over language y. It’s much deeper than that.

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

#123

Post by bmitc »

jack_tripper wrote: post #22
Jtsummers wrote: post #19

> 1. The power to transcend paradigms. - Donella Meadows, Leverage Points: Places to Intervene in a System https://donellameadows.org/archives/leverage-points-places-t... If you're a Python Programmer, and you've made that your identity, you've trapped yourself into the mindset that you are a Python Programmer. Same with any other identity you ascribe to yourself (or allow others to ascribe to you). Separating yourse…

>Getting past paradigms gives you much greater freedom to explore and participate in the world. It's not me who has problems getting past paradigms, or anyone else I know for that matter, it's the recruiters and HR people who screen resumes by only ticking boxes on buzzword.

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

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

#124

Post by asveikau »

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.

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

#125

Post by zzrrt »

bri3d wrote: post #39
seneca wrote: post #33

Earlier quoted context omitted.

This is really the heart of it: > Don't get me wrong - to an extent, some languages (especially more niche ones) drive hiring and what kind of employee you get In my experience, the community around a given language is going to significantly influence the sort of typical applicant you get for a job working in that language. Those profile vary a surprising amount, especially for, as you say, niche languages, but also…

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

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

#126

Post by jolt42 »

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 lessons that were learned the hard way the first time around.

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

#127

Post by WalterBright »

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 rewritten a very large and complex macro assembler program into C. The original developers were gone. Nobody would touch that assembler code. I volunteered. The result was a program that could be maintained and could be ported to multiple diverse platforms needed by the company.

I tried to port Optlink (a linker for Win32) from assembler into C. It failed because the market for Win32 programming died, and so I abandoned the project.

My Empire game started out in BASIC. Then it was converted to FORTRAN, then PDP-11 assembler, then C on the PC, then D.

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

#129

Post by danans »

If you are are starting from scratch, isn't the answer to which language to use just "the framework that best supports the business case and problem you are working on"?

If that produces many options, then choose based on the team's familiarity with the language, frameworks, and ecosystems.

A good software engineer should be pretty language agnostic when it comes to work, even if they have a personal aesthetic or technical preference.

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

#130

Post by _sharp »

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…

The point of the article was to choose your language based on economic impact, rather than technical debates that are a facade of an engineer's identity beliefs.

With that pov, I don't see any contradiction by saying the language is an important decision, and rewriting your project in a new language is probably a bad idea.

Post reply on HN