Re: [Haskell-cafe] Toy application advice wanted

On Tue, 4 May 2004, Bill Walsh wrote:
I am amazed that you can even think of doing anything in a week. I have been at it for at least 15 years: one project; one dead set proof-of-concept .
Well I'm sure you're doing something much more useful/worthwhile than I! =) I understand that the example program I initially thought of is rather, well...typically imperative. That's sort of the reason I chose it. Not only does it have real-world ramifications to my customer (the problem domain is similar) but it will hopefully show me the worst of the best. I.e., Haskell is a beautiful language [disclaimer: this comes from me not really being a Haskell programmer, but admiring it from afar if you will] and can express some unbelievably advanced concepts elegantly, but is it really nasty doing "normal" software crap like loading a bunch of data, popping up GUI windows, etc. etc.? I was hoping that I can piece together something fairly quickly within two weeks in those three languages. They don't have to be robust, or even beautiful. In fact, I can guarantee they won't be. But the real point of the exercise is for me to figure out which environment is the easiest for me to get along with.
I will follow your progress with intense interest. Your are obviously an experienced programmer, but it is your analytical skills which interest me most.
Well, I am an experienced programmer, but certainly not in the same class as most lambda-junkies as yourselves. I have a long sordid history of programming in imperative languages and I've been bitching about switching for long enough that it's time to put my money where my mouth is, so to speak. I've dabbled in Scheme and Erlang and ML. To be frank, I've all but discarded Erlang as a viable language. Don't get me wrong...it's got some great features; I just think that I could easily implement Erlang in Scheme or Haskell and be quite happy. (At some point in the future when I'm smarter =) So to me, the real question is: Haskell, the pure, or Scheme, the dirty? Haskell is lazy all the time. That's awfully nice...I'm not sure if there's a performance penalty somewhere, but assuming there isn't, kudos to it. Scheme lets you be selectively lazy with macros. At least it's highly customizable (for instance, pattern matching can be implemented in Scheme with macros, whereas other languages that have fixed special forms are quite limited). But Scheme lets you change things if you want to! (The Haskell afficianados gasp). Let's face it...in most long-running applications, data changes a lot during the lifetime of a program. So somehow, you have to manage the repercussions of state changes. Haskell does this with monads. (I'm still wrapping my brain around them, but...) Apparently monads plus some syntactic sugar are like functions that return a value and the next function, which in turn returns a value and the next function, etc. so that referential transparency is maintained. This is a heckuva lot of work to do (set! foo 'bar). I hope I'm not far off base with this. I guess it boils down to this: Haskell ensures that your bindings are never ever ever corrupted, and thus the sematic value of your program is never compromised from the outside. The cost of this is a sharp learning curve, and quite possibly a performance hit. Scheme lets you tromp all over stuff (well, you get the picture), in effect letting you still have control over when you really need to do something imperative for performance or simplicity reasons. I'm not sure which I *like* better. So far neither is visually appealing, mostly because I'm not familiar with them. Scheme seems to have a slightly bigger population than Haskell, which of course means squat because if I really cared about how many programmers of language X there are out there I'd just code in Java (which, sadly, I'm doing now). Anyway, I'm starting to ramble, but I talked to a friend who has similar feelings but is actually pretty good at Common Lisp. He suggested I refocus my energies, and I agree: instead of biting off more than I can chew, and having to learn a whole wad of APIs that aren't really about the language (read: wxHaskell or gtk2hs/the like, or audio packages etc.), just code some really simple problems. Like the Sieve of Eratosthenes, in all three languages. Or a simple publish/subscribe framework with a "master" state holder and many slaves. Or quicksort. Etc. etc. So I'm going to head down that path right now, and try to get a feel for the languages in a slightly more pure fashion. I'll still try to get performance metrics out of them, but I'm not going to bang my head against the wall learning new languages, GUI toolkits, and FFIs all in two weeks. =) Thanks for the replies so far, I really appreciate them. -- Mike J. Bell This is all just my opinion. "Outside of a dog, a book is man's best friend. Inside it's too dark to read." mikeb@manor.org

On Mon, May 03, 2004 at 11:27:41PM -0400, mikeb@manor.org wrote:
Anyway, I'm starting to ramble, but I talked to a friend who has similar feelings but is actually pretty good at Common Lisp. He suggested I refocus my energies, and I agree: instead of biting off more than I can chew, and having to learn a whole wad of APIs that aren't really about the language (read: wxHaskell or gtk2hs/the like, or audio packages etc.), just code some really simple problems.
Like the Sieve of Eratosthenes, in all three languages. Or a simple publish/subscribe framework with a "master" state holder and many slaves. Or quicksort. Etc. etc.
So I'm going to head down that path right now, and try to get a feel for the languages in a slightly more pure fashion. I'll still try to get performance metrics out of them, but I'm not going to bang my head against the wall learning new languages, GUI toolkits, and FFIs all in two weeks.
I think that sounds like a good idea (not doing a GUI just yet) but would recommend that perhaps you could do something pretty impure in terms of file or directory browsing. That wouldn't involve going beyond the standard libraries, but might give you some idea of the expressive power of the languages in terms of IO actions. I'm thinking something like a recursive grep, or wc -l... except preferably a bit more tailored to the sort of IO you'll have to do in your actual application. I guess the trick would be in finding something tough enough, since wc -l would be something like a two-liner... -- David Roundy http://www.abridgegame.org/darcs

