views:

783

answers:

6

Had learned Haskell during a Functional Programming course in school. Had found Haskell a bit difficult to work with. Have now worked a lot on Python. Python is quite easy to work with.

Python does support some functional programming constructs.

Was thinking of revisiting Functional Programming. What would be a better language to code? Haskell or Python? Why?

+30  A: 

Ahem, Haskel is a functional programming language, whereas Pytthon just has some features of functional programming languages. So, this is settled. Q.e.d.

Edit: What is lacking in Python, just to give one example, is the optimization of recursive function calls. This is vital in most real functional programming languages.

Googling, by the way, just produced this nice article.

Boldewyn
+3  A: 

From the Haskell homepage:

Haskell is an advanced purely functional programming language. An open source product of more than twenty years of cutting edge research, it allows rapid development of robust, concise, correct software.

Sarcastic translation:

  • "advanced" = "Not for everyone"
  • "purely functional" = "Definitely not for everyone"
  • "more than twenty years" = "And still not everyone likes it!"
  • "cutting edge research" = "There is a chance that you may find a practical problem which you can solve with it but we're still working on it!"
  • "robust, concise, correct software" = "Are you missing simple, understandable, obvious, readable? Guess why!"

Jokes aside, functional languages aren't meant for the majority and never will be. There are people who can think like a stack but I, for one, prefer that the computer tries harder to understand my gibberish.

