[salon, muse] Salon Discussion, February 6, Changes in Programming

[jrising]

I really need to get back in the habit of making thorough notes shortly after the Salon-- I'm losing too many good discussion threads. One of our biggest topics at the Salon concerned recent changes in programming, which I've wanted to write about for a while. Here are my thoughts on it, informed by the Salon discussion, plus some other discussion topics below. Feel free to remind me of other topics in the comments, and I'll record what I remember about them.

Programming has changed enormously since computers were invented. I don't just mean that assembly gave way to higher-level procedural languages which gave way to object-oriented languages, although that mirrors the shift I'm interested in. In the days before C, programming languages had a fairly-small, well-defined collection of building blocks, and it was the programmer's responsibility to construct whatever they needed. In a shift into libraries and then object-oriented languages, the programmer's job has become more to connect pieces constructed by other people.

The pieces are also changing. They're becoming more intelligent, more communicative, and more accepting of ambiguity. Programmers have realized the power in-- and the need for-- type-fluidity. Currently that's instantiated in typeless languages, but these still form a kind of antithesis waiting for new synthesis with traditional typed languages.

The things we're programming are different too. The programmer is no longer a craftsman. In the past, people designed programs to do a certain thing well. Now, people realize that they are really engineering experiences or "ways of understanding". We like one program over another not because it does something better, but because it allows us to conceive of our task differently.

Which is exactly what different programming languages themselves do. With plug-in designs, programs themselves are allowing users to construct the context for their own experience.

The way we think of technology is in such incredible flux right now. With web 2.0 ideas (participatory, dynamic content; new kinds of social networking), the internet is changing and becoming the necessary context of all computer use. With mobile devices, the personal computer, our interface to it, and the ways we use it are changing. In another 10 years, programming will be vastly different; in another 20, it probably won't exist, as we currently conceive it.

Anyway, we also talked about Digital Rights Management, specifically relating to Apple's decision to drop DRM-protection tying iTunes to iPods, and how artists should be "rewarded" for their work. And we talked about the nature of Salons, and the posibility of having a kind of "party-salon", which is more like the kind of gathering that was found in Paris.

Comments

[jrising.livejournal.com]

I've loved following your two's discussion on this, and I have nothing to disagree with from what you've said, but I maintain that these changes are going to go further than you two seem to believe.

One unasked question is, "What is programming?" It's creating recipes for the computer: well-defined directions for producing specific results. As the directions and results become more abstract and less well-defined, the definition of programming is being forced to change. Not just because there's more ambiguity, but because there's more *autonomy*, on the part of the computer (and the application, and the user). We don't call teaching or psychotherapy "programming" not just because it's less reliable. It isn't programming when enough choice surrounds those recipes.

Today programming is an totalitarianism of the programmers. It's growing into a direct democracy, and the nature of the decisions being made are changing in hand. They aren't just less definite: in time, I think, they are going to be less decisions about the computer's operations, more about the user's. Applications as experiences require a whole new vocabulary than the one programming is currently built around.

Sure, applications are more than their user interfaces, and their inner workings will still need programmers, but that exactly why I'm so interested in the parallels between how applications are changing and how programming languages are changing. Higher-level languages allow us to program something like the computer's experience of an algorithm, and they provide for more choice on the part of the compiler, and as such there's no hallmark of programming not subject to change.

[jducoeur]

This is true in some respects, and the first signs of it are coming out: the Hungarian fellow behind much of Microsoft's best work (Smolenyi?) has created a company intended to move in precisely this user-oriented direction. Personally, I think he's still blowing smoke -- what I've read so far doesn't sound to me like he's really wrestling with the interesting and hard problems -- but it shows the beginnings of momentum in that direction.

That said, so far that's mainly a matter of adding a new layer of abstraction on *top* of the rest. That is, programmers are still needed to transform a "domain" into code concepts -- high-level code concepts, but code nonethless. The domain experts (the users) then take that and are supposed to create the final programs from it.

All that said, though, I'm still skeptical, and the reason is precisely the craft of programming. True programming isn't about particular languages or technologies, it's about a way of *thinking* -- the discipline of describing what you want the computer to do. I see little reason to believe that the need for specialists who focus on that mindset is going away any time in the foreseeable future. Even today, decades into the computer revolution and at a time when most people are getting pretty computer-literate, most folks are still *terrible* at saying what they mean, and I don't see much improvement on average. (Frankly, even most programmers are still pretty bad at it: it's the difference between a low-level code monkey and a serious engineer.)

Taking it a different way: the hard part of programming isn't writing the code, it's writing the *spec*. That's your higher level -- describing the program from the user's POV, not the computer's. But in fact, you still need programmers to write specs that actually work right: having non-programmers do it usually results in disaster. Indeed, computer science is beginning to recognize that -- the old model, where specs were written by users and then implemented by programmers, is rapidly giving way to a new one where the design is hashed out by customers and engineers working hand-in-glove. The customer is responsible for describing what is desired, and the engineers provide the disciplined examination of the ramifications of those decisions.

As programming becomes more iterative and interactive, there is room for that to change, and for end users to do more. But I honestly disbelieve that the need for that particular craft is going away any time in the foreseeable future, any more than the need for doctors is going to go away. Yes, people can do simple stuff themselves, but for sophisticated problems, they're still going to need sophisticated professionals. And ultimately, that's still "programming" as I think of it: figuring out precisely what is desired, and how to tell the computer to do just that.

(There's an entire separate rant about what happens if you try to *really* let the computer make the decisions, and the dangers of emergent behaviour. But this comment is getting long enough...)