Happs is a great web kit for haskell, but a a recent thread in the mailing list shows that it needs examples. Here is a good set of starters:
example1: the simple one-liner that serves static files
(with example static files to serve)
example2: adds to example 1 some simple state
(for example a counter)
example3: adds a request handler that displays
a dynamically-generated page that
displays the state
example4: adds an input and a handler that can
be used to change the state
...and so on, for savers, sessions, etc.
Each example would reuse the code from the previous one, so that notes
could highlight the changes, and explain their motivation.
-- credit to Mikel Evins for the example list
This is not a planned out post, but I feel the need to compare Python decorators with The Haskell Way.
I recently read Philip J. Eby's article on decorators and it was eye-opening.
Let's see first what the purpose and definition of a Python decorator is before comparing them with The Haskell Way.
Philip says that one use of decorators is to reduce code duplication. For example if a set of methods needs to be wrapped for additional functionality, such as synchronization, pre/post conditions, etc, then you can simply annotate each with the appropriate decorators.
The second use is to have the meta-information about functions right with the function so that the data is never out of sync with the function. Then you can locate all methods with certain characteristics via the decorator API (I suppose)
I don't know why it took Phillip to the middle of the paper to define a decorator, but I think it was a good move... to sort of whet your appetite before giving you the definition. After all, this is not a mathematical proof. Anyway, a decorator is "...a callable object (like a function) that accepts one argument—the function being decorated. The return value of the decorator replaces the original function definition."
Comparison with Haskell
The very first thing that comes to mind is decorating destroys manifest interface. You can no longer examine a piece of code and examine the type signature of the functions it calls and know what is supposed to happen.
Haskell employs an entirely different approach to modifying function behavior. If you have a stereotyped way of modifying a set of functions, you would have to call the modifying function not call the original decorated function.
This is actually more flexible and composeable - the original function does one thing simply and clearly, then any combination of control strategies can be layered on top via other functions.
Let's take each of Philip's purported purposes of Python Decorators and see how Haskell accomplishes the same thing, but with that unmatched Haskell-esque elegance, flair, power and control. Yes, that's right, all 4 terms apply: elegance, flair, power and control:
Well, that's what functions are for. If there is a list of things that need to be done to a function, then that itself is another function taking the first function as an argument.
The additional power of The Haskell Way is that you are not tied down to decorating a single function in a single way... for example: is it really the case that you should be decorating the division of two numbers with an exception? What happens when you want to decorate it with something to generate HTML instead?
SCATTTERING OF KNOWLEDGE
Phillip says that sometimes "...a framework needs to be able to locate all of a program's functions or methods that have a particular characteristic, such as 'all of the remote methods accessible to users with authorization X.'"
But I dont know about that. When was the last time I needed this sort of information? If so, is seat-of-the-pants annotation the way go? Why not use Template haskell to generate all such methods ahead of time?
Decorators do not belong in Haskell. They rob a language of referential transparency. They result in "pull-style" programming as opposed to injecting control.
This is your very first tool. Write out the type for the function that will solve your problem.
Write down your trivial base cases
You wrote down your accurate base case. Now imagine your function having to process an input data set with just one element more than your base case.
Then, write out that case algebraically
PICTURES OF DATA FLOW
Cale Gibbard has some nice pictures of how data can flow through functions when using foldl. And the technique is applicable elsewhere.
I am a Senior-level Perl developer with 6 years of corporate experience.
I managed to eek my way to this lofty status by imitation. I bought lots and lots of Perl journals, read lots and lots of code, chatted in IRC channels, read perlmonks.org religiously and basically became capable of aping an answer to anythiing at anytime.
Oh and CPAN modules helped a lot because I only needed to follow directions and they cover almost any corporate scenario one might have.
So, at one time I was a junior sponge and now I am a senior sponge. I am not more intelligent I just have more idioms under my belt and can crack them off almost unconsciously.
Flip to Haskell. I have tried this approach to learning Haskell 2 or 3 times and each time I had to call the paramedics for oxygen. There is no such thing as a Junior Haskell Programmer.
You either possess the ability to conceptualize the functional decomposition of a problem or you get NOTHING done.
Haskell is a very exacting discipline and you either Master it or remain a fool and the only difference between the two is how much time you put into gaining a grasp on the power, scope, elegance and techniques for wielding the 3-fold synergy of strong typing, lazy evaluation, and purely functional application.
As a side note, I am of course wise enough to be dropping Perl for Python. And even though it is not Haskell, it is worlds better for 90 million reasons I wont go into right now.
Hoogle is sort of what I'm thinking about. But Hoggle requires well-typed info to find the functions you are looking for. And hoogle does not string together functions into solutions or programs.
In #haskell, all day long, there is question after question such as "How can I get a list of all pairs from this list" or "how do I apply a function to the first element of a list and then take that result and apply it to the next element of the list?"
Can we take the next step from hoogle and take english language requests and turn that into haskell code?
Can we build a browser for Haskell functions that allows one to navigate a tree of semantic concepts?
Most importantly, can we get inside the head of a Haskell programmer and break down his solutions into easy steps to make it easier for others to learn haskell?
John Goerzen has created
a Haskell interface to Python and done a bang-up job.
However, it does not look like anyone has made Haskell available to Python.
Python is a not-bad language... much nicer than Perl. Not as rigid as Haskell. Many more libraries and applications than Haskell. And Python was used in this years winning ICFP as well. And Python stole list comprehensions for Python. And PYthon combined object, functional and imperative in a prettier more understandable way than Ocaml did.
Here is a script I whipped up in Python to remove all m3u files from my music dir... the shell 1-liner of
find ~/Music -name '*m3u' | xargs rm
failed because find did not properly escape spaces and parentheses.
So here's my script:
from path import path
p = path('/Users/tbrannon/Music')
dirs = p.walkdirs('*')
for d in dirs:
for f in d.files('*m3u'):
What would the Haskell look like?
If you look at the winning team's language list:
they listed C++ first. and Haskell second.
Would someone with experience in designing large Haskell systems comment on whether it becomes difficult to manage or understand large Haskell programs due to lack of objects and the benefits of objects (such as inheritance).
I think type classes have polymorphism covered.
Since all language suck more than Haskell and since you suck at haskell, just get the job that pays more.
I recently have had this thang for Python, swearing it was the greatest thing out there but now I realize where the real thing is.
So it's really just bread-winning unless I have finally earned a haskell job.