McDonalds has shipped a new McFlurry with the taste “Strawberry Surprise”. I had a recent opportunity to try one out and the results… well, it could be better, and it could be worse.

Firstly, on the plus side: The McFlurry Strawberry Surprise is a McFlurry. This means that it derives a lot of its fame from the preceding line of excellent tastes. It is a blend of strawberries, chocolate and ice-cream in a small, comfortable package, and that is never wrong.

However, the overall impression of it is not immediately appealing: It is messy. Unbelievably messy. The chocolate and the strawberries are blended together, not lightly, but so to the extent that it is downright sloppy. The strawberries are frozen and once in the mix start to melt, and that makes it even sloppier. Furthermore, the chocolate and strawberries compete with each other, not complementing each other as you would expect. The result is less surprising and more bewildering.

After some consideration, I’m not sure whether to give it 2 or 3 points out of 5 possible. It sort of leans on a 2+ or 3-, trying to be good but not quite reaching there.

In the end, the name McFlurry saves it. It gets 3 out of 5 points, but I’ll be watching it for improvement.

Tetelestai is a greek word meaning, literally, “it is finished”.

It is not without a sense of achievement that I now have finished reading all six volumes of Churchill’s memoirs. In a way, it feels as though I have myself been a witness to all the workings and dealings of the British Government during the fateful years of 1939-1945. I have been a close follower of the agony of the War Office in containing the U-boat threat in the Atlantic; I have seen the Home Guard prepare for defence in their homeland; and I have partaken in the efforts of Generals Alexander, Montgomery, Wavell and many more in battles all over the world. I have followed military engagements in France, Belgium and the Netherlands; from there over to North Africa including Egypt, Tunis, Morocco, Syria, Jordan, Iraq; and then Hong Kong, Singapore, the Dutch Indies and Burma; from there far over the raging seas of the Indian Ocean, the Pacific, the Atlantic, the North Sea and the Mediterranean. And then back to England and France again, the liberation of Europe, and Germany and Japan itself.

“It is finished”, then, may very well have been something that the victors of World War II said to themselves. When Churchill, Stalin and Truman stood in the heap and rubble of Potsdam in 1945, they may have looked out over defeated Germany and rested on their achievements, proclaiming peace and goodwill to man in the future. Unfortunately, it was not to be so, for now an iron curtain descended over Europe, and tore her in two; one with free and newly liberated nations; and the other under a new form of oppression – communism.

And for the next fifty years, Moscow would rule with an iron fist not only over the land of the Rodina, but over Poland, Hungary, Czechoslovakia, East Germany, Roumania and many other nations trapped by the Red Army’s advancing forces. They would continue to pay their penalties and dues from the war in full, under the oppression of their own puppet dictators, disguised in the form of communist party doctrine.

Being Swedish, it is difficult to imagine that so little of Europe and the world has been able to live in times of peace and liberty. For uncertain reasons (and I glance with remorseful eyes towards the Finnish border), Sweden has been spared the heavy blows of war for nearly 200 years. It is a cherished mercy to be able to grow up without war. Nevertheless, war will come, sooner or later, in this fallen world. I hope we may be ready to rise to our duties, when our time will come, and accomplish them with as much grace and dignity as did the British and Americans, in those days.

I just recently came upon a page devoted to introducing functional languages. Functional languages is an interesting concept since it approaches software development from a radically different angle. It focuses heavily on functions and immutability (in everything!). In some aspects it really shines when you understand it.

Erlang is a functional language developed by Swedish telecommunications giant Ericsson. It has a few nifty features and is reportedly used in some large-scale operations in live systems. It’s primitives and functional style makes it a breeze to unit test and debug. “While Java is scalable and stable, Erlang is rock-solid.”

One thing really stood out. It’s super-easy to create processes in Erlang, and it’s super-easy to communicate between processes. Using a simple spawn() statement on a function name, you just created a new process: (forgive me any syntax errors, I just started learning it)

% this is the 'doSomething' function
doSomething() ->
    io:print("I'm doing something now.\\n").

% now call the function
doSomething(),

% now call the function asynchronously
spawn(module, doSomething, []).

Now, this asynchronous call – is it a new thread, or a new process? What’s the difference? Well, threads tend to share data within a process, while processes don’t share data. In Erlang, no data is sharable. So it makes no difference.

And if we, perchance, wanted to send a message to a different process? That’s easy:

