I don't remember who said it, but someone said that human affairs simply don't escape from the same basic set of patterns. Over the years, the patterns will repeat over and over again, each time with different tools, technologies and understandings, but the basic patterns don't change much. I call that the Theory of Deficient Imagination in Human. We just can't escape our bodies and everything embodied in it.
When I first heard that Google made GWT available for any programmer to use, I jumped for joy. It was one of the dreams I had on the web business, that someone would decide to treat all the browsers the way a previous generation of computer scientists treated the computers they had to program in: build an abstract layer on top to shield them from the programmer. That revolution happened more than 40 years ago, and this revolution in Web technology had just begun by Google. Eventually, I hope, programmers will forget how to build HTML pages and program in JavaScript. I think that even CSS will join in this group of technologies, and be forgotten by most programmers. Instead, programmers will use toolkits like GWT or something in the same vein, where the browsers are simply shielded, and program in a high-level language they are familiar with, like Java for GWT. I bet Ruby, Python, and whatever languages that stroke the fancy of some programmers, will also join in the revolution, and basically make HTML and JavaScript as important to know as assembly languages were when I finished university in the early 1990s.
Now, don't get me wrong, I have nothing against HTML or JavaScript. I have nothing against hand-coding them. In fact, the automatic generation tools I have seen until GWT are so bad in generating HTML and JavaScript that I think using them is simply foolish. On the other hand, even when I was struggling with assembly languages of various kinds fifteen years ago, I had nothing against them either. I just did not want to use them for big projects.
Am I equating HTML+JavaScript and assembly languages? You bet I am. Am I saying these sets of technologies are the same or at least similar? Not at all. JavaScript is a high level object oriented programming language. HTML is a mark up language for presentation. Whereas assembly languages are, well, symbolic representation of machine code, the stuff that processors actually run on.
Still, these two sets of technologies share the same characteristics in some important ways.
1. Compatibility is an issue. There used to be many assembly languages. All similar, but different in significant ways, other than one or two brain-dead ones, like 8086. Or some really primitive ones, like 6502, which has only one general register. Porting programs from one machine to another was hell. Well, writing a JavaScript program that will run on all the major browser is a pain, not yet hell, but worse in another way: when you write an assembly language program, you know it would run on one particular kind of machine, you have no illusion that it might run on a different machine. When you write JavaScript programs, you hope it would be run on the major browsers. So you try to program it in a way that it would be browser compatible. That is good and bad, obviously; and the result is that most JavaScript scripts are partially cross-browser compatible. Infuriating at times, if you use FireFox rather than IE exclusively.
2. Assembly languages are permissive: you have the whole machine to screw up. For processors without memory protection, this can be really destructive. But then, you don't want any restrictions at all for assembly languages. Same thing with browsers, they must be very permissive: since HTML and JavaScript are simply to help in presentation, unless there is no way to show some content, the browser should try its best to render it. What this means is of course that the browser has a different understanding of what "not working" means. This is not good for web applications programmers. They need to know that something is not right as much as possible, just the opposite of being permissive.
A toolkit like GWT is like C in the 1980s: finally, we could forget about the architecture, especially if we were using GCC. It is not exactly 100% portable, but good enough for most programs. Many programs can be ported quite easily from architecture to architecture. Of course, C and C++ became less portable again when Microsoft started putting in tons of weird constructs in them in Visual C and C++. Even better, symbolic debuggers became the norm for debugging programs. We did not need to know the assembly language of the machine to debug the program any more.
So, that was the situation: programmers wrote in a high-level language, debugged in symbolic debuggers. The programs were still compiled into assembly language: the best of both worlds.
Of course, many people thought high-level languages were over-rated. They would rather program in assembly language. You see, these high-level languages were simply not efficient enough. And the assembly language code their compilers generated was not elegant and worse, impossible to read by humans. What if we had to debug the assembly code?
Compiler technologies improved greatly over the next 20 years, and rendered this objection more or less meaningless. And I don't know many recent computer science graduates know how to program in any assembly language. In fact, some of them don't seem to know basic processor architecture at all. I guess they don't have to that need to write the vast majority of programs now.
While I love the audacity of the developers of GWT to come up with this most interesting technology, something that finally allows me to build real-world web applications easily, I am waiting for them to remove all abilities for the programmers to get to JavaScript and HTML. When I was writing simple recursive descent parsers for my toy languages, I always kept the asm() construct so that I could code in assembly language in case I needed the efficiency of something in assembly language. I never used it, actually. I can imagine the day when GWT is good enough that doing anything in JavaScript or HTML is simply not advisable.
So, what is my dream technology to build web applications? Well, perhaps a new language that is designed for this purpose. The GWT developers have to keep up with the evolving Java language. But if the language itself is meant for web applications, then there is no such problem. Of course, the whole thing should be seamless: you write a web application, without worrying about which part is part of the client, which part is part of the server. The compiler will figure it out for you. The deployment is not needed. To make the program available, it is simply that, a package that you execute, just like a normal program.
So, what do we need to make this into reality? Well, a server, like Tomcat, but not like Tomcat. You don't deploy to the server. You 'run' the program, like a Java program. The deployment to the server is simply automatic: the program runs whenever the process is there. You hit control-c, and the program dies. On the client side, why, you don't need to know anything more than the entry point to the program on the server. One single URL.
I wish I had the time to design a language for web applications, and build the server. And you know what, at that point, you really don't need the desktop; you only need a well-known browser.
I can't wait.
No comments:
Post a Comment