August 2004 Archives

Marc Hedlund

AddThis Social Bookmark Button

Related link: http://weblogs.asp.net/rick_schaut/archive/2004/08/28/222124.aspx

In Rick Schaut’s blog entry, “Adumbrating in Word,” he very nicely describes the core problem I have with Microsoft Word. Rick writes:

Nearly everything we’ve done with Word, and nearly everything we continue to do with Word, is designed to relieve the user of having to think about the mechanics of writing, thereby allowing her to focus on the content. Don’t want to worry about common spelling errors? Let Word do it. Don’t want to have to type in long paragraphs of boilerplate text? Let Word do it. Don’t want to worry about line breaks and page breaks? Let Word do it. Want to have successive side-by-side paragraphs align at the top with each other yet not have to figure out how much vertical space to add beneath the shorter paragraph? Drop in a table, and let Word do it. Don’t want to bother with counting spaces in order to center a title? Let Word do it.

Now astute denizens of the Web might be quick to point out Adam Engst’s discussion of the hypothetical WriteRight, in which he points out that there is no good word processor for professional writers. And, I should add, Adam is absolutely correct on that score. There is no word processor, including Word, that’s perfectly suitable for professional writers.

So, Rick, if Word’s supposed to be a writing tool, why do professional writers curse it so much? Well, professional writers represent only a small portion of the overall market for word processors. The majority of people who use Word have a primary job function that includes having to do some writing, yet where writing isn’t the core of their work.

The needs of most Word users aren’t the same as the needs of professional writers.

That distinction is the problem. Right after I got out of college, I worked for a while as a paralegal — a job which involves an inordinate amount of copying. I was, in Rick’s usage, for a few months at least, a professional copy-maker. I worked in a corporate law firm, one with a very nice, expensive, top-of-the line copier. It had every button and gizmo and attachment they could possibly think to add to it, and it sang along faster than any copier I’d seen.

And I hated it.

This copier was convinced — absolutely certain — that it was smarter than I. It knew perfectly well what I wanted, and it would get that done for me right quick in a hurry. You see, hundreds of engineers had worked for years to make it the smartest copier on the face of the earth, so that I, the professional copy-maker, could sit back and relax. My job was simply to feed it documents to be copied and occasionally to reload it with ten-foot-high stacks of blank paper, and stay out it its way. It would beep at me when my job was done.

Of course, it wasn’t really so smart, after all — I’m sure you saw that coming, since you, too, are smarter than any copier yet invented. When the copier noticed I had fed it double-sided originals, it was absolutely certain that I wanted double-sided copies — I had asked for copies, right? (Never mind that the court mandated single-sided filings, and that the fax only sent single-sided pages.) When the second page of a 250-page document went through the feeder with the third page stuck to it, it was positive I wanted to wait ten minutes for the copier to feed the remaining 247 pages back into their original order. (Never mind that I could do the same correction in a few seconds — it overrode the cancel button to make sure it got to do it for me. It was Shlemiel the copier.)

I’m sure someone from Microsoft will read this and think, “Yes, Marc, for 250-page documents, this copier got it wrong — but for the average user, it was the right default.” And that’s just what I hate about Word. It assumes that it knows what the average user wants, and it gives the average user just that, good and hard.

I am not (as is probably obvious) a professional writer. I rarely use Word — in fact, I go out of my way to avoid it. While I think many of the ideas in Adam Engst’s WriteRight proposal are fantastic, for the most part I have no need for them. But I use technology every day, and I pay a lot of attention when I see people — “average” people as well as those above and below the average — using and being frustrated by technology. Technologies that always frustrate people are those that assume wrongly what the user wants. Worse still are those that repeatedly make erroneous assumptions, and masterfully obscure corrective actions or settings. Microsoft Word is the Lord High Pooh-Bah of this approach — wherever Rick says, “Let Word do it,” what he really means is, “Word will do it for you, whether you like it or not.” It’s definitely true that Word has, over the years, added settings to turn off all the ways it takes what you type and inserts instead what it thinks you meant to type — and, if you are a “professional writer,” you’ve no doubt found them all by now, and found them again in their new location with each new upgrade. If you are not a professional writer — if you, as Rick says, “have a primary job function that includes having to do some writing,” you probably haven’t. Instead, you probably get mad every time you open Microsoft Word.

