
Hacking Haskell - DanielRibeiro
http://rethrick.com/#haskell-better
======
baguasquirrel
I've actually been trying to prove people like this guy wrong for years. My
takeaway is that Haskell is not the problem. The real problem is that solving
people's problems is hard. Designing and iterating on a product or service is
hard. Finding and involving the ambitious folks with halfway well-baked ideas
is hard.

Now I'm going to get a lot of flack here for saying this but I simply just
don't feel that most of the stuff we make today is of particularly high
craftsmanship. We need one of two things to happen.

The first is that the demand for thoroughly well-crafted software has to
increase. But that much is out of our hands as it is conditional on the public
at large. This will happen eventually. New tech starts life as a toy. At some
point, people will want those toys to be reliable.

Going the other way, we could make it more rewarding for people to build
scalable, maintainable systems in Haskell. But we are already well on the way
to doing this. For example, Snap was much easier to use than Happstack (IMHO),
and Happstack itself has already much improved over the years. The libraries
for Couch and Mongo are as good as any other. Tools aside then, Haskell's main
impediment is that can be a bit intimidating. But a friendly and openminded
developer community can go a long way. We just have to keep this in mind, and
keep fostering projects.

~~~
szany
cf. [http://conal.net/blog/posts/can-functional-programming-be-
li...](http://conal.net/blog/posts/can-functional-programming-be-liberated-
from-the-von-neumann-paradigm/)

------
dons
The "always just out of reach" metaphor is tired.

It's a somewhat outdated view of the community, which is now quite large, with
many members gainfully employed building systems in Haskell commercially, and
in non-trivial applications.

------
alanthonyc
I've been going through the "Learn You a Haskell..." book for the past week or
so (mainly to procrastinate on my main project). After the first few chapters
which basically just show the syntax for things you might do in other
languages (e.g. lambdas, maps, recursion, etc.), I've gotten to stuff that's
new to me (mainly type classes, though I'm sure there's more) and I'm sort of
getting blown away by the possibilities.

~~~
gtani
_Learn You_ is terrific. Besides that, Conrad Barski and Hal Daume's
tutorials, the stuff that the Wash U students did (see Haskell Wiki), and
Hutton's little green book.

<http://www.haskell.org/haskellwiki/Tutorials>

------
ggchappell
I'd have to say that his arguments are interesting, but they only work well
with carefully chosen examples.

In particular, the question of efficiency in the context of lazy evaluation
appears to be very tricky, and thus far it has been only little explored. For
example, the first way to do large-scale I/O in Haskell that doesn't eat up
resources (namedly, "iteratees") is maybe 3 years old, and I don't think an
awfully lot of people really grasp it. No, it seems to me that we're just
beginning to figure this stuff out.

 _Earlier comment_ :

Talk about just out-of-reach, how about the words on the page? Viewing this
under FF3.6 on Snow Leopard, and the words go just off the right-hand side of
the window, no matter what size I make it.

EDIT: Tried Safari. It's a fixed-width column there. And Readable works fine
under FF.

~~~
dons
There seems to be some confusion here.

Iteratees weren't introduced to solve the problem of "eating up resources" per
se. They're a new abstraction for doing _high performance_ IO -- in any
language. You've always had several choices for IO in Haskell: lazy IO (like
pipes in shell programming), or strict IO (like say, Python or C IO).

Iteratees blend these somewhat, giving a third way.

So you could say that IO isn't well explained by computer science yet -- as
new approaches are still being discovered. That doesn't really say anything
about Haskell, other than it was the first developer community to really take
iteratee-style IO seriously.

~~~
ggchappell
Well, perhaps I am one of the many who don't really grasp iteratees.

In any case, my point about efficiency in the context of lazy evaluation not
being well understood, still stands.

~~~
dons
Yes, the space semantics of lazy evaluation is difficult to learn,
particularly when coming from fully-strict languages, or languages with little
support for lazy programming.

Many other programming techniques face similar barriers: e.g. memoization,
concurrency or logic programming result in similar brain twisting -- yet can
be suprisingly useful.

So I argue that programmers shouldn't be scared of technology -- embracing and
learning new techniques can only improve your practice.

------
szany
"I listen closely for the subtle misunderstandings that are inevitably lurking
underneath this newly-minted zealotry. And I am seldom disappointed."

Can anyone elaborate?

