Live data from Hacker News

Why isn't Haskell popular in industry?

palgorithm.co.uk

111–120 of 145 posts

Re: Why isn't Haskell popular in industry?

#111
post #106
post #85

Earlier quoted context omitted.

You made a point. I've been rumbling on this lately, and I'm sharing my current conclusion here to hear HNers' opinions. Let's consider Common Lisp. Newcomers and outsiders complain that CL doesn't catch up because there aren't free CL environments around with a thoughtless setup (I've been in this camp too). However, if you read comp.lang.lisp, it jumps into your eyes that many lispers are accomplished and sharp pro…

That is, if you can't setup a CL system, you simply are not skilled enough as a programmer But these things are unrelated! Your ability as a Lisp programmer is entirely unrelated to your ability as a Windows/Linux/whatever sysadmin/build engineer/whatever. If anything it's the old "it works on my computer" excuse that (bad) tech support trots out. That's the thing that sets the Clojure guys apart, they actually are i…

> Your ability as a Lisp programmer is entirely unrelated to your ability as a Windows/Linux/whatever sysadmin/build engineer/whatever.

Are we sure? Isn't this a case of Law of Leaky Abstractions? We may think we can and should ignore issues related to underlying hardware, but reality is we can't and we shouldn't. As programmers we need a bit of knowledge about system administration too, even when we are working on a virtual machine.

Kudos to Clojurers! Maybe there is more enthusiasm and understanding about newcomers in Clojure because it is a new language. That is, the are not under the Curse of Knowledge.

We should acknowledge that Haskellers are trying to meet the needs of newcomers too, by releasing the Haskell Platform.

Re: Why isn't Haskell popular in industry?

#112
post #37

Earlier quoted context omitted.

Except that it's not necessary, because at least 3 solutions that don't use unsafePerformIO were posted to that Reddit thread.

But "not necessary" has never been the problem here. People are complaining because the idiomatic way to explore a directory structure in Haskell isn't familiar to them —it's functional and mathy and strange (because exploring a directory structure in a pure-functional way is mathy and strange.) They want the language to be "as easy to use" as, say, Python, for directory-diving—but that basically means that they want…

I think you've just nailed it down: Haskell is for mathematicians, or those mathematically oriented.

Most programmers are not mathematicians (especially self-taught ones) since at the end of the day common programming tasks don't require you to know advanced math (I'm not implying knowledge wouldn't be very beneficial).

Re: Why isn't Haskell popular in industry?

#113
post #57

Earlier quoted context omitted.

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 functi…

Can you give an example of where monads are not used to interact with stateful things? That would be helpful to me.

Here's a common example of a monad being used in a non-stateful way:

  map (* 2) [1,2,3,4]
Yep, that's a function on a monad — lists are monads. The same function can be written:

  [1,2,3,4] >>= return . (* 2)

Re: Why isn't Haskell popular in industry?

#114
post #8

Earlier quoted context omitted.

This reddit post tells me why Haskell isn't that popular. http://www.reddit.com/r/haskell/comments/cs54i/how_would_you... Writing a quick directory traversal function should be a no-brainer in any reasonably general-purpose language. The fact that the above reddit thread is jam-packed with the ins-and-outs of doing this simple task in Haskell tells me that Haskell may be great for some things, but it's probably not g…

To illustrate this point, a choice snippet from that Reddit thread, explaining part of what seems to be considered 'the proper solution'. Please note that my intention is not to make fun of this, but to illustrate that the terminology in which people in the Haskell community communicate makes it impenetrable for someone just trying to pick up the language and do stuff with it. it's a straightforward lifting of the no…

Well, sure. Haskell uses mathematical terminology sometimes.

Other languages use weird terminology, too: "public static void main"? How about "pure virtual destructor"? "Visitor"?

Re: Why isn't Haskell popular in industry?

#115
post #85
post #76

Earlier quoted context omitted.

I'll have to correct you a bit. Judging by the article, Haskell currently isn't usable for work. So why should average Joe choose half-finished product? So why even the brightest hacker choose it when he already has all the tools he need?

You made a point. I've been rumbling on this lately, and I'm sharing my current conclusion here to hear HNers' opinions. Let's consider Common Lisp. Newcomers and outsiders complain that CL doesn't catch up because there aren't free CL environments around with a thoughtless setup (I've been in this camp too). However, if you read comp.lang.lisp, it jumps into your eyes that many lispers are accomplished and sharp pro…

That is, if you can't setup a CL system, you simply are not skilled enough as a programmer. Get over it.

"Can't" is not at issue here - with enough effort, anyone can do just about anything. The question is whether it's actually worth the effort.

Given a choice between languages A and B, both of which have very enthusiastic userbases that are utterly convinced that their language is the One True Programming Language, but neither of which I've actually spent enough time with to know whether it will be worth the investment, which one will I spend the time to learn to work with?

A smart programmer will pick whichever one gets up and running the quickest so that he can actually see what coding is like in that language, as opposed to configuring/installing/compiling sources/tracking down a supported version/etc. Why waste time doing all that stuff when if you just hop to the next language over you can have it all for free? Not to mention that problems setting up a dev environment are loosely predictive of future problems dealing with deployment, hiring extra hands, getting support when things go wrong, etc...

Common Lisp is getting its clock cleaned by Clojure because the Clojure folks know that lowering barriers to adoption is a critically important thing when people are faced with such a glut of choice.

But then again, I've never gotten the sense that the CL folks actually want more people using it, that community seems to be more than happy to remain an elite insider's-only club that is - obviously - smarter than everyone else. Which explains a lot of the hate for Clojure - it's bringing powerful tools to the unwashed masses, and it turns out they wield them quite effectively, shedding some serious doubt on the implicit assertion that you have to be really, really smart to use any sort of Lisp.

Re: Why isn't Haskell popular in industry?

#116

Earlier quoted context omitted.

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…

A Kleisli arrow is just an arrow that works like a monad: -- | Kleisli arrows of a monad. newtype Kleisli m a b = Kleisli { runKleisli :: a -> m b } instance Monad m => Category (Kleisli m) where id = Kleisli return (Kleisli f) . (Kleisli g) = Kleisli (\b -> g b >>= f) I only brought it up to show that we can use the same operator, Control.Category.., to compose functions, monads, and arrows and that they are not all…

I don't disagree that every technical community has its own terms. But it's very difficult to broaden that community by restricting yourself narrowly to those terms. To me, "an arrow that works like a monad" reads like a recursive definition: if you don't understand how one works, you can't understand the other.

The net effect is that your community is going to be composed of people who made a conscious effort to break through the communication barrier. This isn't necessarily a bad thing; you end up with a small, focused group of very smart people. But it doesn't buy you many converts in the industry.

Re: Why isn't Haskell popular in industry?

#117

Earlier quoted context omitted.

Way to make his point. Only programming language where Arrows ever come up, Haskell. Wiki page on Arrows "Generalized Monads". So far our definition of a Monad is a specialized version of the generalization of Monads.

Problem is, when you use a programming language without arrows, you end up rewriting generic plumbing every time. If you want to write more code in your app to avoid using the word "monad", that's fine, but probably not rational.

This has nothing to do with the use of monads, but how they are explained. When your explain monads to people who don't no what monads are speach starts with "It is an arrow..." You are explaining monads to yourself, not to someone who doesn't understand monads (and consequently doesn't have a clue what arrows are.)

So far as I can tell monads are abstraction of state(though calling them abstractions of function application is more correct, calling it state is more intuitive to me, and how they are represented in the type system.) From there they get used for different things: Maybe == Nullable Types, List == lists, Either == Unions, St == Mutable State, IO == hide IO. Then a function that is pure and doesn't know about what your monad does gets invoked by the monad where the hidden state changes the flow of computation. Maybe performs a null check, List calls map, Either picks the type in the union then calls the function on that, St allows you to use and update the hidden state, IO performs IO then shares the result with you.

Now there is an explanation of a monad that doesn't assume you already know what a monad is. It may not be good since it basically says monads are sticky higher order functions masquerading as a data type, but there you have it.

Re: Why isn't Haskell popular in industry?

#118
post #97
post #85

Earlier quoted context omitted.

You made a point. I've been rumbling on this lately, and I'm sharing my current conclusion here to hear HNers' opinions. Let's consider Common Lisp. Newcomers and outsiders complain that CL doesn't catch up because there aren't free CL environments around with a thoughtless setup (I've been in this camp too). However, if you read comp.lang.lisp, it jumps into your eyes that many lispers are accomplished and sharp pro…

Yes and no. If you are experienced programmer, then you'll have no problems with "issues". On other hand, why should you waste your time with new language? Each year there is new programming language or framework that "will change the computing". Oh come on. We all know that Windows will become lousy implementation of Unix. We also know that all programming languages eventually will have half-assed implementations of…

It's clear to me that you haven't answered this question for yourself. Haskell has a lot of features that Lisp generally doesn't:

• A powerful type system with inference

• Purity

• Pattern matching baked into the language core

• Full laziness (such that "if" can be written as a pure function, no need for special forms or macro-like functionality)

• Curried functions and partial application (so, for example, Lisp's (defun double (n) (* n 2)) would be double = (* 2) in Haskell)

Re: Why isn't Haskell popular in industry?

#119

Earlier quoted context omitted.

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…

> 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…

Function composition is obscure? Did you take Algebra 1?

(I used the term "Kleisli arrow" so that you could Google for something if you wanted to learn more. All you really need to know is that you can use . to pass the output of a regular function into the input of another one, and you can use . to pass the output of a monad into the input of another. Saying it that way is very imprecise, though, and the goal of people explaining things is to say them precisely so that you have some hope of eventually gaining an understanding.

You have to bootstrap understanding. Assume you know what a Kleisli arrow is. Then read the rest of the post. Now your assumption is correct!)

Re: Why isn't Haskell popular in industry?

#120

Earlier quoted context omitted.

Problem is, when you use a programming language without arrows, you end up rewriting generic plumbing every time. If you want to write more code in your app to avoid using the word "monad", that's fine, but probably not rational.

This has nothing to do with the use of monads, but how they are explained. When your explain monads to people who don't no what monads are speach starts with "It is an arrow..." You are explaining monads to yourself, not to someone who doesn't understand monads (and consequently doesn't have a clue what arrows are.) So far as I can tell monads are abstraction of state(though calling them abstractions of function appl…

Honestly, I'm tired of explaining monads in every HN article about Haskell. I've written detailed explanations for newbies 100s of times. If you want to learn more about something, Google it.

Remember, you understanding Haskell will improve your understanding of the Universe. You understanding Haskell will do nothing for me. So you can see how the incentives are aligned...

Post reply on HN