There is no difference between the needs of the average user and the professional writer when it comes to sitting in front of a computer to get a task done — both want the computer to help and stay out of the way. Word asserts, 70% of all users want a bulleted list right here! or an URL with a blue underline right here! — and annoys the hell out of 30% of all users. Worse, you will inevitably move from the 70% group to the 30% group several times in each document.

Microsoft hires very smart engineers — I would say the smartest in the business. When they see that some number of their users have some writing problem they believe a computer could be trained to solve, they do a better job than anyone at writing the code to solve that problem. They talk all the time about “knowledge workers” and their needs. What the Word team lacks, in my view, is an awareness that, when a user is trying to get his or her own work done, the user is always smarter than the technology. Assuming that smart people aren’t their market is the surest way to produce a bad word processor, which is exactly what I think they’ve done.

Marc Hedlund

AddThis Social Bookmark Button

Related link: http://www.nytimes.com/2004/08/26/technology/circuits/26ipod.html

Okay, developers, head on over to the New York Times’ Circuits section, and get yourself a good laugh reading about how iPod users anthropomorphize their preciousssss device’s “Shuffle” function. Who knew Apple had cracked AI? or that /dev/random had good taste in music?

Donald Norman will get a kick out of this article — it’s a nice example for some of his ideas in Emotional Design. (In fact, when I searched for “emotional design” on Amazon, one of the three “related searches” it showed me was “ipod”!) We love our iPods so much, we attribute to them powers beyond any the developers could possibly provide. Great design obviates the need for programmers to solve some problems.

Sure, Real can compete on price, but can they compete with the awesome power of the “Shuffle”?

Dave Wood

AddThis Social Bookmark Button

Related link: http://www.oreilly.com/catalog/headservletsjsp

Sometime in the next few days, the third book in O’Reilly’s Head First series will hit the shelves. I’ve spent quite a few insanely-early-morning hours as one of several technical reviewers of this book. Consequently, I feel qualified to say that Kathy and Bert (along with new co-author Bryan Basham) have another winner on their hands.

Like the first two books in the series, HF Servlets and JSP has that rare quality of actually being fun to read. I know, it’s a crazy concept for a geek book, but it’s true. If you haven’t read any of the HF books, be sure to check out sample pages from the first one here and here. Head First books manage to make learning complex material interesting, fun, and easy without “dumbing down” the subject matter. The Servlets/JSP book is no different. Going beyond the APIs, this book will really help you understand how servlets and JSPs work.

Oh, and if you’re into the whole Sun Certification scene, the book is also designed to serve as a study guide for the SCWCD exam. Full of sample questions, the book will teach you everything you need to know to pass the exam.

Dejan Bosanac

AddThis Social Bookmark Button

This weekend I attended EuroFoo conference at the University of Twente in Enschede, the Netherlands. The concept of the conference was great. There were no official sessions, but the whole idea was that intenders create the conference schedule.
Although, there were no much Java people and sessions on Java, it was very valuable to see what people from other open source communities are working on.
Rickard Oberg’s presentation of the AOP framework, they have developed and use internally on their project, was very interesting.
Also, there were few sessions for book-lovers and people who are interested in writing. There, you could hear discussions on what makes good book and how to approach technical writing. Tim gave very nice talk on the book selling trends and how it reflects industry trends.
Tim’s “Open source paradigm shift” talk was truly inspiring.
People from Python, PHP and Apache communities talked about development model they follow. As a PHP user, I found very interesting the lack of organisation in PHP development process.
Ivan Ristic gave interesting talk on Web application security. This topic should be important to wide range of developers but too many people seems to disregard it.
Beside these “official” sessions there were few casual events that were very amusing. I specially liked “lightening talks” sessions were people that only need five minutes has spoken. “Gadget olympics” gave chance for intenders to show their favorite gadget. The blinkenlights project hooked me immediately. Great idea.
All in all, it was great fun.

