Live data from Hacker News

Why isn't Haskell popular in industry?

palgorithm.co.uk

41–50 of 145 posts

Re: Why isn't Haskell popular in industry?

#41
post #35

I think there are a couple reason. Haskell is a significant departure from most other languages commonly used by industrial programmers. It's a relatively shallow learning curve from Java to Python to JavaScript, but making the leap to a pure functional language is very difficult. Path-dependence plays a huge part here. This isn't just a matter of "people being afraid of what's different" as the article suggests; the…

achieving anything practical using purely functional code remains extremely difficult ... Excel is pretty much a functional language (though it is a little disabled), and people do amazing things in it. The problem isn't that functional languages are hard. They are a bit different, but good code is often fairly functional anyway. The problem is that most of the community seems to be obsessed with showing that functio…

Perhaps the reason that Haskellers don't describe monads as "just sections of the program that are imperative" is because that statement is _not_ true.

A monad is a very nice container abstraction - period.

The IO part of Haskell just happens to leverage monads. One of the benefits of which is an explicit marking of impure methods in the type signature, but there are others.

Monads are used in plenty of purely functional parts of Haskell.

Disclosure: been programming Haskell for only a few months now, so someone pull me up if I'm wrong. However, I have used a lot of monads so far (and they're not hard, its just a higher, more convenient level of abstraction).

edit: to address your post further. I honestly don't think that the community is the reason that Haskell isn't taking off. If you were to gather stats on the points at which would-be Haskellers give up, I think most people would leave 1) when they can't grok the syntax easily or 2) when they can't get tools or libraries going easily (it was a problem for me) and long before they get to the point of visiting the news groups and start running up against academic-type people.

Re: Why isn't Haskell popular in industry?

#42
Not to answer the question, but I can provide some reasons why I am not going to learn Haskell. I must say up front that I know next to nothing about the language, and my reason my sound very irrational, superficial and plain silly, however: it just looks ugly. That's it. I cannot imagine myself sitting all day and staring (or writing) something that looks like explosion on a regexp factory with ruins of Perl fallen through. True, the beauty is in the eye of the beholder, however even if I believe there are beautiful thing which may need considerable effort and understanding to appreciate the true elegance of it I cannot imagine such thing being ugly at the first sight. For me it just looks like a lot of effort went just to make it look different. Maybe it makes perfect sense once you learn it, but it just does not look elegant and thus kills all the motivation to try. This all of course is IMVHO.

Re: Why isn't Haskell popular in industry?

#43
post #28

Because it doesn't run on the JVM. For a variety of reasons — including critical third-party libraries — anything that doesn't run on the JVM and interoperate with legacy Java code is just a non starter for my company. I suspect many other organizations are in a similar situation. It looks like someone is working on a JVM port now so hopefully we'll see something usable in a few years.

Just to be sure: do (or would) your company use Clojure?

Re: Why isn't Haskell popular in industry?

#44

Not to answer the question, but I can provide some reasons why I am not going to learn Haskell. I must say up front that I know next to nothing about the language, and my reason my sound very irrational, superficial and plain silly, however: it just looks ugly. That's it. I cannot imagine myself sitting all day and staring (or writing) something that looks like explosion on a regexp factory with ruins of Perl fallen…

Really? How beautiful it is is exactly what keeps drawing me to Haskell even though I have more invested in the dynamic language camp.

>max = head . sort

Due to the laziness, the above will find the max entry in O(n) time, just like your hand written loop would. How can you not find that beautiful?

Now I do agree that they often seem to use too many symbols that look like other symbols but the few times I've investigated it actually ended up making sense (e.g. Arrows).

Re: Why isn't Haskell popular in industry?

#45

Earlier quoted context omitted.

You're not. I want to add that he was just the first guy that popped into my head when I thought C. I questioned it at first too, but the more I thought about it, Linux itself could have just as well have been written in Pascal or Lisp. If it had been, perhaps a lot of the tools, drivers, etc that interact with Linux would've been written in that language as well? Perhaps a better example is needed.

Let's not fixate on the examples, folks. Perhaps they're arguable, but the original point is still valid: languages gain traction through prominent projects.

Yeah, let's take a position in a discussion, defend it by examples (a questionable tactic, but let's roll with it for now), and then when someone picks apart the examples say 'let's not fixate on the examples, folks'?

(not attacking the OP, I'm not convinced yet one way or the other on the topic, just saying that when someone is called on his arguments and methodology the refutation in an intellectually honest discussion shouldn't be vigorous hand waiving).

Re: Why isn't Haskell popular in industry?

#46
post #35

I think there are a couple reason. Haskell is a significant departure from most other languages commonly used by industrial programmers. It's a relatively shallow learning curve from Java to Python to JavaScript, but making the leap to a pure functional language is very difficult. Path-dependence plays a huge part here. This isn't just a matter of "people being afraid of what's different" as the article suggests; the…

achieving anything practical using purely functional code remains extremely difficult ... Excel is pretty much a functional language (though it is a little disabled), and people do amazing things in it. The problem isn't that functional languages are hard. They are a bit different, but good code is often fairly functional anyway. The problem is that most of the community seems to be obsessed with showing that functio…

