Home Closet Internet technology pathways

Internet technology pathways

by admin

IBM has just announced the IBM Lotus Symphony suite of office programs. It sounds like another variant of StarOffice (the free office suite from Sun Microsystems ). But I suspect they’re trying to erase the original Lotus Symphony, which was presented and publicized almost as much as the new coming of Christ, but ended up being pretty faded.
In the late 80’s, Lotus tried to decide what to do next with their main tabular data and graphics product, Lotus 1-2-3. There were 2 obvious ways : first, they could simply add new functionality. For example, word processing. This product was called Symphony. Another obvious idea was to create a program which would work with 3-dimensional tables. So 1-2-3 became version 3.0.
Both ideas quickly ran into a serious problem: the old DOS memory limit of 640K. IBM had just started releasing computers with 80286 chips that could address more memory, but Lotus didn’t think the market was wide enough for software that required $10, 000 computers. So they squeezed and squeezed. They spent 18 months trying to get Lotus 1-2-3 to run in DOS with its 640K RAM limitation, and eventually, after a bunch of wasted time, they had to give up the 3-D spreadsheet functionality to fit their product to the RAM limitation. In Symphony’s case, they just cut off functionality left and right.
None of the strategies turned out to be right. By the time Lotus 123 3.0 was released, everyone had an 80386 processor and 2M RAM. And Symphony had an unmodern spreadsheet and word processing mechanism and some other outdated stuff.
"Well, okay, buddy, " you’ll say. "Who cares about any old programs?"
But, give me a minute, because history repeats itself over and over again, and the smart strategy is to bet that the same results will repeat themselves again.

Limits memory and CPU power.

From the beginning of time until, say, 1989, programmers were very concerned about performance problems. Because, computers just didn’t have a lot of memory and high CPU performance.
In the late ’90s, a couple of companies, including Microsoft and Apple, noticed (a little earlier than everyone else) that Moore’s Law meant they shouldn’t pay too much attention to performance and memory savings… just build good products, and wait for the hardware to come along that would make it all work. Microsoft first released Excel for Windows when the 80386s were too expensive for most users, but they were patient. No longer than 2 years later, the 80386SX came out, and anyone who could afford to shell out $1, 500 could work in Excel.
As a programmer, I say thank you to the reduction in the price of RAM. And the number of CPU cycles doubled every year, you got a choice. You could spend 6 months rewriting your internal cycles in Assembler, or you could spend 6 months banging drums in a rock band, both of which would make your program run faster. Assembler programmers are no longer popular.
So now we don’t care too much about optimization and performance anymore.
Except for one thing : JavaScript running on browsers in Ajax applications. And since some time, this is the direction in which almost all software developers are moving, because it is a big deal.
Many of today’s Ajax programmers have megabytes or even more code on the client side. At the same time, it is not the RAM or CPU that creates the limit : it is the download time over a limited network link, and the compile time. In any case, you really have to shrink to create good complex Ajax applications.
History, however, is repeating itself. Wide web feeds are getting cheaper and cheaper. People are wondering how to create precompiled JavaScript.
Developers who put a lot of time into optimizing, compacting and speeding up will wake up one day and find that the effort has been wasted, or at least you can say that it "did not give them a significant advantage", if you are the kind of person who speaks the language of economists.
Developers who didn’t pay attention to performance and preferred to add cool and convenient things to their apps, by a long shot, will have better apps.

Portable programming language.

The C programming language was invented for the express purpose of simplifying the transition of applications from one instruction to another. And it made a huge step forward. But it didn’t create a 100% portable language, so we got Java, which was even more portable than C. Mmmm.
Right now there’s a huge gap in the portability story. And that’s – Taadaaam! – the client-side of JavaScript, especially the DOM (Document Object Model) in Web browsers. Writing applications that need to work in all the different browsers that exist is a nightmare. There’s no alternative but to fully test in Firefox, IE6, IE7, Safari, and Opera, and guess what? I don’t have time to test on Opera. Orega sucks. Startups have no way into the browser market.
So how will the situation evolve from here? Well well, you can try to beg Microsoft and Firefox to be more compatible. Good luck with that. You can follow p-code /Java models and create sandboxes (sandbox) – an add-on on top of the internal system. But it’s not the best option. Sandboxes are slow and suck, which is why Java applets are dying off. To create a sandbox, your sentence is to run at 1/10th the speed of the platform over which you created the add-on. And your fate is that you’ll never be able to use features that are there on some platforms but absent on others. (I’m still waiting for at least one person to show me a Java applet for phones that can access any function in a phone, such as a camera, contact list, SMS message, or GPS receiver).
Sandboxes never worked and they don’t work now.
So what happens next? The leaders take the path which worked for Bell Labs in 1978: build a programming language like C which is portable and efficient. It should compile down into native code (native code that would be JavaScript and DOM) with different backends for different platforms, where the compiler developers would already take care of the performance and you would not have to do this anymore. Such a language would have all the power of pure JavaScript with full access to the Document Object Model (DOM). And it would compile into the native languages of IE and Firefox flexibly and automatically. And yes, it will go into your CSS in an intimidating but logical way, so that you’ll never have to think about CSS inconsistencies between browsers again. Forever! Oh delight, when that day finally comes.

High interactivity and user interface standards.

