Hacking Haskell(rethrick.com)
rethrick.com
Hacking Haskell
http://rethrick.com/#haskell-better
5 comments
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.
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.
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.
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
http://www.haskell.org/haskellwiki/Tutorials
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.
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.
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.
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.
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.
In any case, my point about efficiency in the context of lazy evaluation not being well understood, still stands.
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.
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.
>So you could say that IO isn't well explained by computer science yet
I don't think I could ever be sold on using a language where IO is an unsolved problem. Computer Science has defined it quite well for me in Python
I don't think I could ever be sold on using a language where IO is an unsolved problem. Computer Science has defined it quite well for me in Python
Python doesn't really have the equivalent power of Iteratees.
Iteratees let you compose chains of highly-efficient producers, transformers and consumers.
As a relatively trivial example, how would you write something in Python that performs this:
Iteratees let you compose chains of highly-efficient producers, transformers and consumers.
As a relatively trivial example, how would you write something in Python that performs this:
for word in open("really_big_file", "rb").read().split(","):
socket.send(word[::-1])
Using a generator I think this does what you want. What does the equivalent haskell code look like?
def read_chunked(f, delim=',', size=1024):
buf = []
while True:
data = f.read(size)
if not data:
if buf:
yield ''.join(buf)
break
if delim in data:
spl = data.split(',')
buf.append(spl[0])
yield ''.join(buf)
for s in spl[1:-1]:
yield s
rest = spl[-1]
buf = [rest] if rest else []
else:
buf.append(data)
for word in read_chunked(open("really_big_file", "rb")):
#socket.send(word[::-1])
print word[::-1]
Well, this is basically manually implementing Iteratee inline your solution. The idea is that Iteratees allow writing this as:
* Generalized for any error type and support various modes of error handling/propagation (they can go up to the producer, or down towards the deeper consumer as error inputs).
* Are generalized to many types of "buffers"
* Have a high-performance counterparts of standard "list functions"
* Are a standard base for many libraries to extend (http, xml, etc), and are faster, more powerful and more useful than standard strict IO libraries (Haskell's base libs, and Python's stdlib).
So both Python and Haskell have standard "strict IO" libraries. Iteratees are really a new idea -- that Python does not do well yet. So I don't think Haskell's progression of the state of the art in IO handling is really evidence that "IO is unsolved in Haskell".
main = run_ $
enumFile someFile
$$ splitWhen isComma
$$ map reverse
$$ iterHandle stdout
where
isComma = (== ',') . chr . fromIntegral
* Generalized for any error type and support various modes of error handling/propagation (they can go up to the producer, or down towards the deeper consumer as error inputs).
* Are generalized to many types of "buffers"
* Have a high-performance counterparts of standard "list functions"
* Are a standard base for many libraries to extend (http, xml, etc), and are faster, more powerful and more useful than standard strict IO libraries (Haskell's base libs, and Python's stdlib).
So both Python and Haskell have standard "strict IO" libraries. Iteratees are really a new idea -- that Python does not do well yet. So I don't think Haskell's progression of the state of the art in IO handling is really evidence that "IO is unsolved in Haskell".
That is a nice feature. thanks.
On the just-out-of-reach thing - I notice also that this is another clever motherfucker whose site completely breaks with JavaScript turned off, even though all it has to do is display text. As far as I'm concerned, an idiotic web design decision like that makes everything he has to say about language design suspect.
Only cynical bastards still browse the net with JS disabled.
Or people with screen-readers, or w3m, or actual security concerns. There are lots of sites where JS is an essential part of their functionality! It is a feature when these sites break with JS off (even though it is best when they provide alternate functionality in that case - GMail is a great example). But if you are, like this prat, serving text, if you are presenting a fucking blog, then completely breaking with JS off is, again, evidence that you are a Bad Programmer and a Bad Person.
"I listen closely for the subtle misunderstandings that are inevitably lurking underneath this newly-minted zealotry. And I am seldom disappointed."
Can anyone elaborate?
Can anyone elaborate?
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.