samskivert reviews

Feeding Frenzy: Selectively Materializing Users’ Event Feeds - Silberstein, et al.

2012-02-20T00:00:00-08:00

This is the sort of research that a good systems engineer would love to do, but almost never has time, due to the ever-present need to ship. When some time can be scraped together to do it, it’s rarely as thorough and even more rarely as well documented. The results are embarassingly useful, given the propensity of every Web 2.0 startup on the block to have posting, following and feeds in some form or other. Score one for applied research.

Source: PDF ACM

An Experiment About Static and Dynamic Type Systems – Hanenberg

2011-08-12T00:00:00-07:00

Hanenberg describes an experiment where a largish group of students (49) were split in twain and given a moderately sized programming task (write a scanner and parser for Mini Java). The task was to be implemented in a minimalist, Smalltalk-like programming language with a basic IDE. One group’s language was dynamically typed and the other’s was statically typed. The dynamically typed version got the basic functionality of the scanner done significantly faster, and both groups performed about the same in terms of completeness/correctness (time being a limiting factor).

I don’t think major conclusions can be drawn from the results, even though they confirm some of my own biases that I’d like to believe were based in fact. They noted that the mean time from observed type failure (be it dynamic or static) to successfully executed test was not significantly different between the static and dynamic groups. The expectation was that the static type checker users would discover and fix such errors faster (that arguably being the prime directive of static type systems). However, these things are very difficult to measure. The times they reported from failure to fix were exceedingly large (nearly two hours in some cases) which makes me think that using this measurement as a proxy for efficiency in error correction is not especially valid. The environment also did not provide immediate visual feedback for type errors (like any modern IDE does), which needlessly squanders a level of efficiency that can be had with static types that is much harder to achieve with dynamic types.

Anyhow, it’s a useful data point and a good reminder that our preferences for static or dynamic type systems are far from empirically supported.

Source: ACM

Seven Languages in Seven Weeks

2011-06-11T00:00:00-07:00

Wow, it’s been a long time since I’ve been so disappointed by a book. The premise is excellent: an illustrative comparison of seven programming languages that make substantively different design choices. The execution is abysmal. The author clearly has zero prior experience with any of the languages except Ruby, and has no particular aptitude for understanding programming languages. His “insights” into the differences between the languages are about as sophisticated as “this language has a static type system; I don’t like static type systems.” Here’s another gem: “Functional languages are at a higher-level of abstraction than object-oriented languages.” As if that weren’t enough, he is frequently just plain wrong in the things he says about the languages. Avoid at all costs.

Typeclassopedia – Yorgey

2010-12-27T00:00:00-08:00

As the structure of the title suggests, this is a small encyclopedic exposition of the main Haskell type classes. It focuses on those type classes with category-theoretic foundations. It introduces them incrementally, each building on the type classes before it. Yorgey takes some pedagogical liberties and describes classes that don’t exist, but would if Haskell’s standard libraries were redesigned from scratch today (indeed, Scalaz follows his idealized presentation nearly exactly). The classes covered in detail are: Functor, Pointed, Applicative, Monad, Monoid, Foldable, Traversable, Category, Arrow, and Comonad.

This came at a very opportune time during my own slowly growing understanding of category theory and its applications to computer science. I had made ad hoc inroads on many of these concepts, and was ready for the Typeclassopedia’s organized presentation. My meager ability to read Haskell code was also helpful, because the definitions are presented as Haskell source. I even ended up writing some Haskell to verify my solutions to some of the numerous exercises left to the reader.

PDF

Modules as Objects in Newspeak – Bracha, et al.

2010-12-27T00:00:00-08:00

This paper describes Newspeak’s approach to modularity (along with a grab-bag of other things). Newspeak uses top-level classes as module definitions and declares all dependencies as “type” members of said classes. Newspeak is dynamically typed and names are late bound (hence the scare-quotes in the previous sentence). This late-binding is useful when taking this approach toward dependency resolution.

Using top-level classes as modules is nice in a number of ways. It reuses an existing linguistic concept, rather than adding another structure to the language (in Newspeak’s case, classes, though the same could be accomplished with top-level objects in a prototype-base language like Self or JavaScript). It allows one to abstract over modules (assuming one can abstract over classes). If one’s language allows for mutually recursive class definitions (which Newspeak does), then one gets mutually recursive module definitions for free.

