
Why Not Haskell? - yaaang
http://neugierig.org/software/blog/2011/10/why-not-haskell.html
======
joeyh
I've only written two notable haskell programs.

One (git-annex) is a large-ish, serious work, and I have been very pleased
with how haskell has made it better, even though there was a learning curve
(took me two weeks to write the first prototype, which I could have probably
dashed off in perl in two days), and even though I have occasionally been
blocked by the type system or something and had to do more work. One concrete
thing I've noticed is that this is the only program where I have listed every
single bug I fixed in the changelog -- because there have been so few, it's
really a notable change to fix one!

My other haskell program was essentially a one-off peice of code, which
converted ten years of usenet posts from the 80's into "modern" usenet posts.
At that point I was over the learning curve, so I wrote it as fast, or
possibly faster than I would have written the equivilant in perl, banging out
a 800 lines of code in 12 hours or so. And the code is clean, pure, and even
has reusable modules, which would never have happened with any other language
I've used. And it all worked the first time. Converting the entire known
corpus of A news articles to B news, and from there to C news, with success on
the first try is an amazing feeling.

I'm going to be sticking with haskell. I do worry that some of my haskell code
may need fiddling to keep working for 5 or 10 years though.

~~~
Adaptive
I was very excited when I first discovered git-annex. When I saw it was
written in haskell that sealed the deal for me. The haskell code I run is all
very robust and I was very happy you'd selected it for g-a. Have you posted
anything else about how specifically Haskell has made it better? I'd enjoy
reading more about that.

~~~
joeyh
I've been meaning to blog about that sometime soon. (Edit: I did write this
post earlier <http://kitenet.net/~joey/blog/entry/happy_haskell_hacker/>) Also
been meaning to do a screencast showing what I think of as type driven
refactoring, since while I've heard haskell programmers discuss it I've not
seen it actually demonstrated

~~~
ch0wn
I would love to watch that. Sounds really exciting.

------
PPGualtieri
Once you manged to grok the basic stuff about Typeclasses, Functors,
Applicative, Monads, Monad Transformers, different notions of recursion, a
minimal understanding of how lazyness can be quite tricky, the multitude of
different ways of how errors and exceptions are handled in various libraries,
and perhaps basic STM, Haskell has a tendency to become even more complex. If
you want to do efficient IO and prevent space leaks, you have to learn about
Iteratees, Enumerators and Enumeratees. If you wish to create GUIs in a
bearable manner, its imperative that you learn about FRP and Arrows
eventually. Then there's the innumerable amount of language extensions to
Haskell of the GHC flavor, each of which comes with only scarce documentation
and examples, but with a lot of theory (Fundeps, Type families, Existential
types, GADTs ...). But there's more: Comonads, Kleisli Arrows and probably
things I haven't even heard about. The whole point being: If you want to be
able to handle 'real world stuff' in Haskell, its not enough to stay 'mostly
pure' and use StateT, unfortunately. I like Haskell - I shudder when I think
of C, C++ and Java - but at this point in time I find it overwhelming.

~~~
joevandyk
Are most of those names for simple concepts / design patterns / types?

I'm finding more and more that the hardest part of haskell is understanding
the syntax and the terminology.

~~~
Uchikoma
A lot of stuff is quite easy, after reading <http://learnyouahaskell.com/> \-
but there is a tendency in the Haskell community, perhaps not in the core but
at the fringes to look more elite, and with a lot of hand waving to make
simple things (Monads come to mind) something complex sounding.

Take the IO Monad. Everyone who wrote some web/servlet code, that needs to
output stuff to the web over several classes (might not be the best design in
the beginning) uses a Writer (or other class) to aggregate output. He
therefore, as global vars are bad (and thread local are worse ;-) adds a
Writer to every method.

public T doSomeStuff(T input, Writer io)

This is nasty and ugly, and the IO monad is in essence just another way to
write this in a neat form, make it composable and control the IO environment.