William Grosso

AddThis Social Bookmark Button

Related link: http://www.sdtimes.com/cols/javawatch.htm

Allen Holub recently wrote a perceptive critique of the evolution of JavaOne. Some of it, like the following description of a talk, matches the complaints other people have been making as well.


By contrast, this year I listened to somebody droning on for an hour about a list of APIs, with no attempt to describe the overall architecture and design considerations of the subsystem. Mix in a heavy-enough accent so that you understand only half the words, a pace so slow that it puts you to sleep and no real code examples, and you’ll understand the depth to which the conference has fallen.

Unfortunately, some of his suggestions are lame and he doesn’t address the real problem. Which is this:

The Internet Changes Everything

In the age of the internet, it’s much harder to create a large-scale informative conference. Large conferences have large audiences. Speaking to 500 people is mostly non-interactive. It’s one-way communication aimed at disseminating information. It’s also inconvenient for everyone involved (we all have to be in the same room) and is going to gloss over a lot of the crucial details.

Since the web does one-way communication aimed at disseminating information very well, and the web is much more convenient for everyone involved, and the information from the conference is going to be on the web anyway …. large-scale conferences have to make fundamental changes in what they’re doing, or die.

The choices, as I see them, are:

  • Become more convenient. No Fluff does this very well, by taking the conference to the audience’s hometown. NFJF isn’t a large conference though.
  • Become more interactive. Either the presentations have to become conversations, or there has to be significant support for conversations that wouldn’t otherwise occur. This is what Dave Winer is aiming at with his discussion leader idea. BloggerCon is limited to 300 people though.
  • Offer content that can’t be found on the web, or whose findable web-form is vastly inferior. JavaOne has done this to some extent by charging for access to slides from the conference. But, at the end of the day, you have to ask: is what you learn from JavaOne better than (or does it significantly improve on) the JavaDoc and the articles and weblogs already available?
  • Offer an immersive experience that, by sheer volume and overload, is qualitatively different from what is likely to be achieved in a home office. Big conferences have the opportunity to do this well.

Now, if you read Allen’s discussion, it’s pretty clear that he hasn’t addressed any of these bullet points.

I agree with a lot of what he says, and his suggestions would make the conference better (except for eliminating the keynotes. They’re my opportunity to sleep late without missing anything). But he hasn’t explained why his new and improved version will beat using Yahoo Search on a Saturday morning. And without that, why would anyone go to JavaOne?

Some of his suggestions are also somewhat infeasible. When Allen writes


Sun should ask the user community, “What are you working on, and what programming problems are you encountering?” and then develop sessions to address those problems, to help programmers write programs.

It’s pretty clear he’s proposing a strawman. Polling the developer universe and then crafting the conference around the answers? That probably can’t be done within a yearly timeframe for a fast moving technology. But my objection is mostly a quibble: if you had carefully chosen developers from outside SUN also choosing the presentations, you could get 90% of what he’s looking for.

Of course, I don’t really have a solution either. But I have a suggestion. Here’s what I’d pay money to see. Hire a dozen really top notch consultants for a year. They spend 6 months working with a customer, and then 4 months talking about it to various user groups, refining a two hour presentation on what the customer was doing, what problems the customer encountered, and what the eventual solutions were.

At JavaOne, offer the talks repeatedly. As a two hour talk and then as a series of one hour discussion sessions. It’s “Here’s a top guy from the field, doing a real world case study of a significant implementation.” And it’s a refined and honed presentation that has been improved by repeatedly giving it beforehand.

Why would consultants do this? well, it’s a year long gig with a big prestige bonus at the end, and a lot of speaking opportunities and exposure along the way.

