Computing is still in the dark ages

Despite all the talk of Web 2.0 and the shiny multicore machines with their gigabytes of RAM and billions of cycles per second, I sometimes can’t help feel that we are still very much in the dark ages of computing. This time around my dark gloomy feelings have been brought about by this message to a mailing list which in turn was sparked off by the announcement of the Go Programming Language. As a computer user and a programmer I feel that the actual use of computers is far below their potential.

As the years go by, it seems like we keep on piling layer on top of layer while the results aren’t proportional to what we have to learn to get things done. Now, I’m not proposing that we all start writing down-to-the-metal code or force everyone to become a programmer, but things are starting to look like a mess. Web programming is an interesting development, but it adds yet another layer on top of the existing kernel, operating system, libraries and GUI toolkits. Add to that the fact all browsers are still a bit different from each other and you can start to understand why I’ve yet to make a serious foray into web programming.

But even without the web and the many formats and barely interoperating systems out there, there’s enough on the desktop to get you depressed. Start with the fact that there are currently three major operating systems out there and if you want to write a program that runs on all three of them, you don’t have an easy task. You either embrace three different toolkits and programming methodologies and maintain 3 very different codebases, or you use something like Java which works on all three, but screams non-native on each one. Even though there are languages like Python that run on all of three, it really puts me off that there is still no top-notch multiplatform GUI library. wxWidgets tries pretty hard, but if you look at the screenshots you can pretty easily that they don’t look quite right. It’s not very surprising that lots of smart developers are flocking to the web, where things in comparison are a lot smoother.

There is also the fact that programming languages, like all other pieces of major software, suck more than others. I still stand by what I said in my last post, that it’s an exciting time for language enthusiasts, but I also feel that there are some lessons we really need to learn. I’m starting to have concerns that there may not be any true general purpose language, simply because there are so many different types of problems to be solved. I think we need to start creating broader categories: a set of systems languages similar to C going in the direction of D and Go. A set of hyper-optimizing VM-based languages designed for long-running, parallel server applications (the current JVM is a good example). A set of languages for writing end-user apps that are significantly high-level, but are still compiled to pretty fast native code (maybe not C or even optimized VM fast, but better than todays Python or Ruby). I’m thinking Python in its Unladen Swallow incarnation might fill this gap.

As a programmer, the state of tools that we have to use is really quite depressing. Tools like Emacs and Vi are powerful and all, but let’s face it: we could really be having much more powerful IDE technology. We should be having full blown incremental compilation with autocompletion and support for rendering documentation for every major language out there. We should also have seamless version control with granularity down to the undo level. Every change I make should be saved and I should be able to visually browse all these changes, see what they are and restore to an older state (or commit them if I want to). We have the raw computing power needed to do all this, but yet we remain stuck doing mostly batch-style edit-compile-debug cycles and mucking around in plain text. Eclipse with its incremental compiler makes things much easier, but there’s so much more we could be using our machines for.

As a user, what irritates me is the amount of manual labor we still have to do on a daily basis. We still have to carefully name and place files so that we can file them later. I have to manually hit the save button (see version control bit above). Even with the Internet collaboration is a mess with most people throwing around emails with increasingly larger attachments. Add to that the fact that most email clients are pretty dumb pieces of software. Google Wave is a step in the right direction, if enough people get around to actually using it (and if it can integrate to some extent at least with the desktop). Also I think the web and the desktop need to be brought closer together. Ideally I would be able to sit down on any computer with a live Internet connection and have my full custom work environment (or at least the most important parts of it).

I’m fully aware that none of the things I’ve mentioned are trivial. In fact, they’re probably very hard projects that will take expert teams a good few years to complete. One day I would like to seriously work on some of the programmer-related issues, especially the IDE part. I love Emacs, but there are some parts of Eclipse I really like too. For the time being I’m going to have to make do with what I have, but I’ll be sure to keep an eye for interesting things and movements in the right direction.

Is Bespin the 21st century text editor?

