Visual Studio 2012 drops on Leap-Day, Feb 29

I haven't blogged much in the past several years about my chosen profession as a software developer.  Today, I will.

I am a Microsoft .NET developer.  As such, it was big news for me {this past week} when Microsoft announced they would drop the newest revision of Visual Studio (2012 aka 11) On Wednesday, Feb 29 2012.  This going to come replete with the .NET 4.5 Framework, and the Entity Framework 5.0 built in.  The beta of ASP.NET MVC 4 was released several days ago, and it is also supposed to be built into .NET 4.5 framework.

For me, the .NET 4 framework was a snoozer.  The performance hit this version of the framework foisted upon us nullified any of the benefits it purportedly gave us.  Nothing about .NET 4 was compelling enough to make me want to accept the big slow-down in performance .  For the most part, I continued using the .NET 3.51 client framework in 64 bit mode.  This was the sweet-spot for high-performance data processing in an highly-automated environment like the one I work in.  A multi-threaded console application written in the .NET 3.51 framework, NGEN'ed for x64 processors, can process and transform millions of rows of financial records in very little time.

Most programmers just don't care about performance hits.  We just want to use the latest thing, so we can say we are state-of-the-art.  We are often content to throw away processing power for no good reason.  Most programmers don't think in financial terms about their code.  We are not good about evaluating the cost implications of the slow-downs we gladly accept.

Consider the following example.  A Microsoft blogger recently bragged on the performance improvements Entity Framework 5.0 would bring to the table.  He published performance test-data that indicated that UPON SECOND EXECUTION, EF5 would execute a transaction 400% slower than ADO.NET, whereas EF4.3 would execute it 2,300% slower than ADO.NET.  On first execution, EF5 is also 2,300% slower than ADO.NET.

These findings were advertised as a magnificent 600% speed up.  We were supposed to applaud.  We were supposed to smile as we learned that we would get this marvelous speedup for free when we upgraded to .NET 4.5.

So, I am to applaud when I discover that my transactional operations will performance a mere 400% slower under EF5 than they would if I wrote some better code.  It is better code, just to make sure you understand that.  It's not worse.  It's 400% better.  Better is as better does.

The real take home story of this blog post is that I will cut the carrying capacity of my enterprise servers by 75% if I accept the 400% slow-down that Entity Framework brings to the table.  Stated more precisely, I will need to buy 400% more servers (or virtual cloud capacity) in order to meet my needs if I fuck around with the Entity Framework.  This should come at something like a 400% increase in cost right?

Let's see... that would make me a fucking stupid bastard wouldn't it?  Waaahhhh...?  I am a stupid goddamn bastard if I fuck around with the Entity Framework, aren't I?  If I throw away 75% of my server's capacity and increase my costs 400% just so I can say I use the latest wiz-bang crap from Microsoft, I am a stupid bastard, aren't I?

There are a few non-lemmings like me around out there in the world.  We have been banging on Microsoft about these logical and financial problems.  When confronted with the facts found in their own publications, Microsoft ambassadors quickly fold over, admit that they have performance issues, and say that they aren't done tuning their code yet.  They promise us that big performance gains are still in the offing.  They are working on it.

They say we will be pleasantly surprised when we test the performance of the final goods.

What does this mean?  Perhaps they can get the performance hit down to 2:1?  Perhaps we will only throw away 50% of our server capacity and double our costs when the final edition is shipped?  Probably too good to be true.  I doubt the performance/cost picture will be that good when the final facts are published.

2012 is the year when I get serious about launching my own smart-phone web-enterprise.  You know I am working on a Synastry Engine right now, and I will need web-services to deliver the info to both phone-clients, web-customers, and potential partners.

If the objective is to make money, if the objective is to make a living, if the objective is to stay alive, I will need to think in economic terms about my code.  The entire structure and nature of my software project has to engineered in such a way as to maximize carrying capacity and minimize costs.  When writing code, I do so according to the same motto StackOverflow.com uses:  Be fast at any cost.  I don't care how hard the code is to write, if it performs faster, it is better code.  If it increases my carrying capacity, and reduces my costs, it is better code.

Such differentials will make the difference between life and death, if I am not doing well financially.  It will also make the difference between life and death if my project takes-off, and becomes the next big thing in the web world.  People don't understand the immediate survival problems over-night sensations experience when hundreds of thousands of new users begin to hit your web-apps every single day.  In this situation, carrying capacity is stretched to the utter limit.  You'll wish you had written leaner and meaner code if this ever happens to you.

It could make the difference between being able to self-finance and being forced to sell my asshole to investors.

Visual Studio 11 drops on Wednesday Feb 29, one day after I have surgery on my left hand.  I am going to have a bit of time-off for recovery.  I intend to play with this new system whilst I recover.  I won't be able to write new code, but I will be able to click the mouse and recompile old-projects under the new framework.  I will be able to benchmark how fast the new system works.

I suspect it will be a lot slower.  I hope it will be a lot faster.  I won't use it unless it is faster and more efficient.  You won't get my vote unless you improve my performance/cost profile.

Microsoft needs to redress problems in Microsoft Access

So we fired Microsoft Access here at work. Access was fired for cause, without severance. What do I mean by that? Let me explain.