Why would a company be part of this case study? They get six months of top-notch consultant + support. That’s a significant amount of help, for free.

Does this meet my bullet points? I’m mostly going for the immersive effect (24 hours of real world implementation experience within a week? That’s going to focus my brain in ways that a hour here and an hour there won’t). It’s also more interactive, and probably superior to what can be found on the web (because it focuses on case studies, and there aren’t a lot of high quality case studies on the web).

Got a suggestion for improving JavaOne?

Eric M. Burke

AddThis Social Bookmark Button

Information trackers tend to want more detailed information than producers can produce. What do I mean by this?

Consider the case of defect tracking tools. Most tools let you define a set of priorities, such as “Low”, “Medium”, “High”. What do you think happens when you take this to the defect tracking design committee? In my experience, the committee will want more detailed information for tracking purposes. They’ll want to expand the list to include things like “Showstopper”, “Lowest”, “Highest”, etc.

For issue types it is even worse. You’ll end up wanting to include “defect”, “feature”, “documentation”, “design”, “requirements”, etc… The more people on your design committee, the more detailed and fine grained the information will be. That’s a natural tendency for the tracker-side of the equation.

Resist the urge to make everything so fine grained.

The producers of this information, the programmers, won’t know what to do if they have 15 different issue types to choose from. Some will argue “This is a training issue! Just teach the programmers what the different statuses mean.” But remember that the job of the information tracker is to track this information, but the job of the information producer is to write code, fix bugs, etc. They probably don’t have enough insight into the subtle difference between “high” “highest” and “showstopper” to choose the correct priority.

In my opinion, making these fields incredibly fine-grained and detailed will not result in better data. Team members will just be confused by the sheer number of choices, and they will inevitably default to “Other” as their choice.

I once worked on a very large programming team that held regular code reviews. We were given a standard form, and we had at least 15 different categories for each type of issue found during the review. This was a constant source of confusion and debate during the inspections, diverting attention away from the code review itself. Is this a documentation problem? Is it a programmer error? Is it a missing requirement? Let’s just check “Other” and move on.

William Grosso

AddThis Social Bookmark Button

Related link: http://www.freedom-to-tinker.com/archives/000661.html

Over on Edward Felten’s blog, there’s some discussion of recent papers announcing collisions in SHA-1. As Felten put it, “Since SHA-1 is the most popular CHF, and the other popular ones are weaker cousins of SHA-1, a break of SHA-1 would be pretty troublesome. For example, it would cast doubt on digital signatures, since it might allow an adversary to cut somebody’s signature off one document and paste it (undetectably) onto another document.”

Opinions vary on just how serious this could be (for example, this article argues it’s not so bad in the short term) but it seems clear that, when you factor in the likely collisions in MD-5, that a fair amount of our cryptographic infrastructure may be weaker than we thought.

If you didn’t understand this blog entry, start reading the wikipedia.

The big question: if SHA-1 and MD-5 do have collisions, what should we do?

Eric M. Burke

AddThis Social Bookmark Button

I love IntelliJ IDEA, but I’m baffled as to why I can’t drag and drop items in the project tree. They already support the Move refactoring. It just seems natural to grab a node in the tree and drag it to its new location, thus triggering the refactoring.

The same is true of the Rename refactoring. Why can’t I just click a node in the tree two times slowly (like in Windows) then overstrike to type a new name? (I know, I can hit Shift-F6, but my brain forgets all of the keystrokes).

William Grosso

AddThis Social Bookmark Button

Related link: http://www.forbes.com/home/businesstech/2004/08/05/cx_js_0805msft.html

Suppose you were reading an article on Forbes.com and you saw the following paragraph:

Linux is a different kind of opponent. It’s not a company to bash but a software movement with the backing of the entire tech industry. IBM (nyse: IBM - news - people ) invests billions in open source software and is backing the two leading Linux distributors, Red Hat (nasdaq: RHAT - news - people ) and Novell (nasdaq: NOVL - news - people ). (Yes, there is revenue in free software; these companies get money supporting Linux.)