% this is the server process
server() ->
    receive
        finish ->
            io:print("I'm finished!\\n").
        message ->
            io:print("I got a message!\\n"),
            server()
    end.

% this is our client process
client() ->
    Server = spawn(module, server, []),
    Server ! message,
    Server ! finished.

What happen? Someone set us up the server! Well, actually, client() set us up the server. What happens is that the client() call first invokes spawn() on the server function. server() happily goes into play, waiting for a message. The client then sends two messages to the server process, one “message” message and one “finished” message. The server call traps the first one, printing out “I got a message”, and then restarts the server process. Then the “finished” message is trapped, the server prints “I’m finished”, and with nothing more to do, it exits.

How is that for super-easy?

I’m thinking of the Nav service (“Hub service”, technically) that we used for intra-process communication at my last job. Communication between processes worked rather efficiently, but with certain amount of hassle. Each process logged in, registered itself, waited for and sent messages. With Erlang, that whole part could have been rationalized down to a few lines of code.

Now I’ll just see if I can build a process-and-messaging API that is somewhat as efficient as this in Delphi … before my benevolent Java friends alert me to the fact that this already exists in Java. Most likely.

I’ve spent the last few days coming to grips with this huge, enormous system written in C++.

The more I see of it, the more I’m thinking that C++ is the new COBOL. It worked well during the time of its glory days, but now it’s old, it’s cumbersome, and all of the new features that are being implemented in languages like Delphi, C# or Java, takes years and horrible coding practices to implement in C++.

This current project has classes for everything. It has classes for strings, datetime objects, timestamps, windows, edit controls, everything. Even a scripting language. It is an enormous mass of code built over the years, and the funny thing is that – as time has passed by – most of these classes are now superbly implemented by frameworks such as the .NET libraries, or open source alternatives. At my last job, we built powerful scripting abilities into our products by simply writing a few extensions to an already existing framework called DelphiWebScript, or DWS for short. Unfortunately, it doesn’t seem to be too much maintained any longer, but it works fantastic.

In short, my knees falter and my hands tremble when I see the effort that went into this system, and how much of this effort that could today be replaced by snap-in components.

The world of programming has changed enormously over the past fifteen years. Admittingly, the leap from COBOL to C++ was greater than the next leap from C++ to C#, but it’s a shift of paradigm that cannot be underestimated. Assemblies, interfaces, properties, single inheritence and reflection are but a few of the mechanisms that have ushered in this new paradigm, much thanks to languages like Java or Delphi that has ruthlessly sought to abstract away the ugly details of behind-the-scenes implementations.

In an interesting parallell, pilots in those good, old F-16’s would spend about 70% of their time in the air focused on actually flying the plane, and the remaining 30% would go towards the mission they were carrying out. Fourth-generation fighter planes (like the Swedish JAS-39 Gripen) enable the pilot – as I have heard – to reverse those figures: Flying the plane got so much easier that only 30% of the time now goes into flying. The technological leap from the third to the fourth generation of fighters has marvelously increased the pilots efficiency in the air. No reference to the ugly 4GL term intended (which had everything to do with software like Paradox or Access), the leap from C++ to C# enables the developer to focus on the business end of the implementation, and not about the intricacies of the language itself. The result is cleaner code, and cleaner code is also easier to read.

My hope is that C++, as soon as possible, will be relegated to the ancient software language shelf currently occupied by COBOL and FORTRAN. Few will miss it (and I take no objection if those who actually do miss it, also end up sitting on that particular shelf).

Today was the first day at my new job.

It’s always a little special, those first few hours of the new job. It’s new people, new environments, new languages… A lot of things to learn, and a lot of things to become familiar with very quickly.

C++ is a very different environment from Delphi. I guess everyone starts building their own tools and add-ons after a while, adapting the platform to their particular needs. We did so with Delphi, and my new employer has done so with C++. Some solutions feel rather old; and I can see why they’re pondering the future, about which way to go. On the other hand, it’s a big system with lots of years of development, so it won’t be easy to change everything overnight, should they do so.

So far I’m gathering impressions, getting to know people, finding my way about things. I cannot hide the fact that I miss my old colleagues, some very much. But then again, I’m already thinking about how some solutions could be improved. I’m not sure how this large organization works though, in comparison to a small one, where you have near-total responsibility for entire products. It feels more hierarchical. Very neatly organized. Lots of information in the right place. But does increased structure also mean less liberty? I’ll find out, for sure.

