
What's your strongest opinion against functional programming? - philonoist
https://softwareengineering.stackexchange.com/questions/9006/whats-your-strongest-opinion-against-functional-programming
======
cellularmitosis
I have yet to encounter any closed stackoverflow question and think to myself
“boy am I glad they closed that one!”

In fact, most of the time I encounter one of these closed questions, it was
precisely the question I was curious about.

I just don’t understand why they do this.

~~~
SiVal
I totally agree. Probably a third of the useful answers I've gotten from SO
have been cases where I asked Google, Google said "yes, StackOverflow has an
answer to your exact question", and I am delighted to see that someone helpful
and knowledgeable somehow managed to get the answer out before the guards
swarmed in and demanded an end to all that forbidden usefulness.

What a ridiculous, hostile system.

------
ncmncm
The elephant in the room of functional languages is that they all, somehow,
fundamentally depend on garbage collected memory management. This GC is never
coded in the functional language itself. Why? Because functional languages are
very, very bad at resource management.

Real programs typically need to manage resources besides memory. So, they look
good depending on GC for toy problems, but fail to graduate from their
sandbox.

The only powerful languages not dependent on GC are C++ and Rust. They have
facilities to manage any resources needed, and that are equally adept at
managing memory.

As a consequence, it is possible to write libraries for these languages that
can work in any program.

Programs in obligate-GC languages always need to compromise some aspect of GC
to be practical, but that makes them incompatible with the majority of
libraries. Thus, you don't see good library ecosystems grow up around them.

A functional language that did not depend on GC could be useful, but academics
would kneecap it immediately. Academia absolute detests the idea of non-
obligate-GC languages, for purely tribal reasons.

------
rgoulter
[https://pchiusano.github.io/2017-01-20/why-not-
haskell.html](https://pchiusano.github.io/2017-01-20/why-not-haskell.html) I
found this argument compelling: Haskell is good for programs like compilers:
they do many interesting things but without needing to interact with the
outside world as much.

Whereas "straight-forward CRUD app" is more about interacting with the outside
world, which is harder to do in Haskell compared to, say, Go.

HN discussions 2018
[https://news.ycombinator.com/item?id=17114308](https://news.ycombinator.com/item?id=17114308)
2017
[https://news.ycombinator.com/item?id=13450828](https://news.ycombinator.com/item?id=13450828)

~~~
cheekybillberry
I've never really thought about it quite this way before, but: pure functional
systems basically want to ignore time. In some contexts this is ok or even
desirable, but in other contexts it is counterproductive and futile.

Time is pretty critical to physical reality, one way or another, and the
closer you get to it with lower and lower-level language systems, the harder
it is to ignore.

It seems to me there needs to be some very basic computational/mathematical
theory that integrates time more fundamentally into language/instructional
design without being procedural per se. There probably is one but I don't know
what it is, or am not recognizing it for what it is.

------
magicmouse
There are many buzzwords in the programming profession. These terms are
bandied about with great regularity, and mean almost nothing. Fundamentally,
we only have one kind of computer with two variations: the Intel and ARM
instruction sets which drive 99.9% of all computers used today. Everything on
top of these two hardware platforms is software, and since the hardware's only
commonly used instructions are arithmetic, copy, load/store, compare, branch
and call/return, the most powerful instruction is the function call and
return, and every language from Assembler onward has striven to wring as much
utility out of the call/return instruction. Functional programming is where
you try to give functions more weight, as opposed to the move instruction
which was COBOL's stock in trade. So one cannot be against functions, it is
one of the only power tools we have. What i am against is waving these banners
around, like OOP, Functional Programming, Top Down Design, etc., when what we
really want is reliable software that is easy to understand. We are evolving
towards better notations, but unless you change the hardware (and adding more
cores does very little to help) you are pretending these terms actually mean
something.

~~~
gnode
I think making arguments about programming languages fitting the hardware to
explain their popularity doesn't make much sense outside of high performance
or low level system programming. The obvious counterexample is languages with
garbage collection, which is enormously popular (e.g. Github's five most
popular languages by repository employ garbage collection:
[https://githut.info/](https://githut.info/) ). Another popular feature is
dynamic type systems.

------
he0001
Functional programming is beautiful and contained, the real world is cruel,
toxic, chaotic and doesn’t give a damn about functional programming.