Suppose further that “open source” was a hyperlink. Wouldn’t you expect that clicking on the link would lead to a definition of open source? Or a Forbes article on open source? Or a list of Forbes articles on open source?

You’d be wrong. In this case, it’s actually a “Sponsored Link”, delivered by a company called Vibrant Media, which sends you to a company called Analyst Views (which paid for the link).

In other words, embedded as a link inside the article is a paid advertisement. Here’s how Vibrant Media describes it:

“IntelliTXTsm is a pay-for-performance ad unit that delivers the advertiser’s message via contextually-relevant keywords within article-based content.”

It’s interesting. My reaction to it was that it felt somewhat deceptive. Things that look like hyperlinks, embedded within articles, ought not to be advertisements. It just feels too much like an attempt to disguise the advertisement as part of the article (To be fair to Forbes, if you hover the mouse above the link, you’ll see a tooltip saying it’s a sponsored link. And the “real” links have a slightly different look and feel– scroll down in the article and look for Steve Ballmer)

At this point, magazines like Forbes aren’t first with the news, nor are they the most comprehensive information source. Most of what they’ve got, and the major reason to read them, is their level of editorial credibility. Embedding “Sponsored links” within the article text, so that they look like standard links, goes a long way towards reducing that credibility with me.

What do you think? Are the sponsored links a reasonable way to generate revenue? Or are they deceptive enough that using them reduces article credibility.

William Grosso

AddThis Social Bookmark Button

Related link: http://www.longnow.org/

I first heard of the Long Now Foundation what seems like a long time ago. Stewart Brand was touring the country, giving talks about it, and I went to one of his talks (I remember being astonished; it was a talk in a local bookstore and only 30 or so people showed up. For a free talk by Stewart Brand. That seemed astonishing to me). It was a very good talk about the importance of long term thinking. I don’t remember much of the specifics of what he said, except for a great anecdote which went something like:

Alright. Now, how many of you have eaten a lobster?

[Everyone raises hands]

Now, how many of you have eaten a lobster without making a mess?

[Nobody raises their hand]

How many of you know know someone who’s eaten a lobster without making a mess?

[Nobody raises their hand]

That’s interesting. I know a man who has [pause] Of course, he’s a surgeon and it took him two hours…

[Everyone laughs]

It seems silly, but there’s an important point here. Everything becomes easier if you have the right tools and enough time. A lot of the problems we’re looking at today, that we’re wondering if they can be solved, are easy if try to solve them in the long run, instead of right away.

Whenever I get frustrated by the pace at which things go, I remember the surgeon and the lobster.

Anyway, as part of its activities, the Long Now Foundation holds a seminar on Long Term Thinking. It’s a seriously great series of talks. I always drop $10 (the suggested donation) in the admission jar, but you can pay as little as you want (or nothing; payment is voluntary).

That the seminars are available after the fact is just lagniappe.

I don’t have much else to say. This is more of a public thank you to the folks at the Long Now than anything else.

Do you ever engage in long term thinking?

Marc Hedlund

AddThis Social Bookmark Button

Related link: http://www.bloglines.com/about/pr_08122004

Bloglines, my RSS reader of choice, just passed 100 million blog entries indexed. Wow, that’s mind-blowing. First, it’s incredible that 100 million blog entries have been written in the past year. Get outside, people! Second, it’s incredible that one service does such a great job of indexing and serving so much information. For me, Bloglines is like Google and the Internet Archive in one — it’s not just search and it’s not just archival, but instead it’s a single interface to find and read and organize all the timely information I receive online.

I’m really looking forward to Bloglines’ second year. Mark Fletcher, the CEO of the company (and a great guy) has been quoted as saying startups should design as though hardware were free. Given the growth path they — and blogs and RSS — are on, he’d better hope that becomes true sometime soon!

William Grosso

AddThis Social Bookmark Button

Related link: http://www.nylf.org/

