This needs moderating up. Talk to an Ocaml programmer and a Haskell programmer about what makes a functional language and you'll see very different opinions and these two are languages that were actually designed as functional languages: the bits that end up in other languages are a tiny subset.
Coming from the Haskell side, I see functional programming as programming without side effects and with monads. You can implement monadic constructs in other languages, but it rarely makes code cleaner. Just having higher-order functions doesn't make a language a functional language any more than having structs makes C an object-oriented language.
If the question is 'do you think using higher-order functions simplifies the expression of some algorithms' then the answer is obviously 'yes': programmers have a lot of tools to choose from and most of them are useful at least some of the time.
Oh, so that carrier group really was near North Korea after all!
So if regular programmers who form the bulk of the workforce can't grok them, the languages need to be fixed, not people.
I know what you're saying, but there's a real danger here that the industry will find itself caught in a local extremum. An engineer of 1880 could easily have said that if regular engineers who form the bulk of the workforce can't understand this "electricity", then it needs to be fixed to conform to the world of steam.
The worst thing we can do as an industry is think we know what we're doing. And in a sense, we're already there.
Asking whether you like functional programming is like asking whether you like phillips head screwdrivers.
I do not. Give me JIS screwdrivers any day.
If one is well versed in category theory or has spent a significant amount of time working with functor spaces, monoids, and monads, then it's much easier to understand a non-trivial application written in Haskell than the equivalent object hierarchy in an object-oriented language. The up-front cost is greater in terms of study and learning the semantics, but the end result is significantly more powerful.
I strongly suspect (but can't yet prove) that the supposed up-front cost in understanding Milner-esque functional languages is just the same as the up-front costs for Simula-style object oriented languages. The difference is that in the case of Simula-style object oriented languages, most of the up-front cost has already been largely paid by the time you come to them.
If it's any help, consider that there seems to be a significant learning cost in wrapping your brain around "real" object-oriented languages such as Smalltalk when coming from "broken Simula" object-oriented languages such as Python or C++.
We teach set/function theory and basic logic to high school students. It shouldn't be that much harder to make the very small amount of generalisation to explain the fundamentals of a modern logic-based type system.
It only makes code more readable if you're familiar with it (functional programming).
Well that's a truism. Object-oriented programming is the same: it only makes code more readable if you're familiar with it.
The main distinction between the two, however, is that object-oriented programming was invented, but functional programming was discovered.
There are several things wrong with Python, but the main thing that it has in common with Basic is that it's impossible in general to tell what a program means by looking at the source text. You can only tell by running it.
I wouldn't give up the time I had with Basic, either.
Given that 10,000 years from now the world-wide network will be unrecognisable (if there's any justice in the world), it could be the Thing of Internets.
Like many from my era...
It took years to undo the damage!
Yup. And in that respect, Python is the new BASIC.
"Gotcha, you snot-necked weenies!" -- Post Bros. Comics