Michael Weber: Random Bits and Pieces

A Kart Pilot in Action

Yesterday, the Staff Club of CWI organized the annual Indoor Kart Racing Event at Race Planet Amsterdam.

I have never been to kart-racing before, but it turned out to be great fun! We did two heats. In the second I decided to forget that my vehicle has brakes, and unsurprisingly I did considerably better.

I will definitely attend the next race.

via Orbitz:
Many programmers insist on only having the flow of control in their function end at a single point. I got wondering for a few minutes if any languages enforce this style of programming. Then I realized. Erlang has no 'return' operator, so doesn't Erlang enforce this? That sounds about right as far as I can see. So an Erlang function can only have 1 exit point. That should make them feel good.

Well, I think the single exit point meme is related to structured programming discussions and articles like Dijkstra's GOTO Statement Considered Harmful. It's a quite extreme opinion with which I do not agree, at least not without further context.

For instance, consider the following two pseudo-code snippets:

fun f1(...) do
  if (...) then
    r := ...
  else if (...) then
    r := ...
    r := ...
  end if
  return ...
end fun

fun f2(...) do
  if (...) then
    return ...
  else if (...) then
    return ...
    return ...
  end if
end fun

Why is one better than the other (as postulated by the single-exit metric)?

Or, by extending this line of thought, if my language permits GOTOs I could even trivially transform every multi-exit program into a single-exit program. Why would this be better?

In contrast, having deeply nested or page-long conditionals is neither desirable. They can be avoided with multiple exits, for example (as well, or even better with refactoring, admittedly).

Another useful case of multiple exits is the simulation of contracts in a language which does not support them natively. Often, I write functions introducing data from the "outside" which look like this:

fun contract_example(...) do
  if (!check1) return ... end if
  if (!check2) return ... end if
  return ...
end fun

In the context of functional programming languages, the debate usually does not come up, mostly because programming patterns are different. Recursion is used more often, but there a base case could be considered the moral equivalent of an exit point, when the recursion is not going one level deeper:

fun contract (...) when !check1 = ...
fun contract (...) when !check2 = ...
fun contract (...) = ...

Such code is often very nice to reason about with induction because the base cases stand out, but so do they in the examples I gave above.

In fact, striving for code which is easy to reason about might be one of the causes why buzz-phrases like no GOTOs, single-exit, etc., come up, and then cause a lot of confusion.

So, I guess my (unspectacular) conclusion is that you can write reason-able code with or without multiple exits and the single-exit metric is not meaningful in itself.

I do agree that code containing exits (return, exceptions, etc.) all over the place in an unstructured way should not be written, but the emphasis here is unstructured. The reason is clearly that it is hard to assess correctness of unstructured code, and correctness should be top priority.

Related discussions:

Book cover: The Art of the Metaobject Protocol

Kiczales, des Rivieres, Bobrow: The Art of the Metaobject Protocol (AMOP)

I have been reading AMOP for the past few days, and found it quite enlightening, even from a general object-oriented viewpoint. Now I am inclined to buy some extra copies and have them delivered to some AOP folks in the neighborhood (you know who you are! ;)).

Well, that, or I will try to understand why Gregor took off the AOP tangent, instead of continuing to evolve reflective capabilities of languages through defined protocols.

From my perspective, formal protocol design would have been the way to go, at least I would expect it to make my life not harder. With random code insertions at random places, AOP might scratch an immediate software engineering itch, but in the long run it will also be verification hell. Oh joy...

Almost 15 years ago, Barry Margolin wrote a review on AMOP, with which I quite agree:

Part I is the part that should be of most interest to OO programmers in general, as tour through the OO design process. In effect, the reader is watching over the shoulder of an expert OO designer in action. I don't know about most of you, but I learned most of what I know about good programming by sitting next to colleagues while they worked, or by making later modifications to their programs; there's no substitute to looking at good code, and having the programmer explain *why* it is written the way it is. This book does this.
And further on:

The description is good, but the extensive use of prose underscores a missing facet of most OO languages, including CLOS: formal protocol specifications. [...]
Maybe now that the CLOS designers have polished CLOS and reached a milestone in the MOP design, the next step should be a language for formally defining protocols.

Finally, it has a beautiful cover.

Funny aside, quoting Irina:

It should be forbidden that such [computer-related] books have such beautiful covers. It's misleading!

Visual Complexity

2005-10-30 :: /science

Visualization Example More visualization efforts for large data amounts.

via erlang-questions:

Kenneth Lundin writes:

Just to put an end on all speculations regarding multi-CPU aware Erlang I can reveal that we are working on a runtime system with multiple schedulers (running on different threads) which will take advantage of multi-CPU HW on operating systems which support that.

Previously, SMP hardware could be used with Erlang by starting as many Erlang nodes as there are processors available. This was already not too bad, as Erlang has transparent message passing support. SMP-Erlang just makes it a little bit easier up-front, as we don't have to decide on distributing processes to utilize our processors evenly (This advantage goes away of course, once we want to distribute processes over different machines). Also, messaging between threads on different processors might become a little cheaper.

All in all, excellent news!

Page 21/29: « 17 18 19 20 21 22 23 24 25 »