try { } catch blog

... macht euch bitte lustig. Ich selbst nehme mich schliesslich auch nicht so ernst, ausserdem bin ich (und werde es immer bleiben) ein Anfaenger. This is my zen.

My (and others who I infected) reaction to playing around with erlang, scheme and common lisp, was frustration. Not because these languages are bad, but because they are so nice and fun to programm with! One could even argue, that this alone results in reduced development time and better programms, but while this is definitely true, it hides the fact, that the afore mentioned languages increase efficiency of sw development also by technical means. To provide evidence for this hypothesis is out of the scope of this document, please look for yourself, there's plenty of good material about common lisp, scheme and erlang on the web, there are even life lisp coding videos on google video! I recently bought the new erlang book. It is great and I would recommend it without hesitation. There are also great books online that I started reading: htdp and sicp. Oh and not to forget to mention "little schemers" of wich the chapter about the Y-combinator is online ...(yeahh nice!) Now...

Ich habe da einen interessanten Artikel ueber das Blub Paradoxon gefunden. Jenes besagt, das fast alle Programmierer der These zustimmen, dass Programmiersprachen sich in ihrer "Macht" und Generalitaet unterscheiden, aber trotzdem nicht bereit sind einzusehen, das andere Programmierespachen besser sind als die, die sie habituell verwenden. Verdeutlicht wird das am Beispieln eines eingefleischten "Blub" Programmierers. "Blub" ist eine P.Sprache die im mittleren Bereich des Generalitaetskontinuums liegt, das sich zwischen Maschinencode an einem Ende - und Lisp am anderen Ende erstreckt. Der Blub Programmierer kennt alle Sprachen, die schwaecher als Blub sind, und fragt sich, wie man bloss ohne eine Feature "x" vernuenftig programmieren kann(- natuerlich verfuegt Blub ueber x). Ausserdem findet er, dass Blub alle Features hat die er braucht, und ihm erscheinen features in "hoeheren" Sprachen als verwirrend und unnoetig. Er denkt in Blub, u...

well it's been a while and I have come to trivial but usefull conclusions lately. Once I thought functional programming was fundamentaly diffrent then oo style programming, but I actually realized how well many aspects of fp match to elements of oop; Functions are simply Objects, Closures are anonymous class, certain design patterns ressemble monads(decorator, chain of reponsibility,...) oo style programming can be seen as a restricted variation of functional programming. That matters because the key aspects of oop is encapsulation and information hiding. This can easyly be achieved in fp through the use of closures and the fact that functions can be treated like any other data. In oop very explicit notations usually exists, wich couple certain functions to certain data through the notion of objects. Both, to increase readability of complex programms, and to lighten the restrictions that come with encapsulation, an explicit notion of inheritance is used. While all this seems pretty...

My Colleges and me are in the process of figureing out wich mock frameworks to use. One of my colleges has experiences with jMock and I have used diffrent versions of easymock. We wanted a detailed comparison to help us decide what the strengths and weaknesses are of the diffrent Mockframeworks. During a web search we discovered this comparison between jMock and Easymock. Although, regarding the authors background not necessarily, but to me most likely, this comparison of Jmock to an unspecified version of Easymock is biased towards jMock. Many diffrences/disadvantages in this comparison are obsoleted by more recent versions of Easymock, and speculating on the version used in favour of the author would imho result in 1.3 wich dates way back to 2005. The desription of the link to the jMock project on the easymock project page, states that jMock opposed to easymock uses another approach to define expectations that results in more flexibility to set expectations (you may specify almost e...

The longterm future in Webdevelopment is for sure associated with fading boundaries between systems that provide a service wich incorporates distributed knowledge to form new knowledge, wich it distributes, probably only to one client in a secure fashion. These boundaries are hard boundaries in terms of possible incompatibilities between interacting systems in heterogenous environment. We are confronted with securtiy issues, incompatibilies in protocol interpretations and service metadata propagation for automatic wiring of resources as opposed to hand crafted wiring as i.e. done with hyperlinks between dynamic system with a proprietary but similar structure, we are confronted wich diffrences on many layers of abstraction and orthogonal technical aspects like the necessesity to transform data not only to diffrent semiotic representationens but also to devices with diffrent availibility and diffrent means of human interaction. As diversity greatly increases, the call for unification and...

After a lot of meditation over efficient programming styles, some new ideas finally condensed in my defected mind: always underestimated is the emotional aspect of coding, in a team environment one must be able to critisize and be critizised; also bad code pisses me of so much, that it pulls down my overall productivity test driven development saves time, most of the time clear structure and good documentation helps, because maintainance will be nicer (see 1.) usefull integration testing is a far away dream, never to be reached in a pure XP manner including acceptance tests. jira is cool - combined with good ole paper on the wall does best. customer requests - the customer(or any other person not a freak) will not put sufficient details for a bug or a feature request into the bugtracker or be helplessly faced with a complex and flexible task of specifeing an issue, here improvements to the GUI to reduce complexity by providing more project specific defaults would be nice) wikis are use...