Monthly Archives: October 2013

Todo-lists vs. the creative habit

Posted on by

It happened to me on several occasions that I mixed up todo-list style working mode and creativity working mode, although every single time I was convinced that I did things the right way. In order to boost my creative output I have put several creative items on my daily todo-list and hoped that somehow getting things done and creativity would magically match. Not so! What happened, in fact, was that while checking off my todo-items I would postpone the creative items on the list. They would be postponed to the next day and then to next and so on. Since I have scheduled different creative endeavors on different days, you might already guess what happened. I got my regular tasks done but all the creative items kept piling up. Looking at this pile did not really inspire me to do anything creative at all. In fact, it scared me off. To conclude, during these experiments I haven’t achieved anything creative at all.

In the meantime, however, I have come up with a different strategy to get my regular things done and increase my creative output as well.

Continue reading →

States and complexity in programming – why functional programming helps to improve your code

Posted on by

The human brain is very, very bad at keeping track of states. Especially for code maintenance states are hell, in particular if you are not the original author of the code, and even then. Even if there is ample and up to date documentation around, trying to understand states of a program is very difficult. States don’t match well to the way the human brain is thinking. Computers, however, excel at it. On the other hand, humans are quite good at abstracting functionality, finding commonalities and patterns as well as following an explicit program flow, in particular if the code uses telling function and variables names and generally a coherent coding convention. Abstraction and pattern recognition in code is something that computers don’t do really well at all.

A programming language should therefore reflect this observation and provide efficient tools to use this human ability. Functional programming is a thinking tool and programming philosophy that helps the natural tendencies of the brain to abstract. While functional programming can be applied in practically every language that supports functions (essentially every modern programming language), some languages try to provide suitable and expressive syntax that allow to move much further up on the abstraction scale whereas other languages, allow only elementary functional programming and make life for the programmer more difficult than necessary. Continue reading →

The essence of (functional) programming

Posted on by

Functional programming seems to be a hotly debated issue among some programmers. On the one side there are the more academic, computer sciency proponents, who claim that all programming should be functional, since it supposedly reduces bugs and you can reason about the program and do all kind of fancy formal proofs. These proponents also created several purely functional languages to show the world how awesome this way of programming is (including Miranda, OCamML and Haskell). On the other side there are the self-proclaimedly more pragmatic  programmers who bash functional programming as being unusable for any kind of reasonable work in the real world – work that is actually ending up being used by real users and not just as unintelligible papers in the ivory tower.

Who is right? I don’t know. I find the whole discussion moot, so I won’t try to take a side, since I both feel firmly grounded in the real programming world and still use concepts from the functional programming world.

For the sake of a better understanding what the whole thing, in my view, is about, I will introduce a different nomenclature for common programming terms. It was first used for APL-like languages and was introduced originally by Kenneth Iverson – a Turing award winner, best known for his contributions to mathematical notation and programming language theory. His paper Notation as a tool of thought  (Comm. ACM 23 (8): 444–465) is worth reading several times. Continue reading →