Potato I have

Both the Haskell language and functional programming were new to me; I came across both while reading about darcs. From the horse’s mouth:

Haskell is a computer programming language. In particular, it is a polymorphicly typed, lazy, purely functional language, quite different from most other programming languages. The language is named for Haskell Brooks Curry, whose work in mathematical logic serves as a foundation for functional languages. Haskell is based on lambda calculus, hence the lambda we use as a logo.

[…]
A functional program is a single expression, which is executed by evaluating the expression. Anyone who has used a spreadsheet has experience of functional programming. In a spreadsheet, one specifies the value of each cell in terms of the values of other cells.

The same page contrasts functional languages with the imperative languages most of us app programmers are more familiar with: java, C#, etc, and emphasizes the level of abstraction:

This focus on the high-level “what” rather than the low-level “how” is a distinguishing characteristic of functional programming languages.

Another well-known nearly-functional language is the standard database query language SQL. An SQL query is an expression involving projections, selections, joins and so forth. The query says what relation should be computed, without saying how it should be computed. Indeed, the query can be evaluated in any convenient order.

Okay, now I see that SQL and LISP are functional, so it’s not so new to me as I thought.

Is there much Haskell going on? Well, it has a wiki that is getting daily update activity. Though monster.com finds only nine jobs in four companies in the US.

Wikipedia is very helpful; here are articles on functional and imperative programming, and there is also a one-page programming paradigms at-a-glance category page.

I wonder if this is one of Ward Cunningham’s 100 languages?

While pulling sources for tortoisesvn, I came across the better-scm site; from there, I found David Wheeler’s essay on OSS/FS scm tools, which primarily discusses CVS, subversion, gnu ARCH, and Monotone (the latter two were new to me).

Having recently moved to subversion, and being very happy with it, I was surprised to see a lukewarm review. Of course, my previous experience with scm has been primarily HP’s softbench, clearcase, and RCS (and, fortunately, the briefest of encounters with VSS), so I’m already lightheaded with being set free from the pessimistic-lock camp of version control. Liberal use of branching, and easy separation of commits and lands, has been a major major improvement in my sw development team lead experience. Funny just how long you can work in a cruddy setup without knowing how cruddy it is.

So Wheeler’s paper turned me on to the next scm things that I don’t even know that I don’t know. A basic difference looks to be centralized vs. decentralized models:

Some people believe SCM systems should primarily aid in controlling a centralized repository, and so they design their tool to support a centralized repository (such as CVS and Subversion). Others believe SCM systems should primarily aid in allowing independent developers to work asynchronously, and then synchronize and pull in changes from each others, so they develop tools to support a decentralized approach (like GNU arch, monotone, darcs, and Bitkeeper).

Though even centralization can mean different things; he quotes Bastiaan Veelo:

In short, one could say that Arch is centralized around a code integrator, and that Subversion (like CVS) is centralized around a repository.

Wheeler’s darc horse for scm leapfrog is darcs, something written in Haskell, a language I’ve never even heard of. His example of token replacement showing the handling inter-patch dependencies was pretty cool. But he doesn’t think it will happen: most scm tools are working well enough (yeah, CVS worked well enough for a long time), and Haskell’s functional programming is a serious barrier to contribution.

I had no idea what I was missing in scm. It seems wherever you go, someone has gone a lot, lot further.

A couple weeks ago, MSDN TV had an interview (transcript available here) with Steve McConnell, of Code Complete and Construx.

The missing interview question for me is “what do you think of swebok?

Although blogs often suggest the freshest of web content, I often find myself reading things months or years old, by following a blog’s links.

An example is some OTI stuff on SWT, from way back in 2001. The first article shows rather clearly the impact of two different approaches to using JNI for accessing platform-specific GUI widgets. By strictly using JNI as no more than a forwarding proxy, they get a single API to support, all the power of java for all of their programming logic, and much simpler debugging and profiling.

This led me to a second SWT article which is a good example of coding standards in action. The standards are defensive, and influence the api design, e.g.

This rule occasionally leads to API that seems artificial. For example, GC.getClipping (Region) forces the programmer to create a Region in order to get the clipping region from a GC. Although it might have been a bit “prettier” to provide GC.getClipping () that returned a Region, this would break the rule because it would have to allocate an operating system resource outside of a constructor. While it could be documented that the programmer needs to free the Region returned by GC.getClipping (), programmers don’t always read the documentation. Making the programmer call the constructor for the Region makes it clear that it is the programmer’s responsibility to free the resource.

In the “how did I get here” department: wanting to see the contents of Steve McConnell’s second edition of Code Complete, I bugmenotted my way past cc2e’s registration. Out of curiosity, I clicked the “profile” button for the bugmenot user, and saw a mailinator email address. “That’s cool,” I thought, and seeing that its creator had a blog, I stopped by there and read his java rant. Which had a kind reference to SWT.

Stumbled on to David Chappell’s blog (he of MS tech fame, not the Sonic messaging guy). His 40.000′ view of .NET was just exactly the entry I needed when diving into All That Stuff last year.

He’s posted a decent slideshow (pdf) of BizTalk 2004, stating:

I believe that as integration morphs into business process management, BizTalk is changing from an edge technology into one that’s much more central for .NET-oriented developers.

Earlier, he argued for careful naming of this new platform, emphasizing ’server’ over ’system’. Anyone arguing the importance of names will usually make me smile in appreciation.