public IO<T> doSomeStuff(IO<T> input)

But you would not get this insight from any of the monad tutorials written by
Haskell people (except the link above). Simple monad insight comes form other
people outside the Haskell community, e.g. James Iry

[http://james-iry.blogspot.com/2007/09/monads-are-
elephants-p...](http://james-iry.blogspot.com/2007/09/monads-are-elephants-
part-1.html)

------
nickknw
There was recently a survey on the State of Haskell in 2011 [1]. As many
people here seem to be echoing, OCaml was the main possible "replacement
language". Also included in the survey are ratings of various aspects of
Hackage and also Haskell libraries in general.

It was a really interesting read. I made a follow-up post [2] that analyzed
the free-form responses to the last question, "What do you think is Haskell's
most glaring weakness / blind spot / problem?".

Number one by far was libraries (spread across: quality + quantity, library
documentation, Hackage, cabal). There are a lot of people working on this
though, and progress is being made.

The runners up were 'Tools', and 'Barrier To Entry'.

I think Haskell, at the very least, is a fantastic way to learn some different
ways of thinking and good habits. The (little so far) coding in it I've done
has been very enjoyable for me, but I don't expect everyone to feel the same
way.

It has a very warm community, and a fair bit of momentum. As time goes on I
predict (and hope) it will become more viable for a greater number of people
to use.

[1] - [http://blog.johantibell.com/2011/08/results-from-state-of-
ha...](http://blog.johantibell.com/2011/08/results-from-state-of-
haskell-2011.html)

[2] - [http://nickknowlson.com/blog/2011/09/12/haskell-survey-
categ...](http://nickknowlson.com/blog/2011/09/12/haskell-survey-categorized-
weaknesses/)

------
bhurt
I wished I lived in the authors world. A world where you don't have to
maintain the code you wrote- or worse yet, someone else wrote. Where you could
declare a program "done" and walk away and never have to revisit it. A world
where "mostly works" is good enough- secure in the knowledge that you're not
going to be rousted out bed at 2 in the morning on a weekend because some
server in outer Mongolia hit that corner case you never thought to test. A
world where all programs are small enough to fit into my head, completely, in
all details. So I could simply know, if I change this, that will break.

That is not, unfortunately, the world I live in. If it is the world you live
in, more power to you. Count your blessing and live happily. But the rest of
us need all the help we can get.

~~~
devs1010
agreed, maybe I haven't expanded my mind enough but once I started using a
widely used language to program in (not saying which) where I can write
relatively easily, scalable maintainable code, find plenty of work and pay the
bills, my desire to experiment with other, more obscure languages has kind of
fallen off, there has to be a reason why some languages are widely used and
others aren't. No language is ever going to please everyone but thats how life
is, you can't always change the world to suit your preferences

------
jamii
Haskell is the first language I was ever fluent in. These days I mostly work
in python and erlang with a smattering of ocaml but learning haskell had a
huge influence on the way I think about software.

I find it hard to articulate the ideas that I came away with. Something like
'code should be built out of small, composable abstractions that obey simple
algebraic laws'. It's incredible how powerful this is in combination with pure
code (which enables easier composition and algebraic reasoning), typeclasses
(which make it easy to express the interface to an abstraction) and
quickcheck/smallcheck (which make it easy to express and test the laws which
the abstraction should obey).

Others have written about this more clearly than I ever could. In particular,
Conol Elliot's writing on denotational semantics [1] and Chris Okasaki's
Purely Functional Datastructures [2].

The haskell community tends to be dominated by academic research so it's easy
to dismiss the typical examples as impractical. Right now I'm trying to apply
the same ideas to Kademlia routing in erl-telehash [3]. Hopefully I will
eventually be able to demonstrate what I struggle to articulate.

[1] <http://conal.net/papers/type-class-morphisms/>

