I have been doing quite a bit of elisp hacking lately, for some bigger project. Multiple buffers must be coordinated, as well as some external process. Although my elisp is slowly becoming more idiomatic, I find that it offers little to help with modularity, information hiding etc., so it all comes down to self-discipline.

Having an interactive environment is nice, but can also be rather confusing, i.e. how to ensure that the function that's being called is the one I want, not some old version that still lives on in the netherworld.

Some of this is clearly the impedance of a brain wired for C; but still, some of the glue for modularity that e.g. Guile delivers would be very welcome.

Somehow, I found this three-year-old Coding Horror article about the FizBuzz programming test; it's a very simple programming problem, yet it turned out that a majority of the people applying for a programming job were not able to solve it.

Also interesting is that many people in the comments-section still got subtly wrong solutions – by not carefully reading the requirements.

I suppose many of the job-applicants who could not solve FizBuzz still got jobs in that field, somewhere. What does that mean? Would they just be very slow, that is, could they still solve it after many iterations, debugging and what not? Or is there a sufficiently large segment of programming jobs that put such limited emphasis on algorithms that they can get away with it?

Yesterday, I found that, unfortunately, advogato.org does not work anymore – it's last version was from 2004 or so, and it expects to find browser cookies in some text file. However, times have changed, and these days, those cookies are stored in an SQLite-database.

Anyway, it's actually not too hard to publish by hand. I am using org-mode in emacs, which has some light-weight markup syntax, as I discussed here. I can simply type things there, and when I am done, I run org-export-as-html. That will also put the result in my 'kill-ring' (i.e., paste buffer), so I can paste in the advogato web form, et voilà!.

LaTeX (and to a lesser extend, HTML) is sometimes promoted over WYSIWYG word processors because it allegedly focuses on the contents and allows you to describe semantics, not looks. That is only partly true, as anyone who wants to insert e.g., a table in a document can attest to: in MS-Word or Writer, it's much easier to concentrate on table contents than it is in LaTeX. Programs like LyX alleviate this to some extent, but for me it's a bit too much on the WYSIWYG side.

So, I used to endure the pain of raw LaTeX (and HTML) editing, because it still we was the least painful way to get the what I want. For LaTeX that is, book-quality rendering, with all the magic of maths, indices, numbering, source code blobs and so on. For HTML, it would be standards-compliant 'clean' blobs that I can still understand, and can paste into e.g., a blog.

However, with org-mode the pain is mostly gone! I can export to both HTML and LaTeX and it really allows me to focus only on the contents of what I want to write (as said, org-mode-markup is really lightweight); still it allows for a lot of massaging of the output if needed. I can imagine that this 'output massage' would be quite hard if I hadn't already spent quite a bit of time using 'raw' HTML and LaTeX - anyway, for me it works very well. Coming back to adding tables in documents: this is easy in org-mode, and I can even use the tables as little spreadsheets, with all the power of GNU Calc formulae.

As a bonus, I can easily generate presentations from org-mode, by exporting it through the LaTeX 'beamer' class. This works beautifully well for a lot of the presentation I do for colleagues at work: getting PDFs with the beauty of LaTeX, but without the headaches.

I joined Advogato more than 10 years ago(!), and my last entries here are from ages ago. I am planning to do some more posting here; main reason for that is that I just installed the advogato.el for emacs, which hopefully allows for painless publishing from within emacs, something which unfortunately cannot be said for the interaction with e.g. Blogger.

In the last ten years, I've written a lot of software, both for money and for fun, using C++, Perl, Python, Ruby, Emacs-Lisp, and good-old C. For some reason, most of the code has involved C and Emacs, I am somehow drawn to projects where that particular knowledge is useful.

All those things that were once a bit mysterious, such as autotools, parsers, Lisp and all those obscure tools like objdump, strace, procmail,… have entered my comfort zone. Editor-wise, I am still using GNU/Emacs, as I've been done since the mid-90s, with maybe a month or so somewhere in 2000 where I went cold-turkey to vim. That did not last; I do like vim, but I am much more productive with emacs, and it's taking over more and more of my computing universe.

I went as far as starting a blog with emacs tips at the end of 2008: Emacs-Fu, where I try to share useful thing about the One True Editor. There are many little gems, but some of them are well hidden, such that I still often find some nifty trick that has been in emacs for twenty years, and I never discovered. My emacs-lisp is still a bit embryonic; good enough to glue things together, but not really fluent. I am brushing up my skills in this area though, and re-reading SICP.

I am also still a happy Gnome-user. I have learned a lot from reading the code from so many talented hackers. I think Gnome 3 offers some great opportunities, and I just got my first patch accepted into gnome-shell (it fixes the 12h/24h clock bug). But it must be said that with my workflow revolving around emacs, the desktop environment is less important.

spitfall

Implementing GTK+-widgets and other GObjects in C requires quite a bit of boilerplate code - that's hardly news. One obvious way to deal with that is to use a different programming language. If you're into C++, I can recommend the excellent GtkMM C++-bindings for GTK+. Programming GtkMM feels very natural and follows the C++-idioms; it's easy to integrate with std:: and friends. Also, it's LGPL and pure C++.

Another option is Vala. If you haven't heard about it, Vala is a programming language in its own right, with similarities to C#, but specifically designed for use with GObject. One very interesting thing about Vala is that it compiles to plain C-with-GObjects (as an intermediate step). Thus, you write in Vala, with no 'libvala' needed, with code which is just as fast as handwritten C. Vala also supports many other libraries, which can make them easier to use, compared with plain C. Using Vala, writing GObject/GTK+-based applications becomes a lot easier. Vala Overview.

Finally, my truly low-tech solution is spuug. Spuug is a little GObject code-generator that I wrote in 2006 to learn some Ruby, and to save myself some time. And boy, has it saved me some time! Now, finally a new version. The credit for this go mostly to Viktor Nagy (many thanks!), who submitted some patches.

spuug usage is quite easy; for example:

    $ spuug --class=FunkyFooBar --namespace=Funky --parent=GtkWidget

Of course, spuug works well for Maemo-code, and I know of a number of programs that are using it.

There are of course some disadvantages to using code-generators. But the advantage of spuug is that it doesn't require you to learn any new language. Also, after using it, you're not depending on spuug - the output is perfectly readable C code.

Syndicated 2008-12-24 15:12:00 (Updated 2008-12-24 16:14:31) from djcb