Comment by yogthos
7 years ago
The point here is that for many domains performance is not the top consideration. And it's also worth noting that it's perfectly possible to tune applications written in FP languages to get very good performance. It's also possible to identify the parts of the code that are performance critical and implement those using imperative style. This is especially easy to do with Clojure where you have direct access to Java.
So, yeah if you're working in a niche domain where raw performance is the dominant concern, then you should absolutely use a language that optimizes for that. However, in a general case using FP language will work just fine.
Sure I get that, but I'm saying your statement about "the overall historical trend" is wrong, or at least fails to capture a large part of the truth.
At some point in history, people stopped worrying about not understanding compilers
This part is misleading too -- I would say there is a renaissance in compiler technology now. For the first 10 years of my career I heard little about compilers, but in the last 10, JS Engines like v8 and Spidermonkey, and AOT compiler tech like LLVM and MLIR have changed that.
The overall historical trend is that computing is getting used a lot more. So you have growth on both ends: more people using high level languages, and more people caring about performance.
It's not either/or -- that's a misleading way of thinking about it. The trend is more "spread", not everyone going "up" the stack. There will always be more people up the stack because lower layers inherently provide leverage, but that doesn't mean the lower layers don't exist or aren't relevant.
And lots of people migrate "down" the stack during their careers -- generally people who are trying to build something novel "up stack" and can't do it with what exists "down there".
Once parallel execution became part of every design discussion that had a performance concern, the vast majority of programmers stopped caring (and consequently talking) about compilers. Who cares if you can do 36k requests/s to my 18k if I can do 36k across 2 or 3 machines? I pass that on to the customer. Why try to hire for or wait around for an optimization trick to double performance (that will likely never be realized or discovered) when there's business to be done? The post-optimization is pure profit and can be quantified, so might as well wait and let some specialist (who does care about compilers) handle it if the product ends up being valuable enough to hire them. This is how development and hiring works today.
> At some point in history, people stopped worrying about not understanding compilers
> This part is misleading too
Not in the least. Interpreting that to mean "all people stopped worrying" is deliberate misinterpretation.
You're simply used to working in environments where technical excellence doesn't exist. In such environments performance is not a big concern, but neither is quality in general...
2 replies →