Jou ...

Abk. ist die Abk. für Abk.

Freudscher Verprogrammierer

Du weißt, dass es zu heiß in deinem Büro ist, wenn du dich beim Tippen von folgendem Code ertappst:

import java.util.logging.*

private final static sLogger = Nogger.getNogger(...);

Na, wo isser denn ???

In einem Kommentar im Otherblog hat Matthias gefragt, wo der Rover den gerade steckt.

Well, ich hatte eine Auszeit, in der ich mich mal von den ständigen ernsten Themen zurückgezogen und mich gezielt meinen Hobbies gewidmet habe.
Auch in dem Umfeld war ich schreiberisch aktiv und kreativ, aber da merkt man nunmal hier nicht viel von.

(D.h.: vielleicht verlinke ich hier bald mal was davon).

Bald wird es im Otherblog auch wieder weitergehen. Versprochen ;-) .

Der Geek am Abend ...

Wann weisst du, dass du dich zuviel mit Computern beschäftigst?

Wenn du das Wort "Hubschrauber" liest und es für einen Kosenamen für den Netzwerktechniker hältst!

Esoteric Programming Language: CopyNPaste

Well, there is just a good bunch of Esoteric Programming Languages on the market, some really serious (means: causing serious damage to your brain), some meant as a joke .

Sigh, would I have more time, I could contribute with an idea for a new one.

What makes modern PLs so successful? It is that they express common programming patterns and paradigms directly on the code level.
A good example is Scala, which incorporates e.g. the singleton pattern with the keyword 'object', or implicit getter/setter generation for a property (you find that in Groovy too).

And here is the new idea, here is one pattern which was never implemented on language level:
Copy and Paste.

Really, a such often used pattern, and no language designed for it ....

And it would be so easy!

Simply take a base language, say: Java.

There you could have a class with a method, say:

1  public class MyTest {
2     ...
3     public Collection doSomething(Collection input) {
4         Collection newcoll  = new  SomeCollectionType();
5         Iterator   iter =  input.iterator();
6         while (iter.hasNext()) {
7             Element elem = (Element) iter.next();
8             Object someNewElem = somethingReallyImpressingDoneWith( elem );
9             newcoll.add( someNewElem );
10        }
11    }
12 }

In Java, adding a new method which also iterates over its input, but does some other impressing stuff with the elements and does not return a collection would be very annoying. You would copy and paste the above method and change the parts which shall differ from the original version per hand.

But why doing it yourself if your computer can do it for you? So it would be much better to simply tell your computer what to do, and the best way is to make this an integral part of the language itsself.

So the job could be done very easy with CopyNPaste, a language based on Java, but with additional features:

1  public class MyTest {
2     ...
3     public Collection doSomething(Collection input) {
4         Collection newcoll  = new  SomeCollectionType();
5         Iterator   iter =  input.iterator();
6         while (iter.hasNext()) {
7             Element elem = (Element) iter.next();
8             Object someNewElem = somethingReallyImpressingDoneWith( elem );
9             newcoll.add( someNewElem );
10        }
11    }
12
13    paste:: copy(L:{3-11}) -> {
14              onLine(1): s/Collection/void/ s/doSomething/doSomeOtherThing/ ;
15              delLine(2);
16              delLine(6);
17              onLine(5): delChar({1-21}) ; s/thingReallyImpressing/OtherThing/ ;
18    }
19 }

It will indeed become more interesting if the second method will be used as template for a third one ...

The advantages are obvious: You have to think only once about the way the first method doSomething() shall work. Then you are free to concentrate on how the method doSomeOtherThing() differs from that method.
You are free to think in your copy and paste paradigm without leaving this context when doing the new coding.

Thinks can be so easy ...

Weisheit aus der Arbeitswelt

Schickte uns ein Kollege:

A train station is where trains stop.
A bus station is where busses stop.
A Work Station is where ...

How not to use static class members

Recently I came across a new experience which I consider a good example of "How not to use static class members".

Static class members are members (attributes and methods) which are shared between all instances of a class.

I.e.: If one instance changes the value of a static attribute, all other instances know this new value immediately.

Static members -particularly attributes- are shurely useful for configuration purposes, where all instances share a really really common knowledge with each other.

Static members are also indeed necessary for patterns like Singleton or Factory.

They are absolutely necessary to declare constants.

BUT: Static members are fatal if their usage include a runtime aspect.

I experienced that, when I inherited some code which extended the JUnit Framework to do validation on a loaded Model. Each validation was declared as test method of a so called "ValidationCase". As JUnit implicitly creates new instances for each test method to be called as test case.
So when running a specific test class, there are a bunch of instances of this class. For the validation now they had to share the model element to be tested.

The quick answer to this problem was: put it into a static member, all instances will know it then. Advantage: The location where these instances were created was inside the JUnit framework and didn't need to be touched.

BUT:
The error in this notion was: Not all instances of a test class share this model element. (As there are more model elements which are tested later and before by the same test class).

So the rule is: Only all instances of the test class which exist at a given time share this knowledge. At other times the share contains other information, shared by all instances actually existing then.

It worked well as long as only one model element was validated at a time.
The problem of this approach occured when once the validation system was extended to call a validation of one model element out of a validation of the other.

Now there were two groups of instances, one for element A, one for element B. But when B was under test, all instances shared the reference to B. And the reference to A was lost. Overwritten at a point in time.

Even this worked, as long as the validation of B happened to be the last action in the test of A, and the A reference was never needed afterwards.

But it was obvious that this card house once would collapse....

So: Everytime you introduce a static variable into a class, check carefully if its value is really valid for all instances of this class, even over time.
Avoid using static members out of well known pattern (like constants, Singleton, Factory ...).