The Third Bit

Last week, in response to Google’s announcement of a new programming language called Go, I said:

I’m underwhelmed: it’s as if the last 20 years of programming language research hadn’t happened.

Turns out I was being generous: read this post from start to finish, and you’ll see what I mean.

So what should a new programming language do to get my attention? First, just as applications should be designed for testability, languages should be too. That means choosing constructs to make the lives of static and dynamic analysis tools better. Building such tools after the fact is like trying to add security to an app after it has been deployed; I think we’d do better to treat the capabilities of today’s leading-edge program analysis tools as hard (but not unbreakable) constraints on what’s allowed to go into a language, and see how far it gets us. I suspect this will push us toward strongly typed and mostly functional languages.

Second, user testing of language features. The folks at CWI did this with ABC (a precursor of Python); Steven Clarke has done excellent work on API usability at Microsoft (see for example this DDJ article from 2004), and there’s lots of other prior art — hell, I did a little myself nine years ago for Python (see these messages for details). I’m not suggesting design by committee [1], but checking to see how comprehensible or surprising feature XYZ is going to be to the average programmer before it’s put into the language just seems like common sense. I suspect this will push us away from pure functional languages: monads are just plain hard, and while purely functional data structures are possible, they’re hardly intuitive.

Third, a new language should explicitly be designed to make the expression of common design patterns as straightforward as possible. Languages (of all kinds, not just programming languages) evolve by formalizing the common usages of the day: idiomatic uses of goto statements become for loops, structs with function pointers become objects, and so on. There’s a tremendous literature on design patterns at several scales; why not treat them as something akin to use cases?

Of course it’s never too late — if someone has the time and energy, they could apply these three criteria to Go (or any other language) right now. Hm… sounds like an interesting thesis topic…

[1] Which gets an unfairly bad rap — both the American Constitution and the King James version of the Bible were produced by committees.

Research

The survey of software project portals that Jordi Cabot and I did has now been published by Doctor Dobb’s Journal. Hope you enjoy it.

Later: DDJ’s Jon Erickson just pointed me at this article on Mylyn, Tasktop, and related tools that you might also enjoy.

Research

I would really, really like to repeat this study in requirements meetings…

Research

As a follow-up to our paper on software project portals, Jordi Cabot has started a discussion at Joel on Software:

…the (small) teams building these portals do not use agile methodologies themselves, but instead rely on informal collections of best practices….I’d like to know if the same behaviour can be found among mISVs: Are any of you following a specific (agile) method  in the development of your products? Or it is more about improvising and working on what it seems best at any given time? (given the small size of the team, just 1 in many cases, and its expertise). Maybe not even agile methods are “agile” enough for this kind of teams?

The comments are interesting; lots here to chew on.

Research

For their thesis projects, two of my graduate students are studying what programmers actually do when developing software.  I can’t give you more details than that without biasing their studies, but what I can tell you is that they’re looking for Java coders with at least 3-4 years of full-time industry experience who’d be willing to give them an hour or so. No electrodes involved, and you’d help science move forward in a small way. If you’re willing, and in the Greater Toronto Area, please give me a shout and I’ll hook you up.

Research

Last year, Jordi Cabot and I interviewed the creators of several web-based software project management portals to find out whose needs they were trying to meet and how. Getting the results published academically has turned out to be harder and slower than we expected; since we’re both moving on to other things, we thought we’d put our findings out on the web in the hopes that others would find them useful. The abstract of our paper is below; you can find the whole thing online at http://www.cs.utoronto.ca/~gvwilson/articles/portals.html, and Jordi has a post about its conclusions up on his blog. We’d welcome your comments.

Web-based project portals are at the heart of modern software development, but have been studied much less than individual-oriented desktop tools like integrated development environments. In July to September 2008, we compared several popular portals and interviewed their developers in order to find out what needs they were intended to satisfy, how their feature sets had been chosen, and how they were likely both to evolve and to shape the evolution of distributed software development. Our key findings are that (1) most portals are strongly biased toward agile methods (and in fact may primarily exist in order to support agile development in geographically distributed teams), (2) the teams building these portals do not use agile methodologies themselves, but instead rely on informal collections of best practices, (3) as elsewhere, there is a clear trend toward hosted services, and (4) none of the portals studied provided any kind of support for modeling or user experience design, and only one directly supported test management.

Research, Uncategorized

From Lambda the Ultimate to Phil Wadler’s blog to a link that was working yesterday, but is 404′ing this morning: a workshop on evaluation and usability of programming languages and tools, to be held at OOPSLA in late October. Scope includes:

• empirical studies of programming languages
• methodologies and philosophies behind language and tool evaluation
• software design metrics and their relations to the underlying language
• user studies of language features and software engineering tools
• visual techniques for understanding programming languages
• critical comparisons of programming paradigms, such as object-oriented vs. functional
• tools to support evaluating programming languages

Long overdue, and very welcome.

Research

American Scientist has just published a short article summarizing I wrote summarizing the results from last year’s survey of how scientists actually use computers.

Research, Software Carpentry

• Jason Montojo is trying to figure out how to operationalize some aspects of expertise — he’d welcome your suggestions.  How do you tell if one programmer is better than another?
• Aran Donohue has posted a few hundred words about his intended research (debugging DSLs). He has also summarized some papers on cognitive models of debugging.
• Rory Tulk is thinking about user studies and mutation testing.
• Jeremy Handcock was initially lukewarm about Google Wave, but upon reflection, sees some neatness.
• The Basie students have an AJAX SVN browser working and are switching to Whoosh for search. We should have some more screencasts up later this week and early next.

Basie, Research

…but some of my colleagues have:

• Steve Easterbrook
• Rory Tulk
• Jorge Aranda
• Jason Montojo
• Aran Donohue

Interesting stat from Carlo Ghezzi (via Steve’s blog): “The attendees at the first [ICSE] conference were 80% industry and only 20% academics. This has steadily changed: the conference is now 90% academics.”

Research