Programming 2.0
Brian DeLacy, who runs a Ruby on Rails interest group in Cambridge, MA, sent me an email that I thought was worth sharing more widely. He wrote:
It seems to me that we're seeing a paradigm shift in programming, embodied in the Rails phenomenon. Is this what you're seeing? (I've borrowed from your format of Web 2.0):
While I'm not sure that Brian is right about everything on his list -- for example, you can build cool apps as quickly with new Java frameworks like Spring as you can with Ruby on Rails -- he's definitely right that programming has changed radically in the last decade. As a matter of fact, I began the thinking that led me to formulate the ideas of Web 2.0 in trying to come to grips with the changes in programming that I first saw in the rise of scripting languages. I was struck by the contrast between the lack of respect many traditional software engineers had for Perl and its widespread use as "the duct tape of the internet." (I wrote about that in a 1998 essay entitled The Importance of Perl, as well as in Hardware, Software, and Infoware.)
I think Brian's got a thought-provoking list here. What would you add? What would you argue with?
tags: web 2.0
| comments: 19
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/5137
Comments: 19
I hate to disagree, but I think that's more how programming has been for many developing in the dynamic language crowd for the past decade or so. It's a pretty good list for that however :) . However there's an interesting exception to those comments: realtime updates. I figure this is a symptom of something deeper.
There's a reason realtime updates are possible - people & systems using the data from the service are resilient to service failure. Not only that, there's an increasing number of systems that are "get data from here, merge it with this, and republish". Mashups of web services do this on the large scale.
It can also be done on a smaller scale as systems like Unix, Occam, Erlang & Kamaelia show (with Kamaelia systems we've built a proof-of-concept version of the visual editor that allows us to change the running systems - which is similar conceptually to realtime updates). In each case the service providers become components in a larger system, and are unaware of how they are used. Every larger system can be used a component and so on.
But what does this give you? As well as being able to control many computers at once in an application, it gives you the same benefits an organic system has : resilience and natural manageable concurrency. In the short term, mashups and friends are the general programmer's introduction to how to build concurrent systems in a natural way. However, given the same techniques apply on the small scale as noted above, this could lead (maybe) to a longer term change in coding style (we've found younger programmers find this easier to pickup and work with).
If we want to label anything as the start of a mass Programming 2.0 change, I'd label mashups as the transition point where developers naturally started change from sequential programming to parallel. As an industry we've known its been coming for a while, but it's now here.
Last year I spoke about Kamaelia Macro - which takes a DVB stream, demuxes it and slings it around to do interesting things, all written in a naturally concurrent manner. I've recently found the need to deal with RSS in Kamaelia, and I'm finding very little difference - I still need to detect transitions, demux data to appropriate locations, etc.
Also, I'm beginning to see systems in various places that are similar and reinventing the same wheel of composition for creation (something I find an opportunity, not a waste of resources). They all seem to be converging on similar ideas (some coming from dataflow, some from removing control flow, some from plugin architectures).
As a result if there's some things I'd change:
single sequential system -> communicating sequential systems / natural parallelism
monolithic control flow -> external control flow - eg plugins & data flow
I think its going to be an interesting year!
I'm not sure I agree with much of the chart. Lisp has been text based for longer than many of us have been alive. Unix had an end-user contribution model for a very long time. I assume slow->fast refers to completing projects rather than performance of code :) I think he is mistaken about procedural-> object-oriented. The most interesting stuff about Ruby, Python (and now C#) is taken from functional programming.
Unix, Emacs, vi, Smalltalk, Apache, Lisp is also proprietary, slow, centralized, fragile, monolitic Software?
There are many things that we loose with "new" apps, in the web and web 2.0 world. Fast, responsive and at least partially uniform GUI (see Apple Human Interface Guidelines, etc.). Many of the usability things. Multiple windows. Software development always evolves, and then something happens, and it reinvents the same problems, builds up the same obstacles for itself again. Also, there are problems we can never get over, like internationalization. Every new standard breaks on this. No, don't say HTTP is multilanguage... the biggest mistake was to allow different encodings, instead of Unicode.
We did desktop apps, with nice IDE, and native apps. Then the web came, and web 2.0, and we have similar problems as we did 20 or 30 years ago. Of course we solve som other problems in the process.
Where is refactoring and the modern dev environments? And taking for granted all the facilities that were special a few years ago, because the kits are so agile.
Let's face it, web 2.0 was about the big orange buttons - so much more dynamic, but is the increased volume of kitsch t-shirts sales really important?
The best is yet to come, with environments that can bring in the best component for your current work at the moment, and perhaps even spot collaborators. Dealing with the complexity. I just can't wait until we get past RoR's need for attention, cause it's not all that.
Sigh... I'm sorry, but no. I also program with Ruby, so I can understand why a Rails guy would be tempted to associate with "Web 2.0", but it simply isn't the case.
That list is almost opposite to the actual situation, and could be a list of what is NOT happening in programming, the list of things that will go away in 2007.
I can't replicate the pretty formatting, so unfortunately it's gonna be ugly. Let's go through each item.
Text - all source code has always been text. JIT and interpreters hide the compilation to some extent, but this goes all the way back to the most perfect implementation of this idea... Forth.
Plug-in - This has been around for the last 30 years, but it has indeed become more of a standard way of doing things in the last 10. Basically modular programming, which started with Pascal.
Write-Test-Run - a side effect of using interpreters. The real movement in this area is using embedded languages rather than how the primary code is developed. See F-Script for Mac.
Real-time updates - this does not happen now, and was done far better by Smalltalk and its image based environment. Is currently emulated by updating plug-ins.
User contributed libraries - has always been this way since the year 0. The whole concept of libraries is that users write code! Actual users (users of the users of the libraries) still don't write code and never will.
End-User Controlled - Always has been this way... originally by paying money for unique products, and is now done by selecting from an abundance of competing solutions.
Fast - cough, choke. Everything about Ruby, Perl, Java and other interpreted languages or object orientated languages is slow. Flexibility is at the expense of speed. That's why Fortran is faster than C.
Distributed/Open - this is more to do with communication than programming. Companies have an internal system where people work with each other, and the Net has enabled this outside of a company context.
Creation - too vague for me to comment.
Object-Orientated - the last 15 years, and is finally dying out, thankfully. The current move is towards Alan Kay's original idea of OOP, which was message-orientated. The other direction is functional, which is finally being presented in an understandable way in languages like Ruby.
Customisable code - side effect of plug-ins. If I keep saying the same thing, it's because this list really is repeating itself to fit into the format!
Agile - is dying. Was a bunch of crap in the first place, is now known to be a bunch of crap, and is now going where bunches of crap should have stayed.
Modular - 30 years ago, Pascal.
Small - all of this stuff is breathtakingly BIG AND FAT. When was the last time you saw a significant program in 20k? All this stuff takes MEGABYTES to run, gobbling up insane amounts of CPU in massively inefficient ways.
Microsoft tried to surf down this path with their .Net architecture, and was forced to rewrite in C++. You just can't do serious systems or processing with application languages.
Apple are at the cutting edge by going back to the best of the past, using C with Smalltalk extensions. Objective C is one of the strangest and yet most capable languages out there. See Mac OS X and its applications for proof by example (as opposed to proof by theory).
I'm sorry, but in no way can the state of programming be extrapolated from Ruby on Rails. That's like trying to judge what Carmack is doing by looking at PHP.
Sorry for the sequential posts.
I agree with the analysis by Michael Sparks. A current trend is in grouping multiple sequential systems and co-ordinating their activities.
Google's "Map Reduce" is a good example of this.
I suspect that the author of the list is relatively new to programming and is consequently commenting only on changes from recent practices. For instance, there is an emerging rejection of the massive class libraries used with Java (among others) because they’re too big for most people to have a handle on. But such excessive libraries are only a recent phenomenon. I believe that much of what is happening now is simply a retreat from excessive complication, something that happens periodically in the programming world. I personally am thrilled that many “new” practices resemble those that my colleagues and I used in the 1970s and that today would be termed “agile”. And “modular” has been considered good programming practice since the 1950s. Perhaps the shift he describes would be better characterized as from Programming 2.0 back to Programming 1.0.
Desktop Programming -> Web programming
Compiled -> Interpreted
Strongly typed -> Weakly typed or even type-less
Single language per solution -> Multiple languages per solution (PHP+Javascript)
None of these should be interpreted as the LHS disappearing. The LHS still has it's place and there are plenty of problems that still require LHS solutions.
Generally a good list, BUT...
I'm with Justin Watt re: the "Procedural -> OO" shift. OO hit a mindshare apex in the late-1990s early-2000s, but the preferred programming style has always been "what works best". It's also tricky because how do you differentiate between what's OO and what's procedural since OO programs still execute in a procedural manner - the main difference being that OO procedures ('methods') execute in a non-idempotent manner vs. traditional procedural procedures ('functions').
Another thing is that even some languages that support objects aren't often used in what I'd consider an OO way (this is not a criticism). E.g. PHP has objects but I don't know how many PHP programs I've seen that have code like:
an_object->a_method(true, false, 1, 10, 'hello', 'world');
The above is OO in the sense that it's a method attached to an object, but it doesn't have any other traditional characteristics of OO (abstraction, polymorphism, etc.). Again, this isn't a criticism of this programming style; it's good if it works now and can be adapted over time without too much pain.
If anything the trend I've noticed is greater interest in functional programming (e.g. functions as a first-class concept in Javascript and also the ability for functional programming to more naturally support concurrent programming).
Maybe in the web world these things are true, but in the larger world of software development, embedded applications, desktop applications, etc, I think the main shift is multi paradigm approaches, OO / Functional / Compiled mixed with Scripting / Binary mixed with Text / Better Tools, Better frameworks / More Fluid approaches to design / Networked systems vs standalone.
I think the list presented is just a subset of a set of tradeoffs for different payoffs that works well in the rails world for web apps, I think in differnt enviroments there are different tradeoffs gaining you different advantages.
Understanding the power of how to mix all kinds of ideas for different payoffs is really important. This covers languages, design, deployment, method, people, business model etc.
This list might be true for people coming from php or perl to ruby. But for people who have been programming java/c# for some time, it's not much new here.
- Fragile -> Agile (The agile movement has been here a long time
etc etc
Can someone please ship the Web 2.0 security patch some time soon? The attackers have upgraded to Attacker 2.0, but Web 2.0 uses the Web 1.0 security model.
More thoughts here
http://1raindrop.typepad.com/1_raindrop/2007/01/o_web_20_app_se.html
It's an arm-chair history of software methodology, with about as many truck-sized holes as one would expect from such. For example: about a trillion programmers working on Microsoft technologies for paying clients disprove the claim that compiled, proprietary systems are in any kind of significant decline.
But, hey, this is the Internet, let's shoot from the hip!
I just wish "steve" would have posted a link so I could read more by someone who seems to know what he's talking about.
Brad -- no one said that compiled, proprietary systems were in decline. And your argument might be called "the Cobol defense." The fact that for many years Cobol was still the most widely used programming language didn't mean that the industry as a whole had moved beyond it.
Web 2.0 doesn't mean that other types of programming aren't still incredibly important, just that there's a new class of application that uses very different techniques and skillsets. That's why back in 1997, I was trying to coin a new term -- "infoware" -- to describe the fact that the killer apps of the internet were substantially different than the apps of the shrinkwrapped software of the era that preceded them.
Post A Comment:
STAY CONNECTED
RECENT COMMENTS
- Tim O'Reilly on Programming 2.0: Brad -- no one said tha...
- walter higgins on Programming 2.0: Procedural -> Object-Or...
- Brad on Programming 2.0: It's an arm-chair histo...
- Gunnar on Programming 2.0: Can someone please ship...
- olemartin on Programming 2.0: This list might be true...
- Keith Nicholas on Programming 2.0: Maybe in the web world ...
- Tim O'Reilly on Programming 2.0: Nate -- that is brillia...
- Nate Westheimer on Programming 2.0: Nate can't do it --> ...
- Bill Higgins on Programming 2.0: Generally a good list, ...
- Julian Bond on Programming 2.0: Desktop Programming -> ...
RADAR TOPICS
Justin Watt [01.06.07 12:43 PM]
The only assertion I might disagree with is a defacto move towards object-oriented programming. C++ and Java pushed this methodology throughout the 80s and 90s, and look where they are now (important yes, but not capturing the popular imagination). I think a lot of people writing web apps (esp. those using PHP, Python, Ruby, and JavaScript) are starting to say that the programming methodology should fit the problem---and not vice versa. Rasmus Lerdorf comes to mind, but certainly there are others.