"This is also why programmers who use typed functional languages frequently brag about their low bug count yet eschew methodologies like test driven development: tests pale in comparison to the power of actual models."
I've written complex systems. Games. Graphics modelling tools. Network game engines. I've seen a lot of code.
I've never seen anything that complex written in a functional language.
Why?
My hunch is that models are powerful, but brittle: they don't stand up against constantly changing requirements. A great quote I read the other day was "If it compiles, it works". Great. Now change the requirements. The "beauty" of imperative languages is that they continue to compile and continue to provide some value of "work" even while they are morphing from one requirement set to the next. Functional languages are cast-iron. Imperative languages are steel.
UPDATE: I should also be clear: I think in models all the time. I just don't have to get it down perfectly on paper for the code to compile. I used to hear, back in the day, C++ programmers opining that we should all use C++ because object-oriented programming is superior. Regardless of whether or not OO is superior, they completely failed to comprehend how one could do object-oriented programming in assembly language, or that we'd been doing it the whole time.
So its entirely possible that there's something I dont get about functional programming that means I don't understand what I'm missing. But its also possible that I understand the theory better than you and so I don't see the distinction you are making because there isn't one. To discern which is true, however, I'm going to need concrete examples, not opinion pieces.
I disagree. Generally I see this problem when trying to program in a functional languaged with an imperative thinking. This is not a weakness of the language, but of the developer.
I think the hunch of the original article is that few programmers understand the correlation between math and software, hence the lack of use.
Calculus should change the way you understand and perceive the world around, if it didn't, either you got bad teachers and need to ask for your money back, or you were studying only for the test.
And there are a lot of examples, but you can see that AFTER you understand and apply the math behind the concept. Getting by without it is not a proof of its futility, it is only a defense mechanism of the ego.
Javascript. It is closer to functional programming than to object oriented. But most developers don't see this and believe that since they can get by shoehorning "classes" into a prototype then they are back to what is familiar. Prototypes are templates, no classes. Once you develop in javascript with a functional mentality, boy it becomes easy and elegant.
Sql and set theory is another example.
On the more abstracted side... Requirements modeling and calculus. Calculus classes should change the way that you percive
Do these programs meet the OPs definition of functional programming, or are they, in fact, a whole bunch of imperative code that use closures as a method for scheduling more imperative code?
I think the point is that there's something intrinsically verifiable about a mathematical model since you're dealing with quantifiable output.
Other cases I can think of are systems where high-throughput or low latency are major requirements but there aren't many of those. Most of what we do is about getting more users or making more profit - good engineering performance and decisions are not directly related to these.
Naughty Dog created their own version of lisp called GOAL to control game objects. Scripting languages are common in games, but the "heavy lifting" is done in C/C++, as is the case in Jak and Daxter and Crash Bandicoot. Naughty Dog don't use GOAL any more. Have their games gotten worse?
Also note that the effect on performance and throughput are cited as downsides of using GOAL.[1][2]
I met the Naughty Dog team back then and Crash was an awesome game. Their use of a custom scripting language for so much of a real-time game (as opposed to an RPG) was pioneering. They did other innovative things, like baking in radiance transfer to their models to get the lush levels in the game. But at the end of the day, when the Lisp evangelists left Naughty Dog, they stopped using it almost immediately. Apparently, despite using Lisp, and learning from "one of the best lisp programmers in the world", none of that rubbed off on what appears to be an excellent programming team.
The only explanations are:
a) In 7+ years of working with a foremost Lisp programmer, that knowledge did not transfer, or
b) It did transfer, and the other programmers did not see a net advantage.
The OP would like us to believe that the answer is (a). Subsequent games from Naughty Dog would suggest that it is (b).
"""Other cases I can think of are systems where high-throughput or low latency are major requirements but there aren't many of those."""
Actually, I haven't met many cases of systems were high-throughput or low latency are NOT major requirements.
Sure, you can wait for your admin script to do something for half an hour, if it means you get to write it in, say, Python, over some faster language. But you don't want to wait for most things, including most end user software. Here's a list people complain all the time about the slowness of:
1) text editors, programmer editors etc.
2) spreadsheets
3) media players
4) compile times
5) image editing programs
6) web pages/apps
7) mobile apps
8) games
9) file managers
10) IDEs
11) video/multimedia editing
12) sound editing
13) word processors
14) window management
15) databases
16) ftp
17) file management
18) asset management
19) browsers
If there's a program for something, there are people complaining it's slow/bloated.
Well observed, but I think we need to tell apart cases where performance is mandatory and where it is optional. People wouldn't just complain if it was mandatory, it simply wouldn't be a viable product.
I've written complex systems. Games. Graphics modelling tools. Network game engines. I've seen a lot of code.
I've never seen anything that complex written in a functional language.
Why?
My hunch is that models are powerful, but brittle: they don't stand up against constantly changing requirements. A great quote I read the other day was "If it compiles, it works". Great. Now change the requirements. The "beauty" of imperative languages is that they continue to compile and continue to provide some value of "work" even while they are morphing from one requirement set to the next. Functional languages are cast-iron. Imperative languages are steel.
UPDATE: I should also be clear: I think in models all the time. I just don't have to get it down perfectly on paper for the code to compile. I used to hear, back in the day, C++ programmers opining that we should all use C++ because object-oriented programming is superior. Regardless of whether or not OO is superior, they completely failed to comprehend how one could do object-oriented programming in assembly language, or that we'd been doing it the whole time.
So its entirely possible that there's something I dont get about functional programming that means I don't understand what I'm missing. But its also possible that I understand the theory better than you and so I don't see the distinction you are making because there isn't one. To discern which is true, however, I'm going to need concrete examples, not opinion pieces.