Celebrating Twenty Years of Failure in the Mobile Space

There's interesting reading, great 1990s nostalgia, and some pictures of long forgotten devices at this IT World article:


Flops and Vapor: 10 ways Microsoft tried and failed to rule the Mobile device world


It's an amazing list of Microsoft-sponsored mobile software failures.  It shows us how compelling the "tiny pocket computer" idea has been in all our collective imaginations, and how elusive success has been in that space.


Even those technologies that have succeeded have not had a long or stable shelf life.  Mobile technology is more uncertain, and the market is far less stable than the PC market.


It might give you pause, if you were a major vendor of software for the Pocket PC, in 2001, or a Palm Pilot software vendor, in 1999, that your market might not exist in 10 years.  Could the same thing happen again, to Apple-device software ISVs?  It would be a historical anomaly if the market didn't at least cool off a little bit.


Anyways, nobody has tried (and failed) more often in the mobile-device space, than Microsoft.


Click the link, and read, and weep.  And ask yourself, how many of those gadgets are in my gadget junk drawer.   I personally bought (or wanted to buy) at least a dozen such devices, including Microsoft-based offerings running Windows CE, and some others, including various models of the Palm Pilot PDA.


But while Palm is dead, and its most notable successes lead to nothing but failure, Microsoft has survived its failures, making it perhaps the most unique company in the technology business.  Its sheer financial health, lead by the Windows and Office division's billions of dollars in profits, lets it lose billions on mobile devices, XBox game systems R&D, and other things, without substantially affecting the bottom line.   


So, the ability to not only survive, but continue to thrive, while throwing away more billions on wasted R&D than any other company in history, is in fact, something to celebrate.  I'm actually serious here.  People owe Microsoft some respect for that.  And I do respect Microsoft, even though they do things that make me mad.  Give me back the Office 2003 User Interface, and get rid of that useless ribbon.  But hey.... Windows 7 is nice.  Try not to screw up Windows 8 too badly, okay?

Indentation Holy Wars.

One thing that surprises me to no end is the number developers I meet who are willing to take up arms and fight to the death over the indentation and whitespace style of their code. And capitalization. And other things that the compiler ignores.

This wikipedia article, which is C/C++ centric, shows the main variations popular in C/C++ programming, and in related languages that use curly-braces, including C#, Javascript, and others.

Here's my personal indentation and whitespace style:

// Warren Style (The One True Way)
procedure MyProcedure( Arg1, Arg2 : Integer; Arg3 : string );
var
  i: Integer;
begin
  if arg1 > 10 then begin
      for i := 0 to 10 do begin
         DoSomething;
      end;    
  end else begin 
      DoSomethingElse;
  end;
end;

By my count, there a great many ways that people could rewrite, or nitpick about the above very simple code. Here are but a few of the myriad whitespace options Delphi people argue over:

1.  begin starts a new line, always? (Yes/No)
2.  Do we put a begin..end around a single statement or do we leave off Begin/End where possible?
3.  Indentation levels (2,3, or 4 spaces).
4.  Initial indentation level different than sub-levels (commonly 2 character indentation after var keyword, more than 2 character indentation inside begin/end blocks.
5   Location of begin and end : Pick a style from the wikipedia list.  Allman, Banner, K&R, and others.
6.  How do you police the width of your files and formatting of large argument lists to procedures?
     One parameter per line? As many as will fit in 80 columns?

If I multiply the options above, I get somewhere between 40 and 100 different options, depending on how many choices I can manufacture at the stages 1 through 5 above.

We all know holy wars are not objective matters.  But why do holy wars break out, and why do developers have a hard time dealing with variance from their chosen style?

I would like to propose that developers do not read their code. They see shapes, and where necessary they read their code. When code is not formatted the way they like it, they find that the level of effort that they must expend is increased.  So, in the end, it is a selfish sort of argument, as all holy war topics are.    My own preferences run towards the sample above, but any of the following are acceptable to me:


// 2 & 4 space Jedi Style
procedure MyProcedure(Arg1, Arg2 : Integer; Arg3 : string);
var
  i: Integer;
begin
  if arg1 > 10 then 
  begin
      for i := 0 to 10 do 
      begin
         DoSomething;
      end;    
  end 
  else 
  begin 
      DoSomethingElse;
  end;
end;


// Save The Chars Style
procedure MyProcedure(Arg1,Arg2:Integer;Arg3:string);
var
  i:Integer;
begin
  if arg1 > 10 then
  begin 
      for i := 0 to 10 do      
        DoSomething;
  end 
  else 
      DoSomethingElse;
end;



// consistently 2-spaced Jedi Style
procedure MyProcedure(Arg1, Arg2 : Integer; Arg3 : string);
var
  i: Integer;
begin
  if arg1 > 10 then 
  begin
    for i := 0 to 10 do 
    begin
      DoSomething;
    end;    
  end 
  else 
  begin 
    DoSomethingElse;
  end;
end;




The one style I encountered firmly entrenched at a big Delphi shop, that I could not live with is this style:


// Pascal+Banner Style

procedure MyProcedure(Arg1, Arg2:Integer; Arg3: string );
var
  i:Integer;
begin
  if arg1 > 10 then 
  begin
      for i := 0 to 10 do 
      begin
         DoSomething;
         end;    
      end 
  else 
  begin 
      DoSomethingElse;
      end;
end;




Did you see what happened there? The second (green) end keyword looks to me like it goes with the for-loop's begin (blue), but it actually goes with the if statement's begin statement.  Now not only does the visual "it scans easier" argument that the fans of the banner style prefer not make any sense to me, in the example above,  begin..end blocks inside a procedure have one set of rules (the banner style) but the outermost begin and end above, the ones I have marked in bright pink above, still line up with each other.  The mental anguish that the above style caused me, during my 9 months of employment at the company where the senior developer preferred that style probably caused me more anxiety and grief than any programmer in the world could imagine whitespace causing, until you end up on the losing side of a holy war on a topic you can't win.


You see, when an application's already built, and formatted a certain way, you have, as a single guy working at a company, a bit of a professional obligation to do what you can to work with that style. I tried, and I tried to learn to read the code style above. I found I could not. I gave up on formatting my code like I was told to format it. I just couldn't do it, my brain, and 30 years of habit were rebelling against me. I asked other delphi developers and they said they couldn't live with that style either.  But neither could the company or its longest standing Delphi guys countenance any change.  


In the end, there was only one way out.  I am no longer working at that company, and I'm glad to be gone.  Indentation and whitespace weren't the only ways we were not a good fit.  But it was a bit of a case in point.  Could you rewire your brain, to accept a style that later, after you're gone from a company, you still regard as a form of brain damage?  I couldn't.  


In the end, the rule is the rule;  Companies set up shop and run for 30 years, and you, the developer need to learn to work within their rules, and if you can't, then get out, or be fired.  Fair enough.  But it still amazes me that something as insignificant (to the compiler) as whitespace, can be a make or break criteria for you keeping your job, or perhaps even, whitespace might kill you.  Stress, and anxiety over a long period of time kills and sickens human beings every day.  Even if all the stress and fighting is only over something as insignificant as whitespace.


Addendum:  The multi-assignment alignment Sub-Holy-War.


Have you ever written code like this:
        A.Size       := GetAreaSize(Arg1, Arg2);
        A.Width      := GetAreaWidth(Arg3, Arg4)
        A.PanelColor := GetThemeColor(Arg5);


When I do, I like to have the equal signs line up if all the assignments are in a group. I prefer the above style to using with.  Other people hate it when you put an extra space after A.Size.   

The Delphi 1.0 Installer was Awesome

This is the delphi 1.0 installer running. It's the dashboard of a sports-car, probably a Porsche.  The speedometer shows the progress from 0 to 100% of installed.

Bring Cool back to software installation, Embarcadero. Installers should be fun.  Oh, and free support for installation with a phone number to call, right there, on a little "note" on the windshield of your new "Porsche"; Priceless.

Why I still hate, and yet grudgingly respect, C++

There are lots of great "Programmer to Programmer" questions on the sister-site to StackOverflow, called programmers.stackexchange.com, where a lot of the general non-programming related questions that are somewhat software development related, but not exact technical questions with exact technical answers. Here's one I came across today:

  Why do so many people dislike C++?

The answers there are very good, but my favorite one is the answer that brings up a podcast conversation between Jeff Atwood and Joel Spolsky, two of the guys behind the whole "StackOverflow" empire, among other things.

 The gist of that answer is that you have to read a book about the "gotchas" in order to avoid writing really bad C++ code. A well-intentioned person who doesn't understand the difference between lvalue and rvalue references, copy constructor semantics, the intricacies of casting, const and non-const and when to use each, and the problems of writing exception safe code, concurrency and threading, and on and on...

 Well, I've always hated, but grudgingly respected C++, as a Delphi guy. I am in the C++ guy camp with the desire to have a binary that is standalone with no runtime at all, but yet, I see, that most of the Windows Visual C++ people seem to accept redistributing MS VC Runtime dlls along with their apps. Say it ain't so, m my C++ brothers.... DLLs that you ship should be your dlls only. Being forced to ship a DLL that contains some bits of your standard library is just so wrong on so many levels.

 Since the question on Programmers.SE covers enough of the reasons why you might hate C++ I'll just tell a story about why I hate C++. In 1995 I was working for a small software company making OS/2 software in C++. It was the last professional C++ job I ever held. I was using IBM VisualAge C++ for OS/2. In those days, writing code in C++ was rough. IBM actually had a nicer class library than most people, and their documentation was almost always right.  But it was shockingly difficult to write a database application in C++.

My main gripe was the lack of decent string handling libraries and capabilities in C++.
I counted at least four ways of writing string-processing code in our codebase:

 1. You could use IBM's non-standard-C++-library strings.   These had capabilities that the standard C++ library string types lacked, but the reverse was also true.

 2. You could use the standard-C++-library string types.   The most fun thing about using these was the absurd things that they did include, and the obvious things that they didn't include a way to do, requiring you to hand-code a tonne of string functionality yourself, over and over and over.

 3. You could use regular C char buffers and C pointer to char strings.  And you could then enjoy buffer overflows, and access violations, if you made mistakes.

 4. You could use your own class that basically used operator overloading, or whatever style you wanted to use, to try to provide the semantics that you wanted, as if you were programming in Visual Basic.  Most people started out using #1,#2,#3 and when they hurt themselves badly enough, they would start a side project writing their own C++ String Type. One String to Rule Them All.  Of course, they would then get lost in evil C++ side-effects involving casting, type coercion, lvalue and rvalue semantics, and so on. Oh, and string heap memory management.

 I saw all four of the above in use, and on three different occasions started writing my own C++ string classes, and it sickened me. I wanted one string to rule them all.  I wanted a string type built into the compiler that everyone would just use.

I had loved using Turbo Pascal in DOS, and in 1995 when Delphi came out, I saw that it had one, and only one string type. Sadly, it was the Pascal 255-character string type.  But when Delphi 2.0 came out, it was love at first sight. A proper String type built in.     Ironically, delphi now has a whole pile of string types, and the meaning of String has now changed three times (ShortString -> AnsiString ->UnicodeString)  and yet, we've survived it.

Back to C++ for a moment. You see, the codebases we used were so full of different string classes that I spent a lot of time converting string data from a standard library string to a character buffer or pointer to characters (PChar in delphi terminology).  The UI layer used the IBM string class.  The stored procedure layer used Char buffers and Char pointers with dynamic memory allocation (malloc).  In between, chaos reigned.

Now the above criticism isn't just about strings. It's that C++ is a giant playing field where millions of very talented developers have built giant monster piles of code. Half the world runs on the stuff they have built.

 And now I will switch from griping to respect mode.

 1. Microsoft Office is built in C++.

2. Almost every major Game studio writes in 100% C++.

3. No other language can do everything C++ can do, and yet compile to native code. Never has this been more true than since the advent of the new C++ 2011 standard. Check it out it's pretty neat.

 4. Finally, because of the tools, libraries and the rest of the C++ ecosystem, C++ is the most powerful cross-platform binary compiled language on the planet.

While I'm glad that I don't have to learn all the intricacies and accidental-complexity of C++, I do want to be able to link in C++ code into my Delphi apps sometimes, and for that reason, I'm quite excited at Embarcadero's future directions with LLVM/CLANG and C++Builder. In the microsoft camp, I'm truly impressed with their C++ 11 support in Visual Studio 2012. In the library and tools world, I'm deeply impressed by wxWidgets, BOOST, and the entire commercial ecosystem of C++ game development tools. Almost every major-studio game produced these days is 100% built in C++. So, let's give C++ a round of applause. And be glad if you've got a job doing Delphi and you don't need to understand copy constructors and type coercion, or discussing  some obscure massively-multiple-inheritance scenario you've devised.