Category: Technology

This is why I love Wikipedia.

PIDA 0.2.2 was released recently. This is truly a novel development in the Python/OSS world. What PIDA provides is a nice plugin system and the “makings” of an IDE. So, in a nice IDE you have a class browser, an integrated debugger, a profiler, maybe even a RAD-like GUI builder, an interpreter console, etc. The one piece that tends to be most controversial in every IDE is the text editor. This is one-part because UNIX people are really crazy about their text editors, but two-parts because text editors are very important programmer tools, and no one wants to learn a different text editor for every language one uses.

vim happens to be awesome for C programming, which is probably why a lot of UNIX hackers use it. But for Python, more advanced support would be nice. PIDA can run and connect to a vim server instance in order to allow you to have an “add-on IDE” for vim.

But even more interesting to me is the culebra plugin, which provides a code-completion-savvy GtkSourceView inheritor, which has the initial support for fancy Intellisense-like features.

I’ve already spoken to the developers of PIDA, and they said they would very much be interested in seeing Python Intellisense features brought to VIM. When I started thinking about different approaches to doing this, I realized that the whole OSS community could benefit from a general Python module that enhances the Python introspection features (and perhaps combines them with source code parsing) to make available nice productivity-enhancing features. I was thinking of calling this beast “Pyductivity.”

More on that later. For now, check out PIDA.

This is exciting news. A Trolltech developer has modified KAA, the acceleration architecture used in Keith Packard’s experimental “kdrive” Xserver, to work with the traditional Xorg tree. He announced this new development in an e-mail that makes it clear it is extremely easy to get drivers to use Exa to gain Apple/Windows-like graphics performance.

I know that the unichrome project generally doesn’t bother itself with these very desktop-oriented features (their focuses are more on MediaPCs, etc.), but I think this may be an excellent way for me to begin hacking the new modular Xorg tree I mentioned last time. If I added Exa support to the unichrome driver, would that mean transparency and full-on graphics acceleration for my X desktop, what I’ve long been waiting for? We’ll see.

It seems that Xorg, as of the 7.0 release, has been split into monolithic and modular development trees. The modular model allows you to compile individual components related to Xorg separately from the whole X server, so that you don’t need to do a two-hour compilation just to work on this or that driver or this or that library.

This is good news for me. My biggest craving lately was to put my C skills to use by diving into a big project that has effects on the Linux desktop, and Xorg is certainly the biggest in that sense. However, in the past I was always put off by the huge amount of groking one needs to do just to understand the Xorg compilation process. After class is over, I’m gonna start diving in.

Gene Amdahl once applied the law of diminishing returns to computation. He pointed out that when optimizing part of a computer program or computer system, one must take into account what percent of the overall task at hand that optimization affects.

I recently read some articles comparing the speed of Python to Java, most of which concluded that about the only place that Java beats Python is in actual interpreter speed (i.e. how fast statements and parsed and executed), and that since Python opts to provide thin wrappers for standard C libraries, Python performance ends up being really good.

A good comparison of the language features between Java and Python can be found online, along with a nice comparison of code simplicity and efficiency.

I think I agree with the first author: Python is a better high-level language, and should thus be used for higher-level tasks, and especially for one-offs. What’s interesting is that a lot of people look at Python, say “Man, Python is slow, I could do this better in C,” but then forget about Amdahl’s Law. If your program is accessing the network, the disk, or any other non-CPU/non-memory resource, no amount of optimization through lower-level languages will save you an order of magnitude on performance. So why waste the programmer time, when it can be done in a few lines of Python?

(I think one forgotten benefit of Python in both these articles is SWIG: if you’re truly a performance-oriented engineer, you can always profile your code, find the bottleneck algortihm/code fragment, rewrite it in C, and wrap it with SWIG so that you can access it as an object in Python. Not hard to do, and potentially huge performance gains. OTOH, you can even write Python-accessible code directly in C, using the same abstractions the Python interpreter uses.)

Check it out.

Joel has a new article entitled “Hitting the High Notes”, which probably deserves a link.

I happen to fully agree with Joel, that good programming is about finding that “clever solution,” not just a solution that “barely works.” These little epiphanies may not just be the best product of good programming, but also the reward–another striking similarity to conventional artists. I started to realize this similarity myself a few years ago, when I scribbled in one of my notebooks that programming actually seems a lot like sculpting, in that the task is both highly creative and highly technical, where the goals are simultaneously to solve a complex problem and produce something “beautiful” (or, in programmerspeak, one might say “elegant”).

This ideas of mine didn’t find themselves blooming until I came across Frederick Brooks (who, in fairness, Joel mentions), in whose wonderful collection of essays is a very useful distinction between two components to programming. The more important one, says Brooks, is the essential component, which should be contrasted to the accidental. The essential problem to programming is that it is fundamentally a creative act, and as such it requires long periods of uninterrupted thought and even a spark of inspiration to result in amazing products. The accidental component to programming is everything else that incurs cost in time: dealing with the programming languages, the text editors, the compilers, software revision systems, documentation, and all the other software development tools. Brooks’s theory (which, in my opinion, held) is that there was “no silver bullet” for programmer productivity; that even if major leaps are made to reduce the effect of the accidental problem, the essential problem would remain, and without an improvement in the essential, there would be no order of magnitude improvement in productivity.

In other words (and metaphors), even though word processing is a lot easier than typing–which was itself a lot easier than writing by hand–it doesn’t seem that any of these advancements in “text editing” made the creation of great novels much easier, since it is the content of a novel that matters–presumably–and that comes only from within the author.

But Joel is mostly right: to fight the challenges inherent to the essential problem, one must have:

• A great work environment
• Talented colleagues
• Challenging problems
• Visionary direction
• Lots of alone time for each developer
• Lots of brainstorm time among developers

There are probably a couple of others that deserve to be on there, but that’s a pretty good list in itself.

I just watched a short talk on Ubuntu Linux given by Mark Shuttleworth. Ubuntu is the distro of Linux I have run for the last year or two. Quite an amazing talk, really. You can watch the whole thing here. He is quite a fascinating figure, but more fascinating is how clear his explanation of the Debian-Ubuntu relationship is.

If Ubuntu reaches the level that Mark hopes it will, it will truly be an amazing distribution. And I had never known about the other things Ubuntu works on, like Bazaar-NG, which allows distributed revision control (probably one of the coolest concepts in Open Source I’ve heard of in awhile). Rosetta is another one of those projects, which is a very cool web-based system for allowing translation of free software projects.

It’s an interesting time to be tracking desktop OSS indeed.

A really interesting article has been written at DrunkenBlog about Delicious Monster’s founder, Wil Shipley.

One of the rules of writing algorithms that I’ve recently been sort of toying with is that we (as programmers) spend too much time trying to find provably correct solutions, when what we need to do is write really fast heuristics that fail incredibly gracefully.

How right he is. But actually, it’s quite an interesting interview. I love engineers who work under OS X, and sometimes consider switching, but I’m convinced that Linux doesn’t have to be a “legacy” OS like it’s described here.