Lang.NET Highlights

Jason Bock and Ted Neward did a good job summarizing specific talks, so I won’t duplicate that effort.

Overall, I loved the conference, it was revitalizing for me. The speakers varied greatly in their presentation skills, but I actually liked the “texture” that gave the conference; you definitely didn’t have the feeling of homogenized content. There were only two talks that struck me as near-useless and, from me, that’s high praise.

Most impressive technologies:

  • Newspeak by Gilad Bracha. I was utterly blown away by this. I never thought I’d think “Wow, that looks better than LISP for building languages!”
  • Intentional Software as presented (and explained at the bar) by Magnus Christerson. I think I finally “get” intentional programming and, with that epiphany, reverse from being extraordinarily skeptical of its value to being extraordinarily impatient about getting my hands on it.

Most impressive application:

  • ResolverOne from Giles Thomas and Resolver Systems. Hands-down brilliant. The top half of the screen is a spreadsheet, something familiar to 100,000,000 users. The bottom half of the screen is a programming editor. Click in the programming editor, type:

def foo(v) :
return v + 1


Click on the spreadsheet, put “1” in A1, and in A2 “=foo(A1)” and see the results of your Python function. Look back in the programming editor and see your spreadsheet expressed programmatically. I intend to write more about Resolver soon. Like OneNote, this is one of those applications that give you a shock of recognition — “Yes! This is what I want!” — and makes you lament how much effort we spend gilding lilies in our industry when we ought to be spending our time out trying to come up with this kind of real innovation. (Plus: it’s a fascinating development story… More tk.)

Stupidest Thing I Said: “Why did the OLPC choose to emphasize Python when it ships with Smalltalk and Smalltalk is clearly a better–” At which point I was struck by a sock filled with quarters. Now, in defense, the sentence I’d intended to complete was not, as my assailants later asserted, “–language” (Hey, I’m the one wrote wrote “The myth of better programming languages“) but “– learning environment?” But even so, after Jim Hugunin’s talk (in which it took him three lines of code to import the XNA framework, XBox controller library, and Microsoft Robotics Studio connection) and Giles Thomas’ talk (Resolver), I withdraw from the field.

Second-Stupidest Thing I Said: “Intentional Software? Simonyi’s galley slaves? Those guys are the Duke Nukem 3D of programming — they’ll never ship!” “Well… actually we’re in beta now, and have you seen the boat? It’s quite nice.”

P.S. I had to leave at mid-day Friday, meaning that I missed several talks that might have been highlights — I was very much hoping to hear Chuck Esterbrook’s talk on Cobra, which takes Eiffel-style Contracts and extends them with integrated test-specification (finally!).

Off to Lang.NET


imageimageYesterday I went swimming on a coral reef in 100′ visibility with whales singing so loud that I almost expected to see them underwater. For the next 3 days, I’ll be in Seattle, where I assume they have this thing I hear about called “heating.”

Actually, after canceling the trip because I had such a non-productive, unlucky, and generally lousy January I decided at the last minute that the best thing in the world for me was to be in a room filled with people who totally out-class me.

My plan had been to spend, like, 6 weeks developing something and then saying “Well, I threw this together on the flight over…” and then have people say “well, it sucks of course, but for a plane flight, it’s not bad.” Now I’ll just sit quietly in the corner. I’ll be the guy wearing three layers of sweater over an aloha shirt….

Practical Mathematics: You Should Wait For The Bus

I used to live several miles from Harvard Square, which was (a) a destination in and of itself and (b) the last stop on the Red Line (back in the day). I used to live about 5 minutes from the Belmont Center route, which ran occasionally, and about 15 minutes from the Waverly Square route, which ran more frequently. However, if I went to the Belmont Center route and walked another 20 minutes, I could get to an intersection served by the Arlington buses as well as the Belmont Center bus. However, doing so involved abandoning the Belmont Center route for about 5 minutes, during which, of course, the bus for which I had been waiting might very well drive by… 

Aside from trying to figure out if you got more, less, or identically wet by running or walking through the rain, the question of how best to get to Harvard Square was a central preoccupation of my teenage years. Mathematicians have concluded that I should have waited for the bus.

Programmer Productivity Pumped Post Picture-Picking Paradigm?

Mitch Barnett responds to No Silver Programmers with a discussion of visual programming in BizTalk:

[Y]ou drag n dropped onto the canvas (kinda like Visio) and then you would set a bunch of design time properties and sometimes call out to some C# assemblies, or web services or adapters, but most often it was a matter of using the design surface, which included a designer for mapping one file format to another and a rules engine design surface, etc.

If you thought of the designers as “raising the level of abstraction” or a visual Domain Specific Language, in a lot of cases, not much real C# code was written ? you spent most of your time in this abstract kind of world.  Point being, when I was hiring programmers, like in the traditional sense of yeah, I can write lots of C#, I found that some programmers found using the designers, very easy and others, just could not get their heads wrapped around, to the point, that they could not actually do the job ? period. 

Meaning that in this specialized instance, I found programmer productivity was totally dependant on how well your head dealt with abstractions and not traditional programming constructs ? to the point where some of my guys could whip out a BizTalk solution in a matter of days, others maybe a week or so and others, never.

[Emphasis Added]