[2]
[http://books.google.com/books/about/Purely_functional_data_s...](http://books.google.com/books/about/Purely_functional_data_structures.html?id=SxPzSTcTalAC)

[3] <http://github.com/jamii/erl-telehash>

------
Shakakai
My company (ThoughtLeadr) is using Haskell to analyze big data (social
networks) to great effect. Although, I will admit finding great Haskell
programmers in the wild is rather challenging.

Network effect with programming languages is a difficult nut to crack. That's
the reason most new languages build on the syntax and features of existing
"successful" languages.

The toolchain aspect has been less of an issue for us since we're using it for
pure data analysis rather than shoehorning it into building webapps etc.

------
CoffeeDregs
I wrote a post that was picked up by HN a while ago about why I left Haskell,
so I won't rehash my arguments, but ...

On reflection, I love(d) Haskell, but the tradeoff that created the IO monad
was too much for me. After 5 years using Haskell and a couple of years away
from it, I've become convinced that the way Haskell isolates IO and state is
not the correct solution. I'm not smart enough to know the correct solution,
but creating monads, monad transformers and arrows and then providing sugar to
get everything to look imperative again feels wrong. Uniqueness Types feel a
bit healthier.

Now that I've said that, let me say that I'm most certainly impressed with the
work around IO and state in Haskell because it was an amazing bit of
intellectual horsepower and is an incredible step. But it doesn't feel like
the final step/answer. Unfortunately, I had to get work done for clients and
had to step away from Haskell, but I'm excited to see what the community
brings forth. It's the most beautiful language on earth.

------
radarsat1
I've been doing a whole lot of scientific Python lately, and every time I let
my program run for like an hour only to crash on an array of the wrong
dimensions, or pass in a scalar where an array is expected or vice versa, I
swear and wish I was using a strongly typed language like Haskell. If only it
had the same tools as SciPy I'd be all over doing my scientific work in
Haskell. (Not to mention it would have faster run times.)

(There are a few array libraries, but I'm pretty sure nothing as complete as
NumPy+SciPy+matplotlib exists for Haskell..)

~~~
kisielk
Sounds to me like you're doing it wrong. I write scientific Python code every
single day for work and I (nor anyone else who works with me) never run in to
those kinds of problems. Why are you running simulations that take an hour
before you even know your code work? Where are your unit and integration
tests? Every piece of our software stack has (or _should_ have...) tests that
verify all the bits fit together correctly in a matter of seconds or perhaps
minutes tops.

Strong typing would be nice to have sometimes, but in practice I think it
limits the amount of ad-hoc data analysis and exploration you can do while
trying to piece together a piece of software. I think the scientists in our
company would murder the software engineering team if they had to deal with
strong typing to get things done.

~~~
gaius
The point is that a whole class of things that you would have to write unit
tests for, you get "for free" with strong typing, and for a lot of the others,
there's QuickCheck. Or as the old saying goes, why get a dog and bark
yourself?

~~~
vidarh
Except you don't get them "for free". You get them in the form a ton of
restrictions on you that you need to be mindful of when writing it in the
first place. You just pay for it in different ways. The biggest difference is
that in dynamic languages, you can sometimes get away with being lazy and not
writing the tests to verify the things static languages enforce to varying
degrees (whether or not that's a _good_ thing is another issue).

~~~
SkyMarshal
Haskell frontloads type considerations and tests via a required, tightly-
coupled type system. Dynamic languages backload them via optional testing.

In either case you still have to think about those issues when correctness is
a requirement. When it isn't (ad-hoc analysis, prototyping), dynamic languages
are more pleasant to work with. When it is a requirement, Haskell is uniquely
powerful.

Problem is, many projects are subject to both requirements at the different
times. Exploratory at the start, strict once the problem to be solved is
identified. Know the tradeoffs and pick your poison.

------
swah
With the trend of SOA and webservers like Mongrel2, perhaps its a good time to
start putting the more esoteric languages in production in the form of small
services (w/ ZeroMQ for example).

~~~
boothead
Agreed, zmq and some form of cross language serialization library (we're using
protocol buffers) is a seriously powerful tool to have in your box. There are
some patterns that seem perfectly suited to a small piece of haskell at the
end of a zmq socket.

~~~
gaius
I am using AQ to help get OCaml into "real" use:
[http://gaiustech.wordpress.com/2011/05/26/ociml-new-
feature-...](http://gaiustech.wordpress.com/2011/05/26/ociml-new-feature-aq/)

------
j_baker
I agree with the author, but for different reasons. I think Haskell suffers
from a "network effects" problem. It's not made for real world use cases
because nobody is using it for the real world. And guess what? To get it
adopted in the real world, it needs to support real world use cases.

I think that Haskell is doomed to a life of being a research toy language for
the simple reason that that's what people are using it for, not because
functional programming is necessarily much harder (because I don't think it
is).

~~~
m0th87
Haskell has some notoriety in the financial industry. Obviously the language
isn't used as extensively as, say C++ in commercial applications, but to go to
such extremes as saying "nobody" uses it is plain wrong.

~~~
Agathos
A couple of years ago, the only ads I would ever see on gmail in my haskell-
cafe folder were for Jane Street Capital.

But they don't use Haskell. The ad basically asked if they could talk me down
to OCaml. It came up for discussion on the list, and as I recall they
preferred OCaml so they could write speedy code without getting hung up on
lazy evaluation and its sometimes-difficult-to-predict execution time.

I still haven't looked at OCaml, although I had some exposure to SML in
college. I'm looking at Scala these days (The type inference isn't even
Hindley-Milner! Scandal!).

------
socratic
If the question is, should we use Haskell to solve this problem, or should we
use JavaScript, I can't imagine that the answer is often Haskell. (Maybe if
the question is, should we use OCaml or should we use Haskell...)

That said, what really came out of left field was the OP saying that he and
his friends are more and more using Go.

Is Go adoption happening? I'd love to have a systems programming language that
isn't C or C++, but I'd always assumed that Go was dead-on-arrival
specifically because it wasn't C or C++.

~~~
Sniffnoy
What I want to know is, is Go still undergoing major revisions? I don't seem
to have been able to find an answer to this, and it's annoying. I remember
there being some fairly big changes some time ago -- not so recently now, but
after it was already public -- and I want to know whether that's going to
still be happening before I bother learning it.

~~~
edsrzf
Go version 1, the first stable version of the language and implementation, is
due out early next year. That sounds like a good time to start learning.

------
kamechan
"If you've written a Haskell program that runs, it's highly likely to be a
correct solution."

having done a bit of work with haskell myself, i'd say it's even better for
this for haskell programmers. _if you're using type signatures and you've
written a haskell program that passes type-checking, it's highly likely to be
a correct solution_

~~~
pjscott
But just in case it isn't, remember that QuickCheck is a remarkably easy and
powerful way to test weird edge cases:

[http://book.realworldhaskell.org/read/testing-and-quality-
as...](http://book.realworldhaskell.org/read/testing-and-quality-
assurance.html)

------
mseebach
First, the title annoys me: "Why not X?" is almost always the wrong question
to ask, because it implies that X is so great that don't even need a reason to
use it. If you want me on board, the relevant question is "Why X?".

Second, _A resulting correct Haskell program is likely more reliable,
maintainable, and perhaps faster_ seems fallacious to me. It might as well be
that because Haskell is hard, only people with a deep understanding and
appreciation of computer science ever venture into it. So, in other words,
Haskell programs are good because they're written by very bright people
thinking very hard about what they are doing. The same reason old mainframe
code works well and average PHP doesn't.

~~~
neilk
I am guessing that you have never worked with Haskell?

Your hypothesis -- that difficult languages result in more bug-free code, due
to selection bias -- is, to say the least, somewhat of a minority opinion.

But even if we accept this, Haskell is different. The difficulties of Haskell
are not arbitrary. Nor are they related to the difficulty of understanding the
machine at a low level. In fact, Haskell insulates you from all that; it's
easily the highest level language in common use.

It's that Haskell insists on program correctness. You have to consider the
entire range of values that any function could ever process. And due to its
purity, Haskell applies a razor to your thought process, cutting out all
unjustified or implicit assumptions.

Luckily it also gives you tools of unparalleled flexibility when it comes to
creating abstractions. Creating a new abstraction (like the composition of two
functions) isn't just _as easy as_ function application, that's how you _do_
function application in Haskell. Typically with less syntactical fuss than it
takes Java to initialize a variable.

~~~
mseebach
No, I have not worked with Haskell.

I agree that a good type system eliminates an entire class of bugs (being
strongly typed is what makes Java bearable), but I rarely see bugs in well-
written software caused by not having considered the full range of inputs to
your function.

~~~
outworlder
Really? Try harder :)

