Knowing .NET

The Pragmatic Programmers have a very good sense of software developmet trends — they’re doing today what O’Reilly did in the early 90s. Coming in July from them is Joe Armstrong’s Programming Erlang. Erlang is seen by programming language mavens as one of the real contenders for the crown of “most practical language for writing concurrent programs.” I haven’t sensed any real groundswell for Erlang recently, but a great book on the language might well contribute to an uptick in popularity.

Of course, debates on the theoretical effectiveness of programming paradigms may be missing the point entirely, given the too-horrifying-to-be-true assertion that many programmer applicants cannot:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Last night, I watched a new TV show called Are You Smarter Than A Fifth Grader? (implication: yeah, I watch American Idol. Want to make something of it?) The contestant was a “Computer Systems Analyst.” Rather than answer the question “How many decades in two millennia?” she took the money she had won previously (by triumphing over her doubts about “What is the closest star to the Earth?”). I think she left $50,000 on the table. When asked to guess, she offered “20?” So, yeah, I’m thinking she might have trouble with FizzBuzz.

In far, far brighter news, Microsoft today announced the Beginner Developer Learning Center, which is intended to provide resources for people all the way to “zero experience.” This is a really wonderful idea. I had inklings, but not direct knowledge, that something like this was in the works and I am looking forward to poking around the site.

P.S. Hilariously, Jeff’s comments section is filled with people demonstrating their prowess by implementing — and sometimes failing – the program. Don’t do that here. As Scott Hanselman says, “You’ll only die a little inside if you do.“

My dispute with Wesner Moise continues…

I’m going to take this post with good humor — the “werewolf” being a reference to the question of a silver bullet and an image in one of my responses. And the “naked, pale-skinned” thing I’ll take as pure jealousy of my chiseled physique, descended from Irish kings, tanned in the warm glow of the tropical sun, and followed, wherever I travel, by the wistful sighs of desirous women.

Anyway…

What we’re arguing about is whether there is any:

single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.

This is how Fred Brooks defined the Silver Bullet for Software Engineering. In particular, Wes champions functional programming as a candidate.

My side of the original spat were these three posts in early December. In mid-January, we disagreed as to whether a 14-line Python recursive descent parser and Microsoft’s implementation of regular expressions had any relevance to the question.

Now, he’s posted something that’s either just an ad hominem attack or a response. I’ll take it as a response.

Wes says that I’m “wedded to the idea of no silver bullet.” Not so. I’m not emotionally committed to it. I’m just convinced, absent substantive evidence to the contrary, by the arguments that Brook made two decades ago and which have held since. I’m aware that this places me in what Kuhn would label the “dominant paradigm” and sets me up to be pushed aside by some revolution. But they’ll need more than mere assertions of merit to sweep me away: the werewolf hunters are going to have to ship commercial- and enterprise-sized applications that are developed an order-of-magnitude faster and that, to date, seems to be a sticking point.

Further, let’s be clear that I’m a fan of functional programming: ref. this post preceding the spat in which I praise Wes’s advocacy or re-read any of my posts in this spat, in which I regularly make it clear that I like functional programming approaches and am only skeptical of the hyperbole that it is a silver bullet.

The RegEx parser was held out as a template for a silver bullet approach. I pointed out that it’s capabilities are vastly different than what we mean by RegEx capabilities in a language. The example is, in fact, a perfect example of Brook’s central argument:

the hard part of building software [is] the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

This was lost on Wes, who said:

[W]ith this approach, we can get a reasonable implementation of regular expressions over lists of arbitrary types in less than 200 lines of code, which is two orders of magnitude more concise than Microsoft’s more specific implementation over strings. I’ll produce a port of this one day and post it in my blog.

So there’s a testable claim: a program that clones Microsoft’s RegEx implementation including time and space constraints. I doubt it can be done in 200 lines of code. I doubt that “testing the fidelity of the representation” can be done in an additional 200 lines of code. But perhaps someone will prove me wrong.

Wes invokes Charles Simonyi and IntentSoft as perhaps the company that will deliver the silver bullet. I hope he’s right. Simonyi is a fracking genius and is absolutely credible. However, surely it’s fair to point out that IntentSoft has been in business for 5 years without shipping a product and Simonyi was talking about intentional programming for years before the company incorporated. Whatever the ultimate benefits of intentional programming, there appears to have been difficulty boot-strapping themselves into silver bullet productivity.