We just watched a series of presentations from Microsoft’s Live Communications Server 2005.

Microsoft must be the world champion in buzzword bingo. Any product, any product, that Microsoft releases promises “increased uptime”, “increased availability” and “enhanced scalability” while “improving performance” and “enabling communication”. If the program doesn’t “enable workflow efficiency”, it “empowers decision-making” or “increases vision”.

In fact, I would love to see a product that actually doesn’t “increase efficiency”. If Microsoft ever launched a product with the market ad saying “this product does not make you smarter, more efficient, scalable, available and resourceful. It just helps you write documents”, I’d be the first to buy it.

Many, many other companies adhere to the same philosophy. I spent repeated attempts to figure out what Borland StarTeam was by reading their white papers. I still don’t know what it does, actually – I never found that out. All I know is that it makes me “more efficient”, and apparently it helps me “increase workflow communication and participation”. I’m pretty sure that goes for Notepad too, if you think about it.

I wonder if there is a part of the world’s population – maybe somewhere up in higher management – that actually reads these white-papers and watches these presentations; and buys into them. “Oh, this program makes our department more efficient. I’ll buy it.”

What if most Fortune 500 companies are like that? Now there’s a scary thought.

After at least a year and a half of reading Churchill’s memoirs from the World War II, I have now come to the end of the fifth book. It is the 5th of June 1944. This night, some 160.000 soldiers will cross the English Channel by sea and by air. Airborne soldiers will jump over various parts of Normandy, to clear the way for the main invasion at 0600 hours tomorrow morning.

The ships are already on their way. The airplanes are already on their runways, preparing for the takeoff. The largest invasion ever seen throughout the history of man is beginning. Over the next 60 days, over 1.900.000 allied soldiers will be transported into battle in northern France, to spell out the doom of Nazi Germany forever.

These are good times. The Russians are already standing at the Polish borders. Crimea is freed, Leningrad saved. Rome has just fallen to the allies, North Africa is since long secure. Japan has been beaten back step by step from its far-reaching grasp and is recoiling in its home islands. Now “Festung Europa”, Adolf Hitler’s prized possession, is ready to give way.

Soldiers, Sailors and Airmen of the Allied Expeditionary Force!

You are about to embark upon the Great Crusade, toward which we have
striven these many months. The eyes of the world are upon you. The
hopes and prayers of liberty-loving people everywhere march with you.
In company with our brave Allies and brothers-in-arms on
other Fronts, you will bring about the destruction of the German war
machine, the elimination of Nazi tyranny over the oppressed peoples of
Europe, and security for ourselves in a free world [...]

Good luck! And let us beseech the blessing of Almighty God upon this great
and noble undertaking.

Signed, Dwight D. Eisenhower.

I wrote this poem many years ago. I thought I might post it here.

In a dark and gloomy dungeon
Racked by storms and thunder
A valiant server stood on guard
As lightning ripped the night asunder.
It stood there lonesome and forlorn
Working quietly in the freezing cold
But not a tear was seen
On its faithful color screen
This server had a heart of gold.

In its core a dignified processor worked
Although old, still bravely faithful
And though its software wasn’t new
Its owners still were very grateful.
It flawlessly performed, both day and night
It ticked so quietly, so gracefully and bright
A thousand users everywhere
Put the server’s idle time on hold
But no one knew the server’s heart
Yes, this server had a heart of gold.

Deep down in this server’s brittle chips
A stable, very stable kernel ran.
And through thick cables proceeding forth
It quietly communicated on the WAN.
Hundreds of transactions were processed
On the company’s intra-network site.
But the only evidence of work there was
Was a little light that gently flickered in the night.

And although many years had passed
And newer systems came and went
And elaborate technologies passed by
ODBC, DCOM, Windows and Lucent
Still they just failed and failed and failed
And came nowhere near this server’s unique mold
Of faithful trust and tender hope
Buried in this server’s gentle heart of gold.
Yes, this server had been working quite a while
And if it could be said it had a mind
Anyone who looked inside would find
That splendid willingness to “walk the extra mile”.

