Julie Lerman parsed from an email of mine that I :

• am "kinda nervous" about Tina's first mammogram since her mastectomy,
• was "scared" by the 12' tiger shark I saw while diving the other day, and
• am "terrified" of installing a new hard drive

Apparently, I've got an inverter on my nervousness circuits.

(Incidentally, Tina just told me she got a clean bill of health on the mammogram.)

Microsoft has posted version 1.1.13.8 (whatever the heck that means) of their F# compiler, which gives me an excuse to discuss the book Practical OCaml by Joshua Smith.

Practical OCaml is a new release from APress. My favorite technical book of last year was Practical Common Lisp, by Peter Seibel, and I hoped that Smith could duplicate the feat. It looks like the book has a different editorial team, but follows some similar structural advice. Even if nothing else, both books are reasonably sized (~400 pages, not ~1,000) and divided in a manner that makes them very appealing for those interested in learning a programming language.

My main motivation for reading this book (other than the hope that APress had discovered a way to bottle the lightning of language evangelism) was that "pure" functional languages are inherently parallelizable. That is to say, the language semantics are such that a sufficiently smart compiler could correctly take care of threading the computation over multiple cores/processors. Since I am of the belief that the manycore era is going to require a sea-change in programming approaches, I think it behooves those interested in the future to gain experience with such languages. Concurrency is treated only tangentially in Practical OCaml and I am under the distinct impression that OCaml is not inherently parallelizable (I believe this to be the case with F# as well). Nonetheless, it's certainly true that concurrency is "easier to think about" when using functional approaches, so there're still things to be gained.

What I didn't realize was that OCaml is a very, very good language for writing domain-specific languages. It's pattern-matching semantics are quite advanced and lex/YACC libraries (ocamllex and ocamlyacc) are part of the standard distribution. While I feel that tools like ANTLR and concepts like Parsing Expression Grammars have the potential to displace lex/YACC, there's no questionthat lex/YACC is the dominant "species" in the world of compilers.

Having said all that, I'm afraid that Smith's book is not nearly as persuasive as Seibel's. I abandoned LISP long ago and Seibel made me reconsider that decision. I wanted to learn OCaml but could hardly sustain my enthusiasm through the first chapter. The first sentence of Practical Common Lisp is "If you think the greatest pleasure in programming comes from getting a lot done with code that simply and clearly expresses your intention, then programming in Common Lisp is likely to be about the most fun you can have with a computer." That's a good opening and I think accurately captures the undeniable aesthetic appeal of LISP. The first sentence in Smith's "Why OCaml?" introduction is "It's a fair question." That's a bad opening. At least, it's a bad opening when followed by five paragraphs whose greatest substantive claim is "OCaml helps the programmer to easily express normal concepts and actually express difficult concepts." If that doesn't take the wind out of your sails, rest assured that it is preceded by "Returning to the title question, if I were to answer the question in more mundane terms, I would say that...." That's the type of opening that calls into question the author's precision.

The tutorial that follows is structured well-enough, but the concepts are not presented as well as they could be. Here is the complete discussion of the I-would-think-important concept of mutable variables:

It can be tempting to use mutable references, but I suggest that you resist that temptation. I have generally found that, except in a few cases, the use of a mutable reference could be removed by fixing my designs.

This is not a rule in any sense of the term because sometimes a mutable reference is really the best choice. File input/output (I/O) is a good example because file I/O is often a nonfunctional chore. Some other functional languages deal with these nonfunctional chores by using monadic computation, but that might not always be necessary.

You can hide mutable references in OCaml classes to make their use less problematic (this is discussed in more detail in Chapter 19).

This is on page 23 and is not preceded by a discussion of why mutable references are undesirable or what monadic computation is...I can't resist: the index has only 1 reference for "monadic computation" and that leads to page 251's explanation that:

Monadic computations and monads in general are creations that open up a small loophole for purely functional languages. Although a purely functional language cannot have functions with side effects, it can have values that describe and contain side effects. This boils down to computational sleight-of-hand that comes with a cool-sounding name.

Oh. Alright then. I started the book under the impression that issues of mutability might be fairly important to understanding a functional language, but apparently they aren't.

APress is 1-for-2 with their Practical... series, I hope Practical Haskell comes up to bat next.

In the meantime, if you want a really good book I suggest: Practical Common Lisp.

This post is attempting to measure the speed with which a blog post can propagate across the blogosphere. Feel free to link to it.

Here's a good pattern to use when you have a domain object that combines non-varying and time-varying data. Perrin's modified the original pattern to use generics: a good choice. (Why is it a good choice? Because objects that combine these two types of data are usually conceived of in a direct-but-composed way: we don't think of a Product as changing it's identity because it is or is not on sale, but we do think of a Product and its normal- or sales-price as a combination of two things. While it's easily possible to express this type of structure using inheritance, making them parameters to a generic is a batter match with the conceptual model.)

Here's a challenge (for explicitly typed languages: for those with duck-typing it's trivial):

Design a Snapshot<T> such that you can query any property P in T for a given time. For instance, if you had Snapshot<PlayStation3> myPlayStation, you could query it's price using code similar to this form:

Price p = myPlayStation.ValueAt(myDateTime).Price()

Hint: Would the problem be easier (or possible) if you were to use a CTP?

If you're looking for the perfect Christmas gift for a geek and your budget is around $1800, this reproduction of the kit that started it all would be perfect.

A few days ago was launched the biggest, most experienced, development tools company to be created since the dot-com era. A company that's explicitly turning away from managerial buzzwords in order to concentrate on language implementations, libraries, and tool-chains that will cross platforms. The company includes people who developed some of the world's fastest-working compilers, most famously productive environments, and pretty much invented the models for software components that dominate software development today. The way in which the company was launched is controversial, with a very public reversal of a very public plan. To me, it seems like a big deal. 

How did Slashdot, Techmeme, Lambda the Ultimate, and the blogosphere in general react to this launch?

Almost complete silence.

I don't get it; I really don't.

It's not like I'm the world's biggest fan of Delphi and I don't get why the world doesn't share my enthusiasm. What I don't get is why there's so much more blogospheric coverage of Sun's choice of license for open sourcing Java compared to CodeGear. Heck, there's more blogospheric coverage of the latest mapping "mashup" than there is of CodeGear.

CodeGear seems like a big deal to me. Yeah, Borland's languages division has been neglected and lost status. Yeah, Borland's decision not to sell raises huge questions about commitment and investment, but I don't think the meaning of it all is so obvious that it doesn't bear comment and discussion.

Perhaps I'm just of a certain age and am assigning to CodeGear a weight they no longer deserve; perhaps the blogosphere's collective "meh" is an indication that people have no more faith in the former Borland division than they would in any other startup.

Time will tell. I expect fireworks from Scotts Valley -- for better or worse.

There was a short piece on the news last night about a $540M travel reservation system developed to aid the Department of Defense manage their travel costs (in peacetime). Apparently, it doesn't work (doesn't deliver low fares) and even if it did work, it would take 20 years of projected savings to pay for itself. A congressman is trying to kill the project, and Northrup Grummin trotted out a project manager to say "This is a project that works and of which the American taxpayer can be proud," while smiling incessantly.