Integrated Development Environments are one of the primary tools of our trade. But personally I think an IDE can only be a good product if it has a robust text editing component. The king of text editors is Emacs. No offense to Vi users, but the Emacs + Elisp combo is unbeatable in my opinion, for a number of different reasons, programmability being the main one. Of course Emacs does have its problems. Steve Yegge discusses these problems quite thoroughly in his post on XEmacs. What’s interesting is that he claims that if Emacs doesn’t get its act together and fix its problems, it won’t be long before a browser sprouts enough editing capabilities to eclipse Emacs. I think that time is close at hand.

Enter Bespin. It’s a Mozilla project that is still under heavy development, but there’s a public demo already available. Bespin is an online text-editing environment written entirely in open source JavaScript. It’s provides syntaz highlighting and some project management and looks really slick by making use of the HTML5 canvas element. The best way to understand what Bespin can do would be to watch their introductory video:

It may not be immediately obvious what all the fuss is about if you’re used to using a modern IDE like Eclipse. After all, it’s just a text editor, right? Yes, it is just a text editor and that’s where the beauty of it lies. Firstly, t’s programmable in the Emacs tradition. That means that you are allowed and encouraged to write your own bits of JavaScript to adapt it to work the way you want to. Secondly, it’s sports an open server API which means that you could potentially use Bespin as an editor-like interface to anything you want. This has already led to Bespin running on top of the Eclipse IDE. Eclipse acts as the server and Bespin acts as the editor interface to it. Here’s a screenshot of Bespin+Eclipse in action showing Eclipse communicating errors in the Java code that Bespin is editing.

Keep in mind that Bespin is still in a very experimental stage. However, the example above is clear evidence that Bespin is going to be a force to reckon with in the IDE sphere soon enough. I think that bringing a client-server model to IDEs is going to offer a significant productivity improvement to programmers especially as developers and companies have to wrangle increasingly complex, heavy weight codebases.

Development machines need to be real monsters nowadays to efficiently handle the demands of the software being developed. Using Bespin, developers could invest in industrial strength servers which serve as both code repositories and build farms. The developer’s machine then act simply as terminals or can run local lightweight server instances for the Bespin frontends to connect to. This means that developers can afford having cheaper machines themselves, but don’t need to wait for long compile times as they’re being outsourced to the powerful servers. Code is also centrally stored meaning that it can be pulled up a moment’s notice and worked on collaboratively. This could mean more efficient workflows for software companies.

But the biggest win would be for the developers themselves. Here is how I can see myself using Bespin: I’d have a machine sitting in a safe, well connected location running a Bespin server. This would be my main development machine so I’d trick it out with as much RAM and processor speed as I could afford. The server itself might be some form of headless Eclipse or something equivalent for whatever language I happen to be progamming in. The cool thing is that since there is an implementation agnostic server API, I could even write my own server that lashes together compilers and build tools for whatever language I happen to be using and displays results via Bespin. The server would also use a version control system like Git seamlessly as part of the storage infrastructure. I could then connect to this server either from any modern browser meaning that I wouldn’t have to drag a machine with me to write some code. Anywhere hacking would be a boon for open source developers and students. I can also imagine a Github-like service that hosts both files and their development tools so that developers can avoid even running their own Bespin servers.

So is the age of always-available, online IDEs upon us? I think not quite yet. It’s still untested territory to a large degree. Bespin itself is coming along quite nicely and is implementing some very interesting ideas. But a lot is going to depend on how well the Bespin servers work. Headless Eclipse is fine for Java, but there needs to be similarly capable systems evolving for other languages and platforms as well. The API does a good job of keeping things minimal and implementation agnostic, but it also puts the onus on server developers to make quality systems targeting their respective platforms. I’m looking forward to some good work coming out of the Bespin and related projects in the near future. I’m even seriously considering learning some JavaScript so that I can better understand how the whole thing works. For the time being though I’ll stick to Emacs, though I’ll certainly keep an eye on the Bespin mailing list.