Remember that the "inputs" in non-pure languages are not only the function
arguments, but can be global variables, objects (singleton or otherwise),
external files, and so on. These are all inputs.

Plus, Java's type system is a toy compared to Haskell.

~~~
mseebach
Try harder what? Not seeing bugs I don't see?

Yes, I'm aware what "inputs" are. One property of what I consider well written
software is the absence of global state. "External files, and so on." are,
unfortunately, necessary for any program, even Haskell ones, to do anything
useful.

> Plus, Java's type system is a toy compared to Haskell.

Plus, so what? I'm not even beginning to compare Java with Haskell.

~~~
jerf
'"External files, and so on." are, unfortunately, necessary for any program,
even Haskell ones, to do anything useful.'

I would point out that Haskell _can_ in fact do useful things, so these
problems must have been solved. It is a common misconception that Haskell has
"problems" with external state, when in fact what it has a way of explicitly
managing such state where almost any other language does not. It isn't so much
that Haskell is lacking the ability to manage external state as that _other_
languages lack the ability to manage external state, and end up with a
solution that from the Haskell point of view looks like a punt rather than a
great solution.

But it's difficult to explain how that works in an HN comment; I'd suggest
Learn You a Haskell up through the Monad chapter, then spending some time with
STM until you grok how and why the type system actually manages to guarantee
proper use of STM at compile time. This is interesting because STM has proved
effectively intractable in languages that can't maintain the STM constraints
at the type level. While the course I've just recommended may take a week of
education, that's about all it would take; it's not months, and it's actually
a very valuable perspective to gain on the problem of creating quality code
I'd recommend to anyone.