Then, one day, a strategic decision was made.
“Windows is the future. Old IBMs are not.”
So this server was sadly carried away
And replaced with something that was “hot”.
And the damp computer place was changed
Into nice, air-conditioned halls
With carpets, supervising systems
And thin fiber cables lined the walls.
And in the old computer’s place now there sat
An NT 5.0, spinning like a cat.

But soon enough, something happened
Users called and gleefully complained
Connections lost, memory faults all over
And a general confidence that waned.
Computers crashed, and deals weren’t met
And executives and computer guys began to fret.
Previously trusting users collapsed and cried
As their screens shone brightly blue
With exception faults and many, many GPFs…
It was a horrid nightmare now come true.

In the meantime, this old server sat
Now abandoned, so silent and forlorn.
Its kernel didn’t work. No lights were on.
It couldn’t even mourn.
The letters IBM, once bright and shining
And the cover, once so neat, with silver lining
From all its work so badly torn.
It now simply occupied the tiny space
Between a dead screen and an old computer case.

But then, as its tiny little chips gave up all hope
It finally was remembered.
An angry group of software engineers
Brought the NT system, now dismembered.
They threw the stupid thing against the wall
And took the old computer through the hall.
And accompanied by the staff’s wild cheer
On the old screen there appeared a little tear.
And as it was plugged in again,
Its systems flared to life once more
The BIOS booted, and the kernel started up
The old processes spread through its trusty core.

Then everything was back to normal.
Everything ran well again.
And all throughout the place, executives agreed
That new technology is just in vain.
That trusted systems should not be replaced,
Once it worked, it continually kept administrators amazed.
And deep down, in that old dungeon, now so bright
That used to be forgotten and so cold
There worked a valiant server,
And that server had a heart of gold.

Threading, as I’ve mentioned before, is hard. Especially in non-managed languages, such as Delphi for Win32.

Various people, including Allen Bauer, is thinking about how languages can be adapted to support thread-based development easier:

“This increases the need for the average developer to be become more adept at writing multi-threaded applications. What if the compiler and the libraries made this easier and more accessible? It is these kinds of questions we ask ourselves everyday…”

One way of doing it, I’m thinking, is to have the compiler automatically generate warnings or errors in certain cases. We’ve patched the ZeosLib library so different threads cannot access ZConnection objects created in other threads; the ZConnection objects keep track of thread ownership and refuse to work for other threads (unless manually overriden). This behavior causes exceptions to be thrown in this case, which is far more desirable than having access violations deep inside one’s code.

Just tossing ideas around, why not have certain attributes (I’m inspired by C#) that specify thread access? Like, for instance,

procedure TForm1.Log(const Text: string); mainthread;
begin
... main-thread code here ...
end;

Certain attributes might specify whether, like in this case, a method may only be accessed from a main thread; or with another attribute “threaded”, special vigilance may be required and certain patterns may be enforced by the compiler. A function marked as “thread-unsafe” may not be called from a “threaded” method without certain encapsulation or something.

I think there are lots of things that can be done. Delphi/Win32 right now is at the same level that C++ were with strings (back when C++ was actually used by people). It can be done, but it’s all manual, hard labor. Even few changes can yield significant returns.

Serialization is the process of taking an object, and streaming the contents of that object into a file, or communications channel, or any other form of media; and then rebuilding that object on the other side, so that it takes up the exact same representation as it did on the sender side. Think of it as a Star Trek teleportation device, but for data objects – the data objects being represenations of invoices, computer commands, telephone extensions or more complex forms of data.

Delphi has this for TComponent objects, but not for anything else. So I’ve had to build a complete serialization layer, using such fancy classes and interfaces such as ISerializable, TSerializeBuffer, TSerializeObjectHelperRTTI, TSerializeObjectHelperNoElements, TXmlInterfaceSerializer (which isn’t complete), all available through functions like SerializeObject, UnserializeObject and PeekSerializedClassName, through heavy use of variants and run-time type information.

To further agonize over this, this is but one part of the problem. We’re building server flashes into our system, meaning that a specific information-gathering part of our programs can run in three different ways: 1) through normal execution, 2) threaded execution to provide application responsiveness even though a task is executing, and 3) a server-based remote object call, placing the heavy burden on the server instead of the client.

I don’t know how this happened, but somehow, I find myself building a complete client/server-based remoting layer into a language that doesn’t have it; and interfacing that remoting layer with dynamic fail-over to local methods in case the link goes down.

Isn’t this what the wizards at Sun or Microsoft are supposed to be doing?