Knowing .NET

I’d rather hang out with John Hodgman. I’d rather get a C++ GUI Programming Guide.  

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.)

I wish I could draw. I wish I could use tools to make my hideous drawings into acceptable drawings.

This guy can draw and can use tools to make his sketches into better drawings.

I wish I could learn something from this guy.

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.

I’m going out on a limb, I know, but I’m going to say that I don’t think NASA will be ready to begin construction base on the moon in the year 2020 and, darn it, I know I shouldn’t speculate wildly like this, but I’m going to say that when they do land on the moon again, it’s going to have cost a lot more than originally planned.

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?

Apparently, the next version of Office is going to be 14, embracing the triskedecaphobic convention of buildings in skipping the sp-o-o-o-k-y ramifications of, you know, counting.

Not to put too fine a point on it, but when you get to the point where, despite your worldwide hegemony on office documents, you let superstitious nonsense hold sway because of potential sales-loss among particularly gutless 6-year-olds, you’ve got too much bureaucracy.

Things are beginning to look up for me being able to do some XNA-based projects in the new year. I need a couple realizable games to tackle. I have one designed that I’ll never be able to get approved (it’s called “Fanaticize me!” I think I’d get in trouble even by describing the playing pieces).

I’m thinking it would be a better idea to do a physics-based simulation a la Line Rider. I’d never heard of that particular one until today. It looks like a lot of fun (of course, for me, it’s more fun to program it than to actually play it).

Backseat Playground is a research project that developed a GPS-based game for kids. It seems more like a (great) storytelling system more than a game. Basically, it uses the GPS and location-awareness to introduce game elements, e.g., when it sees that you’re driving over a bridge, it presents you with the opportunity to “explore” the river with that SCUBA tank you picked up in the last town you drove through.

What a great idea. Any story is made infinitely more appealing by tailoring it to the invididual. To present a long car-ride to Grandma’s house as a detective story is a brilliant innovation. I wonder, though, if the better approach would be to feed the parent plot points as they drove, as that would be infinitely more enthralling for a kid.

Scientists have reverse engineered the Antikythera Mechanism, a sophisticated analog computer that was known to have calculated lunar phases and a luni-solar calendar. Newly reported is that it additionally calculated lunar and solar eclipses! Additionally, it may have (correctly) modeled the moon as having a slightly elliptical orbit. The Mechanism predates by at least a thousand years other devices of similar complexity (I’m not sure if that claim is restricted to Western technology or includes the Chinese).

I often fantasize about what life must have been like for an ancient geek. Both the career challenges (“You battle the Hittites without me, I’m going to look at the stars. Again.”) and, more amazingly, the induction. Sure, you’re going to figure out that the moon waxes and wanes regularly. The seasons, complete with solstices and equinoxes? Given the relationship to food, I’ll grant you that. But how in the world do you model lunar and solar eclipses that only occur a few times per lifetime, in a time when you are absolutely beholden to clouds, correspondence is limited to trading routes, and the vast majority of learning is transmitted orally? Or the irregularities of orbits when your instruments of measurement are your eyes and fixed stars? Just incredible.

It gives me hope for the future of programming. However we program the computers that run the United Federation of Planets, it won’t be with text files containing linear descriptions adhering to context-free grammars.