On 2006-05-15 19:36 -0400, Geoffrey Alan Washburn wrote: > Sascha Silbe wrote: > > > >>Infact, if I wrote this Vis paper now, I'd probably try do the example > >>in Haskell with static typing :). > >Actually, I'm doing the prototype in Python. > > Learn Haskell; it will do you a world of good. If you really want > to use a dynamically typed language, use Scheme, it can do everything > Python can, better, has many high performance implementations, and was > designed by people who actually knew what they were doing.
Well, I don't think the core of Vis should be written in Haskell, but the examples in an article just as well might. However, learning Haskell or any functional language will do you good, give you new ways of thinking. Although it may not be the most practical language in all cases, I certainly recommend Haskell in particular, however, as it is so different to everything else. Lazy, statically typed with type inference, pure with monadic IO (think of a domain-specific language for constructing instructions for a separate IO interpreter). The Clean language also has most of these characteristics, but it uses a type system hack (uniqueness types) for mutable state, instead of monads. Unfortunately it seems to be poorly supported, while Haskell is finally gaining a lot of popularity. *Caml, OTOH, are not entirely pure nor lazy. OCaml can get quite good performance, however. All of the above-mentioned strongly statically-typed functional languages feature type inference, which means you won't notice much difference to a dynamically typed (timebomb-typed) language when writing the code: type signatures are not needed, as opposed to timesink-typed languages (which include most statically-typed imperative languages, although Nemerly features type inference and many other cool features from functional languages; unfortunately it uses the .BloAtWare library framework). You'll only notice the difference to a dynamically-typed language when the compiler refuses the compile code with timebombs. The compiler can often be quite picky thanks to the strong type system, but often the code works if it passes the compiler. -- Tuomo
