"On iteration": Why people leave Python(brehaut.net)
brehaut.net
"On iteration": Why people leave Python
http://brehaut.net/blog/2010/on_iteration
82 comments
That article makes some really good points, but I disagree. To me, Python is quickly becoming a good middle ground where I can use these powerful functional ideas, then drop down to imperative whenever I need to. In particular, this means that I can use Python to do scientific computing or to easily work with native libraries while still maintaining a lot of the functionality of more pure languages.
Compared to traditional static languages (C++, Java), Python offers an order of magnitude of improvement in productivity.
Compared to older scripting languages (Perl), Python offers a sane language and a rich programming environment.
Compared to other current popular scripting languages (Ruby), Python offers a solid runtime and better out-of-the-box performance at the expense of some elegance and fluency.
Comprare to some very interesting languages (Haskell, Erlang, Scala) Python is more widely available and allows you to produce good, portable, well-performing code quickly and easily.
It's a state of flux. Right now Python is my language of choice (after ten years of Ruby) and it touches that sweet spot of expressiveness and performance. However, the bolted-on features (verbose object system, clumsy metaprogramming) deliberate crippling of language (e.g. one line lambdas) and the underlying message of "there's one way to do it" (which is my way, because I know better than you) will, for me, mean that eventually I will move on. More expressive, coherent and flexible languages will eventually reach Python's current level of maturity and performance, and then it will be time to switch. It could be MacRuby, Scala or F# (but probably not Haskell or Erlang). Who knows.
But, for now, Python is a good choice.
Edit: typos.
Compared to older scripting languages (Perl), Python offers a sane language and a rich programming environment.
Compared to other current popular scripting languages (Ruby), Python offers a solid runtime and better out-of-the-box performance at the expense of some elegance and fluency.
Comprare to some very interesting languages (Haskell, Erlang, Scala) Python is more widely available and allows you to produce good, portable, well-performing code quickly and easily.
It's a state of flux. Right now Python is my language of choice (after ten years of Ruby) and it touches that sweet spot of expressiveness and performance. However, the bolted-on features (verbose object system, clumsy metaprogramming) deliberate crippling of language (e.g. one line lambdas) and the underlying message of "there's one way to do it" (which is my way, because I know better than you) will, for me, mean that eventually I will move on. More expressive, coherent and flexible languages will eventually reach Python's current level of maturity and performance, and then it will be time to switch. It could be MacRuby, Scala or F# (but probably not Haskell or Erlang). Who knows.
But, for now, Python is a good choice.
Edit: typos.
>Compared to other current popular scripting languages (Ruby), Python offers a solid runtime and better out-of-the-box performance at the expense of some elegance and fluency.
Although, Ruby doesn't have any iteration constructs as nice as Python's generators. (You could create them using call/cc, but I expect the performance would be awful).
Although, Ruby doesn't have any iteration constructs as nice as Python's generators. (You could create them using call/cc, but I expect the performance would be awful).
Comprare to some very interesting languages (Haskell, Erlang, Scala) Python is more widely available and allows you to produce good, portable, well-performing code quickly and easily.
Scala code compiles to Java bytecode, and performs comparably to Java code. It's just as portable and performant as Java, which means very portable and fairly performant.
Scala code compiles to Java bytecode, and performs comparably to Java code. It's just as portable and performant as Java, which means very portable and fairly performant.
May I suggest Lua with metalua? It seems to have most of what you're looking for (and luajit is very fast).
Lua has a library problem for many tasks.
Lua's design assumes you're comfortable with C. Lua in isolation has a library problem, yes, but in exchange can be small enough a language to learn and know in its entirety.
Such as?
Many/most libraries in Python are built in, so you don't need to hunt them down and install. More importantly your users need only have "Python", nothing more or less and don't have to fiddle to get things working.
But unlike Python, Lua is smaller than SQLite. You can just put it in a DLL and install it with your project. Any users that even notice it would be shocked to see how many installations of SQLite they probably have. :)
I would expand that to say that lua has a standard library and framework problem. You can link any old C library but there's little uniformity in how everything fits together and rather few task-oriented packages/frameworks exist.
I like lua and am using it for some tasks where I'd have used C in the past. But for many things where ruby/python have strong, pluggable libraries (e.g. everything web-related) there is simply no equivalent in lua-land.
Kepler project is nowhere near a django or rails.
I like lua and am using it for some tasks where I'd have used C in the past. But for many things where ruby/python have strong, pluggable libraries (e.g. everything web-related) there is simply no equivalent in lua-land.
Kepler project is nowhere near a django or rails.
Lua's historical niche has been as an extension language for C and C++ projects, not web development. It has the necessary infrastructure at the language level, though.
FWIW, I'm working on a lightweight, event-driven webserver and general server framework (like twisted or tornado). It will be released under a BSD-style license at the same time as my distributed filesystem (the project driving its development).
FWIW, I'm working on a lightweight, event-driven webserver and general server framework (like twisted or tornado). It will be released under a BSD-style license at the same time as my distributed filesystem (the project driving its development).
Comprare to some very interesting languages (Haskell, Erlang, Scala) Python is more widely available and allows you to produce good, portable, well-performing code quickly and easily.
Yeah, absolutely not true. You need to do a little more research before you say very silly things like this.
Yeah, absolutely not true. You need to do a little more research before you say very silly things like this.
agreed ... also i think the dynamically-typed nature of python (and similar languages) makes them very amenable to rapid prototyping and experimentation (code just runs without having to fight the type inferencer or checker). python lets you do clean and beautiful functional programming, but also, as you mentioned, to drop down to quick-and-dirty imperative mode
the author has a good point about pure functional languages being better-suited for concurrent programming, though
the author has a good point about pure functional languages being better-suited for concurrent programming, though
Just to be clear, Clojure (and most lisps) are also dynamically typed and thus allow just the same experimental approach. Clojure and Common Lisp (I can't speak for other lisps, but I think some schemes too - PLT Scheme perhaps?) also have optional Type Hinting that allow the program to run quickly too.
The reason Python is such a joy to use is that it hasn't felt the need to be all things to all people.
Those of us who use python are often coming from C++, perl, etc. and know all too well what happens to languages that try to add every feature that someone might find useful.
If you want to use a lazy purely functional language, you know where to find one. It's not python.
If you want a language that allows you to express your inner emotions by using your personal pet programming style, this isn't it either.
Those of us who use python are often coming from C++, perl, etc. and know all too well what happens to languages that try to add every feature that someone might find useful.
If you want to use a lazy purely functional language, you know where to find one. It's not python.
If you want a language that allows you to express your inner emotions by using your personal pet programming style, this isn't it either.
"If you want a language that allows you to express your inner emotions by using your personal pet programming style, this isn't it either."
That would be Lisp. ;-)
That would be Lisp. ;-)
Oh really? I would have said perl or perl-reloaded (aka ruby)? ;-)
Is there any evidence for this supposed trend? Or will these “many” programmers remain merely a vague hand-wave?
I have also observed this trend and commented on it here http://news.ycombinator.com/item?id=1087287 where other HN users have also confirmed it.
My own Python code, over time, became more and more functional in style until eventually I jumped ship to Clojure and Yeti (and over the past week, F#).
My own Python code, over time, became more and more functional in style until eventually I jumped ship to Clojure and Yeti (and over the past week, F#).
I doubt anyone has valid stastics to answer this, but I'll throw in yet another anecdote. For about five years I used Python for all my personal projects, then for a couple years I switched to Ruby because I was using it at work. Last year I switched to Haskell for everything from simple command-line scripts[1] to larger programs[2] to silly recreational programming[3].
[1]: http://github.com/mbrubeck/outline-grep
[2]: http://limpet.net/mbrubeck/2009/10/30/compleat.html
[3]: http://github.com/mbrubeck/mynock
[1]: http://github.com/mbrubeck/outline-grep
[2]: http://limpet.net/mbrubeck/2009/10/30/compleat.html
[3]: http://github.com/mbrubeck/mynock
i've found that demanding empirical evidence from a blog post often leads to disappointment ;)
I left Python for c++ because the job called for c++.
But there wasn't anything in Python that I found compelling so I never came back.
As a scripting language, Ruby seems so much more compelling, despite it's friendliness seeming to doom it to eternal slow bugginess. I'd go back to Ruby before Python.
But I'm more likely to add Python support to an app I'm developing, since I know it's more sensible.
Python's functional aspects seem chronically undeveloped so leaving it for a real functional language makes sense. But functional approaches seem limited in the "real world".
But there wasn't anything in Python that I found compelling so I never came back.
As a scripting language, Ruby seems so much more compelling, despite it's friendliness seeming to doom it to eternal slow bugginess. I'd go back to Ruby before Python.
But I'm more likely to add Python support to an app I'm developing, since I know it's more sensible.
Python's functional aspects seem chronically undeveloped so leaving it for a real functional language makes sense. But functional approaches seem limited in the "real world".
Right now, for me, it comes down to the libraries. I'm much happier in Ruby, but Ruby doesn't have nltk, scipy or boto.
Then again, Python doesn't have rake.
Then again, Python doesn't have rake.
Right on the money ;) All the evidence i have is purely subjective and anecdotal, but I personally know of a number for whom this is true.
As additional anecdotal evidence, this is true for me, though I'm still using Python for my next project simply because it's a proven language with proven libraries.
But I'm certainly ready and interested in moving toward a more functional language -- I've always been interested in the Lisps, and have always tended to write code in the functional style, where possible (even though my first language was Java...)
But I'm certainly ready and interested in moving toward a more functional language -- I've always been interested in the Lisps, and have always tended to write code in the functional style, where possible (even though my first language was Java...)
this is true for me ... though I'm still using Python for my next project
i think you must mean "false", then.
i think you must mean "false", then.
No, he said he's using python, so it's False
it's taken me a day to "get" that - i'd been thinking it was a confused comment rather than a (questionable quality!) joke... have a vote back to 1 since i suspect you've been downvoted by others as confused as me.
I think the point is anecdotal is not evidence and blog posts are all too often lacking in anything but.
Then again he's programming in a hot bed of programmers in that well known programming mecca of Hamilton, New Zealand. Oh, wait...
Then again he's programming in a hot bed of programmers in that well known programming mecca of Hamilton, New Zealand. Oh, wait...
The idea that people inevitably give up on their toolchain and move to another language en masse strikes me as a bit weird. I'm sure some people find itertools a good reason to learn other languages, but it's not some massive exodus. It's possible to use more than one language, you know. On the same project, even.
Python is currently in a perfect storm for experienced users to want to move away. If it was just itertools it wouldn't be the case.
Point the first: Python 2.x to Python 3.x if you already have to make a transition, there is more impetus to make a transition to something that suits how you actually work.
Point the second: itertools is partly a catalyst, partly an indicator. Once you get fluent with it, it illuminates pain points.
Point the third: There is a new batch of functional languages that support the style that is a pain point, as well as fixing other issues that hurt in python.
Lastly, not all python programmers will want to make the shift. But the ones fluent with itertools are more likely to be the subset that will.
Point the first: Python 2.x to Python 3.x if you already have to make a transition, there is more impetus to make a transition to something that suits how you actually work.
Point the second: itertools is partly a catalyst, partly an indicator. Once you get fluent with it, it illuminates pain points.
Point the third: There is a new batch of functional languages that support the style that is a pain point, as well as fixing other issues that hurt in python.
Lastly, not all python programmers will want to make the shift. But the ones fluent with itertools are more likely to be the subset that will.
I've been using Python for a while (since before 2.0). I think it's a good language, but nowadays my first choice for starting new projects in its niche would be a mix of Lua and C, unless the project depended entirely on a complex library available for Python but not C.
I did in fact switch during the 2.x->3.x transition, though I haven't given up on Python entirely - I still know the language, I'm fine with working in it, It's just not my first choice anymore. If there were one factor (and there isn't, my switch to Lua was gradual* ), it would be GvR's insistence that Python will never get tail-call optimization, because it's "unpythonic". (http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...) That has major implications for the expressiveness of the language.
* I think what happened was that I had been reading Lua's source to see how a small, clean implementation of a bytecode compiler worked, and along the way discovered that it suited my preferred development style better. Lua feels like a minimalistic hybrid of Python and Scheme, with the "good parts" of Javascript (prototypes, object literal notation) harmoniously integrated, but designed with embedded and multi-language development in mind. Also, the whole language can be installed with a DLL smaller than SQLite (!), which makes deployment rather easy.
I did in fact switch during the 2.x->3.x transition, though I haven't given up on Python entirely - I still know the language, I'm fine with working in it, It's just not my first choice anymore. If there were one factor (and there isn't, my switch to Lua was gradual* ), it would be GvR's insistence that Python will never get tail-call optimization, because it's "unpythonic". (http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...) That has major implications for the expressiveness of the language.
* I think what happened was that I had been reading Lua's source to see how a small, clean implementation of a bytecode compiler worked, and along the way discovered that it suited my preferred development style better. Lua feels like a minimalistic hybrid of Python and Scheme, with the "good parts" of Javascript (prototypes, object literal notation) harmoniously integrated, but designed with embedded and multi-language development in mind. Also, the whole language can be installed with a DLL smaller than SQLite (!), which makes deployment rather easy.
From the "data is not the plural of anecdote department", I can say that personally, the more I use languages from the Lisp and ML families, the less desire I have to use Python, despite having spent a fair amount of time tinkering with it in the past. Alas, I currently use none of these at my day job, but any hobby projects I start in the future are very unlikely to be in Python.
I am in EXACTLY the same position, though I will be leaving my day job in about a month to work on personal projects/contract work/startup ideas and I will be using a lot of Clojure for these projects. My main startup project is being constructed from a little C++ :-(, a lot of Clojure and some Yeti (ML derived JVM language).
I posted it because it's largely true of me. I'm still using Python (with Django) for my day-job, because I know the libs and the tools and the pitfalls, but almost all the code I've written for myself in the last year has been Clojure. I toyed with Haskell a little, but the type system killed me, and Scala wasn't quite functional enough (in the FP sense) for my tastes.
Just a data point, but I am in this position, for the reason listed in the blog post.
When I say in this position, I mean that I would like to switch but won't in the next future (too costly).
When I say in this position, I mean that I would like to switch but won't in the next future (too costly).
I've had the opposite experience with C#. MS' adding of lambdas and deferred list operations in 3.5 has delayed my switching to F# for all of my heavy number crunching work (For those who have yet to try ruby, python, scala, c# et al-- being able to switch between imperative and functional style on a per task basis is a wonderful way to work).
In the real world, suffering a few weeks of diminished output due to learning new syntax, idioms and best practices is not always (dare I say, rarely) feasible so making an existing language more powerful through the addition of functional constructs can only extend their productive life.
In the real world, suffering a few weeks of diminished output due to learning new syntax, idioms and best practices is not always (dare I say, rarely) feasible so making an existing language more powerful through the addition of functional constructs can only extend their productive life.
As a programmer who has used variants of SML (F# is Microsofts variant), Haskell, and Python, I would say that in terms of concise expressiveness, you have a point that the functional languages match Python's. However, the true power of programming in Python is that the programming logic is easy to understand. If you are actually experienced in functional programming, you'll realize that it is, in all definitions, code. Python is more like english and thus, the appeal will always be there.
If you are actually experienced in functional programming, you'll realize that it is, in all definitions, code. Python is more like english and thus, the appeal will always be there.
I disagree. Functional programming is about as far away from the machine as you get. When I write functional code, I feel like I am describing the problem I want to solve in great detail, just as I would if I were writing about it. (And despite being "far away from the machine", the code still runs quickly. There is something to be said for describing a solution to your problem instead of telling the CPU which bits of main memory to flip.)
As you go down the spectrum from FP to OOP, your code becomes more code-like. Create object. Call method. Save return value. Pass value to another object. Get result. This is still pretty abstract, though, and a fine way to code.
Then you get to procedural programming (C), and then your code truly is code. Allocate memory. Move bits from register to memory. Set interrupt. It's hard to even see an algorithm in there, there's just so much code.
In functional programming, things are often so abstract that you define functions in terms of other functions without even mentioning the data you are processing. Let's face it; that's not "code".
I disagree. Functional programming is about as far away from the machine as you get. When I write functional code, I feel like I am describing the problem I want to solve in great detail, just as I would if I were writing about it. (And despite being "far away from the machine", the code still runs quickly. There is something to be said for describing a solution to your problem instead of telling the CPU which bits of main memory to flip.)
As you go down the spectrum from FP to OOP, your code becomes more code-like. Create object. Call method. Save return value. Pass value to another object. Get result. This is still pretty abstract, though, and a fine way to code.
Then you get to procedural programming (C), and then your code truly is code. Allocate memory. Move bits from register to memory. Set interrupt. It's hard to even see an algorithm in there, there's just so much code.
In functional programming, things are often so abstract that you define functions in terms of other functions without even mentioning the data you are processing. Let's face it; that's not "code".
"Functional programming is like describing your problem to a mathematician. Imperative programming is like giving instructions to an idiot." -- arcus, #scheme on Freenode
(from the Scheme quotes file at http://community.schemewiki.org/?scheme-fortune-cookies)
(from the Scheme quotes file at http://community.schemewiki.org/?scheme-fortune-cookies)
"Python is more like english"
Having written non-trivial programs in Haskell, ML, and Python, I agree with this, but I would add: Functional programming is more like mathematics.
English expresses some ideas more clearly, while mathematics is better for others. And notations that are more "mathematical" often have other nice properties like composability and equational reasoning.*
*The best example of what I mean by equational reasoning is the Sudoku functional pearl: http://www.cs.tufts.edu/~nr/comp150fp/archive/richard-bird/s...
Having written non-trivial programs in Haskell, ML, and Python, I agree with this, but I would add: Functional programming is more like mathematics.
English expresses some ideas more clearly, while mathematics is better for others. And notations that are more "mathematical" often have other nice properties like composability and equational reasoning.*
*The best example of what I mean by equational reasoning is the Sudoku functional pearl: http://www.cs.tufts.edu/~nr/comp150fp/archive/richard-bird/s...
The paper you posted is a good example. The conclusion is:
And, this is not just something that's useful for esoteric mathematics papers; my "enterprise" code in Haskell looks very similar.
sudoku = map (map head) . search . prune . choice
And, this is not just something that's useful for esoteric mathematics papers; my "enterprise" code in Haskell looks very similar.
[deleted]
"Functional Programming is more like mathematics." I would completely agree. In fact, I would add to that and say FP is mathematics because its "Functionally" based and was originally created for easy inductive proofs.
However, from a readability standpoint, english is better than mathematics, and readability counts for quite a bit if you aren't planning on throwing away your code.
However, from a readability standpoint, english is better than mathematics, and readability counts for quite a bit if you aren't planning on throwing away your code.
"However, from a readability standpoint, english is better than mathematics"
That depends on what you are reading. Try reading differential calculus in English, without using notation.
Not to take anything away from your point (and I think it is a good one), but there are all kinds of code. Functional Programs can be astonishingly elegant.
That depends on what you are reading. Try reading differential calculus in English, without using notation.
Not to take anything away from your point (and I think it is a good one), but there are all kinds of code. Functional Programs can be astonishingly elegant.
I guess I should be more specific. When I say code, I mean "cryptic and unintuitive." Yes, you may say FP is intuitive if you've used it for awhile, but at a glance, Python is much friendlier than ML.
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.
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.
[edit: toned it down a little.]
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.
[edit: toned it down a little.]
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.
[in no way toned down]
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.
[in no way toned down]
"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 ;-)
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.
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.
"I think he meant software."
Ok.
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.
Ok.
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.
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.
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.
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.
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.
robot -grandpa's hammer. What a flawed analogy.
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.
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.
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.
Microsoft Excel is arguably the worlds most successful functional programming language.
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).
Except that XPath, CSS, and Regex express the essence of well designed functional programs.
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.
The only reason I'm starting to leave Python is because of performance. When you see a program that used to take 2 hours to run in python now taking 10 minutes in Java, it kind of makes you realize you've been making a mistake by using it places it doesn't belong.
Did you try cython/numpy/fileinput ?
just curious. Our team met perf problem in the past and each time, a rewritten code or even a rewritten module was all it took to get back on track.
just curious. Our team met perf problem in the past and each time, a rewritten code or even a rewritten module was all it took to get back on track.
There's always Jython for occasions like this one...
Jython is closer to Python's speed than Java's.
Or if you mean Jython with the speed-critical bits written in Java...well, there's always C for that.
Or if you mean Jython with the speed-critical bits written in Java...well, there's always C for that.
[deleted]
Try:
Weave Cython SIP
Python is really easy to tie into other languages for the slow parts.
Weave Cython SIP
Python is really easy to tie into other languages for the slow parts.
Python holds a strategic middle ground. It's far more productive, expressive and concise than the traditional procedural and OO languages. Although not as expressive and elegant as the new FP languages like Clojure and F#, the latter lack massive libraries and modules that have been written for Python. That makes them useless for any 'real' work.
Python is seeing some heavy use by the scientific community due to tools like NumPy, matplotlib, libsvm and what not. Good luck finding that range of independent libraries for a new FP language. I am not dropping Python in the near future, but I am watching.
Python is seeing some heavy use by the scientific community due to tools like NumPy, matplotlib, libsvm and what not. Good luck finding that range of independent libraries for a new FP language. I am not dropping Python in the near future, but I am watching.
Clojure can use (with very little mismatch) any available Java/JVM libraries.
F# can use anything available for the CLR/.NET.
Libraries are not really an issue.
F# can use anything available for the CLR/.NET.
Libraries are not really an issue.
I am a Python programmer. I have toyed with functional languages (Scheme, SML) for many years. Over the time my code is becoming more and more functional, in every language I code in. Nevertheless, I do not plan to quit Python at all. Readability counts in my book and I do not see Clojure to be more readable than Python. Moreover, I am not considering F# since it is platform specific and I do not develop on Windows. In my experience Python is not losing programmers; perhaps 0.1% of them are moving to functional languages, but more are coming from C++, Java and even Ruby.
I am an active contributor to www.RosettaCode.org where I browse many languages. What I have seen of the functional languages doesn't make me want to switch.
Despite knowing Pythons functional tools, it wasn't Python that introduced me to that style. I find Pythons mix comfortable and happily switch between programming in Python 3 and Python 2. Maybe the OP hopes to start a trend?
- Paddy.
Despite knowing Pythons functional tools, it wasn't Python that introduced me to that style. I find Pythons mix comfortable and happily switch between programming in Python 3 and Python 2. Maybe the OP hopes to start a trend?
- Paddy.
Judging from the comments, people leave Python to do toy projects in functional languages.
My guess is that after using functional languages in real projects, most of them will go back to Python.
My guess is that after using functional languages in real projects, most of them will go back to Python.
Well, on blogs Haskell, F# and clojure are popular, but in the words of past decades:
Show us the code.
Show us the code.
I've gotten paid to work on a lot more Haskell than Ruby or Python. The languages you see depends on the languages you want to see.
Haskell is really quite adequate for real work these days. It has the libraries you'd expect, and it's a nice language with a nice runtime.
It's also worth noting that blog-popular languages are blog-popular for a reason. The people that blog about programming are the ones that need tools that give them a bit more productivity between the occasional nap or meal; the people that use the more esoteric languages want to solve so many programming problems that a sharper tool is essential to their survival. (There is only finite time, after all, and programming languages are easier to build than time machines.)
In contrast, the "popular" languages are mostly used by people whose goal is to warm their chair for 8 hours and receive a paycheck. There are a lot more people that want money than that want creative time with a cold, unloving machine, so it follows that the languages where you can get paid and not care are going to be most popular.
But if you are the second type of person, there is little advantage in worrying about what is "popular" in "the real world". You don't want to be in the real world.
Haskell is really quite adequate for real work these days. It has the libraries you'd expect, and it's a nice language with a nice runtime.
It's also worth noting that blog-popular languages are blog-popular for a reason. The people that blog about programming are the ones that need tools that give them a bit more productivity between the occasional nap or meal; the people that use the more esoteric languages want to solve so many programming problems that a sharper tool is essential to their survival. (There is only finite time, after all, and programming languages are easier to build than time machines.)
In contrast, the "popular" languages are mostly used by people whose goal is to warm their chair for 8 hours and receive a paycheck. There are a lot more people that want money than that want creative time with a cold, unloving machine, so it follows that the languages where you can get paid and not care are going to be most popular.
But if you are the second type of person, there is little advantage in worrying about what is "popular" in "the real world". You don't want to be in the real world.
Python, popular!!! that is just so great! I've watched it grow for over a decade and a half. Python got were it is, largely without the big initial push of large companies.
Maybe people now blog about python because the community has always tried to be friendly. It is usually nice to blog about Python, and have fellow enthusiasts give measured, polite feedback.
"... so it follows that the languages where you can get paid and not care are going to be most popular."
But it does not follow that there are less caring, articulate, and productive souls in a more popular languages camp.
- Paddy.
Maybe people now blog about python because the community has always tried to be friendly. It is usually nice to blog about Python, and have fellow enthusiasts give measured, polite feedback.
"... so it follows that the languages where you can get paid and not care are going to be most popular."
But it does not follow that there are less caring, articulate, and productive souls in a more popular languages camp.
- Paddy.
Before you get too upset, the "popular" languages I'm thinking of are C# and Java. Python is in the "smart people" category :P
F# and Clojure are rather new and Haskell is only now maybe coming out of it's "Avoid success at all costs" phase (or so I judge by the Coders at Work interview of Simon Peyton-Jones).
Is this like the exodus of the Ruby programmers? Remember Ruby was on rage couple years ago? But suddenly became out of favorite due to various issues. Looks like Python is the same way. People play around with it and find out all kinds of issues. When a new language appears (Clojure), people leave in doves. Just another fad.
I've been using python for about 8 years before feeling like i wanted to move. I think that puts me well outside the fad window.
False: "There is an observable trend in Python programmers that results in a reasonable section of them moving to functional programming languages."
True: There is an observable trend that more and more people are using Python, and there is a smaller set of people that is not a subset of Python in any way that is toying with functional programming, usually for academic or masturbatory purposes.
True: There is an observable trend that more and more people are using Python, and there is a smaller set of people that is not a subset of Python in any way that is toying with functional programming, usually for academic or masturbatory purposes.