2011/01/10

OOPSLA day 2 (belated)

Filed under: Conference Report — Tags: — nick @ 09:41

NOTE: I’ve come back to my notes about the last two days of OOPSLA; it’s two weeks since the conference ended, and my memory is already kind of hazy, so the quality of these last two posts might be less than ideal… and another week and a half has passed before I finished even the first of the last two posts, still, better late than never, eh?

Creativity: Sensitivity and Surprise – Benjamin Pearce

Benjamin gave the oddest invited talk I’ve ever seen. He talked about various aspects of creativity over a large set of photographs, including some of his own. The photos were beautiful and made a great show. Not entirely sure what it has to do with programming, languages, systems, or applications, except at the most abstract level. Still an interesting talk, and it seemed to go down very well with the audience too.

Specifying and Implementing Refactorings – Max Schaffer

Automatic refactoring is popular, and correct in the common cases, but specifications are imperfect. The current `best practice’ (e.g., in Eclipse) is to use a bunch of preconditions, but this is not ideal for automatic tools because it is difficult to identify all necessary preconditions; so refactoring sometimes fails, even if all the preconditions are satisfied.

The authors previously suggested specifications based on dependencies and breaking refactorings down into smaller pieces. In this work, they show that this idea actually works for proper refactorings. The dependencies are static and semantic, e.g., constraints on synchronisation and name binding. The authors specified and implemented 17 refactorings.


What can the GC compute efficiently? – Christoph Reichenbach

Christoph presented a system which checks assertions when the garbage collector is run. These assertions are about objects and relations between objects in the heap. This is a pretty efficient way to check heap assertions because the heap must be traversed anyway to do GC. There is a single-touch property – i.e., each assertion can only touch each object once – so checking the assertions is very fast. Their assertion language can describe reachability, dominance, and disjointness, and assertions can be combined with the usual logical operators. Interestingly, garbage collection must be re-ordered to check for reachability and dominance.

Type Classes as Objects and Implicits – Bruno Oliveira

This work `encodes’ Haskell type classes in Scala using generics and implicits (the latter being a Scala feature that enables the programmer to omit some parameters). My understanding of the work was that type classes can be done using only generics, but implicits are required to make the `encoding’ usable by a programmer. There is a whole lot of other complex-Scala-type-system stuff – I have notes about type members and dependent method types, but I can’t remember why…

The interesting thing is that you end up with a really, really powerful language feature: as well as type classes, you can encode session types, which I find incredible (although according to the paper, you can do this with Haskell type classes).

Supporting Dynamic, Third-Party Code Customizations in JavaScript using Aspects

The authors are motivated by the popularity of JavaScript, both on the web and to customise browsers. Such scripts typically rely heavily on code injection, that is inserting new code into existing scripts. This is a pretty ugly process all round – it’s as non-modular as you can imagine and implemented in totally unchecked and unsafe ways (mostly monkey patching). The authors propose doing it with aspect-style weaving instead, but claim it’s not really aspects, apparently. Weaving is done by the JIT. Their empirical results show that their approach is sufficiently expressive for most use.

2010/11/01

Long Live Metadata!

Filed under: Editorial — Tags: , , — Oscar Nierstrasz @ 17:37

This issue marks the end of the transition from the “old JOT” to the “new JOT” in a number of ways. The papers in this issue are the last of those previously accepted by the founding Editor-in-Chief, Richard Wiener. Starting in January 2011, JOT will move to  a format in which articles will be published as soon as possible after acceptance.  Although this change in policy will bring the risk that new articles will appear less regularly over time, we believe that both authors and the JOT readership will benefit from the more timely publication of articles. The new model will only work if JOT receives a steady supply of strong submissions, so the Editorial Board encourages you to submit mature research contributions for publication to JOT.

This issue also boasts several blog posts on OOPSLA/SPLASH 2010 and co-located events.  As with technical papers, future blog posts will appear as they are posted, and be added incrementally to the currently open JOT issue.  Please note that we are especially interested in volunteers who can provide solid blog posts covering events related to object technology.  Contact the Editor-in-Chief if you are willing to volunteer.

Another notable milestone is that all past JOT publications have now been assigned a permanent Digital Object Identifier.  DOIs are preferred over URLs as a more reliable way to refer to online publications.

Technically the most difficult part of assigning DOIs was to extract the metadata of all the JOT issues since 2002.  This was accomplished with the help of a Ruby script that crawled the JOT web site, attempting to recognize metadata in the HTML.  Since the format of JOT changed slightly over the years, and varied at times for special issues, it turned out that much of the script was dedicated to special cases.

Once the metadata was extracted, it could be used to generate a new web site. The current web site is entirely generated on the fly by PHP pages that are driven by the JOT metadata.  The Apache web server configuration hides most of the PHP behind restful URLs that make the dynamic web pages appear to be static (and which incidentally allows a static snapshot of the JOT web site to be easily mirrored).

Having metadata for all JOT issues available made it easy to provide new services.  BibTeX references, DBLP metadata, DOI submissions, JOT newsletters and search functionality were all relatively straightforward to provide.  The assignment of DOIs to all JOT articles has been made possible by the financial sponsorship of AITO.

The analysis of the old JOT web site revealed numerous errors and broken links.  These have been repaired and are less likely to occur with the new web site being generated from metadata.  Both Design-by-Contract and unit tests are used extensively to reduce the likelihood of errors being introduced as the metadata is updated with each new issue.

Since it was unclear at the beginning what metadata would be needed, extensibility was a key requirement.  Instead of using a database to store the JOT metadata, or to define (say) an XML schema to encode it, a simple text format was used based on the popular Markdown style.  This approach has the advantage of being both trivial to parse and trivial to extend.  The most important lesson from this experience is that simple approaches can help you to move quickly.

2010/10/27

OOPSLA day 1

Filed under: Conference Report — Tags: — nick @ 09:50

OOPSLA proper starts today. William Cook gave a mercifully short introduction and then we were straight into the first ever SPLASH invited talk, on evolving software by Stephanie Forrest. After the break, I attended the Onward! research paper stream, then after lunch an OOPSLA session, and the panel in the last session.

Registration-Based Language Abstractions – Samuel Davis

Samuel presented a method for adding language constructs to a language. These constructs are outside of the language, but also outside of the source code, so each programmer can have their own personal version of a programming language and the tool will present code using the right constructs. It seems like a very sophisticated macro system to me, but with better tool support (I don’t mean this in a derogatory way, the system is obviously more powerful and useful than macros, I just mean it as a simile).

I attended, enjoyed and found interesting two talks – Pinocchio: Bringing Reflection to Life with First-class Interpreters presented by Toon Verwaest, and Lime: A Java-Compatible and Synthesizable Language for Heterogeneous Architectures presented by Joshua Auerbach. I’m afraid I can’t say much about either of them, but they were good talks and I’ll try to read both papers.

From OO to FPGA: Fitting Round Objects into Square Hardware? – Jens Palsberg

A talk on compiling high-level languages to FPGAs, the challenge is to compile a standard OO program to an FPGA. Currently code written in a small subset of C can be compiled to FPGAs, but hand-coded FPGA code is better (faster, less area, smaller energy consumption). The general technique presented is to compile from Virgil to C and then to FPGAs. Unfortunately, the C subset is so small (no pointers, etc.) that objects cannot be compiled in the usual way.

The authors used a mix of existing compilation techniques with some new ideas of their own. Essentially they compile objects to sparse integer arrays, but must then expend a lot of effort in compressing these tables.

They have experimental results which show slightly better performance for their tool chain than for the hand-tuned version (for the non-oo case). In the OO case, it is harder to compare (no-one else has done it), but by interpreting performance results from CPU execution, they reason that their tool gives good results here too.

An interesting challenge which emerged in the questions, is producing an intermediate language for compilation to FPGAs that preserves parallelisation, as opposed to C which ‘flattens’ away any parallel code into sequential code.

Panel – Manifesto: a New Educational Programming Language

For the last session of the day, I attended the panel session on a proposed new programming language, aimed at first year university students. The language is called Grace (http://gracelang.org), it is proposed to be a community effort, with a semi-open development process and this panel was an effort to get the community behind it. Grace will be a general purpose (as opposed to domain specific) language, designed for novices (so no fancy type system), and deigned for programming in the small (so no fancy module system). It will not be industrial strength, therefore it will not need to be backward compatible, and should have low overhead for small programs (no “public static void main”).

The proposers argued that the time is right: Java will be good for the next few years, but is getting big and a bit long in the tooth. Alex Buckley (Java “theologist”, also on the panel, but not associated with Grace) did not disagree, but did say that Java would have a lot of the features discussed in a few years time (which means it might not look so old but will be even bigger).

The proposers (James Noble, Andrew Black, and Kim Bruce) have ambitious goals: Grace should be multi-platform, multi-paradigm (it should support teaching with or without objects, with or without types, in a functional or procedural style), it should be useful for teaching first and second years how to program, and for data structures courses. With Smalltalk never far below the surface, it was declared that everything would be an object, although it was not stated what was meant by “everything”. The proposers proposed that Grace have a powerful extension/library system for adding in things like concurrency, basically because we don’t know the best way to do concurrency right now. This seems a big ask, one thing the concurrency community mostly agress on is that concurrency cannot be added on afterwards, it must be holistically baked in.

It sounds to me like a great idea – an academic, community based teaching language should be much better suited for purpose than a professional programming language. But, to be honest, the session did not have very much buzz. The panel itself was obviously excited about the project, the audience less so. There were no great questions from the floor, or any really exciting debate. The lengthiest discussion was about the relative merits of the PLT group’s book/language/curriculumn. On the other hand no one really disagreed that there was a gap in the market for such a language. I’m interested to find out if the proposers got encouraging words after the session. (Disclaimer: I skipped the last half hour to attend a research talk, so the session might have lit up then and I would have missed it.)

2010/10/25

Dynamic Languages Symposium (DLS)

Filed under: Conference Report — Tags: , — nick @ 16:46

Today (now yesterday) I will mainly be attending the DLS, with intermissions at PLATEAU.

Almost unbelievably, the wifi works really well. It’s been a while since I’ve been at a conference with really good wifi, but the Nugget seems to have cracked it, fingers crossed that it’ll last.

Invited talk – Smalltalk Virtual Machines to JavaScript Engines: Perspectives on Mainstreaming Dynamic Languages – Allen Wirfs-Brock

The theme of this talk is how to get dynamic languages into the mainstream. The talk started well with some interesting general points on implementing dynamic languages, and ended well with some observations on the current generations of Javascript interpreters, but most of the talk was a retrospective of Smalltalk.

An early point was that performance is important for dynamic language take up. As much as language designers and programming guides state that design (of the language or program) must come first, if a language’s runtime performance is not good enough for a given task, it will not be used. Another early point was that virtual machine implementors got blinded by the metaphor – a VM is not a machine, it is a language implementation, and must be coded like one.

Allen gave an impressive Smalltalk demo, running Smalltalk from 1984 on a machine of the day, which practically ran on steam. It was an interactive graphical demo and the performance was very impressive (in fact, the computer was pretty high powered for the time, but it was impressive nonetheless).

More of Allen’s observations: holistic design gives high performance, tweaks to an existing VM will not get you very far (therefore, he is not a fan of trying to extend the JVM to dynamic languages); optimising fast paths is fine, but don’t let the exceptional paths get too slow, it is probably these that makes the language special; methodologies are required to enable language adoption.

Most of the Smalltalk stuff was fairly typical, but the analysis of its death was more interesting: Smalltalk was going guns blazing in ’95, but was effectively dead by ’97. His analysis was that Smalltalk was a fad, never a mainstream language (which sounds right to me, not that it was bad language mind, but its influence in academic language research seems much higher than its influence in real life). One reason for this demise is that the ‘Smalltalk people’ expended way too much energy on GUI systems that nobody actually used, and not enough energy on real problems.

Another interesting analysis was on why Java succeeded, reasons given included: familiar syntax, conventional tools, the network effect, etc. It seems to me that people always try to find excuses for Java’s success (although those points are obviously true); maybe Java was actually a good language that fit the needs of the time better than other languages?

A slight tangent was that Java is essentially a manually dynamically typed language; that is, casts are manual dynamic typing.

We then got back into the good stuff. Javascript was assumed to be inherently slow, then V8 (Google) showed that Javascript could be fast. Fast Javascript is important for the web, which means computing in general nowadays. You only need to look at the competition between browsers to see that Javascript performance is important. This reminded me that I think that Javascript engines are possibly the coolest and most interesting language engineering happening at the moment, and sadly it is not happening in academia (Allen suggested we need a research browser, which would be nice, but seems unlikely to come about).

Some of Allen’s observations on Javascript VMs: most teams are still on their first or second tries (earlier in the talk, Allen stated that it takes three goes to get good at VMs) – things are going to get much better; performance is still low compared to Smalltalk in ’95(!); Sunspider is not a great benchmark and is holding back proper evaluation and development; Javascript is harder to make fast than Smalltalk (because it is more dynamic), new ideas are needed to get more speed; Allen wandered why all the Javascript VMs use so much memory; the Javascript engine needs to be part of an holistic browser design to get good performance; Javascript seems to be the mainstream; Javascript performance is at the beginning, not the end.

The talk ended by reminding us that ambient/ubiquitous computing is here, and suggested that dynamic languages were going to be part of that era. He didn’t explain why, however.

Meanwhile, at PLATEAU – GoHotDraw: Evaluating the Go Programming Language with Design Patterns – Frank Schmager

Frank Schmager presented work he has done with James Noble and I on evaluating the Go programming language using design patterns. This is a novel idea for evaluating programming languages, and hopefully a new tool in the language evaluation toolbox. Apparently he gave a very good talk, go Frank! (sorry for that pun)

PLATEAU invited talk – The Fitness Function for Programming Languages: A Matter of Taste? – Gilad Bracha

For the second session, I attended Gilad Bracha’s invited talk at PLATEAU. Gilad always gives interesting and entertaining talks, and this was no exception.

“There are two kinds of languages – those that everyone complains about and those that aren’t used”
— Bjorn Stroustrup

Gilad’s talk was about how to judge a language. He argued that there was more to a language’s success than popularity, that in fifty years time we will look back and certain languages will be admired, and others won’t. Furthermore, success is really mostly down to the network effect (or the sheep effect, as Gilad called it); and that the most successful languages follow the Swiss Army Knife approach (aka the kitchen sink approach aka the postmodern approach) to language design, which generally, it is agreed, is not elegant or ‘great’. So is it possible to define what makes a language great? Or is it just a matter of taste?

There were a couple of tangents on parser combinators and first-class pattern matching in Newspeak (Gilad’s language project).

Some criteria for greatness (or lack of it) were suggested: how much syntactic overhead is there in the language (such as unnecessary brackets, semicolons), does the language force attention on the irrelevant (e.g., on the low level in a non-systems language), how compositional is the language. Gilad asked if languages can be judged as theories (where programs are models of the theory), criteria here were consistency, comprehensiveness, and predictive value (which for languages means how hard is it to write a given program).

An interesting observation was that the most common actions in a language have no syntax (or actually no syntactic overhead), e.g., function application in functional languages, method call in Smalltalk.

Another observation on evaluating languages is that we often try to measure how hard a language is to learn. Gilad argued that ease of learning is not an indicator of greatness. He uses Newton’s calculus as an allegory – it is widely hated for being difficult to learn, but is truly a great contribution to science.

Finally, Gilad stated that good aesthetics makes good software, that strict criteria for evaluating a language are not ideal, and that quality is more important than market share.

There was a big debate in the question session afterwards, covering how to judge a language, how to review programming language papers and the review process in general, cognitive theories, and even maths vs. art.

Proxies: Design Principles for Robust Object-oriented Intercession APIs – Tom Van Cutsem

Back at the DLS, Tom talked about implementing intercession (that is, intercepting method calls) in Javascript. Unlike some scripting languages, this is surprisingly difficult in Javascript. He described a technique to do it using proxy objects.

Contracts for First-Class Classes – T. Stephen Strickland

The last talk of the day was on contracts in Racket, specifically on and using first-class classes. (By the way, Racket is the new name for PLT Scheme, I assumed I was the only one who didn’t realise this, but a few other people admitted their confusion later. Why did they change the name?) Not being a Lisp fan, I found the examples very hard to read – too many brackets! Anyway, Stephen (or T?) described Eiffel-style contracts (pre- and post-conditions). These can be added using first-class classes (in the same way that methods can be added to classes). He showed that object contracts were still required in some circumstances (as well as class contracts), and showed how these were implemented using class contracts on new classes and proxies to make the old and new classes work together.

OOPSLA FOOL Workshop

Filed under: Conference Report — Tags: , — nick @ 10:59

First day of the conference I attended the FOOL workshop. This used to be one of my favourite workshops, it always seemed to have high quality, interesting papers. It used to be held at POPL, but was cancelled last year. It has now been resurrected at OOPSLA and looks to be just as good as it’s ever been. The following talks were the highlights for me.

DeepFJig – Modular composition of nested classes – Marco Servetto

FJig is a formalisation of the Jigsaw language, which focuses on mixins and ‘class’ composition. This work extends FJig with an extension to nested classes. I believe that virtual nested classes are the most significant change to the OO paradigm currently being proposed. Being able to abstract and inherit at the level of class families, rather than just individual classes, solves an awful lot of problems with the usual class model. Thus, I’m happy to see another take on the idea.

From what I gathered, DeepFJig only supports ‘static’ nesting of classes, this makes the type system simple (no path dependent types, or exact types required), but at the expense of a lot of the benefits of virtual classes. The interesting thing here is that by combining nested classes with the mixin composition operators found in FJig, you get a great deal of expressivity – Marco showed how to encode generics (in a virtual types style) and aspects (yes, aspects, as in AOP). This latter probably means that the language is too expressive for some software engineering purposes, but it wasn’t clear from the talk how much you can sabotage classes, as you can usually do when using aspects.

Lightweight Nested Inheritance in Layer Decomposition – Tetsuo Kamina

Another nested classes paper, this time extending the ‘Lightweight Nested Inheritance’ (J&) concept. LNI uses paths of class names and exact class names to identify types. This work extends that with generics so that types can be more precisely specified. However, it seems that you only bite back some of the expressivity lost when compared with systems such as VC and Tribe (which have dependent path types). So, it is a slightly more heavyweight lightweight version of nested class types. The interesting aspect is that type variables can be used as type constructors for path types (but not generics types, i.e., X.C is OK, but X<C> is not). I guess that if you assume that you are going to have generics in such a language anyway, then getting this extra expressivity is nice. However, I am not entirely convinced that the result is much more lightweight than the path dependent approach.

Mojojojo – More Ownership for Multiple Owners – Paley Li

Paley presented work he has done with James Noble and I on Multiple Ownership type systems. Multiple Ownership was proposed at OOPSLA ’07, but the formalisation was unwieldy. This work presents a simpler, more elegant, and more powerful formalisation of the Multiple Ownership concept.

Traditional ownership types systems give each object a single owner, this organises the heap into a tree, which is great for reasoning about programs. Unfortunately, real programs rarely fall nicely into a runtime tree structure, so more flexible ways to organise the heap are required. Multiple Ownership allows each object to be owned by multiple owners, thus organising the heap into a DAG.

Mojojojo (if you don’t get the name, Google for the Powerpuff Girls) adds a powerful system of constraints over the structure of the heap, generics, existential quantification, and a host of small improvements to the formal system, resulting in something a lot nicer than MOJO. Paley gave a great talk, and I recommend you all read the paper (totally unbiased opinion, of course 🙂 ).

Interoperability in a Scripted World: Putting Inheritance & Prototypes Together – Kathryn E. Gray

More work on integrating typed and untyped languages, which seems to be very fashionable right now. This work focuses on making Java and Javascript work together, rather than focusing on type checking. The most interesting bit is making prototyping and inheritance work together in the same world.

I’m sorry I cannot write more about this paper, because it sounds really interesting, but I was a bit distracted at the beginning of the talk, and never quite got back into the flow. I’ll be reading the paper later though…

Adding Pattern Matching to Existing Object-Oriented Languages – Changhee Park

Changhee talked about adding pattern matching to Fortress (which reminds me to check on what is happening with Fortress nowadays). In fact one of the more interesting bits of the talk was the generalisation – the requirements on a language such that it can support pattern matching in the way described.

The general idea of the work is to support ADT-style decomposition of types by subtype using a typecase expression and function parameters and decomposition of objects into its fields, similarly to how tuples are decomposed in Python etc. What I thought was missing was a discussion of whether or not you would actually want to do this: you are breaking object-based encapsulation, which most languages avoid.

First Impressions of Reno and OOPSLA/SPLASH

Filed under: Conference Report — Tags: — nick @ 08:43

Hi, I’m Nick Cameron, a post-doc at Victoria University of Wellington. I’m going to be covering the SPLASH/OOPSLA conference for the JOT blog.

It should be an interesting year for OOPSLA: it has undergone re-branding from OOPSLA to SPLASH (a re-arrangement of the OOPSLA letters, minus OO (because who programs with objects any more?), and appended with “for Humanity” (cringe)). The research paper selection process has changed too, they introduced `white-ball’ papers (each member of the PC can select one paper to be accepted without argument), and there were slightly more papers accepted than in previous years (including mine, so I can’t really complain; Thursday afternoon, if you’re interested). The payment structure has changed too: you have to register and pay for individual workshops, I can’t comprehend why – the best thing about workshops is wandering between them.

