Hacker News Reader

Comment by wredue | Hacker News Reader

It’s actually worse than you think.

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.

View on HN

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.

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.

lol. No they don’t. The official line from /r/haskell is “all optimization is the root of all evil”.

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)

> The official line from /r/haskell is “all optimization is the root of all evil”.

That claim doesn't match my experience at all. Can you give some examples of that attitude being demonstrated on /r/haskell?

I'm puzzled by this read on the situation. For starters, vanishingly few programmers work in a pure functional context. Secondly, performance characteristics of functional programming are absolutely not dogshit. There are specific languages/VMs/etc that have inherent performance issues, but that's not a universal truth. To claim that would be like pointing at Ruby and saying that imperative programming is slow.

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.

JS developers have largely accepted the FP way of life, it’s why many JS apps are as slow as they are despite JS being actually quite fast.

I don’t think that has anything to do with FP honestly. I think it’s a combination of package culture, the language making it incredibly easy to write poorly performing code, and the massive scale and cultural/corporate tilt of the JS community resulting in a generally lower quality of developer.

Functional programmers have long worked to improve the compiler optimization of functional language implementations. This is how we got innovations like the continuation passing style (first used for compiling Scheme), deforestation, defunctionalization, tail call elimination, and strictness analysis (for lazy languages like Haskell).

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.

I don't think it's just about (or even mainly) functional programmers.

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.

Java ints etc are not boxed, right?

No, but as soon as you want to use anything like standard containers, you need to box them.

"int" is not boxed but "Integer" is. You can't use primitive types like "int" inside generic type arguments so in that case you're forced into using the boxed integer type.

Yeah and personally I've been on both ends of the spectrum. I think there is something to be said for pre-mature optimization and over-optimization. But I do feel like it's a lost art these days.

The quote means to not assume something is slow, but to actually measure it.

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

Reply on news.ycombinator.com