The IBM 360 system used a user interface called CICS, which you can still encounter at the airport when you go through security check. There’s an 80 character by 24 character green screen, and only text mode naturally. The mainframe sends a form to the client (the client is the 3270 terminal). The terminal is smart; it knows how to display the form and allow you to enter data without interacting with the mainframe. This was one of the reasons why mainframe systems were so much more powerful than Unix: the CPU didn’t have to manage editing individual lines; that was entrusted to the smart terminal. (If you couldn’t afford to install smart terminals for everyone, you would buy System/1, a minicomputer that is installed between the terminals and the mainframe and manages the editing process.)
In any case, after you have filled out the form, you click "Submit" and your answer is sent to the server for processing. And then the server sends you the next form. And so on and so forth.
Horror. How do you create a word processor in this type of environment? (You really can’t. And in fact there has never really been a decent word processor for such systems).
This was the first level. It was reported according to the HTML phase of the Internet. HTML is the same as CICS, only with fonts.
On the second level, everyone bought a PC for their desktop, and of course the programmers were able to shove text anywhere they wanted on the screen and whenever they wanted it, and you could actually count every keystroke from the user as they typed. So you could create great fast applications that didn’t have to wait for you to hit "send" before the processor could start processing the data. So, for example, you could create a word processor that automatically finished a line by moving the words down to the next line. Immediately! Oh my God. Can you do that?
The problem with the second level was that there were no clear standards for the user interface… the programmers had too much flexibility, so everyone wrote in their own way, which made it very difficult. If you knew how to use program X, you also used program Y. WordPerfect and Lotus 1-2-3 had completely different menu systems, keyboard interfaces, and command structures. And copying data between the two wasn’t even an issue.
And that’s exactly where we are with Ajax today. Of course, there is a lot more convenience than with the first generation of DOS applications because we have learned some things since then. But Ajax applications can be incompatible and have a lot of problems to work together-you can’t cut an object from one Ajax application and paste it into another, for example. So, I’m not sure if you can transfer a picture from Gmail to Flickr. Come on, guys! The cut-and-paste method was invented 25 years ago.
The third phase with personal computers was the Macintosh and Windows. A standard, consistent user interface with such functionality as lots of windows on the screen and a clipboard designed so that applications could work together. We got amazing usability and power from these new graphical user interfaces, which led to the very rapid proliferation of personal computers.
So if history repeats itself we can expect some standardization in the Ajax application interfaces, so that development will take place in the same way as when we got Microsoft Windows. Someone is going to write an SDK (Software Development Kit) that can be used to create powerful Ajax applications with common UI elements that work well together. And such an SDK will win the minds of most developers and get the same competitive advantage that Microsoft got when it created its Windows with its API.
If you’re a web developer and you don’t want to follow the SDK standards that everybody else follows, you’re going to meet more and more people who won’t want to use your web app because it doesn’t allow, you know, cut and paste and doesn’t allow you to sync with your address book and doesn’t support any of the other functionality that we’ll have in 2010.
Imagine, for example, that you are Google with your GMail, and you feel a growing complacency. But soon, someone you’ve never heard of, a certain budding startup, may be making a ridiculous attempt to distribute a new SDK that combines a nice portable programming language that compiles into JavaScript, and even more, a huge library of Ajax-based chips. Not just cut-and-paste: cool, fun things like synchronization and single-point identity management, so you don’t have to tell Facebook and Twitter what you’re doing, you can just log in through a single point. And you laugh at them, because the new SDK is an intimidating 232 megabytes …232 megabytes! JavaScript alone and it takes 76 seconds just to load the page. And your app, GMail will not lose its customers.
But then when you see on your google stool in google plex, drinking your google chino and feeling arrogant, arrogant, arrogant, arrogant, new versions of browsers are coming out that support caching, compiled JavaScript. And of course the new SDK is now really fast. And Paul Graham gives them 6, 000 more boxes of instant noodles to feed on, so they stay in business for another three years to improve what they started.
And your programmers say GMail is too huge and they can’t port it into this stupid new SDK. They would have to change every line of code. So it must be completely rewritten, the entire program is in disarray and contains many recursions and the ported programming language contains so many parentheses that even Google can’t buy. The last line of almost every function contains 3, 396 right-closing parentheses. You need to hire a special editor to count them.
People using the new SDK have already developed a decent word processor. And a decent email system. And a killer Facebook/Twitter event publisher that can sync with everything, so people have started using it.
And while you’re not paying attention, everyone starts writing apps in the new SDK, and they’re really good, and of course businesses, only want apps written in the new SDK. And all these old-fashioned, primitive Ajax apps look pathetic and can’t even do the cut-and-paste and sync operation and interact perfectly with each other. And GMail is becoming a legacy of the past. WordPerfect from email. And you’ll tell your kids how adorable you felt when you got 2GB of storage space for email, and they’ll laugh at you.
An implausible fairy tale? Replace "Google Gmail" with "Lotus 1-2-3". The new SDK will be the second coming of Microsoft Windows. It’s exactly like Lotus lost control of the spreadsheet market. And it will happen again on the Web, because the dynamics are the same. The only thing we don’t know yet is the specifics, but it will happen.
This article appeared on the Joel on Software homepage. I posted my translation here.
What do you think?

You may also like