Rad Studio XE3 video posted on Embarcadero's site.

This blog post is based on published information from Embarcadero only.

First, the "debut" video from their site:

My two top favorite things mentioned from this video:

1. Rad Studio XE3 supports the latest mac OS X (Mountain Lion) in Firemonkey 2 (FM2)

2. Rad Studio XE3 FM2 supports non-client area (fancy title bars) theming just like VCL Styles did for XE2.  A nice parity-feature for Firemonkey, and something that was actually making me not want to use firemonkey. Nice!

Exciting stuff, but perhaps less here than some people were hoping for. Stay tuned for more updates. I know that JT blogged at Embarcadero's blog site, about how some mobile features will be released after XE3 releases, perhaps as a separate product.  

There's also been a lot of hand-wringing about WinRT.  Personally I am about as interested in WinRT as I am in .Net, Silverlight, and WPF, which is zero.   They're about as interesting to me as the JVM, which is, "yeah, that works, fine, but it's boring".  The world I like is the native code world.  It's fast, and it doesn't depend on gargantuan binary frameworks.   If you're following the Java world these days, you'll see that this is what is "the worst problem right now, in Java land";  Project Jigsaw is the plan to move forward, but that's going to be a long time yet until it's ready.   Framework hell.  

WinRT is about as ready for primetime as .Net was when it hit 1.0. Which is not very ready.  While I'm upset that Microsoft has denied non-WinRT apps the "right to run a live tile within the new start menu, that's just one more reason for me to completely ignore the Win8 "WinRT" world, and live purely in Win32 land.   There's a simple way to force microsoft's hand here.   Let's just wait until Win8 releases to retail, and then let's watch as someone makes a million bucks with some replacement start menu that works just like the one we know, and probably love, from Windows 95 until now.  Frankly, I've played with the RTM and the various previous milestone releases, and I'm unimpressed with the UI-formerly-known-as-Metro, and with WinRT in general.  I am much more impressed with the latest Office365/Office2012 release.

But since XE3 will ship with less functionality than XE2 in the box, I expect to hear lots of whinging from various "nattering nabobs of negativity" out there, but as for me, I'm still amazed that we have a multi-platform Delphi.  Everybody who buys XE3 gets all the XE2 level features for free anyways, since XE2 is included for free for everyone who buys XE2, as per JT's blog.

Yeah, so if it takes longer to build than people wanted it to take for the next level of Mobile app building technology, and you want to learn Cocoa and XCode, and build completely separate apps (Java for Android, C# for Windows Phone and Windows, Objective C for Mac) and share zero code between those systems, then you're more than welcome to do so.   I'm not taking a "holy war" approach to mobile development. I'm learning lots of things, and doing whatever works.  I am quite excited about Delphi-on-mobile-platforms, as a future for Delphi development.

It's a great time to be a big fat Delphi fan. Go team. Go Delphi. Go Embarcadero!

Why yes, I AM a fan boi.   Fine.

I used to be a C/C++ programmer.

Certain not-very-much-like-C things in Delphi still trip me up. Like this code which I wrote today, expecting it to zero pad my integer values:
    var
          hour,min:Word;
    begin
             ...
     result := Format('%02d%02d',[hour,min]); 
     // expected '2400', got '24 0'


After a bit of googling, I found that you need this syntax, which seems very unorthodox to me:

   result := Format('%.2d%.2d',[hour,min]); 


As weird as that use of a decimal place in a Format statement involving only two WORD or Integer type variables (hour/min) looks to me, it works just like a %02d format specifier would in C, Java, C#, Python, Perl, Ruby, and Everywhere Else in the Known Universe, other than in Delphi and TurboPascal.

Clean code, greenfield development, and the Developer Ache

Much has been written lately about "writing clean code".  Whether it's the "Uncle" Bob Martin books, or other similar books, there has been a lot said about writing code which is a joy to work in.

The alternative word to "clean", is "legacy", which means "a pile of crap that I hate working on".

I'd like to suggest that in fact, 99.99% of all the code that runs everything, including Windows, your bank machine, and the rest of your bank, the entire world banking system, the fuel injection computer in your car, the firmware for every system in every airplane currently in the air, and just about every piece of PC Windows, Linux, Mac, and  embedded system software in the world is "Legacy" software.

I'd like to suggest that clean code is an asymptotic desire of an insane mind. That programmers can become obsessed with code cleanliness to the point that they can place some aspects of clean code above the other more important aspects of clean code.  Of course the "clean code" people advise correctness, completeness, usefulness to the customer and the world, but I haven't seen them advance any ideas on how these ideals can be pursued in a manner that is sustainable, and which can balance pragmatism against idealism, such that the survival of the businesses and knowledge-based economies that live thanks to these systems is assured.

Sometimes we create amounts of technical debt which require not only technical solutions, they require mental conditioning to withstand working in the code. Sometimes a kind of zen quietness is needed more than a kind of ninja coding style.

Imagine, if you will, deep in the bowels of the Microsoft campus, lives a senior software developer who is responsible for the Windows Explorer Shell APIs and codebase.  Imagine it's 5 million lines of insane code.  He can't change any of it without breaking a million plugins or extensions, and he's still getting heat from managers who can't code, for the 57 serious bugs that shipped in Explorer.exe in the Vista RTM.  He dreams of a clean codebase, but he knows it can never happen.

There are just too many constraints on real useful software, to ever allow complete rewrites.

Now let's switch to Delphi programming.   What if 99% of the Delphi code out there is a Big Ball of Mud.   No encapsulation.  No abstraction.  No cohesion.  Plenty of bad stuff; Coupling ties everything to everything.   You can't bring one unit in from a project without pulling in 4.5 million lines of code via the snarled mess of uses-clauses that tie the whole unit to everything else in it.  Nothing is unit testable.  You can't rewrite it without killing your company and your main product.   Everyone wants an incremental addition here and there, but nobody has the patience to wait while you clean it up.

What do you do?   I would argue that everything that the clean-coding crew says you need is still true. But you need to turn down the volume dial on your own internal anxieties.  You need to give yourself the time, the imagination, and the freedom (internally) to imagine that these problems really can be solved, but that the solutions won't come in a complete form, but rather, incrementally, slowly, and that after a sustained effort, you might get cleaner code.  Never ever will you have clean code.

But maybe just maybe, you can make things better.  Just not perfect.   And that's the difference between insane, and sane.    Maybe some coders have undiagnosed Obsessive Compulsive Disorders.  So become more self aware, and become a better coder.