Anyway, after twenty-odd hours on a plane from NZ, we started our descent into Reno, we got a birds-eye view of the Nugget (the conference venue and hotel) as we came in – sandwiched between the expressway and a railway yard, it did not look good. Reno airport was like a gateway into hell, slot machines everywhere and a backdrop of billboards for “gentleman’s clubs”.

The conference venue is almost comically grim. The main floor is a sea of slot machines and haggard looking people. There are a lot of cowboy hats around, and not in an ironic way. No-one looks happy to be here, mostly people look desperate, or just plain chewed up. People smoke a lot, indoors, which seems a bit odd in 2010. There is a patched motorcycle gang drinking in the lobby (seriously, this is not an exaggeration).

If I had to describe Sparks, and the Nugget, in a word, it would be “grim”. I don’t think I have ever been so disappointed in the location of a conference. I hope (and anticipate) the conference itself will be excellent, although it will have to be to justify enduring this place for a week. On the bright side lots of interesting people are arriving, and the free wifi at Starbucks has become a natural hub…

OOPSLA Registration

Things are looking up at registration: registration was very quick and efficient, the conference pack was pretty streamlined – no conference bag and not too much spam, which is great – I dislike the amount of waste most conferences generate. There is wifi in the lobby and conference rooms (yay!), and the gift was the cutest set of rainbow mini highlighters, which is a nice change from a USB stick, although not as practical.

