How is the distinction between functional and imperative programming languages “not a real one”?
“Not a real one” is sort of glib. Still, I think Jim’s point stands.
The two words “functional” and “imperative” do mean different things. The problem is that, if you want to give a clean definition of either, you wind up talking about the “cultures” and “mindsets” of the programmers that use and design them, rather than actual features of the language. Which starts making sense, really, when you note “functional vs. imperative” is a perennial holy war, and that these terms have become the labels for sides in that war, rather than precise technical positions.
I mean, I am somewhat partisan in that war, and rather agree that, e.g., we should point new programmers to Scheme rather than Python or Java. But presenting “functional” vs. “imperative” as the major division in thinking about programming languages is epistemically dirty, when there’s so many distinctions between languages that matter just as much, and describe things more precisely.
I’ve wrote about the difference between imperative programs and functional ones (here, trying to explain why an imperative programmer might find functional programming difficult).
The main differences (do vs be, reversed order of reading, and heavy use of first class functions), make a quite sharp divide. Way sharper than other divides, such as “Object Oriented” versus the rest (though Alan Kay’s original vision is probably more distinguishable than the current C++/Java vision).
Now when talking about programming an FAI, the most probable course of action will be to translate the math of FAI into a program. One thing I noticed about math formalism outside the specific field of computer programming, is that most formulations are either stateless, or explicit about state. When at some point we say X = some long expression, we know it won’t change until the end of the assignment. The math I know tend to be functional by default.
“Not a real one” is sort of glib. Still, I think Jim’s point stands.
The two words “functional” and “imperative” do mean different things. The problem is that, if you want to give a clean definition of either, you wind up talking about the “cultures” and “mindsets” of the programmers that use and design them, rather than actual features of the language. Which starts making sense, really, when you note “functional vs. imperative” is a perennial holy war, and that these terms have become the labels for sides in that war, rather than precise technical positions.
I mean, I am somewhat partisan in that war, and rather agree that, e.g., we should point new programmers to Scheme rather than Python or Java. But presenting “functional” vs. “imperative” as the major division in thinking about programming languages is epistemically dirty, when there’s so many distinctions between languages that matter just as much, and describe things more precisely.
(Jim: fair rephrasing?)
I’ve wrote about the difference between imperative programs and functional ones (here, trying to explain why an imperative programmer might find functional programming difficult).
The main differences (do vs be, reversed order of reading, and heavy use of first class functions), make a quite sharp divide. Way sharper than other divides, such as “Object Oriented” versus the rest (though Alan Kay’s original vision is probably more distinguishable than the current C++/Java vision).
Now when talking about programming an FAI, the most probable course of action will be to translate the math of FAI into a program. One thing I noticed about math formalism outside the specific field of computer programming, is that most formulations are either stateless, or explicit about state. When at some point we say
X = some long expression, we know it won’t change until the end of the assignment. The math I know tend to be functional by default.