A few weeks back, I gave a talk at a NYLF Technology Forum. NYLF itself is interesting– it puts on week-long high-exposure events that give promising high-school students the opportunity to learn a lot about an industry, from people in the industry.

I talked about startups in Silicon Valley. I basically went through the gamut of “here’s how they start, here’s a brief look at typical organization structures, here’s what the roles are, and what the positions are called … ” A sort of blend of anthropology and career advice.

One of the things that bothered me when I was preparing for the talk, and which was highlighted by the questions as well, is that, at least here in Silicon Valley, there aren’t a lot of junior development positions.

I’ve been watching it for a couple of weeks now across a couple of sources, and it seems that, in terms of advertisements, less than 5% of the available positions are for junior developers (for example, if you look at craigslist in the San Francisco Bay Area, a typical day has about 30 advertisements, and 1 or 2 of those are junior).

It’s pretty clear that if the market for junior developers is <5% of the total software engineering market, we're not in an era of huge expansion.

But, the question is: is 5% a harbinger of future shrinking in Silicon Valley (all the junior developer jobs are elsewhere) or a sign that we’ve gotten to a stable economy for software developers.

What’s the percentage of junior jobs in a stable industry? And what other easily-spidered indicators are there?

William Grosso

AddThis Social Bookmark Button

Related link: http://jroller.com/page/globalblogger/20040727#phoenix_no_fluff_just_stuff

A few weeks ago, I spoke at the No Fluff Just Stuff conference (highly recommended, by the way). During one of the speaker panels, one of my answers got blogged. Since the blogged answers were probably representative of what I said, but not of what I was thinking, I’m now taking the chance to correct the record. In my last post, I explained why programming languages are unlikely to change much in the next 5 years.

Today, I’d like to address the second part of what I said. I said something like “Instead of changes in programming languages, there are going to be changes in libraries. The biggest of which is that we’re all going to be worring about how to deal with huge masses of semi-structured and slightly incompatible information.”
And then I put a plug in for GATE.

Emad Benjamin blogged this and then wrote “I think he is walking the google line here.”

Which is interesting, but, I think, false. I tend to doubt that google is walking this particular line. And ownership of the line in question really belongs to Jaron Lanier anyway (I also highly recommend Jaron’s talks. If he’s in your area and speaking, GO).

Let’s talk about the line. Here’s some premises:

  • Today, approximately 50 billion years after the first computer programs were written, the vast majority of systems are still standalone.
  • In fact, most business systems are silos.
  • SQL is all about being able to access data, no matter which RDBMS it’s in.
  • CORBA was all about interoperability.
  • The web succeeded in a phenomenal way for a lot of reasons. But at least one of them was the fact that, finally, people could actually access each other’s information.
  • Suites like Microsoft Office use data compatibility as a powerful sales force. If enough people upgrade, then everyone else has to as well (Office used to do this; other products still do).
  • Data warehousing is really all about data integration.
  • Most XML usage is about being able to access other people’s data.
  • Web services were adopted because of interop.
  • Web services continue to evolve in the direction of increased interoperability (coarse grained service oriented architectures are better for interop than SOAP).

In fact, I would claim that most, not all but most, of the major trends in Enterprise Software (which is, for the most part, where the money is) for the past 20 years have been either primarily or largely concerned with interoperability.

Now, if you think about it, there’s are two possible reasons for this. One is that we, as an industry, know how to do interoperability really well, and we’re sticking to what we’re good at. Just like a shoemaker who is really good at making wingtips, and therefore only makes wingtips, we only do interoperability.

I don’t really buy that one. Do you?

The other is that interoperability is one of the major problems with computer systems today. After a couple dozen industry-wide shared solutions, most applications still can’t share data or work together in any meaningful way.

Now you could say “as soon as we all adopt the same set of XML formats for all our business processes and all use loosely-coupled service-oriented architectures, this problem will go away.” And I will cheerfully smile and nod my head and tell you that, by golly, you have a point there. And I will also make a mental note do not buy software from this guy.