------
kd1220
I'm learning Haskell right now. It's the most recent language I've decided to
pick up since R back in 2006. Despite dabbling in Lisp about a decade ago, and
the functional flavoring of R, it's been a pretty difficult ride. However,
it's definitely teaching me to think about writing programs in a very
different way.

I can attest to the painfulness of the IO monad. I still haven't gotten it
fully. The error messages are also fairly cryptic. The first program I wrote
was about 15 lines and it took me about 4 hours of time. But it worked
flawlessly and efficiently. The difficulties notwithstanding, this is probably
the most fun I've had learning a language ever.

~~~
tikhonj
I've found that the error messages quickly start making more sense (most of
the time anyway...); in fact, now I parse the Haskell type error messages
faster and more accurately than similar messages in Java or the like. I'm
sufficiently spoiled now that error messages in languages like Python just
throw me off completely...

------
Adaptive
For those interested in learning Haskell, I can recommend the lesser known
"Haskell Road to Logic, Maths, and Programming":

[http://www.amazon.com/Haskell-Logic-Maths-Programming-
Comput...](http://www.amazon.com/Haskell-Logic-Maths-Programming-
Computing/dp/0954300696)

It's great to go over old and new math concepts and do so while exploring
Haskell.

~~~
darklajid
I don't know. For me this sounds like a very bad idea.

