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…
Why engineers can't be rational about programming languages
101–110 of 206 posts
Re: Why engineers can't be rational about programming languages
#102C++ 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.
The conventional wisdom was "Where will we get C++ programmers?", "We don't have experience with C++", "C++ is too bleeding edge", and so on. The same excuses people give today to not use Rust, or your favorite hyped language.
If we follow the logic of OP, we will almost never develop new languages, because there are already multiple established languages good enough for any task at hand.
Re: Why engineers can't be rational about programming languages
#103I 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.... This and similar are common ideas for the people that never see the real whole world of programming, and maybe have the fortune of be in the "startup" circles. I see the opposite, and is very good predictor to know how bad a product or a team is, using the programming language AND the main DB engine, but that i…
Re: Why engineers can't be rational about programming languages
#104I also don't think it's necessarily bad that people do this. The input to any decision a person makes includes their entire life experience up to that point[1]. How could an executive encode all that in some kind of pat logical explanation, and how could the also-human engineers at the company possibly digest such an explanation, and what could make it more compelling to them than their own life experiences? People need to get through life, though, so they need to make decisions. They can't fully rationalize every single one, but they want to feel at least OK about the decisions they're making, so they tell themselves and each other these incomplete little stories and get on with it. That managers scaffold this process with their own stories is a little manipulative, but how else could people cooperate enough to have companies? The whole process just seems intrinsically human to me.
The most important part of being an executive is understanding all of this and choosing to hire people who will ultimately make good strategic decisions for you. Don't hire a well-known Perl contributor as your CTO unless you like the idea of rewriting your product in Perl. If your company is dying because this has happened, my condolences but at least you're not alone.
Edit: I hadn't read this far when I wrote the comment but the author also literally says, "The moment you hire a Rust developer to evaluate languages, you’ve already chosen Rust." I guess I just disagree that it could work differently. Each of us possesses bounded knowledge and bounded rationality, and "which language is best", is probably too complicated for an individual to figure out, especially when you don't even know what the roadmap will be in a year—you'd have to build the company several times in several languages and compare the results (and the best engineers I've met do write code multiple times, but rarely more than twice IME). Each of us can only really know how we would solve the company's problems. Executives' job is to try and guess, and make decisions that are ideally optimal but at least internally consistent.
[^1] My favorite example of this, actually: even in the highly-rational field of scientific research, scientists have to decide whether a given body of evidence is dispositive of a particular theory, and the standards they apply likewise depend on who they are and what their life experience is. So, as Max Planck put it, science advances one funeral at a time.
Re: Why engineers can't be rational about programming languages
#105I 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.... This and similar are common ideas for the people that never see the real whole world of programming, and maybe have the fortune of be in the "startup" circles. I see the opposite, and is very good predictor to know how bad a product or a team is, using the programming language AND the main DB engine, but that i…
Yes, you may not enjoy turning a legacy system that works into a nicely architected system, but the ones that get to that phase are clear successes IMO.
Contrast this with systems which had nice, clean, maintainable architecture from day one but bit the dust two years later.
The original article is a silly shill, as engineering managers have looked at economic cost of choosing a language and other technology since... forever.
And some of that "invisible" discussion happens visibly too (I've done that a number of times: "how do we keep our engineers motivated who want to explore a new hyped tech stack vs the cost of them being slower or leaving the company").
Re: Why engineers can't be rational about programming languages
#106I 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.... This and similar are common ideas for the people that never see the real whole world of programming, and maybe have the fortune of be in the "startup" circles. I see the opposite, and is very good predictor to know how bad a product or a team is, using the programming language AND the main DB engine, but that i…
> the CTO couldn't be a first rate hacker, because to become an eminent [Windows] NT developer he would have had to use NT voluntarily, multiple times, and I couldn't imagine a great hacker doing that
Re: Why engineers can't be rational about programming languages
#107More 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…
> More often than not, preference should be given to the language most of the team know the best. I'm sorry but I disagree. Languages are tools, pick the best tool for the job. The idea that languages are all good at everything is not true. And when I see takes like this, I tend to think that that person just doesn't understand how to assess a language's strengths and weaknesses. Want to write ML, probably best to us…
I strongly disagree. The top AI companies are using a lot of Python (although sure they also use other languages too, but they're definitely using Python!). Even if by ML you mean old-school ML techniques, a ton of big companies also use Python for this (some might use MATLAB or R).
On the other hand I don't know of a single large company using an FP language for ML, unless you count something like Spark (which I would push back on: the Scala API of Spark is not really FP and almost all users of Spark that I know of program mainly in the more OO part of Scala rather than its FP part).
Even die-hard FP companies such as Jane Street use Python for their ML (see e.g. https://www.janestreet.com/join-jane-street/position/4276720... which notably mentions Python and does not mention OCaml).
Do you know of any company with a team of over 50 ML researchers (either old-school ML or modern AI) using an FP language as their primary workhorse for that team? Because I can't think of a single one.
More to the point, do you know of any ML researcher (and who is acknowledged as primarily an ML researcher by other ML researchers) who primarily programs in an FP language?
Even in the golden era of symbolic AI from the 70s and 80s they still weren't using FP languages (they basically didn't exist yet). The closest you could say is that they were using Lisps, but Lisps aren't FP languages by default. Some are (e.g. Clojure), but many aren't or at least aren't any more FP than any other multiparadigmatic language (e.g. Common Lisp). And again I don't know of any significant ML work being done in Lisps at this point (there's some scattered small teams and individuals doing work there, but nothing that I think could rise to the level of "big ML company").
Re: Why engineers can't be rational about programming languages
#108Earlier quoted context omitted.
great team can write amazon clone in fortran. bad team cannot write todo list clone in… well anything :) it is (almost) always people and (almost) never language/framework/…
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.
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 language for everything (e.g. Java) and tries to write everythin in that language. They are specialist and they may accrue deep knowledge of the language versions, APIs and IDE(s). Another type of developer, in contrast, maintains active knowledge of a dozen programming languages (C/C++, Java/Kotlin, Python, bash, Rust, Go, PHP, JavaScript, ...), and is capable of delivering projects in each. They'd pick a language suitable for the task and stick with it for a project. They won't know any single language as intimately as the first type, but they benefit by virtue of their choice of language being more appropriate to the given project.
Re: Why engineers can't be rational about programming languages
#109I don't agree with the title - I've seen many engineers be rational and pragmatic about programming languages. I'm not entirely sure why the author decided to lead with such a charged headline.
Because his first experience with this debate was forcing PHP on engineers who knew that would be a bad choice. No matter what you are doing, PHP isn't the right choice for it if more than 1 person will ever use or depend upon the software. PS I've seen PHP destroy billions in value in my career. It and Brainfuck are the only 2 languages you should never use to make software for other people. Every other language has…
And similarly, "Python for scripting" (Instagram?)... It's the effectiveness you achieve with it that is perfect for many new projects, based on language itself (dynamism, introspectiveness, readability...) and rich standard library and ecosystem.
I'd say you are not looking objectively at language choices despite the evidence being there in plain sight to counter the claims you are making.
Re: Why engineers can't be rational about programming languages
#110Earlier quoted context omitted.
Probably should be "management" can't be rational about programming languages because that's what it's about. The article isn't talking about a group of engineers coming together to decide on a platform, instead it's about a choice being thrust upon from from up high. That management is also an engineer but that's not really the key point.
Why would management care about tools?
Management does need to care to ensure they hire people who will make the right choices (which is a careful balancing act of investment vs returns) if they don't trust themselves to do it.