Mike,
I'm evaluating several high-level languages as development vehicles for our next suite of applications.
.. just code some really simple problems. Like the Sieve of Eratosthenes, in all three languages. Or a simple publish/subscribe framework with a "master" state holder and many slaves. Or quicksort. Etc. etc.
I would be careful about using your experience with these toy programs as an indication of how suitable functional languages (and lazy ones in-particular) are as 'development vehicles' for your applications. A functional programmer's idea of a 'toy' program tends to be somewhat different from a C++/GUI programmers one. Lazy functional languages lend themselves nicely to parsing, list processing, search trees and the like - but if you're planning to load a wave file, apply a filter and then display the result on the screen .. then let's just say that you've got an adventure ahead of you, and it's not going to take 2 weeks. ... as far as GUIs are concerned, check out http://www.haskell.org/libraries and look at how many seperate GUI libraries there are - I counted 16 - then ask what made the developer for the 16th one choose to start over.
Haskell is lazy all the time. That's awfully nice...I'm not sure if there's a performance penalty somewhere, but assuming there isn't, kudos to it.
There is.. and its name is 'space leak'.. and the function mapAccumL :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y]) is by far the most elegant way of expressing it :) BTW: I've just dedicated the next 3 years of my life to trying to write non-toy programs in lazy functional languages... "adventure" is the operative word.. not "can't". Ben.

On Wednesday 05 May 2004 04:46, Ben Lippmeier wrote:
http://www.haskell.org/libraries and look at how many seperate GUI libraries there are - I counted 16 - then ask what made the developer for the 16th one choose to start over.
The fact that the 16th one is a wxwindows binding justifies this quite well :) V. -- Si puo' vincere una guerra in due e forse anche da solo si puo' estrarre il cuore anche al piu' nero assassino ma e' piu' difficile cambiare un' idea [Litfiba]

I'm finding wxHaskell very nice, and a wxWidgets
binding is something many other "advanced" languages
don't have (even OCaml). The only downside is having a
'Hello World' GUI application with 7 Mb... but it runs
quite well and smooth once it's loaded.
---
[]s, Andrei de A. Formiga
--- Vincenzo aka Nick Name
The fact that the 16th one is a wxwindows binding justifies this quite well :)
V.
__________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover

On Wed, 2004-05-05 at 16:24, Andrei de A. Formiga wrote:
I'm finding wxHaskell very nice, and a wxWidgets binding is something many other "advanced" languages don't have (even OCaml). The only downside is having a 'Hello World' GUI application with 7 Mb... but it runs quite well and smooth once it's loaded.
We have the same problem with gtk2hs. A stripped simple(ish) prog weighs in at about 2.5Mb. I'm not quite sure what's in there that makes it so big. Duncan

I don't want to pick on any particular library, as this issue can pop up with any library in any language. I feel it's an issue which has been addressed before, but the solutions are largely ignored. This is most likely because 1) people assume we have plenty of space or 2) the library isn't yet complete, and it's easier to statically link a big library for now, and worry about alternatives later. If I were writing a library, I probably wouldn't be too concerned with the issue myself. It seems there are two ways to address this problem: 1) Shared libraries. Why not link the library dynamically instead of statically? Is this possible with GHC? Then multiple applications using the library wouldn't balloon the memory use, but share a copy of the same library. For simple development and testing, it's easier to statically link, since we only have to worry about one file. But if we expect people to run many programs using this library, we ought to be more careful about space usage. Dynamic linking ought to be an option. 2) Linking in only what's used. If a simple 'Hello, World!' program only needs a window and some buttons, why link in all the code for other widgets? Is there a library format which allows pulling out only those operations which are needed? An alternative is to recompile the library code with the program each time, throwing away dead code - that is, the library code which is never called. Recompiling the library code with the application takes longer, but need only be done once the program is ready for distribution. If anyone knows of existing solutions in either of these areas, please inform us. - Lyle Kopnicky Duncan Coutts wrote:
On Wed, 2004-05-05 at 16:24, Andrei de A. Formiga wrote:
I'm finding wxHaskell very nice, and a wxWidgets binding is something many other "advanced" languages don't have (even OCaml). The only downside is having a 'Hello World' GUI application with 7 Mb... but it runs quite well and smooth once it's loaded.
We have the same problem with gtk2hs. A stripped simple(ish) prog weighs in at about 2.5Mb.
I'm not quite sure what's in there that makes it so big.
Duncan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

David Roundy wrote:
I think that sounds like a good idea (not doing a GUI just yet) but would recommend that perhaps you could do something pretty impure in terms of file or directory browsing. That wouldn't involve going beyond the standard libraries, but might give you some idea of the expressive power of the languages in terms of IO actions. I'm thinking something like a recursive grep, or wc -l... except preferably a bit more tailored to the sort of IO you'll have to do in your actual application. I guess the trick would be in finding something tough enough, since wc -l would be something like a two-liner...
A one-liner: main = interact (show . length . lines) - Lyle Kopnicky
participants (7)
-
Andrei de A. Formiga
-
Ben Lippmeier
-
David Roundy
-
Duncan Coutts
-
Lyle Kopnicky
-
mikeb@manor.org
-
Vincenzo aka Nick Name