Xorg goes modular, is now approachable

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.

Amdahl’s Law

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.)

Joel Spolsky on programmer creativity

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.

On Being and Deliciousness

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.

New Years Resolution

To upgrade this website to Movable Type, among other things.

Last-minute hacking with my version of Metacity, and I finally got what I wanted. Basically, I was using xfwm4 for window management, and since it is NETWM compliant, I was supposed to notice no difference at all in GNOME. Except that’s not true, since xfwm4 doesn’t know about gnome-panel, and since a lot of useful hotkeys I want to use in gnome-panel are generally bound in metacity. Plus, the gnome theme manager doesn’t work without metacity. So, shame on GNOME developers, basically. You claim you are compliant, but you aren’t.

But then I did some reading and figured out metacity is actually a bit better than xfwm4 anyway, just that some of its features are hidden in gconf and other places. Also, someone has coded a neat app called devil’s pie which lets you manager your windows at a very fine-grained level, which I like… though it is a bit buggy right now, it shows promise.

So, the main thing I was annoyed by is vertical/horizontal maximize. xfwm4 has this working fine, and I’m quite used to it. Metacity doesn’t treat it as a “toggle,” so if you hit maximize vertical button twice, you just sit there with a maximized window… it doesn’t switch back and forth. I find this annoying since when I have vim windows open, sometimes to see more I just quickly maximize vertical rather than scrolling down, and then toggle it back afterwards.

Someone coded a patch to this. You can find it on bugzilla here at Bug #113601. Unfortunately, no one has written a “proper patch” that also works with session management and such, but I don’t really care, I wanted this patch to get back to work. So, in order to jive with my Ubuntu system, I created some debs with the patched version of metacity.

more vim

nonsense, but useful nonsense:

if you have tags working, cd into the directory with the tags and hit something like:

vim -t env_alloc

vim will automatically open to the file with that symbol. Nice.

Other nonsense:

:ab #d #define

vim abbreviations, make it so whenever you type #d it will be replaced by #define

you can actually execute a proper shell from vim, just use the :shell command.

finally, there is a “confirm” option for the substitute command, so:

%s/foo/bar/gc will globally replace foo with bar and confirm each replacement.

Transparency

I read this on a Gentoo forum today about Alsa’s DMIX plugin:

quote:

I mean, why can’t they make a _transparent_ software mixer? Why must every software be “updated” and “configured” to support the software mixing thing? Why on Earth couldn’t they make a plugin that needs no attention from the actual software, but just lets the software open and open the sound device? Why must mplayer, arts and others _know_ about the dmix plugin and _select_ it? That is not transparent.

The guy is right on. This is one of Linux’s main problems. Although we have as a hacker tenet to never reinvent the wheel, we also have a shitload of libraries and ways of doing things, and sometimes it leads to this awful situation: where you want to get software mixing of audio to work, but it will only work if you enable a mixing plugin in each application.

Library, woe is me; at least vim has lots of plugins

At the library for yet another full day, reading operating systems papers. This time, however, I kept getting really bored (can you blame me?), and I kept thinking about so many other things. They take so long to read, so much attention… I have so little to give. I don’t even have my laptop here, and I only spent the last 30 minutes on a computer.

This is my “break,” searching for vim plugins:

ZoomWin for maximizing a buffer temporarily, MiniBufferExplorer for switching buffers (Matt would probably like that one), Project Explorer for “favorite files”, ShowMarks for finding marks you set in a file, SearchComplete’s tab completion for searching (s/bla/bla2/g), cppcomplete for code completion (Matt says it rocks, like intellisense for C/C++/Java)…

I think I’ll actually install most of those (provided they work as advertised).

I think for C# programming all one needs to do is modify JavaBrowser and cppcomplete the recognize all of C#’s syntax, and we’d be all set C#-wise. Hell, maybe I’ll even do it next month.

Programming

While programming today, I came up with some nice vim bindings. If you use vim, and want tags-powered “intellisense-like” stuff, use this. Also thrown in there are hotkeys for :Tlist (indispensible vim plugin) and saving quickly (I save often, so I like to have a single key in either normal or insert mode).


" intellisense - yea well close enough
noremap <F2> mz<C-w>1]
noremap <F3> <C-w>c`za
noremap <F4> <C-w>11_

" for insert mode, goes back to unmatched brace
" so it's good for function prototype lookups
inoremap <F2> <ESC>mz 999[(b<C-w>1]

" tlist hotkeys
noremap <F8> :Tlist<CR>
noremap <F9> :TlistUpdate<CR>

" save hotkey for normal and insert modes
noremap <F10> :w<CR>
inoremap <F10> <ESC>:w<CR>a

Algorithms and vim

I spent about 5 hours today doing algorithm homework/studying. I like that class a little more now, even though some of it is a pain. Divide and conquer and dynamic programming actually are powerful concepts, once you get a feel for them.

Then I came back to my dorm, ate some food, and played with vim for literally 2 hours. I guess that was a waste of time, but I learned so much about this editor. Now I feel I can be twice as productive when I code. Especially with all the stuff I implemented for prototype previewing in my vimrc, and with all the support for ctags vim always had but I never used. Wow, this is one powerful programmer’s editor.

Matt has been telling me that I should use emacs with vi emulation (viper), and then I’ll get access to all that great emacs stuff. Maybe. I have nothing against it, except that emacs seems like an operating system unto itself. Eh, it doesn’t matter I guess, I just need to know one of the two well. They are both portable, and run on all major platforms.