Government software overruns are always scandalous. Back of the envelope: $540M / $250 / person/hour / 40 person-hours/work-week / 50 work-weeks per year = 1080 person-years of effort @ $250 an hour. The contract was granted 8 years ago, projected to go into service 4 years ago, and is "approaching full deployment."

"DTS has processed more than 1.87 million vouchers since its inception, according to DOD." That's not far from the number of travel vouchers that have been processed by reservation systems that I've architected. At the risk of putting myself out of work, I've gotta' tell you: travel reservation systems ain't rocket science. It's big databases, ugly data formats, and business rules. Business rules, of course, are expensive to get right and prone to change. Duh. But not person-millennia at $250 an hour. Nope. Uh uh. I know whereof I speak.

At what point does inefficiency shade into outright fraud?

Hey, isn't there some kind of Federal "whistleblower / watchdog" reward? Like, if I investigated this and gave the government cause to withhold, say, $100M in payments, I would get a reward of, say, a couple million bucks?

SD Times has a newsfeed. Huzzah! Subscribed.

A client relying on a 3rd party service which we had been assured was available received an email today that said "[The service] is in a stop sell mode at this time as we are evaluating etc."

I'm going to have to remember that the next time I approach a deadline: "I'm sorry, Dave, but that column is in a stop sell mode as I am evaluating content choices."