This is a much more impressive video than the one from (Siggraph?) last year. The UI that Tom Cruise’s character uses in Minority Report blew me away and this video, which demonstrates “multitouch” on a big screen (rear projection, I imagine), is amazingly similar. Of course, what they’re showing may not be a universally usable metaphor for users, but to me, this is like Engelbart demoing the mouse.

I’m arranging an interview with a VP at D-Wave, the quantum computer company. Any topics I should be sure to cover?

Showing how clueless aggregator sites are, no one seems to be properly freaking out about the claims of D-Wave to be demoing a 16-qubit quantum computer with plans for a 1K-qubit computer within a year. CNet story here, straight link to company here.

The shocking thing about this is that a quantum computer’s information processing ability goes up exponentially as its qubits increase. I believe that Shor’s algorithm factors at O(n) (goodbye standard cryptography) and Grover’s algorithm sorts at O(n^2). The theoretical power is even more mind-blowing: small numbers of qubits can model incredibly complex things (I’m not going to post the thing I’m thinking of without finding a source).

What triggers a certain skepticism is that the few-qubit computers that have been developed didn’t look like they were going to scale and everyone expected it to be quite a slog to find a scalable architecture. D-Wave’s claims imply a huge breakthrough; of course, given the epochal nature of such a breakthrough, very smart people have been looking for just such a thing.

I’m utterly stunned. I use to play with simulating quantum computations and tried in vain to develop algorithmic design methods that were comprehensible, but I did not expect a significant quantum computer until the 2020s.

I imagine that every single person who reads this blog other than my sister (Hi Donna!) knows who Jon Udell is and knows that he is joining Microsoft. In the small world of “people who make their living by writing about software development,” Jon is clearly the leading light on the technologies collectively known as “Web 2.0.”

Jon has the rare ability to move between high-level conversations with technology business leaders, advocating new ways of sharing information, and demonstrating technical points with his own code. He makes surprising connections between technologies and between technologies and homely matters (LibraryLookup and his walking tour). Typically, he’s constructed these demonstrations with very accessible tools — XML, JavaScript, etc.

There are two things that I worry about Jon’s new position:

• To what extent will the inherent imperative to advocate MS technologies stifle him?, and
• Will he be reduced to just a conduit of information (Microsoft’s new A-list blogger) or will he continue to contribute new creations?

Oh, and I’ll throw in:

• Will direct knowledge of unannounced initiatives keep him quiet on the very subjects on which he’s passionate?

Unfortunately, that last is almost a given. Whether the subject is the way that young people learn programming, design and implementation of dynamic languages, or concurrency, there have been thought leaders at Microsoft who’ve essentially “gone dark.” Presumably, that’s so that they can actually make something rather than talking about it, and I suppose there’s some value in that.

But there’s also value in people who are in the public realm batting around ideas without behing beholden to commercial interest, especially when those people have the rare ability to crank out demoes. One of the most encouraging things to come out of Microsoft in years was Ozzie’s “Live clipboard” — if the boss (or the boss plus a House-like crew of apprentices) produces small conceptual demoes, then one can guess that small conceptual demoes just might be a route to corporate success.

Finally, I have to say that it worries me a bit that Jon is leaving New Hampshire. One of the things that I’ve admired about him is that he showed that a person could have his finger on the pulse of the industry while living in the place that they love — I very consciously took Jon as an example when making the decision to move to Hawai’i.

Paul… uh… NoLastName has an excellent post on silver bullets and functional programming. He cites studies, makes logical connections… why, it’s hardly a blog post at all!

Anyway, I starting writing a comment, but it grew and grew, so I am posting it here instead. Read his post first….

You do a good job of laying out the issues, but I disagree that it’s likely that functional languages are vastly more productive across the field of “larger” systems. (By “vastly,” I’ll take “just” 5x faster across a broad variety of programming tasks.)

I am skeptical that the success of functional languages in smaller tasks (they dominate academic programming contests or the USN prototype you mention) provides strong support to the idea that they strike at “essential” not “accidental” issues. That is, it’s not that they’re silver bullets, it’s that they’re good languages. 