What is putting me off (tried building small things in Haskell a couple of
times) is the already heavily buzzword compliant community, throwing not only
a new language with new concept at me, but adding words that at first seem to
be made up on the spot.

Additionally, as others have said here, I'm having most troubles interacting
with the world (IO!). Pure functions (Math!) are ~easy~ to represent.

You suggest starting with that language and learning 'new math concepts' on
the go?

(I'm sure this works for some people and hats off to you guys, but for me this
increases the mental complexity immensely)

~~~
Adaptive
I think you raise a good point and I wouldn't want to put others off if this
isn't commensurate with their learning style. I suspect the overlap between
math geeks and haskell learners is pretty big, but one should, as you are,
evaluate one's own preferred learning style against this approach.

I find human languages are the same for me. I have always liked to approach
them from a bottom up linguistic direction, but this means largely self-
structured study.

------
pnathan
I've been spending time learning Haskell lately, as part of an investigation
into tools which are amenable to static analysis at work.

To learn about the situation, I've put together similar programs in Lisp,
OCaml, and Haskell, as well as installed compilers for Haskell & Ocaml on the
PPC.

Well -

I've coded for over a decade, and I've never encountered such a difficult to
use language and jargony community & documentation (including AWK & SED). The
only reasons I have been able to do anything are Real World Haskell, Learn You
A Haskell, and Stack Overflow.

I'm not going to say Haskell is useless, or has no libraries, etc. Those
aren't true. It's also not a bad language because it's weirder than my Blub
(Common Lisp). It's a really sweet language, and I think in the hands of an
expert, Haskell can _dance_.

But, I'm going to say Haskell is nearly impossible for an experienced
procedural programmer to pick up and go with on the fly. There are a few
reasons for my opinion:

* Special operators out the wazzoo. >>= ` ++ :: etc. The wrong 'dialect' of Haskell leads you to believe it's Perl and APL's love child. It's just not clear what something does until you find a reference book. Google doesn't help here - I don't even know the verbal names for some of them. :)

* Monads & in particular, the IO Monad. The number of tutorials and explanations (and the number of new ones) suggest that this is not the most obvious concept in the land. It seems to be very simple if you know what you're doing (and what operators to use), though.

* The REPL is not identical to the compiler. This means that you can't _trust_ the REPL. Coming from Python and Lisp, that is a pain.

* Type messages that are quite unclear, and probably require referring to the Haskell98 report to fully understand.

 _Regardless_ , the above are surmountable problems and reasonable when moving
to a new paradigm (very frustrating, though).

However, there are two key issues that are close to deal-breakers, with a
third more minor one.

* Time to put a small program together. Easily 3x-10x my time working on Ocaml, a language which I am less experienced in (in both languages, I am amazingly inexperienced).

* Building the compiler on PPC (business reasons why I would need to do this). Ocaml builds with the traditional ./configure && make. Very straightforward. GHC requires a cross compile with some funky source tweaks, or _possibly_ a binary package (but the bin package dependency tree required replacing libc++, at which point I stopped). This is a dealbreaker unless I can straightforwardly guarantee my boss a good ROI with Haskell vs. (OCaml or other statically typed language).

* Human costs for my code. It's not professional to have a codebase only I can use in a team. Yes, the team could learn Haskell, but would it be a good ROI? If OCaml gets us there faster...

So Haskell is probably not going to work for me at work. :-( We'll see though.

~~~
j_baker
_The REPL is not identical to the compiler. This means that you can't trust
the REPL. Coming from Python and Lisp, that is a pain._

I can't agree more. This is by far my biggest issue with Haskell. It would be
so much easier to learn the language if you didn't have to learn the REPL
separately from the language proper.

~~~
carterschonwald
This problem with the repl is actually going to disappear in the next ghc
release (7.4.*). In particular, as of that ghc release you'll be able to
interactively define types and functions (both!) in the repl.

------
jmuk
I agree with the author, but still it reminds me of "Beating the average" >
This is the same argument you tend to hear for learning Latin.

------
gawi
Agreed that Haskell might not be to perfect fit for most of the enterprise
projects out there, BUT nevertheless it is worth learning and mastering. The
perceived difficulty comes from decades of teaching of imperative programming.
I'm myself the product of C/C++/Java and it's amazing how I've manage to deal
with so many peculiarities of theses languages. After having learned Haskell,
I realize that it's much more coherent than the vast majority of other
programming languages (including the functional languages). I'm learning Scala
today and frankly, Haskell is much simpler. It is just amazing what you can
achieve with good abstractions (parallelism, performance, modularity).

You might be tempted to use it yet but I'd suggest you keep on eye on this
language. The potential is great and Haskell is evolving quite fast.

~~~
SkyMarshal
Yes, I actually started learning Haskell recently b/c I thought it would help
me better grok Scala, which seems to borrow mostly from the ML family.

Scala is definitely a better Java imho, and you get to keep the JVM and all
its libraries, and the Lift web framework is superb, and you can even build
Android apps with Scala.

But ironically I've found myself falling in love with Haskell and not wanting
to use anything else. For the first time ever I know what a real type system
is and what it's for, and Haskell basically pulls a Steve Jobs in completely
rethinking how to do parallelism (strictly control global state and side
effects by eliminating them by default, enabled only via monad).

Mind expanding indeed.

------
bitcracker
Haskell demonstrates the difference between theory and practice.

What does it matter if an arbitrary language X is beautiful in theory if
nobody uses it in practice because they don't comprehend it?

Consider all those theoretically beautiful languages: APL, Ada, Lisp, Haskell,
OCaml, ... How many developers use them? I think less than 1 percent in
summary. Why?

Because syntax really matters. For this reason imperative languages like C++,
Java, Python, Perl, Javascript, even PHP are so successfull.

As a long experienced programmer I discovered that (at least for me) the best
technique is not to be fixed on one language but to use metaprogramming. That
means, use your current favorite language (or create your own DSL) and compile
it to the platforms/languages of choice.

My current recommendation: shenlanguage.org

------
melling
In the end the author seems to be using Go for a lot more development. Are
people here finding it to be a good solution? It seems like it might be the
language that could bridge the iOS and Android systems for app development.

~~~
SkyMarshal
_> could bridge the iOS and Android systems for app development._

How would it do that? Can it compile to Dalvik and iOS or something? Not very
familiar with Go yet...

~~~
melling
Compile to native code. Android has the NDK; they support C/C++.

------
jxcole
I like the shout out to go at the end. If you haven't tried that language yet
I highly recommend it.

~~~
gaius
He kinda has to, being a Googler.

~~~
uriel
Nope. There is nothing that forces Googlers to either use or promote Go.

~~~
gaius
Well they ain't gonna use or promote C# are they?

~~~
uriel
Google is a very big and diverse organization, I'm sure there are some that do
promote pretty much every language you ever heard of (and many you didn't).

Actually, I remember some years ago reading about some Googlers that used C#,
no clue what for, and it was a while ago, but it is not unrealistic.

~~~
nathanwdavis
John Skeet?

------
nxn
My problem seems to be that despite desperately wanting to use Haskell for
some decent sized project, it never seems to work out as my best option. Right
now I'm interested in writing a metro styled app for win8, and even for the
server side portions I feel like I'm better off just using CouchDB instead of
any Haskell solution that I've seen so far. Before that it was yet-another-
web-based-UI-library so my choices were pretty much coffeescript or
javascript. Perhaps it's because I like to have fun with UI, but so far
anything I'd like to actually spend time on -- Haskell just doesn't seem like
the right tool for. My best use of it so far was solving project euler
problems, and considering how much I liked it, it feels like a shame that I
have nothing better to use it on.

~~~
qx24b
That seems to be exactly what haskell is suited for solving, math problems.
Which is great and wonderful when you are doing math related problems or
things that are heavy in math but when you try and go outside those bounds
that is when haskell becomes much much harder to write and work with. But alas
that is both what makes haskell nice and hard to work with.

------
jlarocco
I've been using Haskell on and off for a few years and have written a few
(small) projects in it. Every time I end up turned off of it, though.

First, I don't like how it makes side effects such a PITA. Fact of the matter
is, computing is only useful for the side effects. A computation is useless if
the result isn't printed to the screen, saved to a file, sent over the
network, or used in some other way. So why make side effects so difficult?

Second, the community, or at least a vocal minority, come off as very
condescending. If I have to ask a question on IRC I probably already feel
dumb, I don't need somebody treating me like a child because I don't
understand something.

~~~
gtirloni
One of the reasons I'd suggest Haskell to someone is exactly the community. I
cannot see a question going unanswered on #haskell or at least 2-3 trying to
help (doesn't matter if it's beginner-level or advanced). My experience has
been the opposite.

------
michaelochurch
Haskell is a hard language because (a) laziness is not intuitive, especially
when space-performance matters (sadly, it does) and (b) pure functional
programming is just not practical for most people. Like the OP said, it's
awesome for brain-stretching, but not the easiest language to use.

I started writing a game in Haskell and found that the scaffolding necessary
to do randomness in the "right" way was just too painful. It could be that I
hadn't learned the idioms well-enough to see a better way of doing things; but
if I had trouble, I think it's fair to say that most people would. Don't get
me wrong: I'm a huge fan of functional programming. I just think _pure_
functional programming is impractical. Mutable state is like radioactivity:
it's necessary, powerful, and sometimes very useful, but must be handled with
extreme care, not promiscuously thrown about.

My favored computation model is one in which the waterline between lambda and
pi calculus is clear: message-passing between agents who should ideally be
referentially transparent, unless referential non-transparency is part of
their design. The upshot of this is that if an agent needs to be optimized
using mutable state, none of the others care. That is, it's what OOP _should
have_ been.

~~~
waqf
> I started writing a game in Haskell and found that the scaffolding necessary
> to do randomness in the "right" way was just too painful. It could be that I
> hadn't learned the idioms well-enough to see a better way of doing things;
> but if I had trouble, I think it's fair to say that most people would.

This. My current opinion as to what would constitute a perfect language is:
something built on top of Haskell which would, in some as-yet-unconceived-of
way, make it easy to thread mutable state exactly where it needed to go in
your code.

Like monads were supposed to do, except _readable_.

Frankly, the code contains all the information you need to do this already, so
perhaps we just need a source-code übereditor that marks it up so that you can
see the dataflow.

~~~
michaelochurch
Monads are not unreadable. When you finally get do-notation and realize that
you can use the same idioms for (a) list comprehensions, (b) imperative-style
programming, and (c) error-handling and option-chaining, there's a "Wow"
moment. However, we can give up on selling monads to the masses. The name
alone...

The concept of the monad is beautiful and awesome, but it's too _different_ to
succeed with the masses.

~~~
SkyMarshal
_> However, we can give up on selling monads to the masses. The name alone..._

A monad is just a monoid in the category of endofunctors, what's the problem?

(for anyone not familiar with the in-joke:
[http://stackoverflow.com/questions/3870088/a-monad-is-
just-a...](http://stackoverflow.com/questions/3870088/a-monad-is-just-a-
monoid-in-the-category-of-endofunctors-whats-the-problem))

------
whackberry
Why haskell is a more appropriate question.

------
dlss
The intro read like it would be a much longer article.

tl;dr - Haskell isn't easy enough to use / is lacking good toolchains for
author's use cases

