Passer Rating App

When Dallas Braden pitched his perfect game a week or so ago, the NFL Network celebrated that achievement by counting down the top 10 perfect Passer-Rating games of all time. This, of course, begs the question just what is a perfect Passer-Rating game anyhow?

Of course, this doesn't mean no-sacks, no-interceptions, no-incompletions, and no QB penalties (such as intentional grounding) as I think it should. I think we would still be looking for that first perfect performance if such was the case.

Rather, a perfect passer rating is defined by the passer-efficiency formula. There is a hard-cap of 158.3 on that formula, but it is not imposed by the formula. It's just imposed by rule. You can read these formulas here.

Fran Charles showed us the formula on screen and declared "If you can understand that math, you have a large amount of money in your future." Not being a man given to math anxiety, I wanted to have a good look at it, so I hit the pause button. 'Twas nothing! The formula is piece of cheese cake with some cherry sauce.

When I saw that, at around 12:30am in the morning, I had to fight the urge to flip open ye old laptop and scribble some code. I figured I could code it in under 20 minutes. I had some down-time at work this morning, as per usual, and I decided to give it whirl. The class which does the calculation was trivial. It was more effort to rig the WPF test form than the class which calculates the formula.

Just 75 lines of code, no mas. It could have been smaller and more compact, but I decided to put in some luxory items, like the NCAA passer rating formula, and the passer's first name and last name. I didn't have to do that. There it is in nice shiny Microsoft C# 4.0 code.

Grad total of effort: Maybe an hour and a half. It could easily be converted to Java in 20 minutes or less. Mayhaps I will do that with NetBeans tomorrow. Same goes with Visual Basic.

So I suppose the main question is this: Does NFL.com have a WebService API and can lock-on to and feed my app. I can do real-time passer ratings with this app if I take it a step or two further. It would make a nice Google Android app.

Trying to rain on Windows-7's victory parade

For those of you who do not know, Windows 7 is out. You should be able to get it with any newly manufactured system, and through most retail sources. The Wallstreet Journal and several other sources have begun reporting market data on the early sales of Windows 7.

In the U.S., sales through all channels is equal to 182% of that Windows Vista during the first few days on the market. Sales of boxed copies, by far the toughest SKU to sell , is 234% higher than Vista during the first few days.

These figures are shocking given the relative strength of the economy during the launch of these two systems. The economy was "strong" in 2007, with the Dow Jones finishing at 14,000 in October 2007. This is when Microsoft launched Vista. We are mired in a nasty recession now, the worst since the Great Depression, with unemployment over 10%, and under-employment between 16% and 18%. This is the moment Microsoft has launched Windows 7.

Given the long-term, stable, statistical fact that most people get a new OS with a new computer, nobody, but nobody would have predicted this level of success for Windows 7. People aren't supposed to be buying new computers under economic conditions such as these, nor are they supposed to break statistical trends by upping old computers to Windows 7. Any fair-minded analyst has to shake his head in disbelief. Against the odds, Microsoft just hit one out of the ballpark. This is tantamount to smacking a 2 run home run again Mario Rivera in the 9th.

I hate to bring in this spectre, but piracy is also much more prevalent today than in 2007. Vista DRM and licensing vexed pirates for a time. They seem to have figured out how to bust Windows 7 rather quickly. High piracy rates should negatively impact sales, or so we would think. You can't prove that theory if you look at the current sales figures of Windows 7.

After you kick these facts around for a few hours, the theorist is left to one conclusion: Microsoft must have fundamentally gotten it right this time. The customer has to see some value in this product, or they would not be extending themselves in this way, at such a time as this. This is a huge disappointment for the anti-Microsoft crowd in the Java, Apple, and Linux camps. They are sitting around with big, fat, black-eyes and a headache this morning.

So what are they doing about it? They are inventing large headlines which lie with strange statistics, and stranger claims. Consider the following:

• TechWorld reports that Windows continues to loose market share world-wide. Their figures show that Microsoft 0.23% of the market during October. Apple picked up 0.15% during that same period. Wow... My heart is racing.
• Sophos claims the Microsoft left Windows 7 open to hackers. They neutered UAC too much, says Chester Wisniewski. They were actually able to install 7 out of 10 Trojans... as long as there was no anti-virus software installed on the system. Jeeze... I shit myself when I read that.
• Stranger still is Preston Gralla's weird claim that Windows 7's unexpected success is a bad thing for Microsoft. They are now doomed to turn into General Motors. Err.... WTF? Yeah, a smart guy named Jay R. Galbraith says its a bad thing. You see, Microsoft is going to stick with the desktop instead of going to smart phones now. You see if Microsoft wants to remain relevant, they have to fire all their managers and become Google.Apple with web services and a smart phone.

As I mentioned before, I do not suffer fools lightly or well. I want to know who enfranchises the crack-pots? How do you get a license to become a professional crack-pot? How do I manage to get crack-pot remarks on to the News.Google.com web page? How do you get people to actively quote nonsense as if it is meaningful? How do you get bullshit to pass for knowledge and information? How do you throw spaghetti against the wall and make it stick? How do you babble meaninglessly and make people think you are anything but a complete fool? How do you spin tales told by an idiot signifying nothing and make money while doing so?

One wag commented that nobody ever when broke over-estimating the stupidity of the American people. This is the popular paraphrase of the sage of Baltimore, H.L. Menchen. Maybe these crack-pot websites are indicator that his saying is true.

So just what is a Dynamic Language anyway?

It's remarkable to me how many friends I have in the business who aren't really sure just what the heck a dynamic language is anyway. Many things they say to me indicate that they don't know what a dynamic language really is. For the record, let's clear it up.

Let's start with a quartet of distinctions.

1. Object Oriented Language
2. Interpreted language
3. Weakly typed language
4. Dynamic language

• An OOPS language is not necessarily interpreted, weakly typed, or dynamic.
• An interpreted language is not necessarily OOPish, weakly typed, or dynamic.
• A weakly typed language is not necessarily OOPish, interpreted, and not necessarily dynamic. This is one of the most frequent bits of confusion. Many believe Weak = Dynamic.
• A Dynamic language isn't necessarily interpreted, but it is always OOPSy and weakly typed.
• With that said, most dynamic languages are interpreted and weakly typed.

Here is a list of languages that are not dynamic, although some think they are:

1. JavaScript
2. VBScript
3. Perl
4. PHP
5. Lua

Here are a list of languages that are truly dynamic:

1. Smalltalk-80
2. Python
3. Ruby
4. Groovy

So, you will notice that most of the popular and well known interpreted scripting languages are not dynamic. More obscure choices, selected by the ubergeeks, are the dynamic languages. Being weakly typed is necessary but not sufficient to be classified as a dynamic language. I would have said that being interpreted was necessary also, but then along came IronPython.NET and blew my world appart.

So what is the key? What distinguishes the dynamic language? The answer is in the meta-programming model. In a dynamic language, no class is ever final, not even at run time. It is not only possible, but common for a dynamic interpreter to mock-up or attach methods to a class or object at runtime. I can also tack on additional properties at runtime. I can also write code that edits its own source code, and dynamically reloads it on the fly. I can create self-mutating code. This is the key feature which permits research into genetic algorithms.

Can I attach new methods and properties to a class at run-time in Java and C#. No, not per se. There are ways to try to achieve a similar effect, but these belong in the category of dirty hacks. This approach is absolutely not supported by either of these languages. How about VB.NET? Nope. How about VBScript? Please! This isn't even an object oriented language! How can you attach new properties and methods to something that is not a class in the first place? Same thing goes for JavaScript.

So why the hell would I want to dynamically dispatch new methods I never intended to be a part of my class when I designed a wrote it? Why would want to dynamically attach additional properties to the object at runtime? Isn't this unsafe and unsound? Aren't I allowing the interpreter to alter my architecture in ways I did not intend?

Maybe, if you don't know the language and don't know how to use it.

What if I do know the language and do know how to use it, doesn't the mere existence of such a feature open the door to entirely new categories of unintended consequences and unpredictable behavior?

That is the rub now, isn't it? We have put out finger on the exact point of critique which serious computer scientists have been arguing about for several years now. Decades really. Ever since Smalltalk-80, this debate has been running among serious men of great learning and skill.