Looking through the program is pretty exciting, there seems to be a lot of good-sounding papers and invited talks. The organisers also seem to have managed the scheduling well – despite three concurrent sessions at most times, there is not a single clash between talks I’d like to attend; Thursday’s invited talk does seem to clash with lunch, however, not sure how well that is going to work out.

2010/09/16

Conference Report: TOOLS’10

Filed under: Conference Report — Tags: — Jan Vitek @ 18:05
The 2010 TOOLS Federated Conference Series tool place between the 28th of June and the 2nd of July in Málaga Spain. TOOLS has been around the block a  few times, 48 times to be exact.  The conference was founded in 1989 by Bertrand Meyer as a place where practical results in object-oriented technology could be published. After a hiatus from 2002 to 2006, TOOLS reinvented itself as a Federated Conference consisting of the International Conference on Model Transformation (ICMT), Tests and Proofs (TAP), Software Composition (SC) and TOOLS Europe. For the first three years of the new formula, TOOLS was held in Zürich and financially supported by the Chair of Software Engineering at ETHZ and Eiffel Software. This year was the federation’s first time away from home and it has been a great success. The flawless hospitality of Antonio Vallecillo and his team from the University of Málaga and a wonderful weather conspired to make TOOLS a success. The program included nine workshops: Business System Management and Engineering, Dynamic Languages and Applications, Model Comparison in Practice, Model-Driven Service Engineering, Model Transformations with ATL, Quantitative Approaches on Object-Oriented Software Engineering and Related Paradigms, Transformation Tool Contest, Transforming and Weaving Ontologies and Model Driven Engineering, and Component and Service Interoperability. There were eight invited speakers: Stefano Ceri (Milano), Oege de Moor (Oxford), Betrand Meyer (ETHZ), Ivar Jacobson (IJI), Michael Ernst (Washington), Nachi Nagapan (Microsoft) and Valérie Issarny (INRIA).  Videos of their talks are available here.
The technical program of TOOLS Europe itself consisted of 16 papers selected with care from 60 strong submissions. Dynamic languages were well represented in the program. Arnaud et al.’s Read-only Execution for Dynamic Languages proposes a dynamic view mechanism on object references to prevent updates in Smalltalk (using the new Pharo VM). JavaScript was the topic of Phillip Heidegger’s talk on Contract-Driven Testing where an automated tool (download) for generating test cases from behavioral contracts is presented for JavaScript. In this work the specifications are mostly type-like properties and value ranges but even such simple properties are quite challenging to check in JavaScript. Stephen Nelson presented a more focused study of contracts in Understanding the Impact of Collection Contracts on Design. The work focuses on the equality contract between collection classes and the objects it contains. The contract is that equality should not change while an object is within a collection even if the object’s state changes. The contribution is an extensive analysis of the behavior of a corpus of Java programs taken from the Qualitas Corpus. Statically typed languages were also represented with, amongst others, the presentation by Ostlund of Welterweight Java a new formalism for researchers looking for a formal calculus that approximates Java and, unlike FeatherweightJava, supports threads and state. Ernst presented Revisiting Parametric Types and Virtual Classes which sheds light on the power of virtual constraints, a mechanism available in gbeta and Scala, for type refinement. Lastly, Renggli bridged static and dynamic languages with Domain-Specific Program Checking which argues for static checking of DSLs embedded in Smalltalk.
Many photos are on the Facebook page of the conference (here) where you can find the results of the TOOLS photo contest.

