On the flip side of that though, hardware has gotten fast enough, where this is possible.
Users/customers accept a certain level of quality, and it doesn't make short-term economic sense to provide more.
Do you spend a ton of time writing beautifully optimized code, but ship less features, or do you ship a ton of features that mostly work. I feel like if you take too long to ship, a competitor will eat your lunch. But if everything you ship is trash, then a competitor will also eat your lunch. All about finding that balance I guess.
Functional programmers have been in a massive propaganda campaign to actively paint optimization not just as “usually not necessary”, but actually as a negative thing.
Ask any developer what they think of optimization, and the vast majority will respond “optimization is the root of all evil” or some other nonsense variant.
Now that they’ve successfully paint optimization as bad, they’re working on painting any profiling or measurement at all as bad.
They need this because the performance characteristics of pure functional programming is pretty dogshit.
You also find hordes of developers that selectively care. Watching Python developers shit on Java for “being too slow” is getting pretty old.
Pure Functional Programmers state that you should not even measure performance. They take this position because despite their many claims that Pure FP is performant, it turns out that if you measure it, it’s not performant.
Hence “don’t measure”.
Look on something like java or kotlin, that are inherently slowing down EVERY.SINGLE.VARRIABLE. access by boxing them into objects.
On other hand there is rust, which takes quite a bit of inspiration from fp aproach but obviously still cares about the performance.
Based on what? FP advocates like performance as much as anyone else.
They need this because the performance characteristics of pure functional programming is pretty dogshit.
Research languages like ATS show that functional programming doesn't come at the price of performance.
Nobody is going to use theorem proving languages for a lot of reasons, but actually, mostly cause functional programmers did themselves in with their other ridiculous propaganda campaign to declare that developer time is too expensive.
If ATS is a pure functional programming language, then it by definition of how cpus work cannot be performant, although there may be some things it can match other languages (usually reads are not noticeably slower)
That claim doesn't match my experience at all. Can you give some examples of that attitude being demonstrated on /r/haskell?
I think maybe a more measured take is that many modern environments remove the developer sufficiently from the actual execution of their code that performance optimization becomes much less obvious and straightforward.
Also, and this is just my personal experience, but I've basically never heard anyone actually claim that optimization is bad or unnecessary. I have never, ever heard anyone claim that profiling tools are bad.
What I have repeatedly heard is that there often isn't a compelling business case for performance optimization. Unfortunately that's probably correct a lot of the time.
I really think you're pointing at the wrong folks here. The hordes of JS devs out there who are deprioritizing perf aren't doing so because they think it's fundamentally a bad thing to optimize, that's just a self-apparently ridiculous notion, they are doing so because they work in a culture that values delivery of features massively more than optimization.
Also, a lot of literature on improving garbage collection came from trying to improve the speed of a functional language like Lisp or Standard ML.
It seems to me that functional programmers tend to care more about optimization than e.g. Python or Ruby developers, because functional programming has a long history of being perceived as slow and they want to change it. Scheme, OCaml, Standard ML, and Haskell all have implementations that perform well and compile to assembly.
You have to consider the survivorship bias. Maybe the people that care about optimization don't 'survive' to keep caring about it.
> It's just "ship, ship, ship, move faster, ship."
Are startup with that mentality more likely to do well?
I've built my career around performance work and I've noticed that there a time and a place for everything. Sometimes shipping is more important, and sometimes performance can be a day one defining feature.
Until customers care about performance/optimization, most businesses won't care. Eventually there will come a day where hardware will stagnate sufficiently to incentivize software efficiency.
They do, Businesses and programmers are incapable of listening to them
Users primarily care about features first and speed second.
This software exists? When all your alternatives are bloated enshittificated crap, what exactly can I as a user chose?