And much earlier, in January, only his 2nd or 3rd blog entry, he restated Moore’s Law in a dramatic way:

My favorite way of expressing Moore’s Law, one that I think better captures the extraordinary impact this rate of change implies, is the realization that we’ll make as much progress in processor speed in the next year and a half as we’ve made in the entire history of computing to date. Who can predict the effect of this level of change? Answer: nobody.

I stumbled across a couple of old posts from Bruce Eckel, and especially appreciate how much experience he brings to the topics, and how reasonable his tone is, in contrast to some of the (un)checked exception debate, for example. The first is one of a handful of things I just read advocating unchecked exceptions, as is used in C#. For Eckel, someone who’s been looking at exceptions for an awful lot of years, the light went on after using a language with exceptions, but without checked exceptions:

When I started using Python, all the exceptions appeared, none were accidentally “disappeared.” If you want to catch an exception, you can, but you aren’t forced to write reams of code all the time just to be passing the exceptions around. They go up to where you want to catch them, or they go all the way out if you forget (and thus they remind you) but they don’t vanish, which is the worst of all possible cases [emphasis mine]. I now believe that checked exceptions encourage people to make them vanish. Plus they make much less readable code.

Here’s an entertaining illustration from Heinz Kabutz:

I enjoyed using Together/J, even though it was rather memory hungry. Instead of starting with 512MB as default maximum old generation memory size, I set it to only use 92MB. This made Together work faster and save resources. However, occasionally random threads would simply die, so you could perhaps not print anymore or some other functionality would vanish.

Kabutz’s article also has a good discussion of how java 1.5 helps you catch all unhandled exceptions. And it introduced me to the cool java api diff tool here.

My own experience with exceptions has been one of periodic enlightenments punctuated by sharp realizations that I don’t completely get it yet. I learned SmallTalk and CORBA at the same time, and after getting burned by uncaught exceptions killing worker threads, I got in the habit of wrapping all remote calls and remote call implementations in top-level catches. When I came to java, it became more complicated: UserExceptions were checked but SystemExceptions were not. I slowly grew to appreciate this, but my top-level catching was still swallowing a lot of exceptions, and/or I was spending a ton of time how far up the stack to carry my checked ones. Then I started thinking of RuntimeExceptions as “bugs” or things I didn’t want to catch. Finally a useful rule about what to (not)catch! Except for the SystemException special case, uncheckeds were bugs, not to be caught.

Then I had a subsystem very vulnerable to bad data: I needed a ton of positional string parsing (and therefore RTE handling code), and it was far simpler to take a best-effort approach and swallow all those RTEs at the top. Simple success or failure, and I couldn’t do anything about the badly formatted data anyway. Ah, RTE=bug but with some more intentional special cases, because sometimes it’s so damn much more productive.

Okay, now it’s not such a big step to using RTE (unchecked) any old time, for productivity reasons, because we will find all the problems at runtime anyway, and we’re much less likely to swallow. The tests are key: TDD makes deferral to runtime a feedback loop almost as tight as the compiler.

The second Eckel posting I’m blogging is very related: his emerging preference for strong testing rather than strong typing. Huge experience in C++/Java, but some personal experience with high-productivity, low-problem Python systems has caused him to reconsider a very basic, long-held assumption. Here he makes an analogy to the productivity boost the compiler brought us:

It’s very much like going from old C to C++. Suddenly, the compiler was performing many more tests for you and your code was getting right, faster. But those syntax tests can only go so far. The compiler cannot know how you expect the program to behave, so you must “extend” the compiler by adding unit tests (regardless of the language you’re using). If you do this, you can make sweeping changes (refactoring code or modifying design) in a rapid manner because you know that your suite of tests will back you up, and immediately fail if there’s a problem - just like a compilation fails when there’s a syntax problem.

What will the post-TDD programming shift bring? I want Eckel’s posting where he says “It’s very much like going from old strong-typed languages to weak-typed, test-driven development. Suddenly, your tests were catching all your bugs as fast as you wrote your code. But those tests can only go so far. Now, …”

Signed up today (well, tomorrow, according to system timestamp–guess that’s Russia) for resharper EAP at intellij’s confluence community site. VS.NET has been a major disappointment since IDEA; I can’t wait for nav, dead-code graying, and at least the push-it-around-and-rename-it refactoring stuff. I’m the proud inheritor of a 4000-line C# class that needs some help bad.

Those tired of managers seeing demos and assuming the thing’s ’bout done can finally make it look like it was just thrown up, using a napkin look and feel. Here it is in action, for the java webstart swingset app.

(via TW Alan Francis’ blog)

Greg Gretsch highlights the brain drain (from Silicon Valley in this article at AlwaysOn) aspect of offshoring tech work, not just the building of know-how elsewhere, but the picking-up and going-home of the considerable numbers of foreigners who came here for educations and/or good tech work.

But which know-how? Americans and others who are actively offshoring activities will of course be learning lots about how and when to offshore, what are the “crown jewels,” what is higher up the value chain for deep-skill workers. Will that be interesting work? Will it be the kind of advantage that tech has been for some decades now?

What will draw back all those people who will have gone home?

Sam Ruby has started a survival guide for internationalization. It includes some references, of which I particularly liked Joel Spolsky’s minimal i18n bar for programmers. Platonic ideals, okay, now I’ve got it.