I think Newspeak is a very interesting language, and I applaud the “extreme” opinions of its designer and the influence they have on its design. However, I have a couple of issues with modularity in Newspeak.

The first is that they are missing the party, as far as I’m concerned. Scala is another language that is taking this approach toward modularity, and Scala is in active use by hundreds (possibly thousands these days) of professional developers. Systems come in uncountably many shapes and sizes, and to really understand an approach to modularity, you need to try it on a lot of different systems. That’s not to say that Newspeak’s authors are wrong not to focus on adoption first, but they’re going to have a hard time evaluating their modularity ideas until the language is more widely used.

Furthermore, Scala tackles the interesting (in my opinion) challenge of providing a type system that checks that your module assembly is well-formed. Just as one wants to reuse a linguistic structure to support modularity, one also wants to reuse type-system mechanisms to check those structures. Scala accomplishes this with self types and (mixin composed) traits.

My second concern is that Newspeak takes the extreme position that every dependency must be explicitly enumerated and brought into the namespace. This extends to basic platform classes like, for example, List. In Newspeak one would write code like so:

class NewspeakExample usingLib: platform = (
|
List = platform collections List.
...
|
)(...)

The platform library is declared as a dependency, and the platform collections List class is brought into the local namespace as List. This amounts to the same level of syntactic drudgery as a Java import statement (and its addition can probably be automated to the same degree by an IDE, but readers of the code still have to read it).

Putting aside the potential benefits (and dangers) of Newspeak’s extreme approach to late binding (the name List is just a member of the NewspeakExample class and can be overridden by subclasses or changed at runtime, thereby changing the class instantiated at every place List is used inside NewspeakExample), they are missing the strong message being sent by the Python, Ruby, Perl, etc. communities that they want their batteries included. They want the standard set of data structures and utilities available without having to specifically request them.

Assuming that the vast majority of programs will use the standard libraries, and use them in the “standard” way. When would the ability to replace the standard libraries with specialized versions actually be useful? (Let’s also ignore the massive potential for confusion if you redefined the standard libraries to behave differently.) Perhaps when profiling or debugging one could replace the standard libraries with instrumented versions. Explicit enumeration of the standard libraries as a dependency seems like a steep price to pay for this marginal use case. Such a use case would probably be better accomplished via some extra-linguistic mechanism.

This explicit approach to modularity is great for structuring the major components of a system. There the benefits of explicit dependency declaration outweigh the costs. You frequently want to test such components in isolation, so supplying mock dependencies is useful. You may in some cases want to supply meaningfully different “production” implementations of some dependencies. It is also beneficial for readers of the code to see the dependencies made explicit because they may not be intimately familiar with the system’s structure.

However, this approach is cumbersome when used to provide access to the vast vocabulary of standard libraries and de-facto standard third-party utility libraries. In those cases, you are not replacing the implementations for testing. You are generally not providing alternative implementations. These libraries are widely understood by any reader of the code, and to explicitly enumerate every use is a distraction rather than a helpful guide. To make an analogy with natural language, one often clarifies a use of jargon (like say “applicative functor”) with a definition or reference to some external definition. That is far more likely to help a reader than distract them. But if one has to explicitly prepare the reader for terms like “the” (or “define,” or “terms”), communication is almost certainly going to be impaired.

PDF

Applicative Programming with Effects – McBride and Paterson

2010-11-28T00:00:00-08:00

Introduces applicative functors (in Haskellese, and assuming familiarity with functors and monads), a mechanism for threading a computation through an environment—crucially, without allowing the results of one computation to influence the choice of subsequent computations (otherwise you’d have a monad). The insight for applicative functors seems to have come from observing a repeated desire to thread computations through traversable data structures.

Having a reasonably firm handle on monads, applicative functors seemed like the next bit of functional programming jargon to get my head around. I found the paper to be mostly easy going (though I found myself stumped when trying the exercise hinted at in “For example, the functor (→) env cannot in general be Traversable. To see why, take env = Integer and try to distribute the Maybe functor!”). They give a nice example of the crux of the difference between applicative functors and monads, however the comparison between arrows and applicative functors is a bit more opaque. Arrows are probably up next in the functional programming pantheon, so perhaps enlightenment is just around the corner.