Just to be a skeptic, I’m not sure that there’s just 1 thing (raising the abstraction level) going on when you’re developing on a design surface. You’re engaging the visual and spatial and pattern-recognition components of a your mind in a way that, perhaps, leads to different problem-solving skills (whether inherent or learned). I dunno’. The interesting thing would be to study the problem-solving ability of developers using a visual design surface with an equivalently high-level abstraction that used a text representation (block_1 = new Foo; block_2 = new Bar; block_1.outputPlug1 -> block_2.inputPlug1; etc…)

A related point, and an important one, is that different languages “engage” your mind in different ways and part of the joy of being a computer programmer is finding a good match (or better yet, good matches) for your particular wiring. Personally, I quite like pictures in some development tasks, but have never found a visual design surface that actually delivered a high-enough level of abstraction (in terms of “things you can do with code,” i.e., meta-programming, reflection, code generation).

Hackstat : A Framework for Software Development Process Data

Philip Johnson tells me by email of Hackystat:

[A]n open source framework for collection, analysis, visualization, interpretation, annotation, and dissemination of software development process and product data….

Hackystat aspires to be the “Apache” of software engineering measurement systems: open source, standalone, scalable, extensible, and platform and technology neutral.

Our current thrust with Hackystat is “Collective Intelligence for Software Developers”, and we are thinking about things like annotable Simile/Timeline representations, mashups with Facebook and Twitter, and other ways to create a kind of collaborative sense-making between man and machine so that metrics can be reliably and efficiently refined into actionable knowledge.

I’ve long been a fan of metrics, but traditionally programmers have resisted the introduction of metrics due to a (probably reasonable) fear that simplistic measurements would be tied to performance reviews, e.g., “Gee, you didn’t add nearly as many lines of code to the system as Bob. No raise for you!”

Hopefully, the time of such fears has passed and Hackystat or a similar project will start giving us some of that missing data.

Development Homeruns

In email, Charles Gallo makes a point regarding “No Silver Programmers“:

I think the HUGE difference between the mean programmer, and the silver bullet programmer is NOT how fast they can code “x” function points. The HUGE difference is when they sit down to solve a problem, and they can come up with an “elegant” solution to the problem that takes 1/2 the number of function points (or less), and therefore even the average programmer writing the design that these super programmers came up with would do it in 1/2 the time and with 1/2 the bugs (because there is 1/2 as much code).

This is definitely a fair point — good programmers sometimes hit home runs. I had a case in point last year, when I had a client that had a problematic partner. The partner had a solution that they believed to involve such a huge barrier to entry that they could charge whatever they want, not respond to user needs, etc. Well, sadly for the partner, the barrier to entry was “write a parser.”

Parsers are hard if you don’t know what you’re doing. Given their adamant refusal to make requested changes (not “that will take time” or “that will take money” but “no, that cannot be done”) and confidence in their position, I strongly suspect that their parsing code was a very big, very complex hairball of hand-crafted code. On the other hand, I had Antlr, the Visitor pattern, and a couple weeks.

But the question is not “do homeruns exist?” but “To what extent is overall productivity affected by homeruns?”

This is a hard question to answer. On the one hand, you can say “Homeruns are infrequent — even the best programmers spend a lot of their time doing mundane work.” On the other hand, you can say “Homeruns, though infrequent, have ongoing effects on the system. Implementing a new Visitor over a nice AST is easy, if not entirely trivial.” And, sometimes, a homerun can be something like Google’s PageRank and have consequences vastly greater than “who has above-average productivity?”

I’m going to try to wiggle out of the conundrum by saying that homeruns (or even “extra-base hits”) more often come from design and architectural decisions than from actual coding techniques. Not always, but more often. And once you raise the question of the distribution or impact of architectural talent, I don’t think we have any data. And since we don’t have any data about it, I think it’s very hard to reason about it. I have my biases (I strongly distrust architects who don’t code) but I respect the opposite belief (architects are less effective if they are busy “in the weeds”).

Reading on a Kindle : I Miss The Weight of Pages Transferring From Right to Left

I’m now reading Dan Simmons’ The Terror on my Kindle. He’s a very competent writer, and perhaps it’s his very slow, very claustrophobic build-up (which he’d d*** well better pay off) that makes it so noticeable, but I have to say that I’m very aware of a certain “running on a treadmill” sensation when reading on the Kindle.

I turn pages, click click click, and the story progresses, but the only token of my progress is a bar at the bottom (the same length for all material, no matter the word count) that occasionally deigns to darken another pip. Like the animated plane on the in-flight display, this is almost worse than no indicator at all (“We still aren’t past Nebraska?” Wait for it… wait for it … tick it moves a single pixel…).

Especially with thrillers, the book-reading experience includes the sensation of the story moving from right-hand to left. It includes the canny appraisal of the upper-right corner, when the remaining pages become individualized — “An hour more, then! I can miss the sleep!” The force of will to read every clause as the thumb holds down only the last 3 pages…

Stephen J. Gould on Baseball : May Relate to Programmer Productivity

Andrew Dalke reminded me of an essay by Stephen J. Gould (discussed at: and about the decreasing deviation in performance as a field matures. Relating it to the old studies on programming productivity, Dalke wonders:

If that applies to programming, and I expect that’s a strong confounding effect, then those 1980-era studies have another problem – the field was too new. Many of the good programmers my age have been programming since high school or earlier, so about 20 years. Who in the 1980s had that background?