Aaron Digulla
+1 for understanding gibberish - The computer should be more like ME.
whatnick
What has a stack got to do with functional languages? Forth is the language if you are into stacks. If is the base for your opinion on functional languages then I am afraid you have a long, **long** way to go before you grok them. Sarcastic as well.
rvirding
What? Your claim is that functional programming is too close to the metal? In a world where C is the dominant language, no less? You have to be off your meds. Haskell is very high-level. What you actually mean here is, "It's not what I already know."
Chuck
@rvirding: The syntax of Haskell is more readable than Lisp but the same basic principle applies: Problems are expressed as recursive expressions so you must simulate some kind of stack in your brain to understand them.
Aaron Digulla
@Chuck: What are you talking about?
Aaron Digulla
@Aaron: You said you "prefer that the computer tries harder to understand your gibberish." Haskell makes the computer do a lot more thinking for you than most popular languages do. The idea that C "tries harder to understand your gibberish" is just weird. And I don't find that I need to simulate a stack in my brain to write recursive solutions. I'm about the stupidest programmer you'll ever find, and I can follow it. Even when explicit recursion is necessary (which is rarer than people make it sound), you often just need to write a transformation and the condition where it should terminate.
Chuck
A little more explanation: It's a lot easier to write subtle and annoying off-by-one bugs with iterative solutions (I saw a question here just yesterday that turned out to be an off-by-one — after a lot of debugging). The equivalent code in Haskell would be something like `map (* 2) list`. I don't have to mentally envision a stack and there's no room for bugs. I just tell it, "I want all this stuff doubled" and it does it for me.
Chuck
A number of the respondents on SO are actually advanced AIs (written in Haskell, no doubt) trying to pass themselves off as human. Fortunately they are still pretty easy to unmask as they completely fail the "humor" section of the Turing test.
Carl Smotricz
@Carl: It's the "Jokes aside…" part that rvirding and I disagree with. The humor at the beginning was actually pretty funny (except for the part where he doesn't seem to know that "concise" means "simple, understandable, obvious, readable").
Chuck
@rvirding: That's "stacks you into IF language FORTH is THEN" to you.
David Thornley
@Chuck I understand where you're coming from and agree that Aaron's assertion may sound a little trollish; but I agree with him in principle: Conceded that there is a good number of IT problems that fit FP like a glove (math with primes, Fibonaccis and factorials come to mind) and are very amenable to a declarative/decriptive style of representation; I'd say the vast majority of "programming" tasks map much more intuitively to imperative, state-mutating procedures. And I assert (without proof) that it's generally easier for people to learn imperative than FP.
Carl Smotricz
As for "simple, understandable, obvious, readable:" Ruby meets those criteria: I was able to read and understand complex functional Ruby code almost from day one (with no prior Ruby experience). Haskell does not: I've looked at Haskell code samples and found myself baffled. Could be my C/Java background, but would a background in, say Erlang/OCaml allow me to understand Haskell as easily?
Carl Smotricz
@Carl: I imagine Haskell would look pretty clear to you if you knew an ML-type language (OCaml, F#, Standard ML). It's about as similar to those languages as Ruby is to C-type languages like C and Java, I think. When I first saw OCaml, I thought it was absolute gibberish too. It took learning Ruby and being fascinated by the FP-ish features (lambdas, maps, folds, etc.) to give me the motivation to try again. After learning one, the others were much more clear.
Chuck
-1: Failed humour. This kind of joke requires some understanding of what is mocked.
Charles Stewart
+1  A: 

What Boldewyn said. Haskell is one of the most "hardcore" functional languages there is, insofar as there simply isn't any way to maintain mutable state.

That said, Haskell is (unsurprisingly) wildly different from all the imperative and mixed-model languages most people come in contact with, so there would be a learning curve involved in picking it up if one came from a background of, say, VB or C(++) or Java.

Python, on the other hand, features a "Functional Show and Tell" section where a handful of functional features can be test driven within an otherwise predominantly imperative environment.

Thus, if in his original question, the OP's "better" meant "more functional" or "a better citizen of functional-land" (as he has since made clearer), then Haskell "wins" hands down.

Carl Smotricz
Haskell certainly provides mutable state, it just isn't the default. Consider both the mutable references (IORef/STRef) and mutable arrays (IOArray/STArray) in the base libraries.Just because it isn't the default, doesn't mean it doesn't exist.
Don Stewart
Of course, test-driving functional features in Python is a bit like test-driving a car by turning it on and leaving it in park. Guido himself is pretty critical of functional programming in Python. For starters, lambdas are definitely second-class citizens to real functions.
Chuck
+7  A: 

While Python does indeed support some functional constructs, Haskell is a functional language. What you also need to consider, is that Haskell is also purely functional and lazy, two concepts that may be the cause of the difficulty you find in Haskell. If this is the case, read on.

What you may want to consider, if, of course, you have the time, is learning another, less complex, functional language. I found that learning a less "aggressively functional" language before moving on to Haskell is a step worth taking. You may want to consider OCaml (Objective Caml), another functional programming language, that is not pure nor lazy. Thus, some imperative programming constructs will be available to you (references, loops, mutable arrays, etc), and you won't have to cope with the monads until you actually want to.

This entirely depends on the time you are willing to spend revisiting functional programming, and on your current background in this same paradigm.

CharlieP
Again, *Haskell does provide mutable arrays, references and loops*. They are just not the default: IORef/ IOArray/ Control.Monad.for etc.
Don Stewart
Agreed, but they are a rather obscure part of the language that is usually discouraged, or not even brought up, to new users.
CharlieP
@dons: It's not about what the language makes possible (beware the Turing tarpit), it's about what the language makes easy.
Chuck
+9  A: 

This question highlights one of my pet peeves about the common understanding of functional programming. Having language features like closures and first-class functions do not make a language a functional programming language. Functional programming is as much about a specific style of programming as it is about specific language constructs. Python has closures, first-class functions, and yes, even a function called "map", but the language itself encourages a procedural, OOP, imperative style of programming; so even if you make use of the functional features, you're still programming imperatively.

As a purely functional language, Haskell basically mandates that one program in a declarative, functional style, so hands-down, Haskell is "more functional" than Python.

mipadi
First-class function requires proper anonymous lambdas, and reasonably space-efficient tail calls, neither of which Python has. Otherwise I agree wholeheartedly. Cf. http://lambda-the-ultimate.org/node/3532#comment-50319
Charles Stewart
+12  A: 

You'll find many criticisms elsewhere about how Python programmers should not use functional features like lambda. Alex Martelli is particularly good at this. But if you approach functional programming as a Python programmer, you will not get much of a feel for why people are interested in functional programming in the first place. In particular, you will not have access to a powerful static type system and algebraic data types. These tools are definitely part of the Haskell mindset.

Functional programming is not so much a set of features a a way of thinking. To see that way of thinking in action and to start to learn it, check out the paper Why Functional Programming Matters by John Hughes. What you learn from Hughes you can easily apply in Haskell. In fact, Haskell is much more likely to force you to learn that new way of thinking. With Python you can use a few lambdas here and there and fool yourself that you're learning functional programming. You won't be.

That said, Haskell can be a lot to swallow all at once. If you're finding it difficult you might want to try Standard ML or DrScheme. Standard ML will introduce you to more new ideas, but those people don't have their act together to welcome newcomers in the way that the Schemers or the Haskell people do.

Norman Ramsey
Do you really think a powerful type system is the draw for functional programming? Looking at the TIOBE Index, Lisp and Erlang appear to be the most popular functional languages, and both of those are dynamic AFAIK.
Chuck
I think a powerful type system is *a* major draw. A powerful macro system is also a major draw, which I think explains some of the popularity of LISP. Erlang is popular not so much for its functional features but because of its reliability and scalable parallelism. Plus it doesn't hurt to have a major hardware manufacturer behind you. Ericsson is to telephony and Erlang as Sun is to computing and Java. Maybe more so.
Norman Ramsey
The simplicity of QuickCheck on Haskell (vs. Erlang) comes direct from its leveraging of Haskell's type system. So, yes, Haskell's type system is offputting to some (I think type classes are dirty, and lead to needlessly difficulty in typing programs), but it is powerful, and provides a foundation for much of what Haskell achieves.
Charles Stewart
The type systems in Haskell and ML are orthogonal to functional programming. The central concept is that programming is done with data structures that are immutable, but efficient for the creation of modified versions with shared structure, and then using pure, first-class functions to operate on that data. Clojure is a modern example of a functional language that doesn't put much emphasis on using types.
Zak
@Zak: The type systems certainly are not orthogonal. Read Phil Wadler's paper *Theorems for Free*. Phil's results are intimately connected to the type system and are possible only in a purely functional setting. As for relative importance, this is a topic about which reasonable people can and do disagree, but a large majority of functional programmers value types. Even Scheme is getting into the act: http://tinyurl.com/c6wgz6
Norman Ramsey
@Norman Ramsey: thanks for the reference to an interesting paper. I've found a non-paywalled version but haven't had the chance to read and digest it yet. Perhaps we're using the term differently. I'm taking orthogonal to mean that the features do not depend on each other, not that having both doesn't result in a whole greater than the sum of its parts.
Zak
@Zak: I think we're agreed on the meaning of orthogonal. But I'm saying that Haskell's type system is intimately tied to the purity of functions and would be much weaker (or perhaps not even make sense) in a language in which functions were first-class but impure.
Norman Ramsey