I even mostly grokked their closing discussion on the category theoretical manifestation of applicative functors as strong lax monoidal functors. (How is that not an oxymoron?) I owe this understanding mostly to the foundation I acquired through Gilbert’s numerous patient explanations of abstract algebraic concepts.

PDF ACM

Lightweight Modular Staging – Rompf and Odersky

2010-11-24T00:00:00-08:00

They describe a type-driven technique for staging computations, which seems to mean generating optimized, low-level code based on higher-level code, written directly in a host language. You might be thinking that writing code in a high-level language and generating optimized, low-level code sounds a lot like compiling. I would have to agree. The value here would seem to be that you reuse much of the machinery of the host language (in this case Scala) and that you can generate differing kinds of output: OpenCL which is compiled and sent to a GPU, more Scala code which is compiled and loaded back into the VM, GraphViz graphs to visualize your code.

I appreciate the light-weight-ness of this approach, and it’s yet another clever application of Scala’s type system and implicits. However, I don’t do much that is so performance critical that I spend time dreaming about ways to generate highly optimized machine code from high-level descriptions of algorithms.

PDF

Deprecating the Observer Pattern – Maier, et al.

2010-10-26T00:00:00-07:00

This paper builds on the Scala delimited continuations mechanism and describes a set of reactive programming libraries. They describe some basic FRP primitives (for which they have helpfully selected new names, much like everyone else who treads this path): event sources and signals, along with a variety of useful combinators (e.g. merge, next, delay, etc.).

Per usual, everything is fitted nicely together through a combination of operator-like methods, implicit conversions and clever construction of the type hierarchy. In this case, the additional special sauce of delimited continuations is needed to allow data flow operations to capture and postpone the remainder of their computation when appropriate. Fortunately, this is almost entirely hidden from the user. An example of where it pokes its head up is in the inability to use an if statement without a corresponding else in CPS-transformed code, but what good functional programmer would do such a thing?

This is all packaged up into a framework called Scala.React which has remained tantalizingly unavailable to people not named Ingo Maier. I’m fairly convinced that this is the road forward for civilized UI programming, and likely for a variety of other domains. Thus, I look forward to getting my hands on the code and discovering that the glorious future is not as bright and shiny as it seemed in the brochure.

PDF

Type Classes as Objects and Implicits – Oliveira, et al.

2010-10-03T00:00:00-07:00

I earlier wondered, in regard to the use of implicits to achieve type-class-like functionality in Scala, “Given the global nature of Haskell’s type classes, a limitation remedied by … Scala’s implicits, I wonder what’s so poor about Scala’s approach.” This paper answered that question and more, with its long laundry list of things you can do with implicits, and how that compares with type classes. I love a good explanation by example(s).

PDF

Implementing First-Class Polymorphic Delimited Continuations by a Type-Directed Selective CPS-Transform – Rompf, et al.

2010-10-03T00:00:00-07:00

I think it’s been six months since I read this paper, but I kept thinking that I had already written a note about it in my blog. I must have shifted that computation into a delimited continuation and then forgotten to call the continuation, so it never got executed. Ah, computer science humor.

Continuations (delimited or otherwise) can quickly make code incomprehensible, as the examples in this paper so nicely demonstrate. However, used in a disciplined manner, they can do some very nice things, including distributed computing, improved UI APIs and reactive programming.

PDF ACM

F-Bounded Polymorphism for Object-Oriented Programming – Canning, et al.

2010-10-03T00:00:00-07:00

I don’t even remember how this paper showed up on my reading list, probably I saw a comment about f-bounds in the javac source code and wondered what it meant. In any case, it was very refreshing to read about a technique that I make use of nearly every day.

PDF ACM

Modular Type Classes – Dreyer, et al.

2010-08-21T00:00:00-07:00

I backed into type classes via Scala’s poor man implementation thereof. Thus it is illuminating to see them formulated as ML modules, even though I’m not particularly familiar with ML modules either.

Given the global nature of Haskell’s type classes, a limitation remedied by both this work and Scala’s implicits, I wonder what’s so poor about Scala’s approach. Are there things that are expressible with “real” type classes that are not expressible with implicits? Or maybe it’s just a matter of preserving the holy grail of perfect type inference.

Source: ACM PDF

Compiling Structural Types on the JVM – Dubochet and Odersky

2010-08-21T00:00:00-07:00

