aporem.net

I found this post arguing that one can draw inspiration for writing code from poetry:

Poetry (…) is an abstract block of words in which every one must carry meaning if the poem is to be any good. We value the poem for the beauty not only of the story or image given, but of the way in which it is constructed as well. It tends to be much denser and more compact than prose. When you read it, you must proceed carefully and consider the meaning of each word, and each group of words, and pay attention for double meanings and allusions if you are to grasp it fully.

Fortran, the first higher level programming language turned 50 this year. It was created to let non-computer scientists formulate their problems in a more natural language than assembler code. Hence the name is an amalgamation of the term “formula translator”.

There has been a BBC Radio show observing the anniversary. And for the historically interested, there is an interview with John Backus, the team leader developing the first version from 1979. Telepolis has an article (in German) too.

Eight stories of how people got into Perl programming. Eight stories of highly successful hackers. Eight stories of what could have been about any other language but happens to be Perl.

Happy 20th anniversary Perl!

Larry Wall has written a post on scripting languages titled “Programming is Hard, Let’s Go Scripting…” in which he challenges the preconception that programming and scripting are different endeavors. As always Perl 6 is at the core of the message. And as always it’s worth reading.

So again the question about the best programming language was put up. This time for an aspiring 13-year old.

The answer given by Ned Batchelder is concise and in my opinion a great starting point not just for children. The main point is that there is no single best choice and that the language would be a means to an end and not an academic pursuit in itself. This is quite close to the general definition of a sound choice of a programming language and every developer should ask himself this question for every job at hand!

Testing, especially when doing test driven developement, is only effective if the tests cover 100% of the code, i.e. running all tests means all of the production code has been executed.

But coverage testing is not so easy as it seems. One can give simplistic examples which have 100% test coverage but still are buggy. The reason is simple: branching (and combination of paths) can produce a plethora of possibilities. But once every line of code is executed once, by definition, the coverage is 100%, although not every permutation has been tried.

An introduction to this topic can be found in Ned Batchelder’s blog, more at Wikipedia and here.

A roundup on the old struggle between too simple and too complicated development strategies: On the one side there are the quick fixes on the other the overly perfect designs. Obviously, these extremes are rarely reality but a constant threat to every project.

Keeping the design simplicistic means risking extensibility and maintainability. Even though it’s easy now, no one will remember the ad-hoc decisions made during coding.

The opposite extreme is over-engineering, the fiddling with the design to make it even more pluggable or extensible or use the newest patterns. Especially seasoned developers are prone to this behavior.

To counteract these extremes and in particular the second there is the “Make it Work First!” motto. It helps to get a first look and feel of the program while requiring to keep an eye on the ease of refactoring since the first version will have to be modified almost surely.

I like this very personal history of reverse engineering and the suggested test driven approach taken by S. Lott as a solution.

The idea is to extract an object structure from procedural code, cover it by unit tests to ensure its functionality and then take on the next piece of code. The question the author puts up, if this really is test driven in the strictest sense. I would not be this picky about it, since reverse engineering is a far more painstaking process than starting from scratch.

There are quite a few parallel programming environments around: MPI, OpenMP, Ct, HPF, TBB,Shmemm, Portals, ZPL, BSP, CHARM++, Cilk, NESL, PVM, Pthreads, mpC, Tstreams, GA, TPIE, UPC, Titanium, Parlog, Split-C …

This creates a problem of choice for programmers, where one can argue that less choice would be beneficial; that it would allow to focus on improving the remaining languages.

An other argument is that a new and hence “yet another” parallel programming language will solve the problem.

This alone is an example of the problem of choice.

I found this little game which tries to teach dragons to survive with genetic programming the assault of the player.

It’s not working as desired (the dragons don’t team up and chase the player) but this makes it even more interesting. There are several flaws in the setup:

• Genetic programming does not create complexity by and on itself. The less input/initial instructions you pass to your agents, the more thought has to go into the genetic (i.e. reproductional) part of the code.
• The rules must enforce an active behavior. In this case, running away from the player would be a very good option for the dragon, since it is not punished for running, only for getting killed.
• The calculation of the individual fitness has to be tailored to the problem. If a dragon is killed in the first few rounds because it was put right next to the knight, it is considered less fit than his peer at the other end of the game field.
• There is no possibility to learn form encounters with the player: if he strikes, the dragon is slain. The dragon can not come up with a strategy in this short time.

But hey, it’s a good place to start and experiment with the code.