[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

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