What is a Multiton? It is a multiple Singleton. Below I have a Multion for some random primes of a given length, but it might as well be some config data you read from a named DB connection, etc.

Some say that the Multiton is an antipattern (shrug), but it is widely used, here my high performance implementation. It uses a IODH variant - note that the classic IODH cannot work for Multitons as the holder there - even if the Wikipedia article mentions this. The IODH relies on the fact that the (singleton) instance is bound to the class that holds it. As a class can bei initialized only a single time, this works for a Singleton, but not for a Multiton.

The following code is designed for a quite expensive creation where the instances are queried very frequently.

public class Multiton {

	private interface MHolder {
		Multiton m();
	}
	private static final ConcurrentHashMap instances
		= new ConcurrentHashMap();

	public BigInteger primeForLength;

	public Multiton(int key) {
		primeForLength=BigInteger.probablePrime(key, new Random());
	}

	public static final Multiton get(final int key) {
		MHolder m = instances.get(key); // most of the time we should have it already, no locking
		if (m==null){
			m = new MHolder(){
				/**
				 * might be contended if same instance is requested during computation
				 */
				public synchronized Multiton m(){
					final Multiton m = new Multiton(key);
					MHolder mh = new MHolder(){
						@Override
						public Multiton m() {
							return m;
						}
					};
					// replace with simple holder after value is computed
					instances.put(key, mh);
					return m;
				}
			};
			MHolder mh = instances.putIfAbsent(key, m);
			if (mh!=null) m=mh; // race occurred
		}

		return m.m(); // now the expensive creation is outside the synchronized block
	}

}

The key for performance in parallel system lies in the reduction of contended locking. Here we have two locking points:

• putIfAbsent - only locks a segment, thus most parallel creation will not be affected
• synchronized Multiton m()

The later is the interesting one: As the creation is slow m() might be called in parallel, here we have our IODH pattern. Instead of relying on the synchronization of the classloader we sync the object. To avoid unnecessary synchonization the holder gets replaced by a non-synchronized one which returns that same value.

Monads are usually associated with being something highly theoretical that nobody really understands - unless you either worked with category theory or came to Haskell via another route. An elephant in some sense - big grey matter…

James Iry provides a Monad introduction for Scala programmers, he leaves out most of the what a monad is, but explains more pragmatically what the qualities of monads are. So far part 1, 2, 3 and 4 (of a series of 5?) are available on his blog.

Give it a read, you might learn that you had been already using monads without knowing and why this perfectly nice Java code is hard to understand for other programmers. If this is the case give this intro to those programmers, in any other case learn it yourself.

(updated 15.11.2007)

Already a bit late hour, but after a nice couscous some things become clearer.

Currently I feel quite a pressure. After more than 12 years in this monkey business I have learned to ignore it - “people under pressure won’t think faster” (oracle@lister.com)

What was more important is a sudden shift of my manager. He became quite nitty-gritty and micro-manages some developers (we have “team-leaders” for that:-). This means the pressure he feels must be enormous.

I had been completing two important functions in the last days - both had been properly prepared and well - though not formally - specified. Implementing them had been easy. Two issue of highest priority and severeness resolved. Normally something that makes a manager’s face shine.

But a bit to my surprise he had been mildly angry with me. His point was that working on another issue was more important as the testing was more complicated. During the afternoon I grabbed together what was going on. It is true that we don’t even have a plan to test it, three parties are involved in the development, the specification is vague as the functional architect hasn’t barely any knowledge about the underlying technology. To make it worse the three parties work completely disconnected have not even a process to synchronize their work using a common code repository (each part is build and deployed independently!). I have advanced my work to everything that can be tested at the moment and I was reluctant to write anything that is either untestable of would stop me from completing over parts. Instinctively I stopped working on the project and turned to something more fruitful.

I had been chewing all evening long if I had been acting correctly. What had been the alternative? Instead of providing real value I had been writing junk code, perhaps got lost in an architectural beauty that just camouflaged my lack of understanding of the problem - I know myself: When I start to think deeply about a design, despite my experience, it is a warning sign that I actually didn’t understand the problem and try to build something very general that can be turned into the right thing or even anything in the last minute. Useless to mention that these attempt fail sufficiently often and with all the time consumed for these over-engineered solutions such an approach it ridiculously inefficient.

Question is now: Can we savely say that we should focus on the parts that are thoroughly understood and postpone everything else, or at least put the least understood at the back of the queue? This would be a radical approach to priority management, but it falls in line with some “truths” we have learned to accept:

1. Don’t start coding until you have the complete spec (from the waterfall processes)
2. Every function must have a provable business value. (the XP stuff)

Truth 1 is rarely fulfiled, but if you accept it: a problem you don’t understand is perhaps poorly specified. For Truth 2 it is easier: How can you prove business value if you don’t understand what you are talking about.

My stance therefore is: Do what you really can do

Scala is now again capable to compile to IL-code so that you can use it from a .NET program!This feature vanished a while ago as the compiler got overhauled and now it is back - according to Martin Odersky, the main figure behind Scala “There are some known problems with exceptions, which we might be able to solve soon.” - but still, the best thing since sliced bread.Here is how to do it (get your paths properly set!):

1. Get Scala (JVM >1.4.2 needs to be installed)
2. Install the MSIL package with “sbaz install scala-msil”
3. Compile your  scala files with “scalac-net  <files>”
4. Build  a dll from them with  “ilasm /DLL  yourfiles.msil”  (use /EXE if you have a main method to get an executable)
5. Reference the dll from you .NET project

You can also use .NET libraries from Scala code, for the compilation you have to add the referenced DLLs with the parameter -Xassem-path First.dll;Second.Dll to the scalac-net commandNot so difficult and with some scripts pretty quick to integrate. Of course it will not work to use scala classes that  reference java libraries! Neither will you be able to run (not even compile) scala classes that use external DLLs - unless you want to dive into the JNI hell. A compile switch that warns of “unpure code” to the Scala compiler would be helpful here (Something I should ask for, hopefully I won’t forget).The limitations are not such a problem, the main goal is having a modern language (that is even more powerful than C#, more modern than Java 7 with all discussed extensions) to implement business function that can be directly used on both platforms is a huge win. I am curios what nice libraries will be published for the use on both platforms - distributed as a DLL for .NET or a simple JAR for Java environments.

From time to time I re-read two books: The Deadline and The Soul of a new Machine. They both are a sanity check to me and to what is going on around me. Both are in a novel form that makes them also a bit fun to read. This night I picked up again The Deadline, went to my favorite brasserie for some dinner an wine, I flipped through the pages and started reading somewhere in the middle.

Fine grained design (sorry I have only the German translation)

The key statement was that you can move quicker if you spend less less time on debugging. This is undoubtedly true I think, but their remedy is something I ever disliked: Fine-grained designed where you try to verify before starting coding . I never liked theses design documents for a simple reason: They spend lots of pages on the obvious to hide the sloppiness of what is poorly (if at all) understood. When verifying it you spend much time on the obvious and happily overlook the parts that aren’t well defined, as they can’t be that important – otherwise the author(s) would have spend more space on it, haven’t they? When implementing it, you’ll get the 90% syndrome: ask the developer after about half of the estimated time how far he got and he will answer “90% completed” - problem is – these ten percent will stay around forever, after 200% of the estimated time the programmer (now with tired eyes and a bad shave) will still tell “about 90% done”.

Short, I believe the only true design is the code (“The system is fully documented – granted you can read C++“- Z.Köntös), but of course not any code, it has to be expressive. In C days a basic design had been made from documented header files, in Java you create interfaces or if someone pays you to do so you’ll sketch endless variations of UML diagrams. UML is believed to be a superset of what you can code – given a smart generator it transforms your design into code where “you just have to fill the gaps” and changes to the design in the code “can be reverse-engineered”, NOT. There are some cases where certain diagrams are really useful to get you an overview of a project, but all examples I know fall in two categories:

1. Reverse engineered and handcrafted for better readability

2. Metacode that is feed into interpreters and MDD tools

If we have to accept that the design and the code have nothing in common, why not simply skipping this stage. 20 years ago this hadn’t been a proposition. But it is not true anymore. Modern languages and IDEs provide browsing and refactoring or mix in mechanisms that make the design malleable even if it it is (already) in code. With C and COBOL it might be possible as well, but it hadn’t been possible in their time. This means that your design process is less a constant than perhaps the design! If we accept this the consequences for the work are huge: If you use a language that is capable of expressing your design, it is idiotic to use a design tool outside to describe it. You’ll break your neck to describe in prose or diagrams what is a common idiom in your language (…API, DSL) – only to end up with something that is weaker than the code you have written. And this is the crucial point: Design tools and generators assume that their representation is complete, as any generator can only loose information – if your code is more expressive the generation and the reverse engineering of code cannot work at all. If you are inclined to follow, beware of the caveat: If your language is expressive enough, but you don’t use it appropriately the representation of you design will stay incomplete and you might need additional documentation - or better (but fewer) programmers.

You can use an expressive language to get around formal design, what do you get:

1. Instead of an intermediate layer, you have something you can work with

2. Your design is as live as the code is – any refactoring updates your documentation

But back to the claim of DeMarco’s book. It is is indeed still that verification of the design saves debugging, but that doesn’t mean that the design has to be made in another medium than the code. I came to this during my recent experiences learning Scala. I wrote some pretty complicated stuff and went naturally a bit wild with some feature of the language, but I noted one thing: I spend very little time on debugging (one thing I wrote was a specialized implementation of nauty). The language forced me to (or perhaps I did myself as I wanted to learn as much as possible from my examples) express concisely what I want to do. And as the language allows you to be extremely type-hard in your code it actually enabled me to do so. I also discovered that I wrote code that tended to be more declarative to avoid debugging into deeply nested list comprehensions. This topped even the positive experience I had years ago starting using Java, which I found pretty crippled as a language coming from C++.

One of my famous war stories is that I once wrote 400 lines of C++ on a single afternoon that compiled with no errors and also worked as I intended. I never managed to do it again. It was pretty convoluted code (technically a small interpreter) and I never managed to the same in another language I know very well: PL/SQL. And I have also Java code that has a complexity below those 400 lines C++ where I think that I’ll never be able to get them to work correctly.

So what is the key difference? Abstractions. Scala makes it easy to build abstractions, also because you get instantly rewarded by it, C++ as a very flexible language allows it also (though it is much harder), Java knows abstractions in form of APIs and frameworks – but this doesn’t help you as soon you are getting into region far from the API and your framework. These abstractions can be called DSLs, you shape your environment to you needs, perhaps even in multiple layers. In C++ operator overloading has been the too for that, in Java frameworks and APIs (quite clumsy in terms of syntax) where in Scala the difference between operators and methods dissolves completely ( as does the difference between a block and a parameter; and the extractors as antonyms to constructors). My C++ example was btw a good example of abstractions, many classes, few methods with am orthogonal interaction – such code either works or can’t be written at all. Making good abstrations in PL/SQL is as in Java on API-level.

Where is the dynamic world?

As much as I share the thoughts of Paul Graham, I can’t relate to his indissented preference for dynamic typing; there he is missing the point. Yes, malleable code is important, by if you have to keep track of each instance you might reinterpret it will likely blow your mind. I think he meant that you are coding DRY (Don’t Repeat Yourself), something that can be done perfectly (not that hacking style that is considered as expert Ruby) in Lisp (if you know macros!). Static languages can offer you the same comfort without resorting too often to macros (hard to implement in any language with syntax – Lisp doesn’t have any that’s why it is the only language having this feature) if you have type inference as well (Scala, C# 3.0). If you need to change a type, do it, the program will follow, but the compiler will shout at you if you crossed the line. This makes it even possible for others to change you program, because they get a quick feedback when they do something your initial design didn’t foresee.

The others

How is most software written today? Unfortunately with the methods of the 70’s and the tools of the 80’s (if at all). Even if they happen to use a technology of the 90’s, the methods are the old ones and the code will not exploit what is possible, but what is in the line what the environment gives you. In summary: You have a spotty design, verbose inexpressive code (“it is simple everyone can write it” – “if you have some dozens of programmers in India”) and exploding budgets and/or disgruntled customers. Poorly understood design leads to missing/faulty features, correcting these in a mess of thousands of lines of indistinguishable rubbish slows you down; the actual development moves to the debugging stage (if you are still lucky with a customer a beta(?) tester) – I call this “debugging into existence”. Even if development is always trail and error - debugging is different: When you discover a misconception during development, you go and update the spec – in debugging, the only trace will be a “resolved” in the bug database, more over debugging should fix issues and mustn’t create new ones, thus most people that correct bugs, correct them as locally as they can, even for the price of copy&paste code and compromised architecture.

First of all I am not for removing checked exceptions from the language. Quite often I am annoyed by them, but that doesn’t mean that we should pour the baby with the bath.

The problem

The classic is Method.invoke(). This method declares five checked exceptions, but when you are using checked exceptions seriously you’ll get situations like that all over where you can’t deal with the exception and it gets just rethrown as

throw new MyRuntimeException(e);

If all catch blocks look the same you should rethink the exception handling strategy in your, but if not - read on.

There are good reasons why not declaring all possible exceptions in all using methods, the most obvious is that this ripples through your code (I assume you IDE can automatically add/remove the necessary throws while editing) and in a large project this will create constantly problems with merging versions. More severe is that the exceptions leak implementation details, thus the standard technique is wrapping exceptions into types declared by your API.

Catch annotations

What about injecting the exception handling where you need it? (Remark:The annotations might not be the right way of doing it, but for illustrating the idea it is good enough)

@catch(ex=CheckedException.class)
void myMethod() {

do();//throws CheckedException

}

The annotation has the effect of wrapping each statement that declares CheckedException into

try {

do();

} catch(CheckedException ce) {

throw new RuntimeException(ce);

}

This covers perhaps 60% of the bogus catches in an environment that uses checked exceptions heavily, another annotation

@cast(ex=CheckedException.class, to=MyRuntimeException.class)

covers most of the remaining cases by assigning a target exception to the type to be caught. if we allow to have multiple annotations for a method.

@cast(ex=SQLException.class, to=MyRuntimeException.class) //throw MyRuntimes for all SQL ex.
@catch(Exception.class) // throw the rest as RuntimeException
void myMethod()

Further ideas

• The annotation should be allowed also at class level for having a better structured exception strategy.
• Class-level annotations are (overridable) inherited to the methods
• The target exception needs not to be a RuntimeException

Der Safari Browser ist nun - in einer Beta Version - auch für Windows verfügbar. Schnell ist das Biest wirklich - Kompatibilität ist OK.

Ich habe einen neuen Lieblingsbrowser.

Die Beta ist noch nicht lokalisiert - was mich weniger stört.

Hoffentlich wird die WebKit API bald auch für Windows verfügbar sein. Idealerweise auch als API für Java, wie es Apple schon mit Quicktime gezeigt hat.

After playing with implicit anon function I came up with the following useful extension to Tuple, here the new method for Tuple2 :

def apply[R] (fn : Function2[T1,T2,R]) = fn(_1,_2);

This allows the following to write very easily:

def add(a: Int, b:Int) = a+b;

val a = 1::2::3::Nil
// calling binary functions with implicit parameter of Tuple is not possible
val li246 = (a zip a){_(add)}
//nested implicit parameter - acts like an explode on Tuple
val liSquared = (a zip a){_{_*_} }

Perhaps this is best implemented on the Product traits.

What bothers me a bit is that there are now two equivalent ways of adding

(2,2)(add) and add(2,2)

Anyway, I think having a tuple and calling a function with this as parameter list is quite a common idiom. Really nice if this would also work for currying, have to check this

Why not adding this to Function2? I thought about (and tried it) and then decided otherwise:

1. It would weaken the typing, afterward it would be impossible for the compiler to tell if I was calling a Function1[Tuple2,R] or the Function2[T1,T2,R]
2. It gets very confusing for the parser, especially with the new uses of ‘_’ for impartial function evals and implicit args

I came across a 10-year old presentation on Java - less interestering, I flicked quickly over the pages, but this slide made me stop:

Object-Oriented Benefits
• Better software design
– different way of thinking about software
– software can more closely models real world problem being
addressed
– domain experts can more easily participate in initial software design
• Easier to maintain
– problems are easier to isolate
– changes are more localized
• Easier to extend
– easy to make extensions to existing functionality
• Less code to write
– more likely to reuse code from other applications
– more likely to find commercial code (class libraries) that can be
used for portions of an application 

I think this is a good writeup of the alleged advantages and capabilities of OO from the time where OO was not yet 100% mainstream.  Did this live up in reality? I doubt that. The tend towards (or back to) more functional languages seems to be an indication. The more I hit the limits in Java the more I find myself imitating functional programming techniques in Java code - rarely pretty code you get by doing that. Irony or just the prove that be all keep learning: The author from the presentation cited above is now touring whith some JRuby slides

A nice looking clock in JavaFX reveals that transforming images in JFX still needs some work. But luckily SVG is rather easy to use, some small change to the script and you get this:

Note the second hand in comparision to the others.

The script-change:

var secondHand = Path {stroke: red, fill:new Color(0xDF, 0x0E, 0x08, 0xFF)
transform: bind rotate(t.seconds * 6,255,245)
d:[
MoveTo {x: 250, y: 300},
LineTo {x: 260, y: 300},
LineTo {x: 255, y: 50},
ClosePath {}
]
}