Name: Anonymous 2008-04-05 8:08
Haskell, in the light of Nomads.
Haskell language. However, I find that the Algorithmic Language Scheme is a much better language.Nomads, they are unscientific and ultimately destructive.
PutStrLn "hi" or hPutStr "GET / HTTP/1.1\r\n" or launchMissiles is a bit silly. You can write imperative code. map), I, personally, would write most of my code in a pure and functional way. (Indeed, most of the CPU time of Haskell programs is in pure functions. Unless you're working with OpenGL, most of your program will be pure code.) This would lead me to conclude that the language should be pure by default. f is changed from pure to impure, then map f l must be changed to mapM f l and h $ g $ f x to f x >>= liftM (h . g) (I think), of course propagating upwards. Ideally they could just stay the same, which is exactly what imperative by default achieves. Maybe 'composable monad by default' will do this too, but then what's the difference?mapM, when, etc).length . map to length).private Foo and pure Bar().IO a -- can do any IO effects, including STM effects. STM a can only do STM effects (read/write/create TVars). From these types we can see exactly what side-effects can occur. We might, for some reason, create a Socket a type and monad, which can perform socket input/output, but no file IO. Or a GUI a type, where GUI effects like makeWindow and setWindowTitle can be performed thread-safely, based on STM (and thus they are composable).trace to print something to stdout from a pure function using unsafePerformIO, for those cases where you need to print things out, but that is besides the point. Besides the fact that using trace produces unexpected results due to laziness, using printf-style debugging is not really my favourite kind. I'll digress here; I want to say a little bit about how I debug my Haskell programs. I admit, I started doing this when I first learned Haskell. I'd be printing debug values out so I could fix problems, because you need to see how the function interacts with the state of the real program, right? But I realised a much more elegant approach is to have a few functions which construct a state for me, and then run my program inside GHCi, and then I can test these functions from the prompt myself and inspect the results. Infact, I did this for all functions I'd written, so I knew that these functions were working as I wanted them to, because I could test them as they would run in the real thing -- with a state, and this is the advantage of passing state around (through function arguments or via monads). Of course, some functions can be tested like that with QuickCheck, too.