try { } catch blog

[this is the only religious post you will ever encounter on this blog] After an excessive amount of thinking, reading and weighting pros and cons I came to the final conclusion that actually and deep down in me, I beleive that 1. God exists 2. Christianity makes sense Many, many arguments exits against 1 and also 2. But as soon as you accept 1. arguing against 2 becomes really hard. All objections brought into field against 2. failed to convince me finally; ok some of them convinced me at first, and it took years to find out that they were errornous. Many objections seem clever at first, but really contain discrepancies or stem from pure ignorance. Most of those uttering them, do not really reflect these objections very well. A nice example is the following "objection" against 1. and partly 2.: "If god was almighty, could he create a stone so heavy, that he can't lift it?" It takes a bit of thinking, but is actually easy to debilitate. I will leave that as an ex

Code like that: blah(X) -> X1 = f(X), X2 = g(X1), X3 = h(X2), i(X3). is very error prone, and worse very hard to extend. Just adding another function application between f(X) and g(X1) requires you to alter all lines upto the end of the function: blah(X) -> X1 = f(X), X2 = j(X1) X3 = g(X2), X4 = h(X3), i(X4). This causes 2*numberoflinestoendoffunction potential error sources; And this is also not at all a very functional style. Why not rewriting it like this: blah(X) -> (chain([ f, g, h, i ]))(X). where one chains together the functions. Adding a function invocation in between is as easy as pie. chain(FunList) -> lists:foldl( fun combine/2, fun id/1, FunList). id(X) -> X. combine(F,G) -> RF = to_local_function(F), RG = to_local_function(G), fun(X) -> RF(RG(X)) end. to_local_function(F) -> case F of {FM, FF} -> F; _ when is_atom(F) -> {?MODULE, F} end. Anot

Lazy Evaluation and "undefined" I am on the road to being a haskell programmer, and it still is a long way to go. Yesterday I had some nice guys from #haskell explain to me lazy evaluation. Take a look at this code: Prelude> let x = undefined in "hello world" "hello world" Prelude> Because of Haskells lazyness, x will not be evaluated because it is not used, hence undefined will not be evaluated and no exception will occur. The evaluation of "undefined" will result in a runtime exception: Prelude> undefined *** Exception: Prelude.undefined Prelude> Strictness Strictness means that the result of a function is undefined, if one of the arguments, the function is applied to, is undefined. Classical programming languages are strict. The following example in Java will demonstrate this. When the programm is run, it will throw a RuntimeException, although the variable "evilX" is never actually used, strictness requires that all argu

{- Intro -} module BlogPostAnswer where import System.Environment {- This is haskell source code, which relates to a nice blog post of someone comparing java with python. Original post I picked some of the python-java comparisons from that post, which I would like to extend in order to contrast java and python with haskell. You can actually use the complete post as a haskell source code file. All prose is embedded in "{-" and "-}", wich are the block comment tokens in haskell syntax. I am a beginner haskell-hacker, and I dont have a clue about python, so enlighten me, if you spot a mistake. Like python, haskell allows you to use indenting as part of the syntax, unlike python however, you also have the choice of using "{", "}" and ";" instead of, or combined with, indentation. Also, like in python, and unlike java you don't need to put type declarations into you source code. The step from java to haskell is not the step from a static