2010/08/26

Ten Things I Hate About Object-Oriented Programming

Filed under: Editorial — Tags: — Oscar Nierstrasz @ 17:25

Boy, I some days I really hate object-oriented programming.

Apparently I’m not the only one. In the immortal words of Edsger Dijkstra: “Object-oriented programming is an exceptionally bad idea which could only have originated in California.”

Well, I’m not normally one to complain, but I think it is time to step back and take a serious look at what is wrong with OOP. In this spirit, I have prepared a modest list of Ten Things I Hate About Object-Oriented Programming.

1. Paradigm

What is the object-oriented paradigm anyway? Can we get a straight story on this? I have heard so many different versions of this that I really don’t know myself what it is.

If we go back to the origins of Smalltalk, we encounter the mantra, “Everything is an object”. Except variables. And packages. And primitives. And numbers and classes are also not really objects, and so on. Clearly “Everything is an object” cannot be the essence of the paradigm.

What is fundamental to OOP? Peter Wegner once proposed that objects + classes + inheritance were essential to object-oriented languages [http://doi.acm.org/10.1145/38807.38823]. Every programming language, however, supports these features differently, and they may not even support them as built-in features at all, so that is also clearly not the paradigm of OOP.

Others argue convincingly that OOP is really about Encapsulation, Data Abstraction and Information Hiding. The problem is that some sources will tell you that these are just different words for the same concepts. Yet other sources tell us that the three are fundamentally different in subtle ways.

Since the mid-eighties, several myths have been propagated about OOP. One of these is the Myth of Reuse, which says that OOP makes you more productive because instead of developing your code from scratch, you can just inherit from existing code and extend it. The other is the Myth of Design, which implies that analysis, design and implementation follow seamlessly from one another because it’s objects all the way down. Obviously neither of these candidates could really be the OO paradigm.

Let’s look at other paradigms which offer a particular way to solve programming problems. Procedural programming is often described as programs = data + algorithms. Logic programming says programs = facts + rules. Functional programming might be programs = functions + functions. This suggest that OOP means programs = objects + messages. Nice try, but this misses the point, I think.

For me the point of OOP is that it isn’t a paradigm like procedural, logic or functional programming. Instead, OOP says “for every problem you should design your own paradigm”. In other words, the OO paradigm really is: Programming is Modeling

2. Object-Oriented Programming Languages

Another thing I hate is the way that everybody loves to hate the other guy’s programming language. We like to divide the world into curly brackets vs square brackets vs round brackets.

Here are some of the nice things that people have said about some of our favorite OOPLs:

“C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.”

It was Bjarne Stroustrup who said that, so that’s ok, I guess.

“Actually I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind.” — Alan Kay

“There are only two things wrong with C++: The initial concept and the implementation.” — Bertrand Meyer

“Within C++, there is a much smaller and cleaner language struggling to get out.” — Bjarne Stroustrup

“C++ is history repeated as tragedy. Java is history repeated as farce.” — Scott McKay

“Java, the best argument for Smalltalk since C++.” — Frank Winkler

“If Java had true garbage collection, most programs would delete themselves upon execution.” — Robert Sewell

But perhaps the best blanket condemnation is the following:

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” — Bjarne Stroustrup

3. Classes

Classes drive me crazy. That might seem strange, so let me explain why.

Clearly classes should be great. Our brain excels at classifying everything around us. So it seems natural to classify everything in OO programs too.

However, in the real world, there are only objects. Classes exist only in our minds. Can you give me a single real-world example of class that is a true, physical entity? No, I didn’t think so.

Now, here’s the problem. Have you ever considered why it is so much harder to understand OO programs than procedural ones?

Well, in procedural programs procedures call other procedures. Procedural source code shows us … procedures calling other procedures. That’s nice and easy, isn’t it?

In OO programs, objects send messages to other objects. OO source code shows us … classes inheriting from classes. Oops. There is a complete disconnect in OOP between the source code and the runtime entities. Our tools don’t help us because our IDEs show us classes, not objects.

I think that’s probably why Smalltalkers like to program in the debugger. The debugger lets us get our hands on the running objects and program them directly.

Here is my message for tool designers: please give us an IDE that shows us objects instead of classes!

4. Methods

To be fair, I hate methods too.

As we have all learned, methods in good OO programs should be short and sweet. Lots of little methods are good for development, understanding, reuse, and so on. Well, what’s the problem with that?

Well, consider that we actually spend more time reading OO code than writing it. This is what is known as productivity. Instead of spending many hours writing a lot of code to add some new functionality, we only have to write a few lines of code to get the new functionality in there, but we spend many hours trying to figure out which few lines of code to write!

One of the reasons it takes us so long is that we spend much of our time bouncing back and forth between … lots of little methods.

This is sometimes known as the Lost in Space syndrome. It has been reported since the early days of OOP. To quote Adele Goldberg, “In Smalltalk, everything happens somewhere else.”

I believe that the code-oriented view of today’s IDEs is largely to blame — given that OO code does not accurately reflect the running application, the IDE gets in our way instead of helping us to bridge the gap. Another reason I believe that Smalltalkers like to develop in the debugger is that it lets them clearly see which objects are communicating with which other objects. I am guessing that one of the reasons that Test-Driven Development is popular is that it also exposes object interactions during development.

It is not OOP that is broken — we just haven’t figured out (after over 40 years) how best to develop with it. We need to ask ourselves: Why should the source code be the dominant view in the IDE?

I want an IDE that lets me jump from the running application to the code and back again. (For a demonstration of this idea, have a look at the Seaside web development platform which allows you to navigate directly from a running web application to the editable source code. [http://seaside.st])

5. Types

OK, I admit it. I am an impatient guy, and I hate having to say everything twice. Types force me to do that.

I’m sure some of you are thinking — “Oh, how could you program in an untyped language. You could never be sure your code is correct.”

Of course there is no such thing as an “untyped” programming language — there are just statically and dynamically typed ones. Static types just prevent you from writing certain kinds of code. There is nothing wrong with that, in principle.

There are several problems, however, with types as we know them. First of all they tend to lead to a false sense of security. Just because your Java program compiles does not mean it has no errors (even type errors).

Second of all, and much more evil, is that type systems assume the world is consistent, but it isn’t! This makes it harder to write certain useful kinds of programs (especially reflective ones). Type systems cannot deal well with the fact that programs change, and that different bits of complex systems may not be consistent.

Finally, type systems don’t cope well with the fact that there are different useful notions of types. There is no one type system to rule them all. Recall the pain we experienced to extend Java with generics. These days there are many interesting and useful type systems being developed, but we cannot extend Java to accommodate them all. Gilad Bracha has proposed that type systems should not only be optional, in the sense that we should be able to run programs even if the type system is unhappy, but that they should be pluggable, meaning that we can plug multiple type systems into different parts of our programs. [http://bracha.org/pluggableTypesPosition.pdf] We need to take this proposal seriously and explore how our languages and development tools can be more easily adapted to diverse type systems.

6. Change

“Change is inevitable — except from a vending machine.” — Robert C. Gallagher

We all hate change, right? So, if everyone hates change, why do we all complain when things don’t get better? We know that useful programs must change, or they degrade over time.

(Incidentally, you know the difference between hardware and software? Hardware degrades if you don’t maintain it.)

Given that real programs must change, you would think that languages and their IDEs would support this. I challenge you, however, to name a single programming language mechanism that supports change. Those mechanisms that do deal with change restrict and control it rather than enable it.

The world is not consistent, but we can cope with that just fine. Context is a great tool for managing change and inconsistency. We are perfectly comfortable adapting our expectations and our behavior in our daily lives depending on the context in which we find ourselves, but the programs we write break immediately if their context changes.

I want to see context as a first-class concept in OO languages and IDEs. Both source code and running software should be able to adapt to changing context. I believe that many design patterns and idioms (such as visitors, and dependency injection) are simply artifacts of the lack of support for context, and would disappear if context were available as a first-class construct.

7. Design Patterns

Patterns. Can’t live with ’em, can’t live without ’em.

Every single design pattern makes your design more complicated.

Visitors. I rest my case.

8. Methodologies

“All methodologies are based on fear.” — Kent Beck

Evidently some of my students follow the Chuck Norris school of Agile Development:

“Chuck Norris pairs alone.”

“Chuck Norris doesn’t do iterative development. It’s right the first time, every time.”

“Chuck Norris doesn’t do documentation. He stares down the code until it tells him everything he wants to know.”

9. UML

Bertrand Meyer tells this story about always wondering why diagrammatic modeling languages were always so popular, until one day it hit him: “Bubbles don’t crash.” I believe his point is that OO languages are modeling languages. (AKA “All you need is code”)

There similarly appears to be something fundamentally wrong with model-driven development as it is usually understood — instead of generating code from models, the model should be the code.

By analogy, when FORTRAN was invented, it was sold as a high-level language from which source code would be generated. Nowadays we think of the high-level languages as being the source code.

I like to think that one day, when we grow up, perhaps we will think of the model as being the source code.

10. The Next New Thing

Finally, I hate the catchphrase: “Objects are not enough. We need …” Over the years we have needed frameworks, components, aspects, services (which, curiously, seems to bring us back to procedural programming!).

Given the fact that objects clearly never were enough, isn’t it odd that they have served us so well over all these years?

Conclusion?

25 years ago we did not expect object-oriented programming to last as a “new” phenomenon for so long. We thought that OO conferences like ECOOP, OOPSLA and TOOLS would last for 4 or 5 years and then fade into the mainstream. It is too soon to dismiss OOP as just being part of the mainstream. Obviously we cannot feel passionately about something that does not interest us. The fact that academic and industrial research is still continuing suggests that there is something deep and important going on that we do not yet fully understand.

OOP is about taming complexity through modeling, but we have not mastered this yet, possibly because we have difficulty distinguishing real and accidental complexity.

I believe that to make further progress we must focus on change and how OOP can facilitate change. After all these years, we are still in the early days of OOP and understanding what it has to offer us.

Oscar Nierstrasz
[Banquet speech given at ECOOP 2010. Maribor, June 24, 2010]

2010/08/01

The Trouble with Configuration Management

Filed under: Column — John McGregor @ 02:19

The trouble with configuration management in some large technical organizations is that it is not just configuration management. An organization often assigns to a single role responsibility for software builds, configuration management (which often includes change management), and releases of products to customers. While these responsibilities are mutually dependent they are distinct roles, have different goals, and require very different skills. When we evaluate a product line organization this role is often identified as a source of problems. One or more of the dimensions is either neglected or incorrectly executed by the personnel assigned to the position.

There are several issues related to this approach. People in this integrated role are often not familiar with how software development will be carried out on a specific project and as a result they will often design a repository structure that does not permit, or at least hinders, parallel development. This has to do with the grain size of each versioned blob and the dependencies among blobs. A poor structure results in the possibility of two people needing to working on the same file at the same time. Developers who are unaware of the structure of the repository or who do not understand how that structure relates to the structure of the products will not be able to write build scripts that are sufficiently modular to be reused at every level up the aggregation hierarchy and may codify dependencies incorrectly resulting in an improperly linked module.

The CM staff will also define one process that is applied to both development activities and delivery activities. While this makes the release part of the CM job simpler, it slows down the development process which needs quick, frequent access to repositories to commit, update, and retrieve program elements. Some companies address this by having separate development and release CM processes without sufficiently differentiating between the processes.

First I will talk about the goals of each role, then the required skills, and finally dependencies among the roles. I will describe a company doing it right and will briefly describe how they perform these three functions.

Goals

Each of these roles has a specific goal that distinguishes it from the other roles.

The goal of the build role is to provide an executable that reflects the current development state of the product. Often legacy modules are not recompiled during a build. This is sometimes because of the time it would take to build the module but more often it is because there is a risk that the module will not build in the current environment. The result of partial recompilation can be that other modules that have changed and should be rebuilt aren’t.  Building is a sufficiently complex task that many organizations require an independent auditor to witness the actual building to affirm that the correct modules were used to produce an executable with no errors.

The goal of the (real) configuration management role is to allow controlled changes to the source code by multiple people at the same time while protecting the integrity of previous work. This sounds simple, but in an environment such as a software product line it is not so simple. The structure of the repository of versions of the code facilitates specific development patterns more than others. The CM role must anticipate the eventual complexity of a development effort that will involve multiple players for multiple products. In a software product line the emphasis is on multiple references from multiple products to single copies of assets.

The goal of release management is to deliver to the customer a complete and consistent set of modules and resources that represent a correct product at a specific point in time. The product release and related resources such as the installation mechanism must be tested and the release manager determines whether particular features meet quality standards. Each release represents a build that has a permanent life in the CM system.

Skills

The build role needs an understanding of the product architecture, compile and link time variation points, and, obviously, the build tools. The build manager assures that the final build and installation package includes all the required resources including appropriate licenses.  In a software product line, the build script for a product specifies a configuration of the product with compile and link time variations resolved.  The script is placed under management because it captures the variant choices. The build role provides build automation to the development and test staff. In many projects every commit is a compile and test before the commit is confirmed. If every developer commits every day the organization has “always running” code. I have developed for many years using this style and it is a very efficient approach, but it is only feasible if the builds and tests are automatic.

The configuration management role requires knowledge of design, variation mechanisms, and the development process. The structure of the repository must support the approach taken to development. Some parallelism in work is required. The CM process should support concurrent work in a baseline. One way this happens is by having assigned ownership of assets so that only one person does work in a specific asset. Or at least having a separate trunk for each asset with only one person allowed in the asset at a time. Newer build tools allow logical references to files removing the need to physically copy code, but many organizations still do copy and are then faced with a diverging code base.

Release management requires an individual who understands the development process, the needs of the customer, the install time variations, and the paperwork required to support a release.  In many companies the release manager is responsible for negotiating with the customer and development team for what will be ready for delivery in the next release and by what date. The manager determines that every module in the release has been through the full life cycle and is ready for release. The release manager is also responsible for assembling the installation package. Automation is critical to be able to exactly repeat a build and to quickly get ready for the next build.

Every project should establish and maintain a regular schedule of releases.  This steady rhythm will establish a positive expectation on the part of clients. Many large open source projects release nightly builds, which are less well tested than the periodic stable builds. Software product line organizations often make both core asset and product releases on a regular schedule. Eclipse creates a stable, deliverable build for a large percentage of its project twice a year with nightly builds in-between. While the rhythms may vary from one organization to another, this is still a useful approach.

Dependencies

The three roles all manipulate the source code for the products. Essentially CM manages a set of files, some subset of which are selected to be built together, and the result of that build is the key element in a release. While the build process could take place with almost any physical organization of the code, the CM role can facilitate the build process through the structures that are chosen. An organization of the code that reflects some logical structure can reduce the chances of build errors. Clear labeling of versions allows for the automatic generation of new build scripts. The Build role needs to understand the content of a release and know any specific constraints for resolving any compile/link time variations.

Figure 1 Interdependencies

CM needs to know logical dependencies among the source files. The CM role captures a complete snapshot of its database for each release. This does not have to be a separate copy. It can be a versioned script that specifies a specific version for every element in the release. This goes beyond the scope of a “build” which is limited to the elements needed to compile and link the code to produce an executable. The copy includes all tests, test results, the development environment, and more.

The release role needs to know the exact contents of a release, which means the contents of one of many builds and the structure of the repository. If build scripts are managed in the repository by the CM function than the release role can retrieve a specific one at any time.

A Modest Proposal

Much of this confusion can be clarified by automating the build process and treating the build script, which may be more than a single text file, as a first class object. In fact, the build script should be thought of as the product. The script is placed under management and is versioned as changes are made to the contents of the product. The CM role creates a structure for the product that will include the build script and any product unique code. The build role creates the script and submits it to the configuration management system. The release of a product simply requires that the build script be baselined, references into the core asset base are changed from relative to absolute addresses, a separate branch is created to assemble the elements of the product.

Even if the three roles are assigned to a single person, this is a sufficiently simple process that can be handled by a single person. Many tools such as Eclipse and Visual Studio support this approach with integrated build tools. Eclipse has several projects such as Buckminster and b3 that manage the build process (and much more) and consist of artifacts that can be managed in the configuration management system.

Case in Point

My example company will have to remain anonymous but it is a major software development house specializing in a single domain but producing a software product line of consumer and professional products in that domain. This company separates the build, CM, and release roles and is large enough to have several people in each role.

Build – Building a product begins with builds of individual executables. These builds are initiated by development team members.  The owner of a module develops a build script for that module. Successive layers of integration also produce build scripts that utilize the lower level scripts to build from the ground up. Finally each product has a script that automates the instantiation of the lower level pieces. Since a fundamental responsibility of the build role is to ensure that the correct code is compiled and linked, this bottom up aggregation of scripts provides a natural traceability mechanism.

CM – The configuration management is largely automated at the start of a project. The structure of the core asset base has been fixed for some time and each new product sets up to utilize that base in their scheme. The developer sets up a directory structure for their code and includes references to each core asset used rather than copying the asset into their project. The CM role establishes and evolves the basic structure and is responsible for “baselining” deliveries, which only requires creating a branch for the build scripts and making variable references in the script to the latest versions of assets into fixed references to specific versions of those assets instead.

Release management – The role of release manager carries both responsibility and authority.  Once a delivery date is set and the scope of the release is negotiated with all development streams, the release manager has the authority to remove a feature from a product if including that feature puts the delivery date at risk.   The manager also has the responsibility to ensure that any included features have been appropriately tested and have satisfied quality requirements. The release itself is based on the baselined build scripts that have been used from initial development through testing and now to release.

Summary

These infrastructure roles are important to the success of any software development effort but they are particularly critical in a software product line organization. The role definitions and training for each role need to be sharply focused and we need to push for trained personnel in each role. In the event that two or more of these roles are assigned to the same person, controls should be put in place to ensure even-handed and competent treatment in each of the three areas.

Running through this entire discussion is the notion of automation. There are many tools that can be used make building, change management, and product release much more repeatable and robust. Most of these tools support a variety of process structure and styles but most also make the lines between the three roles much more discernable.

2010/07/28

Word template for JOT submissions is now available

Filed under: Announcement — Tags: , — Oscar Nierstrasz @ 14:45

This new template can be downloaded from the information for authors page. It mimics the LaTeX template as far as possible. To use the Word template you should install the Computer Modern fonts (instructions provided).

« Newer Posts — Older Posts »

Powered by WordPress