Re: [Haskell-cafe] Toy application advice wanted
On Wed, 5 May 2004, Frank Atanassow wrote: Frankly, I think it's completely unrealistic to expect to be able to fairly evaluate Haskell in 32 hours. As you noted yourself, Scheme and Erlang, being strict, are much closer to conventional programming languages than Haskell is, so it's easier to transfer skills to them. Yeah, I'm starting to see the difficulty in recommending a language I can barely dabble in up the chain (not as bad as pointy hair bosses, but still not computer scientists). Furthermore, they're untyped, and learning how to exploit Haskell's static typing is one of the bigger hurdles to learning how to exploit Haskell. That was one of the things that attracted me to Haskell...the type system. I enjoyed strong typing in ML when I played with it in college. At best, I imagine you'll come away curious and hungry for more; but clearly that doesn't suffice for a language evaluation. Certainly. Of course, the fact that Haskell can't be grasped in a day (or week) can be construed as a practical argument against its adoption. On the other hand, if you accept that there's no such thing as a free lunch, you might consider that a merit; what is the point of adopting a new language if it doesn't change the way you think about programming, and let you write old programs in new, perhaps better, ways? [1] This is the crux of the argument. I don't understand how we can make good programming languages more popular. My son was born just a couple of weeks ago, and I barely have enough time now to keep up with anything in my career/field; I was lucky I convinced my management to let me do a (too-) brief language survey. But without having thought in Haskell for at least a couple of months, how can I hope to promote it successfully? How can I get a couple of months proficiency in Haskell unless I've promoted it successfully? (Co-routines? =) While Haskell is IMO the best programming language around, and I want to encourage its broader adoption, if you want a well-designed language with good implementation and support which permits swifter skill transfer, may I (strongly) recommend you add Objective Caml to your list of candidates? Once you acquire some experience with an ML-like language such as OCaml, which after all resembles Haskell in many ways, you will, I believe, find yourself better equipped to evaluate Haskell. Thanks for this...I actually just added ocaml to my list last night. I was looking over the programming languages shootout and read some of the source. It looks pretty neat. I spent last night writing a simple object system from scratch in Scheme with macros, and starting thinking about all the things I'd have to do to implement any kind of type safety, and it just sort of clicked that ocaml might be an interesting solution. Thanks again for your comments (and everyone's). -- Mike J. BellThis is all just my opinion. Outside of a dog, a book is man's best friend. Inside it's too dark to read. [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Toy application advice wanted
Hi folks, I've got an interesting task this week for my job. (Note that this will undoubtably last for longer than a week). I'm evaluating several high-level languages as development vehicles for our next suite of applications. The languages I'm currently considering are Scheme, Erlang, and Haskell. Scheme and Haskell have fairly wide acceptance in their particular roles (Scheme as the pretty lisp, supporting higher-order functions and mostly strict [until you roll your own laziness with macros], and Haskell the absolute purest language with no side effects and fully lazy evaluation). Erlang has a really nice distributed computing model, and has a nice union of non- and side-effect qualities (although it's completely strict). The toy application I've designed for myself is a simple GUI-based app that can load a Sun .au format sound file, display its waveform in a window, perform some simple filtering, play the sound for the user, and then save the changed sound file back out to disk. If I get familiar enough with the respective environments I'd like to add zooming in/out and scrolling to the waveform display. This application should allow me to see all kinds of different characteristics of the language/implementation, such as performance (how fast can the filter run), I/O (how fast can I load/save data to disk), OS interaction (how easy can I play the audio), user acceptance (how easy is it to do GUI programming) and of course the software engineering goals of modularity, correctness, and simplicity. The end goal is for me to have three working programs, in three different languages, so that I can present to my boss the performance/software engineering characteristics of each system to choose our next development language. So I'm writing you to solicit help. I have an amortized four days (32 hours!!!) to implement this simple application in Haskell. Can anyone point me to example code, supporting libraries, tutorials, etc. that are in this area of development? If I have to dumb down some of my application in order to make a great discovery about a language, that's fine. I'm expecting some great differences between these three programs. Any advice/pointers/flames welcome. Thanks in advance. Mike -- Mike J. BellThis is all just my opinion. Outside of a dog, a book is man's best friend. Inside it's too dark to read. [EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
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. BellThis is all just my opinion. Outside of a dog, a book is man's best friend. Inside it's too dark to read. [EMAIL PROTECTED]