You argue that the defect rate staying constant (per KLOC) argues for the “essential” case, but this is a long-known phenomenon that holds true across a broad variety of languages. (I think the original studies were by Boehm, but it may have been Capers Jones.) I believe the way to read this is that “expressive density” is beneficial in programming languages. In other words, what you describe as “packing more into fewer lines” is itself a benefit (but not a silver bullet).

As you recognize, concurrency is the anvil on which will break today’s popular programming languages. The threading models in the popular C-derived languages are demonstrably intractable, just as C’s memory model was intractable and has led to decades of misery. But this is clearly a problem of “accidental” quality: it’s not that programming dual-cores falls short of 2X times easier than single-threading, it’s that doubling your cores makes your programming task harder.

Functional languages, with their guarantees on the semantics of assignment, have a huge leg up on concurrency. It is much, much easier to build a system that automatically and efficiently manages the distribution of work when you have those guarantees. However, I don’t believe there is any language that has reached the “finish line” in terms of expressive density, interoperability with mainstream languages (i.e., a C interface and “zero-config” interoperability with one of the two major managed platforms), and runtime efficiency.

When there is such a language, though, it’s worth pointing out that it’s embrace by the mainstream is still far from guaranteed. LISP is probably as close to that “finish line” as anything. LISP has been around for 48 years! And yet it is the most-abandoned language in programming (perhaps C has gotten to the point of contending that title). Smalltalk is universally admired for its embodiment of OOP, the construction approach that absolutely dominates mainstream programming. And yet Smalltalk doesn’t show any sign of a dramatic increase of acceptance. What is increasing rapidly? Ruby. To me, Ruby seems a Smalltalk-like language with a primitive development environment. But maybe text editors and command-line-like shells are actually benefits. … The subject of another post … My final point regarding the mainstream embrace of languages: if I were to design a language that I hoped to be popular, I’d use curly brackets to denote code blocks.

Productivity jumps (and silver bullets, if they’re at all possible) arise from embodying in a language (or perhaps a framework) new concepts that are broadly applicable. Languages have long been the vehicle for delivering these advances because facilitating the use of truly broad concepts (use of functions as first-class objects of reason, modularization of state and behavior in “classes”, search — a concept embodied in Prolog and Oz) generally requires semantic guarantees.

This certainly advocates for the power of domain-specific languages embodying domain-specific concepts.

For general-purpose languages, I think the challenge for the manycore era is to discover a new concept (and I don’t think it’s software transactional memory, or message-passing as we conceive it today) that allows us to exploit parallelism. I think the challenge for the perhaps-not-vanishingly-far future is to develop new concepts that relieve, by orders-of-magnitude, the tasks that we commonly consider programming.

For instance, right now there’s a huge debate about explicit typing. Is it helpful or not to declare that a variable is an integer? Meanwhile, there’s not a huge debate about the value of unit-testing. That is, everyone agrees that it’s helpful to declare that a variable always be greater than 0 and less than, say, 2^32. Is the irony not clear? Unit-testing assertions are type information: constraints on the interpretation of the inherently-plastic memory representation. It seems to me clear that unit-testing specification should migrate into languages, not remain the province of libraries. It ought to be the case that a failure of the unit-testing suite have the same, if not greater, ramification that comes from assigning a signed int to an unsigned one.

More generally, one can see that there’s a conceptual failure with the idea of a purely static compile phase, followed by a monolithic runtime representation (we conceive of differences between “Debug” and “Release” runtimes, but those are simply compile-time conventions). Microsoft’s C++ compiler has an advance on this model, with the idea of instrumenting a build, profiling it, and then altering the code-generation based on the results of that profiling. That’s how testing should work! There is useful information about program structure that could be automatically extracted from unit-testing; if nothing else, that a particular class or method is a source of trouble. Far, far more speculatively, might it be possible for the computer to generate alternatives and present to the “programmer” those that satisfy the tests/constraints? Back in 1990, I speculated that genetic programming might be the only thing that could use up all the power of the then-distant gigahertz-speed processors. (Little did I expect Office 97.)

In comments to my previous post, Wesner Moise says:

• given today’s components, “why build vi?”;
• the difficulty arising from software state “is a solved problem in functional programming”; and
• suggests that the advances in graphics and networking that I’d acknowledged amount to a silver bullet.

I’m afraid he’s missing the central point regarding “essential” vs. “accidental” characteristics.