TeX and METAFONT have version numbers that asymptotically approach π and e. This reflects Don Knuth's decision that it's more important to create consistency with those tools than to add features. I've thought about something similar with programming language design: languages like Java and C# were very "teachable" in their initial releases. The addition of generics, if nothing else, makes them significantly harder to teach. Add closures, LINQ, type inference, etc. and you're talking about something that, while not C++, has very different "teachability" characteristics, if nothing else. Plus, there's the burden of supporting old decisions -- like the confusing way that C# deals with finalizing resources (using, IDisposable, ~Class()).

Niklaus Wirth may have been on to something producing a family of languages (Pascal, Modula, Modula-2, Oberon) each of which incorporated his experiences and current thoughts, but which were clearly distinct efforts. I suppose that programming languages have become the brands, so we have Perl 6 and C# 3.0, rather than "the latest effort" from Larry Wall or Anders Hejlsberg. I can understand why dissociating a person's name from a brand is good for the company, but I don't know that it's the best way to serve the industry. Maybe it could be like movies "From the people who brought you..."

The new spinoff from Borland, CodeGear, is strongly hinting that they will produce at least one dynamic language:

CEO Ben Smith: "We’re also working on plans that can help developers take advantage of growing and emerging areas like web services, Ruby, Python and Ajax. "

David I: "We are not limited to just a few programming languages (Delphi, Delphi .NET, Java, C++, C#)....[CodeGear will be driven by languags that are ] compiled, managed, scripted, dynamic and more...What will be the next CodeGear programming language?"

CodeGear FAQ: "The emergence of web services and new development capabilities from Ruby to Python to Ajax provide an opportunity for even more substantial innovation."

Obvious interpretations: a stack for JavaScript programming and debugging (Ajax) and at least one of Turbo Ruby or Turbo Python.

Borland's Developer Tools Group, including the Delphi, C++, C#, and JBuilder tools and the Interbase database tools, have been spun off into a new company called CodeGear to be headed by Ben Smith (Byte's old tech editor?). Contrary to all previous reports, CodeGear will be a wholly owned subsidiary, not sold off.

While Alan Zeichick is skeptical about the confusion (and I share his dismissal of "ALM" as a market separate from the development tools market), I take a measure of hope in my April observation that "if Borland corporate saw a way for a self-sufficient company to keep the balance sheet in the black, it would be spinning the division out, not selling it off."

Dr. Dobb's Journal has taken over the Jolt Awards now that Software Development is no more. Once again I'll be judging and, actually, serving as Moderator of the Development Environments and Languages category.

Given that we considered VS2005 last year (but, hey!, XNA) and given that Callisto is certainly going to be nominated, what other languages and development environments have or should have "Jolted" the industry in the year 2006?

IronPython went to 1.0 a few months ago. 

The re-released Turbo products? Were they just a reboxing of existing tools?

Perl 6 may beat the Dec 31 deadline, but JRuby won't.

I wonder if I can sneak in consideration of Piet, the programming language in which programs look like abstract paintings. (via Harry Pierson)

What new tools and books have helped you kick butt and take names this year?

I don't have an HDTV and I don't think I'm going to buy one in the foreseeable future. I watch TV every evening for a couple of hours. I like TV fine.

I have analog basic cable that requires no set-top box and for which I pay around $40 a month (it's bundled with my cable Internet, so it's hard to say). I live in a rural area on an island -- I really doubt that I get any HD programming over the air. If I bought an HDTV, my cable rates would climb a minimum of $20 as I would have to pay for digital cable, set-top box "rental," and an HDTV package.

Every broadcast show I watch -- everything -- I watch via time-shifted Tivo. If I had HDTV, I would either have to buy a new DVR ($$$) or give up 20 minutes per hour to commercials.

My favorite channels are old-time movie channels (TCM and AMC) and Comedy Central, which I don't think broadcast in HD. My understanding is that non-HD shows look somewhere between worse-than-before to terrible on an HDTV.

I have a 27" diagonal set. HDTVs are 16:9, so I believe that a 36" HDTV would provide around the same picture size for broadcast TV.

I watch DVDs from Netflix. DVDs are, what?, 720P? And presumably, you can somehow set them up so that the 16:9 HDTV shows them fullscreen. So those would look better.

So, I buy an HDTV for, say, $2500. Plus maybe $50 per month in recurring charges. In order to get a no-better picture for my favorite shows, watch new HD shows with commercials and without time-shifting, and get an incremental improvement in DVDs?

<GeekTone value="Spock">Highly illogical.</GeekTone>

