Actually, machines are attuned to flat, unstructured lists of instructions, the polar opposite of functional programming. But when people wanted to think clearly, they invented math, of which FP is nearly the computational manifestation. You have the human-vs-machine thing exactly backwards. The reason we tend to think in imperative terms is one of familiarity: most of our first programming experiences are in languages that are (sometimes high-level, but still) descendants of assembly, because at first that was the only programming that existed: flat lists of instructions designed for a machine.
Granted, if a human wants to describe a physical process, they will use procedural language. But computers are primarily about information, and we think about information in terms of relationships. That's exactly what FP is about: expressing computation in terms of relationships.
I agree that a Turing machine is imperative...when I refer to machines I am generally referring to an inflexible approach to solving problems, not so much how computers execute instructions.
As humans I think we need the ability to be messy and imprecise in order to be creative.
>The reason we tend to think in imperative terms is one of familiarity
That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption.
I'm writing OCaml now. I'm being messy and creative all over the place, sketching out ideas, and simply not trying to compile them until I think it'll work. I do this precisely because OCaml maps naturally onto how I think about the problems I'm working on right now. It's pseudocode until I run make, at which point the computer is running very useful checks on my reasoning.
The "inflexible approach to solving problems" you refer to has, as far as I can tell, nothing at all to do with "machines", except perhaps in an exceptionally abstract sense, in the form of virtual machines designed for thinking about. On the other hand, problem solving doesn't get much more flexible than raw assembly. My point stands.
I think the early adoption of imperative languages was more due to pragmatism than elegance[0]; at first, you had to stay close to the machine to get anything done, at first because that's all that existed (Fortran beat Lisp into existence by a year) and then for performance. Remember, Fortran was still basically a shortcut for assembly, while Lisp started as a purely mathematical abstraction, designed expressly for thinking about, that some goofball wrote an interpreter for.
[0] This principle is still clearly in force today. We wouldn't bother with C++ and JVM languages and Unix so much if pragmatism wasn't paramount.
I'm using Fortran as my example of an early imperative language. There might have been earlier ones (maybe a version of COBOL?), but since they were imperative it doesn't materially affect my point.
> That's debatable given that both approaches have been around for about the same length of time with different outcomes in terms of adoption.
If unix had been created in LISP or ML, I believe we might be in the opposite position. Though that hinges on a LISP unix being as successful as the C one.
Was that because C was better than Lisp though, because of timing, or because the people working on UNIX's goals were more closely aligned with the industry as a whole?
There are of course many other things it could have been, but these are the first that come to my mind.
>But when people wanted to think clearly, they invented math,
No, they didn't. They invented a syntax two milleniums ago, optimized for use-cases of those ages, using alphabets of those times. Thinking in greek symbols is not helping anyone think clearly. It's just more confusion, because now suddenly, i can't type or phrase a relevant question out loud, until i get a greek keyboard and learn the proper pronounciations of the greek alphabet.
The notion we should just stick to a notation and conventions optimized for a different era, a different culture, a different alphabet and a different writing tool (paper), is ridiculous. Do NASA scientists calculate speed using knots? Or power using horse power? They do not.
Math is to computer science, what classical music is to pop music. A historical relic that stopped having economic and cultural value beyond being a mere status symbol.
>of which FP is nearly the computational manifestation.
No, it's not. One could argue the same thing for logic programming. Computation is not the manifestation of math. It's a strategy to answer a mathametical question. The original strategy was to just 'try things and explore' and when you found (guessed?) the answer, you would prove it to be sure.
Functional programming, in the religious Haskell sense, is just a term rewriter. That's not the manifestation of computation. It's just one way to specify a strategy. In the case of Haskell, which is a term rewriter with a bible full of fine print and exceptions, a very sado-machistic one.
>But computers are primarily about information, and we think about information in terms of relationships
No, that would be Prolog. A different default strategy. Less fine print, but not the cure-all either.
>That's exactly what FP is about: expressing computation in terms of relationships.
Nope. A relationship doesn't have a computational direction. In math, all these statements express the same relationship:
double( x ) / x = x
double( x ) = x * x
x * x = double( x )
In Haskell, only one of them happens to be legal. Because you are not writing a mathematical equation. You are specifying a computation. The fact that isn't even obvious, makes matters worse.
> But computers are primarily about information, and we think about information in terms of relationships
Yes, and the biggest challenge, the pain everyone tries to lessen, is managing the coordination and standardisation of changes (mutations) to that information. Wrapping every computation with the same type of state-monad actually helps a lot with this, and has been the most popular strategy to deal with this problem in the last 20 years.
Relationships can be directional if you want them to be. Also, I wish people would stop conflating "religious" functional programming with pragmatically expressing algorithms as compositions of functions. That said, I don't think you and I really disagree much on the big picture.
>Also, I wish people would stop conflating "religious" functional programming with pragmatically expressing algorithms as compositions of functions.
Yes, me too. And that type of functional programming is very popular and very succesfull. Every programmer uses it often, when they touch SQL, jQuery, LINQ, etc.
>I don't think you and I really disagree much on the big picture.
I love functional programming.
But i consider languages like Haskell and their derivates to do a lot of harm to the reputation of functional programming. Lazy evaluation and the whole pretending math == computation. It's borderline harmfull to the development of a programmer to even be exposed to it. The last thing you want a programmer to believe, is that there is some intrinsic order of execution that is magically correct and optimal, and can easily be derived. There isn't. The correct order of execution is not even objective (in a GUI one would trade throughput for lower latency, for example), so the notion we can just skip that whole part, and have the 'compiler take care of it' seems damaging to me. Languages that allow you to specifiy these things manually are considered ugly mutations of some kind of pure math. Sinners. That we need return to one true god, which is "pure" math, mascerading as a term rewriter and bible full of fine print, and a zero tolerance on maintaining global state. Yuck.
I've never heard anyone refer to Haskell's lazy evaluation as The One True Evaluation Order. it's just one interesting way of doing things. I think there's a useful place for Haskell in the space of programming languages, I just don't want it to be the default example of a functional language.
Granted, if a human wants to describe a physical process, they will use procedural language. But computers are primarily about information, and we think about information in terms of relationships. That's exactly what FP is about: expressing computation in terms of relationships.