[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

[jducoeur]

Hmm. I think you're mixing concepts a little too fluidly here. As I mentioned in my other comment, I don't really see "programming" going away; I just think we're going to see things continue to move up the abtraction chain. That'll be a nasty difference for some people, but I expect it'll still be "programming" for those of us in the field.

The contextual changes are certainly dramatic, and they'll change the nature of our *applications*, but there's nothing about that that really implies changes to the nature of *programming*. That is, I believe that the two alterations are going to be largely orthogonal to each other. Indeed, I suspect that the changes of platform (to mobile and suchlike) are actually going to slow *down* the pace at which programming changes: since those mobile platforms are relatively weak, they can't deal with some of the cutting-edge changes to the technology.

As for no longer a craftsman: nonsense. We've simply raised the level of abstraction of the craft. If anything, I would argue that programming is much *more* a craft than it was when I started. It's just a *different* craft...

[g-w-s.livejournal.com]

I would definitely agree that it's a different craft. I have seen those with higher-level experience come in and have difficulty working with low-level languages, preferring instead to work in a shiny, abstracted world. I happen to prefer the opposite (thus far), because I model the processor's behavior in my head and have much more difficulty doing this when I don't know what's below the hood. This is also why I would prefer to work on an older engine than a modern one with a closed-source car computer.. ;-)

Chisel and hammer vs power tools? One certainly allows you fine control of the final product, while the other most definitely allows you to develop and fabricate a product much more quickly. Tighter tolerances vs simpler re-design. I guess it all comes down to what the customer wants, and how much they are willing to spend!

(I particularly like the romantic imagery of using a chisel and hammer, as my great-grandfather had an incredible way of crafting beautiful objects from wood.)

[jducoeur]

The analogy isn't a bad one, but it's worth noting that the power tools aren't just about speed -- even more, they're about *scale*. Hand tools are perfect for small, precise sculptures, but you can't build a skyscraper that way. That's where the modern languages come in: they're the only way to get things to scale up properly.

In many ways, they're also the only way to get the tolerances *consistent*: when you have lots of people doing stuff by hand, there's a tendency for the pieces to not match properly unless they are communicating really well. The very higher-level languages effectively standardize things, so that things can match up properly without nearly as much communication. The cost is the one-size-fits-all approach.

(Okay, I guess I do like the analogy...)

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