Aside from describing how Scala structural types are implemented (via reflection), this paper shows that such an approach isn’t wildly slower than an approach that generates shim classes on the fly. Certainly it’s not ideal for the programmer to have to remember that some kinds of method calls are three times slower than others, but the shim class approach is not without drawbacks either. In addition to the problem of the type of this, it has performance related problems as well, as discussed by Charles Nutter of JRuby fame.

Two interesting developments may change the landscape here: interface injection, which would solve the problem outright, but has low odds of ever seeing the light of day in a shipping JVM, and invokedynamic which could make a reflection-like approach more performant, and should ship with Java 7 (assuming Java 7 ever ships).

Source: ACM PDF

Principles of Traditional Animation Applied to 3D Computer Animation – Lasseter

2010-07-06T00:00:00-07:00

A distillation of various traditional animation knowledge that Lasseter apparently picked up while working with the grand old men of Disney. Well outside my research area but still fascinating.

Source: PDF ACM

Extensible Pattern Matching Via a Lightweight Language Extension – Syme, et al.

2010-07-06T00:00:00-07:00

Describes the design of the pattern matching capabilities in F#, which they dub active patterns. The ability to create patterns after-the-fact for classes you may not even control seems quite useful. Even without the ability to “extract” internal representation from an instance (a much misunderstood feature of Scala’s pattern matching), one can still get a lot of mileage out of clean syntax for matching and variable binding. It’s a whole lot better than a pile of if statements and local variable declarations. As a bonus, with total patterns, the compiler can check that you covered all the cases.

Source: PDF ACM

Bricolage Programming in the Creative Arts – McLean and Wiggins

2010-07-06T00:00:00-07:00

This is a surprisingly postmodern paper (for the field of computer science anyhow), and it is accordingly pretty content free. However, they include data from research on metaphors used by programmers to talk about programs, which is interesting. A few examples: “components own and trade data,” “execution is a journey in some landscape,” and “data is a substance that flows and is stored.”

Source: PDF

Breadcrumbs: Efficient Context Sensitivity for Dynamic Bug Detection Analysis – Bond, et al.

2010-06-03T00:00:00-07:00

Describes a nice technique for tracking enough information at each call site to reconstruct the stack at said call site with high probability after the fact. They implemented the technique in the Jikes RVM and got reasonably good reconstruction with overheads in the range of 10-20%. They augmented a race detector and null pointer origin tracker, and I can imagine various other clients for which it would be great to report a full call stack rather than just a single program point.

Source: PDF CiteSeerX

Using Information Fragments to Answer the Questions Developers Ask – Fritz and Murphy

2010-05-19T00:00:00-07:00

They created an interface for combining data from four sources: team members, change sets, source code, and bugs/issues. They built on top of Jazz, which makes these things available in a structured form with consistent keys. Their UI puts together some natural joins on the data and then visualizes it in a hierarchy that corresponds to the order of the items chosen by the developer. So you can see changes by source file, or changes by person, or source files modified by person, etc.

The tool definitely seems useful, but unless you’re using Jazz, this data is scattered around in a bunch of unrelated sources. The problem that I see with a tool like this is that the effort required to get this data into a format that a tool could consume outweighs the perceived benefit to be had from the tool. A more interesting project, IMO, would be a tool that could be pointed at arbitrary bug tracking databases and version control histories and tried to automagically extract and correlate structured data. Then one could pretty easily build this visualizer and any number of other interesting tools on top of it, and many more development teams could actually use it.

Update: Reid points out that said automagic extractor has already been investigated. If I get a chance to give it a whirl, I’ll report on my findings.

Source: PDF

The Office of the Future: A Unified Approach to Image-Based Modeling and Spatially Immersive Displays – Raskar, et al.

2010-05-19T00:00:00-07:00

An early kitchen sink paper on how to use projectors and cameras to do a bunch of stuff: augment physical spaces with projected graphics, locate and track objects and people, seamlessly combine overlapping projected images, capture depth information, imperceptibly project structured light onto surfaces, and other things I’m probably forgetting. The technology is all neat, but I’m not that excited about the things they proposed doing with it. Unlike most HCI researchers, I don’t really like projected displays.

Source: PDF ACM

Hacking the Nintendo Wii Remote – Lee

2010-05-19T00:00:00-07:00

A summary of bunch of cool interaction techniques you can implement with the Wii remote. Head tracking on the cheap!

Source: PDF ACM