Functional programming simply isn't any better than the usual style of python development.
I have used much of itertools. When you need to do some complex iteration through lists, itertools is great. When you need to pull an address out of a web page, itertools does absolutely nothing to make that easier, nor does any other functional programming technique.
So here is the difference. Procedural style is better for dealing with a problem. Functional style is great for applying a solution to lots of pieces of data in a structure that can be iterated over or recursed into. The hard part is dealing with each problem, not the part where you apply it.
> When you need to pull an address out of a web page, itertools does absolutely nothing to make that easier, nor does any other functional programming technique.
I'd say an approach like "iterating through all nodes, filtering for the one(s) you want" is quite functional. Add lazy iteration to that, so you're only parsing/consuming as much of the document as necessary, and on-demand, and you've got a really nice, _functional_ solution.
Ok, that is great so long as you are processing XML. Actually, it isn't great even if you are processing xml.
What is the functional way to get the 3rd - 8th li in the 2nd ul where the ul has id="foo" and is in a div (either directly or as a decedent) where the div is directly before the 'comment' <-- content area --> ?
You use XPath, or CSS after finding the comment with a regex. People get incredibly retarded about functional languages, but in reality the only software that I have used that is written in one is XMonad. So in your mind everyone who actually gets things done is using the 'wrong language'? Or an inferior one?
Name one big success story of functional programming. There isn't one. Nobody uses it who actually cares more about getting things done than reading self congratulatory blogs between CS classes.
"Name one big success story of functional programming. There isn't one."
Map Reduce. It is implemented in C++ (and other languages) but MapReduce itself is very functional. The users of mapreduce do "functional programming". Maybe you wanted success stories of functional programming languages? (which is a different question).
Another : SpreadSheets
Yet Another: SQL . SQL is (at the core) relational rather than functional, but functions are relations. This keeps getting rediscovered every now and then (witness all the noise around Rails3 and Arel)
"Nobody uses it who actually cares more about getting things done"
It must be nice to be so certain and knowledgeable about such things. You are a lucky man ;-)
I think he meant software. SQL is a standard on paper, not software.
Map Reduce is a framework, ok. But written in C++?
A software project that i would say counts is ejbabberd. But, that's the only one i can think of.
Somehow i never looked at it in this way, but Lisp has been around since 1958, Erlang and Haskell are not new either. Still there is not much software written in those languages compared to other languages.
The AXD301 switch contained over a million lines of Erlang, and reported to achieve a reliability of nine "9"s. Would that count? RabbitMQ?
"Nobody uses it who actually cares more about getting things done" is a stupid (and more importantly wrong) thing to say. Joe Armstrong is a very "get things done" person for example.
It sounds to me like you're the kind of person who has trouble recognizing OO code written in C.
Once you truly understand a programming paradigm you can express it in any Turing-complete language you want to. If you find yourself unable to do this, then you don't really understand that paradigm. And I assure you that the people at Google who implemented the map reduce framework understood functional programming very well.
Incidentally the fact that you disqualify SQL from the discussion because there is a paper standard seems to me to be silly. It is about as silly as saying that C isn't really a software language because there happens to be a written standard defining the language. The existence of the paper standard doesn't change the fact of a lot of software is being written with that piece of programming technology.
The fact that you compare SQL to C tells me that we clearly have a different understanding of programming languages, yes.
There are people that say "i code HTML". Yes, call it coding and programming if you like. I won't. Clearly SQL is powerful and great but you don't write software in it, which is my point of differentiation.
Yes yes, and there are probably a lot of programs writen in Ada and Fortran that have millions of lines of code and are reliable.
But, you can argue with me or not, it still is a niche.
C appeared in 1972.
Lisp (as one of the oldest i can think of) appeared in 1958.
Can we agree to say that there are far more programs written in C then in Lisp?
I don't argue which language is "the best" (because clearly, it's more subjective then objective to state on that).
But somehow, there is probably a reason, that C, as a newer language than Lisp, has by far more "followers" then Lisp.
If Lisp (as the grandfather of functional programming, but you can replace lisp with haskell, erlang or whatever you like) is so easy, creates better, more reliable code, etc. etc. Why did C take off and Lisp didn't?
In fact why do younger languages like Ruby have the bigger growth? Clearly people look for new languages, the people that nowadays learn ruby or c#. Why don't they learn Haskell?
For example:
Look at http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
The really brand new language Go made it to #13. Lisp/Scheme after decades is #18. It's becoming more popular it seems, but i bet it won't be in the top10 for the next years.
Now, my simple and plain question is: Why is it like it is?
I actually don't want to argue what the best language is, there is no sense in that. And i can't code functional. See me as an observer from the outside. I'd like to learn erlang some time, for sure.
I agree. It's like saying that a Porsche is 'better' than a Ford, but you own a Ford because the Porsche costs more money than you make in a year.
I think functional language proponents want to compare languages using one set of metrics, even though they actually pick a language to write software in on an entirely different set of metrics. I mean they must either do that, or be entirely all talk, since very little software is being written in functional languages.
Consider your grandfather's old hammer. The one where the head fly off and you have to wedge it back on as best you can. Yes, it will fly off and hit you and bystanders, but the nails generally get in there when it stays on. It's basically as bad as a hammer can be, but a garage, a covered porch, and countless forts have been built with it.
Now consider a robot that, when properly programmed, can build a house from scratch, all by itself. All you need is a team of 5 engineers on standby to program it, and to keep it humming along. It is very hard to figure out how to use the robot to even drive a single nail, but if you know how to use it effectively, and have the entire house planned out in CAD and in every detail, it will just build a house in an afternoon.
It's easier and cheaper to hire carpenters to build a house than to hire the engineers that it takes to babysit the robot. Plus, no construction crew can plan a building down to the tiniest detail before they start, because the ground ends up being too soft, or it turns out that there is a bolder which must be cracked using explosives, or the windows called for in the plans aren't made anymore and the replacements are 3cm narrower, or the insulation is out of spec and a little too thick.
Don't rent the robot, buy a new hammer that isn't broken.
But just to stick to it, if you are building a house, use carpenters wielding your grandpa's hammer to drive in the nails.
if you need to explore Mars, your illiterate hammer wielding carpenters won't help and you might want that robot and expensive scientists after all.
The whole metaphor is flawed anyway. You argue by metaphorical extremes. Even within the metaphor (this is a wrong way to argue a point), there are plenty of intermediate positions between Grandpa's crusty hammer and terminator style robots. Would you use a power drill and bulldozers or would you use shovels and hammers? (or cudgels and stone tablets?
See? Metaphors can be twisted to argue any view point, even diametrically oppoiste ones. Arguing by metaphor is a logical fallacy (Equivocation iirc) It breaks down very fast and has no legs.
CouchDB (used, among other things, for both the client and server of Canonical's "Ubuntu One" desktop sync service). Dynomite, SimpleDB (though reportedly some parts of SimpleDB were initially rewritten in Erlang and later ported to C++). Darcs. Mochi Media's web stack. Jane Street Capital's trading systems. Unison (popular two-way rsync written in OCaml). Flightcaster.com. Coq. FFTW. Hacker News.
I want to give a special mention to FFWT, the gold standard for Fast Fourier Transform libraries. If you use any audio or video software, you probably use this library without knowing it. An OCaml program generates the C code that compiles to the FFTW library.
Spreadsheets are not functional, they are spreadsheets. Try to re implement a complex spreadsheet in another language sometime and you'll see what I mean (hint, any change propagates through the whole sheet instantly).
That's like saying that abstraction expresses the essence of well-designed functional programs. True, but so broad a statement as to be nearly meaningless. There's nothing about regexps that makes them closer to well-designed functional programs than well-designed OO programs or structured programs.
I have used much of itertools. When you need to do some complex iteration through lists, itertools is great. When you need to pull an address out of a web page, itertools does absolutely nothing to make that easier, nor does any other functional programming technique.
So here is the difference. Procedural style is better for dealing with a problem. Functional style is great for applying a solution to lots of pieces of data in a structure that can be iterated over or recursed into. The hard part is dealing with each problem, not the part where you apply it.