Most all of our work here revolves around Microsoft SQL Server 2005 & 2008. We use Access only as an export format, or a quarantine cleanup space for extremely dirty data. Some of our clients do like their data transmitted to them in Access format. We're going to stop doing that... almost immediately.

Microsoft has effectively ruined Access. Once upon a time, it the moral equivalent of a very useful Victorinox Swiss Army Knife for data. Now, it's pretty well worthless.

Now why would I say a thing like that? Two expert reasons:

1. At the moment Microsoft Access has no 64 bit API for database creation and manipulation.
2. Microsoft has destroyed the application itself with the Trust Center setting.

The first point spells out our primary affliction. We run a collection of websites that provide data to the 7,000-8,000 financial institutions of these United States of America. Some of those institution like their data served up on a platter of Access MDBs. We have supported this in the past, but no more.

Since we made the conversion to 64 bit mode, a conversion we found necessary due to the volume and complexity of our data, we've been experiencing serious issues supporting Access MDBs. We have re-discovered the following tangle of faux-solutions and problems.

1. The ADOX code we wrote years ago cannot be upped to 64 bit mode. ADOX is an ActiveX library. It is 32 bit. There is no such thing as a 64 bit ADOX library. Our old 32 bit code will run, but it breaks when upped to 64 bit mode. The COM library cannot be found and loaded. That is because a 64 bit ADOX does not exist.
2. If you are running SQL Server in 64 bit mode, you can forget about exporting Access MDB files. The 64 bit SSIS engine will attempt to lock and load the JET 4.0 engine, which is just a 32 bit COM library. Naturally, this fails. Tough shit.
3. We attempted to use SSIS packages in SQL Server (32 bit) to export the data in an Access MDB. We found this extremely cumbersome. The SQL machines and our web boxes are different boxes. Getting a SQL machine to deposit an MDB on a web server, or a mutually shared directory is a mater of opening more holes in the firewall, exposing more things to the DMZ, and there are timing issues beyond that. We also dislike the notion of keeping a 32 bit SQL Server in town.
4. We explored the possibility of writing .ACCDB XML files using XML Literals and compression. We were working on this very complex task when our customers signaled that they were not using Access 2007, and had no plans to go to 2010. The old MDB was demanded, not the new format. This effectively terminated our work.
5. There is currently no managed code (that is, C# .NET) library for manipulating Microsoft Access schemas in either the old or the new formats. Not even third parties such as the marvelous Syncfusion make such a library available.
6. Of course, we could continue running our 32 bit app, but this precisely the thing we want to retire.

This left us in a quandary. At the moment, there is no working solution.

COM is evil, and Microsoft is quite correct in killing it off. We don't want to see Microsoft up ADOX to 64 bit mode so our old code can recompile and run with success. That is not what we are after.

It is difficult to reason with clients about Microsoft upgrades. If they don't want to upgrade, we aren't really going to talk them into it.

I think I am going to finish the code that creates new ACCDB export, but I will do so privately. My company isn't interested. Neither are our clients. I do see a future value for this product. It will be worthwhile in the end. That should be the first Open XML OOXML managed code solution for the .NET framework.

As you can see, this leaves us hanging. We want to be comprehensively 64 bit from end to end. We want to flush the COM. We do not want ADOX, as it is both 32 bit and COM. We do not have a managed solution for producing the binary MDB. Neither does anyone else, for that matter. Our clients do not want .ACCDB.

Where do we go from here? The logical solution is to simply state that will not be supporting MDB anymore. We are simply phasing out that service. It has become to problematic.

I suppose this fits Microsoft's objectives of marginalizing the non-OOXML formats. This serves their end objective of applying upgrade pressure to their clients. I really don't like it. There aught to be a fully managed code solution for MDB construction. The net effect is that Access is going to marginalized by our firm and many others.

The second issue revolves around the utterly obnoxious Trust Center. The mere existence of the Trust Center--in this context--is proof positive that the lawyers are now running the software design process in Redmond. This is why we are seeing so many bad changes lately.

So what is the problem with the Trust Center in Microsoft Access? Aside from the fact that it utterly breaks any Access MDB/ACCDB solution, there is nothing wrong with it. Your app won't run until (under advisement that he/she should not) a user clicks "Enable Dangerous Macros". I say that breaks the application. The application does not work anymore. Further, breaking the app in this manner does nothing to protect the system. The very moment the user clicks "Enable Dangerous Macros", and the user must do this, all protection goes out the window. Microsoft would tell you this is a feature, not a design flaw. Stupid. Very stupid.

More stupid than selecting a QB #1 overall in the NFL Draft. Believe me, that's saying an awful lot.

The trust center effectively kills Access, shutting it down such that it cannot be used. If the application is so dangerous that it must be shipped in a lockdown state, it is too dangerous for public consumption, and should be removed from the market. If it is not that dangerous, the application should not be shipped in a castrated state for the sake of your legal department. Get a clue, Microsoft!

Frankly folks, this thing is utterly baffling. It's existence can only be understood as a stunt foisted upon Redmond software developers by the Microsoft legal department, who insisted on a disclaimer built into the package.

Outlook: The object of ridicule among Microsoft programmers

I recently had the pleasure of catching up with some of my favorite Podcasts. These include such stalwarts as .NET Rocks, Hansel Minutes, the Polymorphic Podcast, and Java Posse... among others.

I was impressed by the number of Outlook jokes these programmers were cracking. What is an Outlook joke? Any joke which sticks a thumb in the eye of the designers and programmers responsible for the Outlook application. The suggestion is always the same: They did an outrageously bad job on this application, they obviously don't know what hell they are doing, and they should be ashamed of themselves.

Example: Anders Hejlsberg, probably the greatest genius at Microsoft, is being interviewed about the future direction of the .NET programming platform. He is the man most responsible for setting the course in programing systems at Microsoft. Anders is explaining the sorts of strides that must be made with programming languages, techniques and tools to support the multicore present and future. Anders believe that the .NET development team must revisit the basic design of threads in .NET. When a user says something like var x = new Thread(); the CLR initializes such a threat with a 2mb logical address space. This would mean only 2048 threads in total would be possible in a 32 bit address space, and frankly you'll never get close before memory will become so congested that problems will strike.

Richard Campbell, cohost of .NET Rocks seizes the opportunity to strike: "But that would mean we can only run Microsoft Outlook on our machines with 4GB and then we are all done?!?" This brought howls of laughter. Anders did not really want to comment. It would be tough to venture a defense. Believe me, if there had been something to defend, he would have mounted a defense. Anders is extremely knowledgeable and fair minded. He loves to argue. The fact that he dropped the subject speaks volumes.

Anders motto is "I think we can do better." He is always seeking to "do better". Believe me, if Anders was tasked to run the Outlook group, he would kick a lot of asses right out the door. He might recommend the dreaded EOL logo also.

I heard several other jokes on the other Podcasts. Those would be more difficult to explain. Even the Java Posse, a group unrelated to Microsoft, were wondering aloud why Microsoft programmers continue to suffer Outlook when we hate it so. The answer is simple: Because bad men with MBAs continue to ram it down our throat. Believe me, we would burn it, if we could.

Folks, I want you to know that Outlook is a bad joke among Microsoft programmers. It is a byword meaning "everything done wrong" from the programmers point of view. It is a detestable, reprehensible, object of hissing and horror. None of us can understand why the bloody bastard has 32-46 active but idle threads open when you are doing nothing with the application. We still can't understand why Microsoft would ever have though that modules of Visual Basic behind your eMail (Active Mail) was anything but a virus writer's wet dream.

Folks, it goes deeper than that. All groupware fuctions can be performed in a web environment. No client-side tool is necessary. Microsoft has a fully-orbed web-based system themselves with Outlook Web Edition (OWE). They should have placed Outlook in the EOL (end of lifecycle) category and deprecated it immediately when this web edition hit the streets. Microsoft Live! has even better implementation for most of us. Google long-since crushed Outlook with their Gmail-based suite of scheduling and groupware tools. Mail and groupware is simply the perfect case-study for the "software as a service."

It is conceptually wrong to build a thick client, or maintain an existing thick client, for the purpose of doing mail, schedule, and group actions. If you go to Visual Studio and select File->New->WinForm Application, and begin to write any sort of thick client for eMail and groupware, you are instantly wrong. You have made a mistake. The mistake isn't that the niche is filled. The mistake is that there is no niche in the first place. These apps should not exist.

There are many pieces of evidence for this. I know many scores of Mozilla Firefox users. I know of no one in my circle who uses ThunderBird. Oh, what's that? You've never heard of ThunderBird? Excellent! That's precisely my point. Thunderbird is the Mozilla mail client.

When I ask Mozilla fans why they don't download and use ThunderBird for free, the answer is always the same: I can see no use for the application. Now that we have webmail, who needs a mail client on the machine? These individuals are thinking correctly. Their conclusions are well merited and valid.

Outlook is evil. Outlook should not be used. I am not the only Software Engineer who thinks so. If you are dependent upon Outlook, you are wrong, period. Get right. If you have built a business around Outlook, you have built your business poorly upon shifting sands. You are also wrong and should correct the situation as soon as possible.

Putting the band-hammer down on Microsoft Outlook

So, I guess the economy must be rebounding or something like that. Not only have the Rams selected a QB who will cost 256 times per year what Vince Ferragamo once cost, but my relatives are now contacting me about the prospects of building new computer systems for them.

I used to build computers for fun. There's nothing to it really. If you can snap together Legos as a kid would, you can assemble a computer these days. You just put the round peg in the round hole, and the square peg in the square hole. It is amazing what a challenging concept that is for some people. When I was a 6 year old kid, I was asked to perform a series of stupid tasks like this in an IQ test at Fresno State. I rang the bell at the top. The Ph.Ds were very excited. My grandmother was stunned.

I still have no idea what they were going on about. A fool could do what I did then.

But now I am going to withhold my lego snapping skills for cause. I am going to flat-cold refuse to build new computers for these relatives. I am going to do this for a very important reasons: The folks are using Microsoft Outlook.

Yep, that's right. Because they are using Microsoft Outlook and Outlook Express, they get no love from me. They are on the contraband list.

The last time I built machines for my mom and cousin-in-law, I had weeks of headaches with one phone call after another related to one fucked up piece of shit program: Microsoft Outlook. Toss Outlook in Express in there also. The difference between these two is the difference between colon cancer and anal cancer. About 6 inches of distance mayhaps.

There was nothing wrong with the hardware I built for them. The machines were humming along superbly. The build was flawless in both cases. No, these two users were experiencing software problems related to exactly one piece of software: Outlook. For this reason, they called me repeatedly with question after question about Outlook.

This pissed me off to no end. You have no idea how much I hate Outlook. I never use Outlook, except at work, where I am forced too by very poor management decisions. At work, I use the disease as little as possible. As far as I am concerned, Outlook is the worst application ever devised by mankind. There is no piece of software more poorly conceived, more poorly designed, or more poorly implemented.

Asking me questions about Outlook is like asking me questions about Gay sexual techniques. I don't know much about the subject, I don't want to know what I do know, and I am certainly not willing to learn more about it to help you get it right. Don't ask. Don't tell.

Being an Outlook user is a shameful thing. If I was an Outlook user, I certainly wouldn't tell anybody about it. I would hide that fact in the closet and never admit it. I certainly wouldn't ask for help in continuing with this problem. I would seek help in kicking this habit.

Take this to heart, Outlook users: Be ashamed of yourselves, be every ashamed. Shame on you. You are bad; very bad.

Outlook is the worst application Microsoft ever did, and that is saying an awful lot because they also wrote Internet Explorer. Internet Explorer and Outlook are the two greatest security holes Microsoft ever invented. Most of the alleged security flaws in Windows itself are really problems with Outlook and IE. If you never use either application, your probability space for infection by malware shrinks down to almost nothing.

With Outlook the problems run much deeper than mere security holes. Outlook is a pure waste of skin. It is an app without a purpose in life. It has no reason to live. There is literally no purpose in putting a local database of eMail and contact information on your computer. There is no logic in it at all, ever, under any circumstances. This is a completely outdated and outmoded approach to doing business. If you have a local database of such information, you are wrong, full-stop.

All of that stuff should be handled in web-based systems like Gmail, or Microsoft Live! There are no exceptions to this rule. In this way, you never experience problems in moving from computer to computer. There is no need to synchronize databases between a laptop and a desktop. There is no reason to worry about what will happen to your email or contact book if your hard disk crashes. All of these problems go out the window. Asking how you synchronize Gmail between two machines is like asking how you rewind a DVD before returning it to the rental store. The problem does not exist.

Amazing how entire categories of problems can be entirely avoided if you merely don't go there and don't do that. Just say no to Outlook. You will be grateful you did.

I'm putting the band-hammer down on Outlook. I'm going to leave these relatives hanging. They can stay in these current machines until those hard disks die. They can loose that entire database of mail and contact information. At that point, they will experience excruciating pain, and I will be there to tell them "I told you so."

I know they are not backing up on a regular basis. I know that asking a user to backup on a regular basis is a very unsound approach to doing business. I know they will loose mission critical information they can never recover when this eventuality happens. I know that is going to hurt like hell. I will be there to tell them "I told you so."

It's going to take a pain-event like that to make them kick the Heroin habit. I just saw fragments of "Requiem for a Dream" last night. Absolutely disgusting movie, and I hated it. However, it did demonstrate that Jared Leto had to lose his entire left arm to infection before he could begin the process of quitting Heroin.

Outlook = Heroin. Kick the habit.

Death to the Background Compiler

Of all the misbegotten ideas that Microsoft has hatched over the years, the worst of them all is the background compiler. It is worse than the system registry. It is worse than the notion of supporting ActiveX inside Internet Explorer. It is worse than Microsoft Bob. It might even be worse than the IBM PCjr Chicklett keyboard. It is a totally confounded, wretched, filthy, nasty, counter-productive, anti-quality idea.

The notion is that the C# or VB compiler should be running continuously in the background while you write code. It should be (according to this misbegotten theory of the world) giving the programmer continuous feedback about what he is doing and whether each stroke of the keyboard is correct or not. The idea is absolute rubbish because it does not allow the programmer to finish a single thought before declaring that errors exist in his code.

It is obtrusive and obstreperous as fuck when declaring compiler errors also. We're not talking about mere blue and red underlines below your code. Nope, it will pop up the full compiler results window bar (chewing a considerable amount of screen real estate) just so it can show you read dots declaring that the code will not compile due to this or that error.

My response is simple "Of course the code will not compile. I am still writing it. Now will you please fuck off and die?" Of course, if you are shitty developer, you may need the crutch of constant compiler feedback. You might not know the difference between right and wrong code. You may need the compiler to tell you the difference between right and wrong code. This is true because you do not know the language you are coding in. If you are a good developer, who knows his chosen language, and you like to refactor your code for performance, organization and clarity, the background compiler is the worst enemy you have ever encountered.

Cut just one method or variable or property to promote it or demote it up or down the chain of inheritance, and the background compiler will scream its fucking head off about compilation errors. My response is simple "Of course the code will not compile right now. I am in the middle of refactoring my code. Now will you please fuck off an die?"

Of course, if you are a shitty VB programmer, who never refactors code for any reason (Microsoft Mort as they call you in Redmond), you won't be bothered by this problem at all. You will probably wonder how you could ever get it right without the background compiler. You may never need to promote or demote members or methods due to the fact that you don't use inheritance in the first place. If you are thinking this thought, you just might be a shitty developer and not even realize it.

I would like to get my hands of the fucktard who came up with the notion of the background compiler. I would make Jack the Ripper look like the Church Lady. He would not survive the encounter. I would beat him to death, and not quickly either. I would make him feel that he is dying.

I have already argued with a few Microsoft Devs about this online. Their standard defense of the background compiler goes like this: If we didn't have the background compiler running the time we:

1. Couldn't know the type of some variables if you are using type inference or automatic data coercion.
2. Couldn't give you immediate visual feedback in a XAML design environment.
3. Changes to other assemblies in the project would not be reflected immediately in client assemblies
4. You would have to hit CTRL-SHIFT-B or F5 to figure out if your changes were good.

My answer to that is "I am perfectly willing to hit the F5 key. I am perfectly willing to wait for compiler feedback until I am finished with a group of changes. Let me hit the F5 key for compiler feedback when I want it. That is the way all good programmers work. I don't need continuous feedback training wheels. Type Inference is cool, but automatic data coercion is not. If you are using ADC, you are a shitty developer and don't yet realize it"

Microsoft need to give us the ability to opt out. We need a simple switch under the options tab that will allow us to shut off the background compiler. That's all we need. Just let us turn the stupid fucker off.

Does the government have any idea of which direction it should shoot?

Once in a while I read something that makes my blood boil.  Yesterday, around noon, a flurry of articles were published indicating that the Department of Justice intends to begin stricter enforcement of antitrust laws. Assistant Attorney General Christine Varney said the Justice Department is abandoning legal guidelines established by the Bush administration in September 2008.

So who is in the cross-hairs of the sniper rifle this time?  Sure it is Citibank, Bank of America, JP Morgan and Wells Fargo, right?

Wrong!  Google, Intel and Microsoft are the main targets.  Obama is shifting to the European approach to anti-monopoly action.  Since Google, Intel and Microsoft are constantly in trouble with European regulators, we can expect the same from the good old Federal Government.

Now, as much as I like small competitors like Borland (now dead), Yahoo (dying) and AMD (also in trouble), I know better than to think that monopoly power did it.  AMD simply failed to compete with Intel.  There were some very bad decisions there, such as the merger with ATI.  I know Yahoo has not been competitive with Google in terms of apps & hard information research for years now.  That isn't Google's fault.  Yahoo wanted to be a celebrity tabloid machine.  They decided move towards People Magazine on their own, and now they are fucked.  Borland died because it didn't seem to know how to market to corporate America.  They had awesome persuasive powers with true programmers, but they had no idea that they needed to market direct to corporate officers.  The CIO needed to be in the crosshairs.  They also had no idea that they needed to recruit MS Office power users.  It is a horrible thing that Borland basically died, but market-wise, they were stupid.

So, instead of breaking up the Banks, who fucked the entire world, the Justice Department intends to prepare anti-trust proceedings against Google, Intel and Microsoft.  These are the three most powerful and important firms in the high-tech sector of the world.  Incidentally, the tech sector is the only thing keeping our American economy afloat right now.  Boy, these supreme assholes in the Justice Department really don't have a fucking clue do they?

I have nothing against Trust Busting.  Teddy Roosevelt did it all the time.  He is one of my favorite guys, and I don't much like presidents and politicians.  If you are going to bust some trusts, bust the dangerous ones.  Don't go after the healthy, useful and benevolent ones.  For crying out loud!  Shoot strait will yah!?!?!?

This new policy statement indicates indicates that the Government does not know the difference between its ass and hole in the wall.  This has to be the most AFU announcement I have heard in sometime.

Why I don't like talking to other programmers online

Those who I work with know I don't spend much time online interacting with my fellow programmers.  Sometimes I regret this.  The websites we have today for interaction are vastly superior to the ones we used to have.  The web software itself is better, but the content is also much better.  You have multi-disciplinary coders, working with many languages, and many architectural patterns all sharing one common web forum these days.  Unfortunately, these cats seem to be in a perpetual flame war.

The problem is that most of the heavy users of these sites are beginners.  They ask a lot of questions, because they don't have much knowledge or experience.  Intermediate pros answer these questions.  They give very stereotypical platform-centric, ethnocentric advice.  You get rote Java advice from Java programmers.  You get rote VB advice from Visual Basic programmers.  Same thing goes for all the languages.  These guys do not know or understand each other's approaches.  No VB programmer is particularly honest about, or even aware of the flaws in his game plan.  Same is true for Java programmers, C++ programmers, C# programmers, Python programmers, etc.  Ethnocentrism reigns supreme all over these forums.

Very few of the guys on these forums have more than 10 years of experience.  Most of us stop coding before we reach age 10 as professional coders.  We get kicked up the chain of command.  This is what makes a brilliant guy like Robert C. Martin so amazing.  He has been coding for 39 years.  He just never stopped coding.  This is a deeply experienced polyglot programmer who really knows the answer to the question "Why?" because he has seen the full evolution of software development.  He lived through every movement. 

Recently, Uncle Bob had a smack down with the dudes at StackOverflow.com.  I was rather appalled.  The Stackoverflow gang wrote the site in C# and the Microsoft MVC framework.  Ergo, they are members of my most recent tribe.  I was shocked to see such good members of my tribe speak so ignorantly.

It was pretty clear to me that the very brilliant young entrepreneurs at StackOverflow.com did not use the SOLID techniques Uncle Bob advocates.  It is also clear that they felt threatened by the advent of SOLID, because an acceptance of these techniques would marginalize the StackOverflow.com software itself.  They took Uncle Bob to task for preaching SOLID.  As you listened to these podcasts, forum posts, and blogs, it became clear that the noise coming from the stackoverflow gang was driven of their own personal insecurities about the status and longevity of StackOverflow.com rather than the validity of Uncle Bob's SOLID principles.  They didn't want to talk about SOLID.  They wanted to talk about owning a business.

Uncle Bob knows this.  He did a caper Podcast with Scott Hanselman in which the recapped this smack down.  Although he didn't explicitly say it in this way, Uncle Bob gave me every impression that he knew he was dealing with young and insecure entrepreneurs floating on their very first life-boat on the high-seas of commercial SAS.

Older, veteran, multi-lingual programmers with 14 years of experience and 4 or 5 major languages worth of professional experience have a hard time finding people to talk too.  Programmers are rare.  Veterans are scarce.  Multi-lingual veterans are seldom seen.  I wonder if it is possible to form a club where the scarce 2000+ of us might get together on line.  We would have to restrict membership quite sharply.  No monolingual or mono-platform guys allowed.  If you are Unix only, you are out.  If you are Mac only, you are out.  If you are Windows only, you are out.  If you are C/C++ only, you are out. If you are VB.NET only, you are out.  etc.

If such a forum existed, it would be possible for serious and objective software engineers to discuss the patterns and practices of the various languages and platforms free from the sort of fundamentalism that drives so many in our field.  That would be a wonderful thing.  Can you imagine an objective discourse on the strengths and weakness of software systems?  Could be very beneficial.  

But you just can't discuss the pros and cons of Islam with Osama Bin Laden.  Neither can you discuss the pros and cons of VB.NET with a mono-lingual VB programmer.  Neither can you convince a Java programmer that Microsoft uses its own software to write MSN or Microsoft.com.  They think must be running on Unix because Windows doesn't scale.

The last time I had a "conversation" online, it was with a young Java programmer.  I am sure he would have embarrassed James Gosling.  I was doing a comparison of Java, C# and Scala.  He quickly got belligerent.  He seemed to think I was unfairly putting Java down, by not recognizing it's innate superiority to C# and Scala.  His response was to resort to mocking derisiveness.

The lad didn't seem to know that Java generics aren't real generics.  He didn't seem to know that Java lacks full lexical closures.  He was sure it couldn't be important if Java didn't have it.  He didn't know that closures have been burning topic #1 in Javaland for some 2 years now.  He didn't know what an event is.  He didn't know what a delegate is.  He didn't know what a Scala trait is.  He was quite sure Scala could not replace Java because it could never be as cross-platform as Java! (!!!)  He was very rude & insulting in the process.  Young men like to play king of the hill, and they want to beat you down.

I can recall the bad days of 1994 when I was first doing a bit of professional work on the market.  I was very insecure.  I didn't know if I could make it in life doing this particular line of work.  I didn't know how long it would last.  I did know the other options were worse.  But still, this profession might not be for me.  One thing I knew:  Borland and Pascal were my only life-line.  An attack on these agents was an attack upon my livelihood.  I took any objective criticism as an attempt to sink my ship.

I am sure that the young Java lad was in the same boat.  He is probably working on his first pro assignment.  He knows some Java and nothing else.  Any objective critique of Java is immediately interpreted as an attempt to sink his financial lifeboat.  He must respond vigorously.  Most other members of the tribe feel this way.

Still, you can imagine that a guy like me dislikes dealing with a young guy like that.  He can't discuss the pros and cons of his system.  He just isn't experienced enough.  At this point, he would not be willing to be honest about it.  He really can't hear what you say because fear of financial collapse.

This is the rant of a lonely old programmer who has nobody to talk too.  Many of these points are being refreshed in my mind day by day as I learn Scala.  Many programmers around me, particularly those I work with, have no idea why I would ever want to learn a language like Scala.  They believe I am letting down the Microsoft faction.  

What these young fellows don't know or understand is that you can't get married for life if you are a programmer.  Computer languages are not women.   You do not wed a language or vendor as you would a woman.  Even if you did, languages and vendors die, ergo in death shall you part.  Neither are languages religions.  You do not experience a religious conversion experience and become a programmer of language XYX.  

Excited about Scala

I am excited about Scala! Those of you who know me know that I am a career-long Micorosoft Developer. First with Borland tools, second with Microsoft tools. Delphi & Paradox gave me my first real taste of professional success late in 1994, but there has been plenty of VB and C# along the way. Ergo, it will suprise many of you to know that I am excited about Scala.

For those who don't know, Scala is an OOPS/Functional hybrid language which primarily focuses on the Java VM and J2EE framework. It does run under .NET, but good luck in finding tool other than Notepad to program with.

Speaking of tools, the primary reason I have not learned Scala already was the tool experience. I am not a fan of EMACS. I piss on VI. I detest Notepad. Don't show me a plain text editor and expect me to accept that as a development environment. I am Borland guy at heart. I expect and advanced IDE, powerful tools, and a great experience. Borland JBuilder shocked the Java world, and tools like Eclipse and Netbeans followed quickly. Borland guys want killer IDEs. Visual Studio wasn't always the most advanced environment. Microsoft was forced to compete on an entirely different level by Borland.

Sadly, until just yesterday, I just couldn't get any of the plugins for Eclipse, Netbeans or even IntelliJ to work correctly with my installation of the Java SDK, and my installation of Scala. Without a good development environment, I just would not get into the language.

Wonderfully enough, this all worked out last night. I noted that there was a new edition of a Scala plugin for the Eclispe environment provided directly by the Scala team. I grit my teeth as I began to think of another major disapointment. It took some effort to get it going under Windows 7, and this effort included installing the basic JRE on top of my already installed JSE.

With that done, I only need to change the the developer "Perspective" in Eclispe to Scala, and begin work. Marvelously, everything worked. I could create a new Scala project. I could create Scala classes. I could compile. I could run. I could get correct results. I could copy code fragments from tutorials into Scala text files, compile them, and execute them. They all worked, exactly as expected.

Believe it or not, this was precisely what I could not do before last night. Copying code directly from tutorial pages into the editor would produce all manner of strange errors. Most assured me that this was a consiquence of integration problems between the development environments and the Scala compiler. That turned out to be the case, but it was little comfort when I was chomping at the bit, ready to go. It reminded me of the early days of Visual Basic 1.0, which was nasty buggy.

So why the hell do I care about Scala? I have been looking around for the next big thing for some time. I am looking for pure technical merit. I don't give a fuck about fashion trends. I rarely trust the uber geeks. It is clear to me that Ruby on Rails was advocated by Adobe web artists who clearly did not understand binary data types. It is clear to me that Erlang is being advocated by a certain species of Uber Geek that wants to exclude the mass-majority of rank & file programmers from their secrete club. When I look for the next big thing, I am looking for something with lasting and enduring power. For a number of reasons, I think Scala could be that thing.

Why?

1. Multi-parallelism: We are coming into a new era where every machine is can execute 4 simultaneous threads on a minimum of 4 cores {laptops are stuck at 2 cores these days, but even this is changing}.  Also, Hyper-threading is making a comeback.  Four-core chips like the Intel Core i7 are hyper-threaded, meaning it can execute 8 simoltaneous threads. Apple is already shipping a PowerMac with a pair of i7 Xeon processors.  That box will execute 16 simoltaneous threads.  WOW!   Right now, everybody I know {particularly my local Visual Basic programmers} are living in a violent state of denial about the implications of these developments. They intend to go on programming in a single threaded execution mode forever... or until somebody runs them out of the industry. I guarentee you, they will get run out of the industry. We are going to have to start programming in parallel. Scala offers us Actors, which are the easiest method for doing parallel programming I have ever seen.
   
2. Brevity: Scala seems to be a very terse language. It is the most terse thing I have seen since Python. Unlike Python, it does not achieve that brevity by going dynamic, omitting all type references, or type declarations. This is very good. You can write less code and get type-safety also
3. Immutable Data: Scala is a functional language. With it comes a couple of features of functional programming with which I am completely enthralled by. The first is Immutable Data. Once assigned, a variable... er... identifier becomes immutable and cannot change again in scope... unless you explicitly declare it as mutable. Most Ruby and VB programmers would blanch at this and turn white as a sheet. These buggers often want to change the class types of variables at runtime, not just the value of the variable itself. This is dreadfully unsafe. It also increases your Cyclomatic complexity dramatically. Immutable data means safer, more predictable, more stable software. This is going to be a tough discipline for some to learn, but we have to get used to it. It is good.
4. Monads: One of the terms Functional Programmers have added to our lingo in the past two years is the term Side-Effects. Side Effects are any changes to the state of the system which an application might perform at run time. Printing a document is a side effect. Writing changes to a database is a side effect and can create other side effects. Changing the users display is a side effect and can have other side effects. It turns out that things like network IO are the sources of most failures & errors these days. When you print, you cannot know for sure that the network is fully functional. You cannot know the printer is on. You cannot know the printer is loaded with paper. You cannot know it has ink or toner. When you make a web request, you cannot know the target website is up and running. We trust these things will work on a daily basis, but sometimes they do not. Functional programers have decided all such side effects must be locked inside a class type called a Monad. A Monad explicitly declares what sort of side effect will be created, and an entirely different level of error handling is imposed. This is a marvelous thing. I love it.
5. Traits: Traits are basically implement interfaces. If I have a series of common methods (say Load or Save) which must be implemented in identical fashion for 4 or 5 different class prototypes, I can now tack on a trait which will contain these methods. All the code is implemented in one place. This promotes very dry coding. Also, you can type variables according to their traits, just as you can by Interface in Java or C#. This is truly a simple and brilliant idea. I wish we had it in C#.
6. Super-Generics: For those who don't know, .NET offers us a pretty good implementation of generic collections. We can also make our own generic methods and generic classes. Java has a pretty poor implementation of Generics. In either case, both languages are out-classed by Scala. Scala brings the full-house of type-parametrization found in functional languages. This is well beyond what we are used to in .NET.
7. Functions are objects: The great shock to all imperative programmers like myself comes when we discover that we can make a generic dictionary of functions, or generic stack of functions, and pass that data structure full of actual code-functions to another class as a parameter for the further processing of data. I am not talking about passing the results of one call to function in a data stack. I am talking about passing the function itself. The possibilities boggle the mind. I have seen some stunning things done with this feature, not the least of which is pretty slick compilers and interpreters.

There are many other things that intrigue me, not the least of which is the LIFT web framework. I am very excited about the notion of writing my first website in LIFT and deploying that WAR file to Glassfish or Tomcat. I think it should be damn interesting,

Windows-7 is a big winner. Apple is in for a very rough ride

First of all, let’s make one thing perfectly clear: Windows-7 is not really a new operating system. Windows-7 is a marketing gimmick contrived to ditch the massive negative press dogging Vista. Windows-7 is actually Windows Vista SP2. It is the second major service pack, or redux, of the Vista operating system. Re-branding it is a smart move. It makes stupid & ignorant people {who generally don’t keep track of current events} take a second look at the system.

With that said, let me make another thing perfectly clear: Windows-7 is a killer winner. It is the real deal, the legitimate, genuine article. It has all the fit and finish we would expect in an SP2 level operating system. It is mature, stable and fast. It installs like butter and runs smooth as silk. It is faster & more efficient than Vista on 64 bit systems. It is somewhat lighter on memory use. All of your software packages work just— as well or better—as they would under Vista.

UAC, at least in my beta copy, has been toned down. UAC is still a bad idea and still somewhat obnoxious, but it has been improved a little. Don’t cleave too tightly to that statement though. Rumor has it that Microsoft is going to dial UAC up a notch due to the protestations of the FUD-ruckers. More on this subject in a moment.

After this weekend I have now officially installed Windows-7 twice. The first was on my new and luxurious Core i7 system. The second time was on my brother's Sony Vaio laptop. These are two very different systems, but both were installed from the exact same DVD-R disk. The results were basically the same in both cases. Both systems finished the install flawlessly. Neither needed any drivers. Both brought down two patches from MS-Update. Everything worked exactly as it was supposed to. You don't even need to Install the .NET framework 3.51. It is in the distribution. The system is butter-smooth. No problems.

My Config looks like this

1. Core i7 920 processor
2. MSI X58 Platinum Eclipse motherboard
3. 6GB of G.Skill DDR3-1333
4. 3GB of disk storage
5. Asus Radeon HD4850 with an Arctic Cooling heatsink
6. An LG combo HD-DVD & Blu-Ray burner

The bottom line is that this is a pretty high end system right now. It contains all the new-fangled hardware Intel just pumped out a couple months ago. My brother's system config looks like this:

1. 1.86Ghz Core 2 Duo (Conroe)
2. 2GB of DDR2-4200
3. 200GB disk
4. Intel X3100 graphics
5. Standard DVD
6. 3rd Gen Centrino chipset

Bottom line is that this is now considered an older entry-level laptop. It originally shipped with a 32 bit OS. Windows 7 Ultimate X64 went on smooth as silk and actually improved the performance of Ben's laptop. He said he felt as if the machine has a whole new lease on life. This is what we would expect from an SP2 level operating system.

My considered opinion is that Windows-7 is vastly better prepared to ship now than the original Vista RTM was. This is the best punch Microsoft has delivered since Windows XP SP2. When it ships, it is going to sweep over the land like a tidal wave. There mere fact that all you old and new hardware is supported in a rock-solid OS will be sufficient to cause people to jump. Easy setup makes for light migration pain. Quick setup makes for short rebuild-times.

Apple has had some fun in the past two years, but now they are in for a very rough ride. They need to batten down the hatches and secure for battle stations.

The one place where Microsoft can fuck themselves silly at this point is to listen to security wieners, and ratchet up UAC again. UAC was and is a bad idea. That is all. Only this and nothing more. We have always had unmanaged code in the system. It too late to impose management on unmanaged code. Attempting to do so is stupid and counterproductive. UAC should be entirely removed from the system. Fuck the security fagots.

I want to make another thing perfectly clear: All this paternalistic hand-holding has got to go. I don’t want to click “Yes I want to Install” 6 times before getting Adobe Flash installed under my web-browser. I do not want that system to prompt me before I unzip something I just downloaded. I don’t want the system to prompt me before running a Setup file I just unzipped after I downloaded. I do not want UAC to prevent NetBeans from launching Glassfish. I really get pissed when Windows interrupts large copy operations 10 or 12 times to ask “Are you really sure you want to Copy/Move this system file?” Fuck yes! That is why I copied/moved it, asshole! I do not want to have to go to PowerShell to type:

Copy-Item “C:\Music” J:\Music -Recurs –Force

Just to avoid the multitude of prompts UAC will throw when backing up my Music collection.

Honestly, I do not know what goes on inside these line-managers’ heads sometimes. Interfering with a backup process? They must be on drugs. Microsoft must have about 10,000 pounds of collective brain damage due to narcotics use. It takes 10,000 pounds of brain damage to cook up something like UAC. Just about all Windows developers shut off UAC immediately because of its wretched interference with simple productivity.

At the very least, you have to give us UAC setting levels where we can control how much disruption & interruption is going to be imposed on us.