The majority have chosen not to use dynamic languages. The majority have chosen statically typed OOPs. A rather small minority have chosen dynamic languages.

So, why have those who have chosen dynamic languages chosen dynamic languages?

• Very loose coupling. You can pass anything to anything. If it works it works. Very large systems can be built this way.
• Interpreter safety: If it doesn't it throws a soft error and you make a correction. The OS does not crash.
• Auto-Mocking. These days, we have come to recognize that we need automatic testability for all code. We call this Unit Testing. We aim for 100% code coverage. This means we want every line of code automatically tested in a unit test project. To facilitate this process, you need something called mock objects. These are objects that doppelgangers for dependencies your test unit needs to function, but they do not produce the real world side-effects. Real files do not appear and disappear. Real records are not created, read, updated, and deleted.
• Mocking in a static language like C# and Java is a real pain. Python and Ruby just construct Mocks for you, dynamically attaching empty properties and methods for your. You never need to write Mock object when doing TDD in Python or Ruby.

Isn't there a substantial performance penalty for this approach?

Yep, Ruby and Groovy are the two slowest languages currently accepted in the world. Although Smalltalk and Python are faster, they are not that fast. We can pretty well destroy them with C#.

With that said, a fully compiled variant of Python, called IronPython.Net is now making some waves in the world. IronPython's compiler is written in C#, and it cranks out CIL like all the languages on the .NET platform. This CIL assembly is locked and loaded by the CLR and handed over to the JIT for transformation to x86 or AMD64 code. That code is greatly fattened and slowed by the dynamic approach to things, but it is real machine code. IronPython is now something like 8x faster than standard C Python. It is still not as fast as something like Java or C#, but it is still far better than it's brother and cousins in terms of performance.

I personally am very interested in IronPython.Net. However, I am more interested in Scala.

My religion is generally opposed to Dynamic languages. I believe in static typing. I believe in a strong compiler. I believe in things like checked exceptions. I love design my contract. I love annotating requirements on code. C# does not give me as much static verification as I would like. I hope Scala is better. Python means busting my version of the 10 commandments. This is risky, and I dislike the notion. However, I am trying to keep an open mind, and determine whether IronPython can provide some wonderful new service to my .NET applications.

The problem with C# 4.0

I hear many things about my favorite programming language these days.  Not all are favorable.  Some statements conflict.  There are a couple of facts about the latest edition (additions) to C# that cannot be denied.

1.  Anders has added in support for dynamic language interop.  This is mostly a matter of implementing a new static type whose static type is dynamic.  I guess that is the C# way to do it.  Basically, a declaration of 'dynamic X;' means we will obtain a boxed object with some metadata attached to it to let us know what type it really is.  This is almost like generics in Java.  The performance penalty is not too terrible at run time when all factors are considered.  Still, there will be a penalty.  This won't be high performance.  Worse, there is no question that this is full-bore late-binding.  In any late binding situation, you loose type safety.  No compiler can ever predict that any piece of late-bound code will ever work, or work in all scenarios.  The compiler will go along with it, presuming that you know what you are doing.  When the build is successful, do not presume that the compiler has endorsed your code.

2.  Anders has added support for optional parameters, so we can now have pain-free use of C# in connection with the dreadful, much-detested, out-dated, out-modded Microsoft Office object model.  Optional params are big in OLE2 or COM or ActiveX or whatever you want to call that disgusting old shit we used to do.  Lamentably, the dastardly Microsoft Office object model is still a filthy COM beast.  You should obtain less painful interops with all COM servers because of Anders most recent additions to C#4.  Still... this is a dirty thing to accommodate.  It is the programming equivalent of saying "have sex with HIV infected individuals, just use this condom".

3. There is also some stuff about co & contra-variance with greater safety.  I have never stubbed my toe on Co & Contra Variance, so I see no issues solved here.  I suppose this helps in a few marginal edge cases.  I know of none in my code.

4. Finally, Anders & co are re-writing the C# 4.0 compiler in C# itself, thus making the compiler available as just another managed code software services at run time.  The presumption is that C# 4.0 programmers will now use this handy-dandy, ever-ready compiler to engage in meta-programming techniques and tactics.  Once upon a time, this was the exclusive privilege of people coded with Interpreters.  Java programmers can only get access to this sort of dynamism through a jar library called Janino.

