Tuesday, January 24, 2012

On Why Scala is The Perl of JVM Languages

One of my first technical jobs was to develop a system in APL.  There are two lessons I still carry from that experience: one, I can write any program with fewer characters and two, that doesn't make it a better program.   The mark of a great programming language is not the number of characters you can write a program in (see: APL) but how well the language allows the program author communicate with program readers.  Is the meaning of sentences and paragraphs of the language obvious or do I have to "work it out."

Unfortunately, Scala (and most other modern JVM languages) seems to have learned all the wrong lessons from Perl.  When I hear programmers make fun of Perl, I understand that they are really making fun of all those unreadable Perl programs they've had the misfortune to have to have read.  You didn't have to write programs that way in Perl (and I didn't) but it sure seemed like there were too many $s, @s, bless this, and optional parameters that defaulted to $_ and just what did that evaluate to in the middle of a map.

And Scala does all of that.  Implicit conversions.  Methods that use symbols for method names.  A type system that used + and -, :< and >: to differentiate covariant and contravariant type and upper and lower type bounds and who even understands what those things are.  Semicolons are optional except when they're not.  Braces are optional except where they are not and sometimes they become parenthesis.  And too many nifty ideas like case classes that don't work with the rest of the language.

Look, we can all agree that Java suck.  I learned object oriented programming in Smalltalk.  Java really sucks.  And collection classes require functional programming techniques to really work well.  I am certain that you can write code in Scala that is more elegant and more expressive than Java.  And I am equally certain that you can write code in Scala that makes the typical CPAN library seem like a beacon of clarity.  Scala may be a better choice than Java, but that doesn't make it a good language.

And I like programming in Perl.

Sunday, January 22, 2012

On Why is George Karl Still Coaching?

The Nuggets won a close one last night in New York.  Playing their fifth game in seven nights and having arrived at 4:00 am, the team was clearly exhausted in the fourth quarter and overtime.  This was made worse by the short bench of Coach Karl, he played only seven players.  In the back court, this was forced by injuries.  But in the front court, this was a result of inexplicable decisions by the coach.  While Timofay Mozgov had one of his better games, in what universe is he a better player than Chris Anderson who Karl is increasingly reluctant to play?  Here are the per/48 stats:

Raw Stats
MinWP48WinsPTSDRBORBREBASTTOBLKSTLPF
Andersen204.2361.016.09.94.514.40.21.23.52.46.4
Mozgov284.0240.115.28.82.911.72.03.02.50.76.3


And here are the shooting efficiency stats:

Shooting Efficiency
FG%2FG%3FG%FT%eFG%TS%FGA3FGAPPSFTA
Andersen51.2%51.2%0.0%66.7%51.2%57.8%10.10.01.588.5
Mozgov52.1%52.1%0.0%73.7%52.1%55.3%12.30.01.233.2


By the stats, Anderson is not just a better player, he is a MUCH better player.  And he can't get off the bench in a game where the team is playing tired?  A game where they were giving up second and third attempts because they were too tired to rebound.  Really?

The Nuggets are an interesting team this year, a team of a bunch of good but not great players.  The only clearly bad player on the team is Mozgov who is a Doug Moe big stiff.  He's 7'1" and can't rebound.  This team will go only as far as George Karl's personal decisions allow, which is apparently not very far at all.