“Why build vi?”

The point of vi is not that Bill Joy rapidly wrote the first programming editor, it’s that he rapidly wrote a programming editor to meet particular and unforeseen requirements. Several editors (I think even emacs) already existed when he wrote vi, but Joy needed an editor that ran over a 300 baud connection.

We’re always building vi. Software development is never about the requirement you get in the elevator (“I need a text editor,” “I need an online store,” “I need to share data”), it’s always about the specific needs of the end user. Why build vi? Because the editor needs to work in the memory of a cellphone. Or over a satellite phone link. Or via an SSH connection. Or because we don’t want to retrain the users and they want an insert and a command mode. Or because we want to have piped program output insertable into the middle of a text file.

Brooks makes this as plain as possible in his essay:

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.

The essential problem is not the representation we develop, it’s developing the concept of the system. The fault lies not in the source code, but in ourselves.

Functional programming solves the problem of complex state

Nonsense. Functional approaches have strengths, as I’ve discussed. However, they fall far short of solving the problems of complex state. The conceptual strengths of existing functional approaches diminish as the system grows: it is not an accident that object-orientation won out as the preferred method of conceptualizing larger systems. I am not saying that OOP is a panacea (not at all) or that state-carrying objects are a better approach to construction, but OOA&D is clearly more appealing and more successful in the broad marketplace of ideas than other approaches.

I personally believe that functional approaches may very fruitfully evolve in the coming years in both construction (where I think it’s clear that they will be important in the evolution towards manycore) and analysis and design (perhaps hybridized with certain aspects of OOA&D). But personal beliefs aren’t silver bullets.

Some silver bullets

Wesner again misses the forest for the trees when he clams I’ve acknowledged silver bullets for “development for an end computer (graphics programming) and development for a network of computers (network programming), there is a no order of magnitude improvement for any other form of computer.”

For one thing, by “graphics programming” what I meant was not GUIs, but 2D and 3D visualization. I meant things like the ability to present, light, and move through space 3D objects.

More generally, the point is, again, that libraries and frameworks advance but the conceptual challenges remain the same. Design-time form building, if anything, argues for Brooks, not against him: “friends don’t let programmers design interfaces” and all that.

Here’s an example of the fundamental issue: Eric Sink’s woodworking application. The whole issue of “silver bullets” boils down to whether you think the problem is creating a 3D view or writing an application that linearizes the steps in a woodworking project. Is coding the views 10 times simpler than it would be if he were using DirectX? Just about. Is DirectX 10 times simpler than writing your own projections? Yep. So for 3D views, you have substantial advances: multiple generations, programming becoming faster not just by integral factors, but by orders of magnitude. Yes, I think that’s fair.

But… what about the “steps” part of things? How much more capable is this program at creating a list of materials than was the copy of Autocad I used twenty years ago? A little? A lot? I dunno’. But I guarantee you that there is not an order of magnitude difference between the time Eric spent representing those domain rules in whatever-language-he-used and the time it would have taken to express the same design rules in OCaml or other functional language and the time it would have taken to express those rules in AutoLisp (assuming the Eric was fluent in all of them).

Creating a representation of a conceptual system is the essential task of programming. Developing a conceptual system that can express something useful is the essential task of software development.

Once upon a time, I used to make a big deal about that distinction– at Computer Language, I forbade the use the term “programming” or “programmer” to describe our subject matter. When I left publishing, I purposefully embraced the opposite swing of the pendulum: I called myself a “programmer” and intentionally embraced in my writing those aspects of our job.

Wesner Moise quickly reviews Brook’s “No Silver Bullets” assertion and claims “[t]hat assertion turns out to be pure nonsense, amply disproven by numerous advances in IDEs, languages, frameworks, componentization over the past few decades.”

I couldn’t disagree more. While the cumulative effects have given us more than an order of magnitude improvement, no single development has come close. I would say that the two single areas where there have been a close to an order-of-magnitude improvement are in user interfaces, with the rise of the compile-time visual form builders and HTML for text presentation, and network programming, with Java’s stream-based model being a huge step over sockets.

Outside of network and graphics programming, I don’t see the cumulative effects as being even two orders of magnitude. Bill Joy admits that he didn’t write vi in a weekend — that it tooks months. Let’s say it took him 100 days. You think you could do it in 1?