These last two items are of no consequence to guys like me.  Some may be jumping for joy, but I don't need a runtime compilers just now.  

Surprisingly, the announcement of these language features has tripped off a debate surrounding the question of whether C# is getting too big for it's britches.  Some say that C# is becoming an over-bloated Swiss Army knife.  I really think this debate misses the point entirely.  The issue is not one of whether the language is getting too big, but rather whether it is growing in the wrong direction.

Certainly, I do not welcome the advent of the dynamic type.  I don't need it, and I don't plan to use it.  I suspect that the mere presence of this type will slow the compiler considerably.  I hope it doesn't result in generally fatter CIL for all, which would in turn lead to fatter X86 code.

I am not a fan of optional parameters.  Optional parameters are element & aspect of a generally sloppy approach to programming.  That is why they are in VB.  They are not unlike the unstructured goto statement.  They are just bad for your code.  Either a param is necessary or it is not.  If it is necessary, it should always be required, and it should always be set.  Programmers should not be allowed to 'safely' ignore a parameter. This is one of the many ways in which unexpected and somewhat unpredictable behavior emerges in a system.  Programmers should be aware of the change in behavior flag settings will produce.  Of course, I realize that Optional Parameters were big in the days of COM.  This is one of several reasons why COM was a dirty, fifthly, nasty, ugly, disgusting, detestable, nasty, wretched, leaky, buggy, unstable, evil piece of shit.  [Did I mention that COM had no security model and was single handedly responsible for the Great Spyware Pestilence of 2003?]  There are explicit reasons why we flushed COM down the toilet in .NET.  One of the reasons optional params were rejected in C# is that we wanted to rid ourselves of this corruption.  Now here we go again.  Not good.

I understand why Anders reversed himself.  Many, many, many C# programmers have been bitching for years about how difficult it is to drive the Microsoft Office Model because C# does not support optional params.  Anders caved in under pressure from customers and the high command.  In a very real sense, I know this will make my life easier when I must do an Office automation project.  Still, I do not look forward to fully managed C# library, with no element of COM, which show optional params all over the place.  This eventuality will signal the arrival of sloppy coding techniques in the rather purist world of C#.

My real bitch is that the two language features we really need the most did not make it into C# 4.0.  What are those features?

1.  Traits, just like in Scala

2.  XML literals just like in VB.NET

In all honesty, these are the only two linguistic innovations I have seen in the past 6 ot 7 years that did not originate in the C# project.  

Traits are basically implemented Interfaces which you can tack on to almost any object.  They give you the advantages of interfaces with the advantages of mixins in Ruby.  The final yield is a language feature which gives you the reliability of single inheritance with some of the advantages of multiple-inheritance.

XML literals threw me for a complete loop.  XML literals took VB, a language which was dying IMHO, and suddenly made it the best language for the MVC framework. You don't know how much it hurts me to say this, but I would never want to code a helper class in MVC without the aid of VB.NET XML literals. This is not to mention all of the complex XML transforms which this system makes incredibly easy.  

XML literals are probably the greatest, most practical, most useful idea I have encountered in the past 5 years.  The biggest thing since Generics.  Scala also has a form of XML literals, but they don't seem backed by the sort of library power VB.NET offers.  In any case, C# should have had this feature.  Omitting XML literals from C# 4.0 is the same thing as capitulating the MVC framework to VB.NET.  Anders needs to take notice of this fact and make some corrections.

So the final verdict is clear.  C# is not guilty of getting too big.  C# is guilty of expanding in the wrong direction.  C# is guilt of not expanding in the right direction.  All-in-all I am quite disappointed.

Java programmers are just hog wild about AOP

Recently, a flaming post went up on the DZone.com website.  A Java fellow posted a blog in which he bluntly stated that he would much rather employ Java programmers than C# programmers.  The absolute point of the piece is that AOP is extremely popular in Javaland, and all Java programmers (young and old) are well versed in the paradigm.  Such cannot be said for the C# programmer.  C# programmers seem to think that AOP is for testing only.  We don't seem to understand the other mega-benefits of AOP.  For this reason you should hire Java guys, not C# guys

