Andy Wingo: recent developments in Guile

I watched a talk by Andy Wingo recently: recent developments in Guile. GNU Guile is a Scheme implementation, and a library providing an extension language for applications. Guile is actively developed, and promises some exciting stuff in upcoming releases, which is why I took these notes and publish them here–read on.

Andy starts by noting that Guile is different things to different people:

• A GNU language, with bindings for many components of the GNU system and under LGPL 3.
• A Scheme implementation, supporting R5RS and part of R6RS, plus other goodies: modules (not the R6RS ones), hygienic macros, the CLOS-like object system Goops with transparent integration with GLib’s gobject, Posix interface, and Unicode support.
• An extension language for applications, like the Gimp.
• A part of the GNU system (that we are making, even if we don’t know yet how it will look like).

Andy sees Guile’s perception among developers as its main challenge currently. It’s seen as being slow, although it’s generally faster than Python. But there are also opportunities for its perception: its multilingual vision and support–its next release will support ECMAScript besides Scheme, and Emacs Lisp is coming–, and the GNU brand.

Some technical notes

It uses the Boehm-Weiser garbage collector now, which is fast and reliable.

There are ten committers and monthly releases. This is after the project emerged from a long drought in 2000-2007.

Guile has a VM, and a native compiler is coming. Also: JavaScript support, ELisp coming!

It has really good Emacs integration now with Geiser.

There was also a small remark about licensing. Readline and Guile are not quite license-compatible, which makes using the REPL a pain. This sparked a longish discussion–kinda what you expect from a GNU developers meeting :-)

Spreading the Emacs nature

And now, the meat of the talk: spreading the Emacs nature, to emacsify the GNU system. Yes, that sounds like it!

The upcoming Guile 2.0 (or maybe 2.1?) will have full ELisp support, at the moment about equally fast than Emacs’ own, but it will be much faster. It will also have native compilation for even more performance.

Besides performance, it will have much more to offer:

• native threads,
• a clear FFI,
• modules,
• other languages, as described above,
• the Goops object system,
• lots of library bindings – Emacs-Gnome integration would easily be possible, for instance.

Andy’s plan is to replace Emacs’ Lisp engine with Guile. The rest stays unchanged, existing ELisp code will run as-is. Then no form of coercion should be necessary to get people to start writing their Emacs code in Guile languages. The timeframe is 18-30 months from now–looks like a developer release is not too far off!

Allison Randal: Exploring Dynamism

Here are some brief notes on Allison Randal‘s talk Exploring Dynamism, seen at InfoQ.

In this presentation from the JVM Language Summit 2009, Allison Randal discusses what it means for a language to be dynamic, the spectrum between static and dynamic languages, dynamic typing, dynamic dispatch, introspection, dynamic compilation, dynamic loading, and a summary of the main differences between static and dynamic.

Different ways of looking at things can yield very different, complementary insights, for instance regarding light as waves or particles.

Most languages are actually centering on the middle of the range from very static to very dynamic.

CS has been focusing on the static perspective. (But Smalltalk has been extremely dynamic all along.)

Dynamic vs. static typing is really only about when type constraints are checked. Own note: that’s not completely true – e.g. compiler optimization. Also, later she mentions computing dynamic dispatch at compile time which is only possible with a strong (explicit) type systems.

Dynamic dispatch

Introspection is not necessarily dynamic, just more common in such systems. Information comes from different sources: asking the VM/interpreter, compile-time annotations, execute-time annotations (e.g. annotated stacktraces). Meta object models are essentially introspection information for your object systems, provided by making the classes first-class objects.

Dynamic compilation: lots of options such as eval, JIT, file-based etc. She mentions the REPL without naming it, calling it “interactive compilation” and giving Python as example – odd.

Dynamic loading is surprisingly varied, ranging from linking to name binding to mixins, traits and roles (which often mean the same thing).

Her conclusion is that we’ll have both dynamic and static systems for a long time to come and that’s a good thing. In the end it’s about tighter control vs greater abstraction and productivity vs performance.

There’s an interesting-looking paper on the Further Reading slide: “Static typing where possible, dynamic typing when needed: the end of the cold war between programming languages” by E. Meijer and P. Drayton.

Hey, it’s Ada Lovelace Day!

Today I get to kill two birds with one stone. It is Ada Lovelace Day, “an international day of blogging to draw attention to the achievements of women in technology and science. Seeing that I’m just about to publish notes on a talk by Allison, why not write a little about her. And there sure is a lot to write.

I became aware of Allison’s work when I got interested in the Perls, both 5 and 6. When I start something new, I like to dig deeply into the web community around it; it tells you something about the culture surrounding a product. If you do that for Perl, it’s impossible to miss Allison.

The blurb on her website says

Her first geek career was as a research linguist in eastern Africa. But eventually her love of coding seduced her away from natural languages to artificial ones. A C and dynamic language (Perl/Python/Ruby/etc) programmer by trade, Allison is the architect of Parrot, chairman of the Parrot Foundation, on the board of directors of The Perl Foundation, and founder and president of Onyx Neon Press. She also works for O’Reilly Media, planning the program for their Open Source Convention (OSCON).”

Naturally, for Perl people writing this up means repeating the obvious. But given the unfortunate perception of Perl these days, it’s worth showing that cool things are still happening in that community. Like Perl 6 and Parrot. A virtual machine that can run 30+ languages? Check.

Allison is one of the lead developers as well as a manager for both Perl 6 and Parrot. She also wrote the current version of the Artistic License that Perl uses. You can easily find lots of talks she’s been giving over the years at many conferences. So for Ada Lovelace day, thank you Allison for all your hard work for Perl!

CouchDB and your life

I just watched a moving talk, Damien Katz‘s CouchDB and Me. It’s about Erlang and financial security, family and distributed databases, being a good programmer and being unemployed, dreams and bureaucrats at IBM.

At the Rubyfringe conference, Katz gave a personal account about how CouchDB came to be. Programming and some technical aspects naturally play a role, but he mainly talks about the personal decisions he had to make. Giving up your steady income and social position to write cool open source software – why would you do that? He did it and made it from feeling like an unemployed loser to being paid to work on his project, on his own terms, by IBM. He comes across as being really open about his experiences and his decisions, and I certainly took away a couple interesting insights. Find out what interests you and just start doing it, learning what you need. It’s ok to be driven by the idea of having an interesting story to tell; after all, the story of your life will be what you did and experienced. These are just two out of many things that stuck.

I came across this talk reading a discussion on HN. Like Katz’s talk, it’s kinda about programming, but really about life. Life as a programmer, maybe; but maybe about everyone. It makes me happy to see these discussions. I’m into programming not because I want to live in a cold world of machines, but because computers challenge your mind, because you can create something with them, even on your own, and maybe even make a living out of it. It’s about you in the end, not about the machine.