Skip to main content


Showing posts from August, 2008

Got Religious

[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 exercise to t…

Erlang code snippet....

Code like that:

blah(X) ->
X1 = f(X),
X2 = g(X1),
X3 = h(X2),

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),

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) ->

where one chains together the functions. Adding a function invocation in between is as easy as pie.

chain(FunList) ->
fun combine/2,
fun id/1,

id(X) -> X.

combine(F,G) ->
RF = to_local_function(F),
RG = to_local_function(G),
fun(X) ->

to_local_function(F) ->
case F of
{FM, FF} -> F;
_ when is_atom(F) -> {?MODULE, F}

Another solution might be using the state m…

Lazy Evaluation(there be dragons and basement cats)

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"

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

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
arguments of a fu…


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 statically typed language