I've given this political statement consideration over the past several days, I am completely sure that this a further example of the ethnocentric and narrowly learned specialization of all programmers in our field.  You see, the Java guy clearly doesn't understand the deep strategy of C#.  Neither does he understand the deep strategy of Scala.  Neither does the C# programmer understand why AOP is totally essential to life in the Java ecosystem.  The C# programmer does not understand why a lack of events and delegates in Java would push the entire ecosystem towards AOP.

Let me tell you about it.

Since the dawn of time, the dream of programmers everywhere has been code reuse and modularity.  We want to stop writing the same code over and over again every time we start a project.  We want a nice library we can compose with.  Composition is a big fucking word in our profession.  It is the dream of the blue turtles.  We want to write just those little bits of app-specific logic our customers demand.  Composition and reuse are the absolute ideas driving most changes over the past 30 years of computer languages.

Simple OOPs is nothing more than an attempt to achieve composition and reuse.  In the days of Smalltalk, simple OOPS worked out fairly well.  Because of the weak typing system, simple objects did the trick fairly well.  It was easy to interchange BaseA object with ModifiedA object, or BaseA with BaseB, or ModifiedA with ModifiedB.  The weak and dynamic typing system just went along with it, and if it could work, the interpretor would make it work.  For this reason, composition was pretty dang easy in Smalltalk.  There was pretty good code reuse in Smalltalk.

The problem is that a lot of us hate interpretors and weak typing systems.  A lot of us out-right fear dynamic systems for their unpredictable behavior and their slowness.  Others hated the ugly and goofy looking interface of the Smalltalk virtual machine.  Ergo, Smalltalk was not widely adoped and it ultimately died.  It was always a niche thing which the Ubergeeks used.  It is now having an interesting undead afterlife in the form of Squeek, but Smalltalk is dead none the less.

In response to Smalltalk, a number of strongly typed and compiled OOPs languages were invented.  C++ and Object Pascal were two perfect examples of this movement.  The problem was that they were only half-assed OOPs languages.  They were also structured.  A lot of Dephi programmers programmed in flat structured Pascal and claimed to be object oriented.  Likewise, a lot of C++ programmers were really writing C code and claiming to be object oriented.  As you might imagine, this approach did little for Composition and Reuse.  Worse still, once the language is strongly typed, interchange of BaseA object with ModifiedA object, or BaseA with BaseB, or ModifiedA with ModifiedB is no longer possible.  The signature of a function or a method demands a specific type.

Next, Java came around with a simple language and simple OOPs and the notion that you should inject dependences in an AOP fashion.  In this approach, you pass everything by interface type or abstract class.  This loosens the type system enough so that interchange of BaseA object with ModifiedA object, or BaseA with BaseB, or ModifiedA with ModifiedB is possible... with in some limits.  IoC and DI were formalized in things like Spring, AspectJ, and Guice to make this even easier.  You get pretty good code reuse in this AOP approach to doing business.  Implicit within this success story is a clear cut admission that pure OOPs doesn't yeild composition and reuse when you are compiled and strongly typed.  You need to take an AOP approach, or you don't get composition and reuse at a good high level.  

At roughly the same time (a bit earlier) Delphi came around with the notion that you should have something greater than objects called components.  These should be wired together with delegates and events.  Delphi died.  Java won by default.  Delphi was reborn as .NET and C#.  Suddenly the battle was renewed.

Of all the things that have triggered the greatest number of flame-wars between Java and C# programmers over the past 8 years, a pure lack of understanding of the .NET Component is top of the list.  C# programmers know they have components.  Some are dimly aware of how they work.  Many of them have no ideal in the world that Java lacks components.  They don't understand that strategy and command patterns are built into the CLR as first class citizens.  Specifically, strategy=events and command=delegates.  [Some would rap my knuckles for making that hard fast association.  Bring it on.  You'll get knocked the fuck out.]  These first-class citizens of the .NET framework are the foundation of components and loosely coupled, modular, composable, reusable code framework that we enjoy in the .NET system.

