Archive for the ‘Elsewhere’ Category

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!


Intro to Perl 6 by Damian Conway


These are some lightly edited notes from a one-day intro to Perl 6 course given by Damian Conway. I had the pleasure of attending this session in summer 2009 at EPFL Lausanne, organized by my employer, the Swiss Institute of Bioinformatics.

If these short notes make you curious about Perl 6, see its website, and don’t miss the Perl 6 Advent Calendar, that shows off a lot of cool features – with code examples, in contrast to my notes.

First a nugget of wisdom that Damian Conway shared in the evening at the local Perl/Linux user group: Geeks are people who manipulate reality via language. In that, they are like the wizards in stories. Nice!

The big changes

  • Everything’s an object. That’s one of the biggest changes from Perl 5, however it’s very declarative and easy to use, and still hidden from view until you need it.Perl 6 is statically typed! This comes as a surprise, but its consequences are not drastic (if the programmer doesn’t want to) because of the Any type. It’s like Object in Java, but it’s implicit.

    If you want/need to be explicit: my Str $value.

    The type system has restrictions, a very cool feature: my $short_string of Str where {.chars < 10}.

    Each type is also a method that casts, as in print Str($obj).

  • The punctuation has been changed around in a “Huffmanization of punctuation”. They looked at a lot of CPAN code and made the most often used punctuation the shortest and easiest. And indeed most of the punctuation characters have a new meaning, so expect some re-learning if you’re a Perl 5 programmer.
  • Conway estimates that a Perl 6 program should be 20 to 40% shorter than the equivalent Perl 5 program.
  • It has blocks, written as {}, and they are first class. {} means “block” everywhere, even in strings.
  • Ah, sigils. Perl 6 still has them, but different from Perl 5: they never change for a given variable. For instance, an element of array @foo is now accessed as @foo[0]. Don’t we lose information here in comparison to $foo[0], namely that the foo contains scalar values? Conway
    says that this is true in comparison to Perl 4, but the references in Perl 5 already destroyed this.

    There is also the new sigil & for subs, but it’s not required for calling. Passing a sub looks like foo(&bar).

  • One of the most innovative parts of Perl 6 are Junctions. They are, if I understood correctly, Conway’s invention and are conceptually inspired by quantum physics. The analogy is that something can be in multiple states until it is observed. Transferred to a programming language, that gives us data-centric parallelism. The all, any, and none operators for lists execute the tests in parallel for each list element (with the actual number of threads depending on the hardware). If the list is of blocks, these are also executed in parallel. This gives a concise, readable, and safe to use parallelization facility.I have this hastily scribbled note saying that if a sub gets one of these lists or list expressions, |list| copies of it are executed in parallel – have to check what I meant with this exactly.
  • Perl 6 has extensive introspection:
    • .WHAT # type object
    • .WHERE
    • .WHICH
    • .HOW
    • .WHENCE # auto-vivifier
    • .WHY # comment

    For instance, $foo.WHAT.methods.

  • The language has built-in support for grammars and rules, essentially giving you a parser and lexer built into the language, using the normal (powerful) regular expressions.grammar G {
    rule R {} # whitespace significant
    token T {} # whitespace ignored

    The compiler is being written in this! So you can manipulate Perl 6 code easily as the parse tree is built in.

  • Perl 6 is defined in operational semantics via its comprehensive unit test suite. A compiler is a Perl 6 compiler when it passes all tests. There are currently about 20,000 of them; should be around 100,000!

I have a lot more notes about smaller features and nice syntactical sugar, that I cut out here not to bore the reader. Overall, I’m pretty excited about Perl 6 now, even though it’s not finished yet. It just has so many things that look so handy!

Interestingly, it’s kind of the antithesis to Lisp in that regard. It comes with a ton of syntactic constructs that do specific things, while Lisp is minimal and malleable so you can construct your own language. Both approaches have their merits, and both ways of developing software depend on how well they are executed. I think the Perl 6 designers have succeeded in making the standard language very well suited to writing elegant and succinct programs.

Elsewhere: Java generics


This one is basically a write-up of a collection of links about Java generics. Yes, I know, it doesn’t get any more boring. Every Java developer knows this by now, and the cool kids have moved to Scala and Clojure. (I’m working on it, too.) But at work I kept seeing that while the idea is simple, using generics in practice in a useful way is not easy for beginners. So I started tidying up a few bits and pieces I had written for colleagues and had that in my drafts for over a year now, and as I think it’s at least a collection of the best references about generics, here it is.

Let me get it out of the way first: every Java developer should know the Generics in the Java programming language tutorial by Gilad Bracha. Definitely study this first, and that might be enough for most people.

If you’re like me and need another round of explanations and examples to fully get the corner cases, Brian Goetz’s two articles on developerworks are great.

The second article addresses the question

Because the language supports both upper- and lower-bounded wildcards, how do we know which one to use, and when?

Goetz answers

There’s a simple rule, called the get-put principle, which tells us which kind of wildcard to use. The get-put principle, as stated in Naftalin and Wadler’s fine book on generics, Java Generics and Collections (see Resources), says: “Use an extends wildcard when you only get values out of a structure, use a super wildcard when you only put values into a structure, and don’t use a wildcard when you do both.”

Read the article if that concerns you at all, it’s very useful. I particularly like his clear explanation and example for the less often used lower-bounded wildcard:
public static <T extends Comparable<? super T>> void sort(List<T>list) { ... }

Goetz explains the idea behind the wildcard in the example like this:

[…] rather than restricting the domain of sort() to lists whose elements are comparable to themselves, we can go further — we can sort lists of elements that know how to compare themselves to their supertypes, too.

Alternatively we could say the Comparator must be able to compare at least T – if it can compare more, i.e., more generic types, we’ll take that as an added bonus.

Finally, let’s be balanced and mention the big shortcoming of Java generics: the type erasure, i.e., that the generic types are erased by the compiler and are not available at runtime. So, if you have a List and cast it to an untyped List, you can then insert any old Object into it. Mike Stone explains this in detail.

Java is pass-by-value


Does the Java parameter passing follow pass-by-value or pass-by-reference semantics? For primitives, it must obviously be by value, since we don’t have any references. For objects, you can find a large number of discussions on the net, some quite heated. Today it came up once again on Hacker News, as a link to Scott Stanchfield’s Java is Pass-by-Value, Dammit!.

The answer is absolutely clear, as Scott correctly points out. Java passes the object references by value. This is not the same thing as passing the references directly, and it’s not the same thing as passing the objects as data, i.e., as deep copies. The code sample below shows why the distinction is important.

I only write this to make one more small contribution to the enlightenment of Java programmers, and to highlight a piece of code from the comments of the HN discussion because it’s probably the simplest way of clearly demonstrating the truth of Scott’s article.

public class Test
    public static void main(String[] args)
        Object x = null;
        makeString (x);
        System.out.println (x);

    static void makeString (Object y)
        y = "This is a string";

If you execute this, you see that the reference to x cannot have been passed to makeObject.

SICP in Emacs


Most people reading this will know that Structure and Interpretation of Computer Programs (SICP) by Abelson and Sussman is one of the most well known and recommended books when it comes to core Computer Science, algorithms, and functional programming. Suffice it to say, if you want to explore these areas and enhance your programming on a level beyond knowing the latest framework, check out this book. It’s freely available online, as well as recordings of lectures the authors gave.

Now, in case that’s not nerdy enough for you, I found a version in texinfo yesterday. Complete with all graphics converted to ASCII art. Yes, kinda scary, but it rocks: have your Emacs display an info buffer with the book and a Scheme or CL REPL to play with the book’s code and work on the exercises. Just move around the book and evaluate the code snippets there. Neat!

I guess that means I have to resume my project of working through the exercises. I’m not even sure where my first couple solutions are…