Instead of the panacea du jour, I will put forth the following deeply skeptical (of current solutions) and highly optimistic (about future technology) proposition:

We will get out of the interoperability mess when a piece of software can run across a file format it has never seen before and, perhaps with an end-user (not a programmer) answering a few simple questions, figure out if the file contains useful data, what that useful data is, and be able to handle files in the same format later without any additional help.

Then, and only then, will we start to make a dent in the interop problem.

And, I think that by 2009 we will be starting to approach this level of fluency. Programs will simply be able to handle any data we throw at them, in a reasonable and robust manner. And tools like Lucene and GATE (and jtidy for that matter), along with really fast CPUs and tons of memory, are a very good start.

Was that walking the google line?

William Grosso

AddThis Social Bookmark Button

Related link: http://jroller.com/page/globalblogger/20040727#phoenix_no_fluff_just_stuff

A few weeks ago, I spoke at the No Fluff Just Stuff conference (highly recommended, by the way). During one of the speaker panels, one of my answers got blogged.

The question was addressed to the entire panel and was, approximately, “What do you think the big changes in 2009 will be?”

Ted Neward started the ball rolling with new languages emerging, Java much smaller than it is today and gradually dying, and maybe aspects a big thing. The next guy said similar stuff. And then it was my turn (and Stuart Halloway was after me, and I just knew he was going to talk about being test-infected and dynamic languages as well).

So I said was something like:

  1. There won’t be any widely adoped new programming languages.
  2. Instead, we’re all going to be worring about how to deal with huge masses of semi-structured and slightly incompatible information.
  3. Libraries like GATE will be a big part of this. Simply finding relevant information is going to be hard, and fields like computational linguistics will become more and more relevant to the task.

Now, in retrospect, that was much too coy, and I can see how it might have been heard as “talking the google line.” If we’d had more time, or if I had Ted’s carefully honed gift for pithy declarative statements, here’s what the “there won’t be any widely adoped new programming languages” part would have looked like:

  1. The rate of programming language change and adoption in the mainstream is going to continue to slow down. Basically, software development is a huge business and it’s got a lot of inertia. The switching costs for a new language are huge.

    Much as I’d like to go and deeply learn Ruby, I’m not going to because it doesn’t offer a lot of extra bang for the learning buck right now. And, by the time it does, if it ever does, it’ll be too huge to learn easily. One of the great tragedies of software development is that you have to learn early, and gamble that you learned the right thing.

  2. The style of apps we build will more or less be the same. Dave Thomas likes to point out that the web is similar to 3270 programming, and he likes to do so in a tone of voice that suggests this is a scandal akin to Tony Blair dumping Cherie for Bjork.

    But, hey, look at it the other way: in 50 years of computing, we’ve only found one architecture that consistently works on a large scale. Why assume that will change?. I’m with Adam Bosworth on this one– web interfaces are generally the right solution.

  3. Which is not to say I think that web-browsers are always the right solution. I think web browsers are good enough for 80% of our apps. But I do think that “web-architectures” (fat server, thin client, markup delivered to interpretation engine) are good enough for >95% of our apps (yeah, I know. People have been predicting the success of SVG for a while now. This goes a little beyond that though).

  4. In fact, I think we’re about to see one of the big architecture flips that our industry is so enamored of. Server-side container architectures are slimming down and becoming less overwhelming. But client-side containers (and that’s really what a web-browser is) are going to take off. I wouldn’t be surprised to see several more XML-based markup languages with their own containers emeerge by 2009. And people are going to be having fun with Eclipse.

All of which is to say: I don’t think there’ll be much change between now and 2009 in terms of what programming languages we use.

In my next weblog entry, I’ll explain why “Instead, we’re all going to be worring about how to deal with huge masses of semi-structured and slightly incompatible information”
isn’t just walking the google line.

Am I wrong? What do you think will be vastly different in 2009?

Advertisement