Java programmers do not understand this.  Events, delegates, properties, full lexical closures, all these things work together to make AOP far less necessary in the .NET programmer's life than in the Java programmer's life.  Coversely, because you lack events, delegates, properties, full lexical closures in Java, you need AOP much more than we do.  We get good composition and reuse without AOP.  We get good simple code without AOP.  If you think your AOP code is clean, you should see our component code.  It is wired together and loosely coupled with Events and Delegates.

This is not to say that AOP is completely irrelevant to the C# programmer.  Many of us, especially me, are asking serious questions these days like:

1. How can we take advantage of some of the goodness of AOP?  

2. When should I select AOP rather than a component approach?  

3. What are the specific scenarios where AOP is preferable to writing a component?  

4. Can AOP improve certain approaches where components don't work so well?

5. If so how?

So far, there is a lot of debate about this topic among serious minded C# programmers.  We don't have a lot of clear-cut, indisputable design-wins and use-cases for AOP.  Logging application activies and errors is one winner.  Automatic unit testing of production code is another.  This is strong sign of the high value of components.  They only break down {with certainty} in a couple of scenarios.  Of course, we do not yet understand AOP as well as we will in 10 years time.  In that time we may have even more compelling use-cases for AOP.  Right now, we don't.

It should be noted in passing that several veteran polyglot programmers are rallying against AOP in the .NET world.  In particular, the gentileman scholar Ted Faison has written a super book called "Event-Based Programming:  Taking Events to the Limit".    I remember Ted well from my Delphi days.  He was a great Delphi programmer.  Like most of us, he moved with Anders to the .NET platform and C#.  I like him and respect him, so I read his book.

Although Mr. Faison doesn't say it bluntly, a careful consideration of what he says in this book boils down to the following: "All of you C# programers runing toward AOP are headed in the wrong direction.  Don't do AOP just because the Java guys do AOP.  Use the events and delegates in our systems to wire together components, and you will obtain better and looser coupling.  This will give you the best possible composition and reuse you can obtain today."  I reached a conclusion that mega-AOP, as it is practiced in Javaland, is a specific solution pattern, in a specific language, which lacks key attributes we have.  Ted Faison might not have actually said that bluntly in his book, but I achieved that realization from reading his book.

This conclusion becomes even more interesting when you consider the design goals of the Scala language.  For those who don't know about it, Scala is Java's replacement and successor. This is like Marcus Ulpius Nerva Traianus taking over for Marcus Cocceius Nerva.  It is the succession from a good emperor to a better one.  Martin Odersky is explicit in his design manifesto for Scala.  Two questions drive him:

1.  Can we provide better language support for component systems?  He wrote a nice paper and did a video about this subject.

2.  Can we find a perfect fusion of Object Oriented Programming and Functional Programming at the same time?

Dr. Odersky very delicately offers a tough critique of Java in Scala.  You don't actually have a delegate in Scala, but you don't need one.  You pass functions without any delegate machinery in any functional language.  You don't have interfaces in Scala, but you don't need them.  You are better served by Traits, which give you all of the advantages of Interfaces, Mixins, and Multiple inheretence.  You don't have to pass things by Trait or by abstract class in Scala.  Type Inference and fully-orbed Generics will get the job done for you.  This generic based polymorphism obviates the need for OOPs polymorphism.  All of this adds up to a system which can do serious components, composition and reuse.

But this Scala approach to the problem is not well understood by Java programmers.  This is where they are going to have a big problem adjusting to life in Scala.  As a proof consider this:  A Java programmer learning Scala posted up at the Scala-Lang.org site.  He asked the following question:  How do I use Guice in Scala?  Since he was a Java programmer who did not want to reinvent the wheel, the question is perfectly understandable.  One of the Scala team members on the site answered his question.  Paraphrasing, the team member answered that AOP is basically out of place in Scala.  You can use it.  It is not recommended.  It isn't the Scala way of doing things.  Scala uses components.  Scala achieves composition and reuse by loosely coupling components together.  You don't have to inject methods, objects or any dependency anymore.  Use a trait, or pass the function or class to the object.  The old problems are not a big deal anymore.  To get the juice out of Scala, you need to get the Guice out of Scala.

The Java guy seemed extremely disapointed that the Scala team did not appreciate the great value of AOP.  It was likewise, I am sure.

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,