Take monads. The only way to "get" monads is to realize that they are just sections of the program that are imperative.

Not really. Monadic function composition is just like regular composition, except that the programmer is given the ability to make "f of g of x" do something more than just pipe the result of g(x) into f. This can look like imperative programming, but it's still purely functional.

If you're willing to call monads Kleisli arrows instead, then you can even the same syntax to chain monadic computations as "regular" computations.

For example, write a function to add one to a number, then multiply by 4:

   f :: Num a => a -> a
   f = (*4) . (+1)
That's a normal function, with the normal function composition operator.

Now write a function to increment the state, in a stateful computation, by a number:

   inc :: Int -> State Int ()
   inc x = put . (arr (+x)) . get
Even though State is a monad or Kleisli arrow, you can treat the stateful computation as regular function composition, because it is just composition. There is no imperative programming anywhere to be seen. Although operating on some hidden state feels imperative, it's not. (Under the covers, it is a bit different than what you might be used to. Each stateful function is really a function from its arguments to another function from the current state to the result. We compose the "result" functions into one big function from state to result. This involves a bit of plumbing, but the actual implementation is only two lines of code. And it makes for a very useful abstraction in many cases. But I digress...)

Monads are just a way to make similar things, chaining computations with an arbitrary combinator, look similar in your code. We did it with State above, and there are lots of other things that work similarly. Computations that can return zero or more results, computations that can fail, computations that operate on transactional memory, etc. We use "Monad" (or "Arrow") to provide the programmer with a common syntax for interacting with each. That's all a monad is.

(IO is weird, and it is a monad, but it could also be an applicative functor, or comonad, or arrow, or a lazy list, or. Don't extrapolate your knowledge or fear of the IO monad onto monads in general.)

Re: Why isn't Haskell popular in industry?

#47
Haskell is not popular because to be popular you must cater to the average Joe. And to cater to average Joe your foremost goal must be not making him uncomfortable about himself. Never forget this.

And since most average Joes just work to pay their bills, they don't give a damn about technical superiority, you know.

Re: Why isn't Haskell popular in industry?

#48
post #24

I outlined some of the problems a while ago: http://www.codexon.com/posts/why-arent-functional-languages-... Short version: Haskell is harder than C while being slower and uses more memory. The main implementation GHC, comes with GPL concerns.

Interestingly, I came to the exact opposite conclusion. Haskell is easier than C++ (less code and more safety), and it is equally fast.

Haskell may not be the perfect language for your generic FFT library to be distributed with your OS, but it's a great choice for building applications that would otherwise be C++ or Java. Java and C++ had no trouble catching on, despite being slower than C, and Haskell isn't even that much slower than C.

Re: Why isn't Haskell popular in industry?

#49

Not to answer the question, but I can provide some reasons why I am not going to learn Haskell. I must say up front that I know next to nothing about the language, and my reason my sound very irrational, superficial and plain silly, however: it just looks ugly. That's it. I cannot imagine myself sitting all day and staring (or writing) something that looks like explosion on a regexp factory with ruins of Perl fallen…

"True, the beauty is in the eye of the beholder, however even if I believe there are beautiful thing which may need considerable effort and understanding to appreciate the true elegance of it I cannot imagine such thing being ugly at the first sight."

It's always the same reason why people dislike new languages. People don't realize, that they can't look open-minded at a new language, if they already know a language. Because they will always compare the new to the already known language.

Most people are only open-minded if they learn their first language, after that, everything else is just ugly compared to the first one.

You just can't decide if something is ugly, until you have learned it, understood the meaning of the syntax, how all the single parts of a language fit together.

Haskell is nothing like Perl. It's one of the most beautiful and well-thought-out language I saw until now. Absolutely nothing compared to the auto magic of Perl.

Re: Why isn't Haskell popular in industry?

#50
post #35

Earlier quoted context omitted.

achieving anything practical using purely functional code remains extremely difficult ... Excel is pretty much a functional language (though it is a little disabled), and people do amazing things in it. The problem isn't that functional languages are hard. They are a bit different, but good code is often fairly functional anyway. The problem is that most of the community seems to be obsessed with showing that functio…

Take monads. The only way to "get" monads is to realize that they are just sections of the program that are imperative. Not really. Monadic function composition is just like regular composition, except that the programmer is given the ability to make "f of g of x" do something more than just pipe the result of g(x) into f. This can look like imperative programming, but it's still purely functional. If you're willing…

I have no idea what a Kleisli arrow is, and a simple Google search points me right back in the direction of the HaskellWiki. They may be a perfectly simple concept, but if they are, then the term is not in widespread use. One of the major problems with explaining monads is that programmers who understand them frequently attempt to explain them by using terms even less well-understood than "monad". You get points for precision, but none for evangelism.

It is of no help or use to those who do not understand monads that they could also be an applicative functor, or comonad, or whatever. You may be perfectly correct, but for someone who is not already part of your community, and conversant in its terms, it does not particularly help.

Post reply on HN