Update: I grabbed 486i from some Google search for "NTSC" but after being mocked, I double-checked. So I guess standard TV is 484i. And HDTV's are 9:5, not 16:9? And DVDs are only ~480 resolution?

Bill de hÓra's post on the language's he's used in the past year contains the provocative thought "...some people are looking at things like HTTP and Ant and CSS and wondering whether they are really programming languages....[T]hey are either replacing or reducing the raw coding I used to do....[A]t least, if you start thinking about HTTP as a language, the job of using it becomes far easier...."

To me, the definition of a programming language has always been simple: Is it Turing complete? More practically, I skip any type of formal analysis and look for control structures and recursion. By my criteria, not only is HTTP not a language, SQL (as it's generally used) isn't either. This definition has two advantages: it's pretty bulletproof from a theoretical standpoint and, pragmatically, something feels "right" about assigning looping and recursion as the uniquely "program language-y" thing. Lots of things are complex or reduce complexity and lots of things have state that evolves over time, but solving problems by looping is what makes a solution feel like programming.

On the other hand, this view seems a little out-of-touch, if not anachronistic. Much of the "action" traditionally associated with language development ( conceptual mappings, problem-solving models, etc.) has shifted to framework development. Part of this is the evolution from "libraries" (generally, a group of related functions at the same abstraction level, such as a library for trigonometry or statistical analysis) to "frameworks" (a set of components of different abstraction levels covering an entire problem domain). Objects unified the vocabulary for discussions of behavior, data, and structure. Once that was established, patterns gave us a channel for professional discourse that previously might have required a shared language background (indeed, they're called "pattern languages.")

Further, something is wrong with actually writing a programming language. As Bjarne Stroustrup puts it, "On the order of 200 new languages are developed each year and...about 200 languages become unsupported each year." So on the one hand, you have the great value of expressing domain reasoning directly in code and on the other, you have a task that requires a large effort and which is almost certainly doomed. Perhaps one is smarter to simply embrace studying frameworks.

But ultimately I cannot believe that that's the right answer: frameworks are great, but I don't think they shift your reasoning in the way that a language does. I was fortunate enough to spend some time in my early professional years shifting back and forth between C and Prolog: two radically different languages. It was obvious to me that different parts of my reasoning were engaged by the different languages; I could be exhausted in C and fresh as a daisy in Prolog and vice versa. (In retrospect, it's probably fair to say that in C I was dealing with "housekeeping" and in Prolog I was solving "higher-level" problems, but in those days, low-level coding for data acquisition, transformation, and speed-ups was not optional.)

Stroustrup advocates Semantically Enhanced Libraries as the route forward. I note an echo of the modular compiler meme that Harry Pierson has mentioned (essentially: start from a complete language and extend/restrict it rather than start with a grammar and fire up lex/yacc). Those familiar with Lisp will naturally point out that extending/restricting the base language is precisely what Lisp macros do; the disadvantage being that the language being extended/restricted is Lisp (which I don't mean in a snide way, but simply in the way of acknowledging that the market has declined to embrace Lisp over the course of forty-five years).

Given my belief that the shift from single- to multi-to many- core is going to be the issue in programming within a half-decade, I naturally think we need tools for exploring new semantics. To me, it still seems that the best tools for that are new languages, not new constructions built on sinking foundations.

Tim Bray compares Frameworks (Source: Still done seeking). I largely agree with Tim Bray's analysis, particularly the point that all major web frameworks will scale sufficiently and that, in the long run, maintainability is likely to be the most important factor in the attractiveness of a framework.

 By that token, Bray recommends Rails and Java, and is skeptical of PHP.  I think this is probably right, and that ASP.net, using C# or Visual Basic, would compare to Java.  The Rails advantage, according to Bray, derives from Ruby's increased expressiveness: fewer lines of code means clearer code.  While that's often true, it ain't necessarily so (metaprogramming can be very hard to understand). Further, implicitly typing language has disadvantages for maintainability.  Further, one should not ignore the ease with which one can hire a maintenance programmer, which will be certainly easier if one chooses a Java or C# framework.

In my opinion, the jury is still out on the relative maintainability of Ruby on Rails versus Java/Struts and ASP.NET.

Off Tonga, a volcanic island has emerged from the depths. How cool must that be to see?

 Alan Zeichick explains why if you must get a new passport, you should invest in a lead foil billfold.