Onward! this year was a bigger conference compared to previous years; it spanned the entire 5 days of OOPSLA. I had a hard time deciding whether to attend the research tracks at OOPSLA or the presentations at Onward! The research tracks at OOPSLA are dedicated to concrete ideas which have been implemented and evaluated; whereas the Onward! tracks are dedicated to newer, interesting and sometimes out-of-this-world ideas with prototypes and preliminary evaluation.
Pretty much everything was interesting at Onward! – yes, even the Harmony-Oriented Programming papers though I have yet to be convinced whether it's more of an deliberate (but interesting) juxtaposition of current programming ideas or something new and useful.
There are two papers that I found particularly relevant to my interests and I will summarize them here for you. Definitely take a look at the other papers too.
Software Evolution and the Moving Picture Metaphor
When we think of software evolution, we usually think of something like the image below ...
... where we have a timeline that shows the different commits to the version control system. However, if you think about it, each of those commits are merely snapshots of the software as it evolves. What happens in between those snapshots is lost. We don't have an idea of the debugging sessions, the testing sessions and the trial-and-error sessions that a programmer goes through before committing the code.
Viewing the evolution of software through those snapshots is like watching a movie except that we only get to glimpse at snapshots of the movie at certain points. For the most part, we can definitely get a good idea of the story behind the movie – though we might miss some of the more subtle points.
It's the same with software evolution. Each commit in the version control system tells part of the story. And sometimes that might be enough for what we need since we only care about interesting chunks of software development. But sometimes we care a bit more about the things that happen between snapshots. Using our movie metaphor again, you can think of this as viewing a movie with the director's commentary.
I don't think anyone has explored the idea of capturing software evolution as a movie (instead of snapshots). There has been some work on visualizing software evolution but no one has tried to capture software evolution itself as a movie. People have tried recording entire development sessions – how people design the architecture on whiteboards, how requirements are gathered, how they communicate with one another, etc. For instance, there is the DOLLI project that filmed the entire software development process of a group of university students.
So if we were to create a movie of software development, what would it look like? Here are some interesting questions for an idea like this:
- What to capture? - Do we capture only the code in the IDE, the debugging sessions, the testing sessions, etc? Or we capture more context like what Tasktop is doing?
- How much to capture? - Capturing too much information will lead to very boring movies very quickly. We need to find out what's really important to the programmer and filter out everything else.
- How would we do this non-intrusively? - The programmer just wants to continue programming so we would need to capture this information without affecting how she programs.
- How to replay this information? - It will be very boring to play it from the beginning to the end. How would we edit the movie to make it interesting and useful?
- Would something like this be useful? - Who would be interesting in using it? The programmer herself when she is reflecting on her program? Or someone learning the system for the first time?
Like all Onward! papers, this is a preliminary idea. And there is a lot work that needs to be done to see how useful this will be.
Pi: A Pattern Language
I missed the actual presentation but the authors have been nice enough to post a .mov file of their presentation online.
Short summary: You are trying to solve a problem. You know how to express your problem and solution but your programming language just doesn't let you express it succinctly. Nonetheless you persevere and manage to code it within 500 lines though you have now lost the essence of your solution amidst the lines of code. If only you could easily define some language constructs to capture the essence of the problem you are trying to solve and its solution.
This trend isn't new. The DSL folks are very happy to create custom languages. People in Lisp have been doing this for years. And with the rise of interest in intentional programming, language workbenches and language-oriented programming, we might just see more of such systems.
The paper itself does a good job of talking about related work so you can read it and have a good idea of how it compares to a system that you are familiar with. One related work that the authors missed is the K Framework developed at UIUC by the FSL group. The K Framework is worth mentioning because it is a nice and modular approach - using continuations - for solving the context problem while designing your own language constructs. As you design your own constructs there is always the risk of interference especially if you are trying to reuse the same symbols to mean different things for brevity.
To reflect on this trend, it might be good to read (or re-read) the popular essay by Paul Graham on the 100-year language. As languages evolve, they seem to gravitate toward Lisp.
Paul Graham, The Hundred-Year Language:
"The trend is not merely toward languages being developed as open-source projects rather than "research", but toward languages being designed by the application programmers who need to use them, rather than by compiler writers. This seems a good trend and I expect it to continue."
Now the next question to ask would be how to easily develop tools that can grow as your language grows as well. Imagine having a syntax highlighter that is smart enough to recognize new syntax as you define it. Imagine having refactoring tools (my colleague, Jeff, is working on something related) that can help you refactor from an older construct to a newer one. How would you test a system like this: you would have to test your language and also your program written in that language. How would you be able to debug something like this?
PS: The paper has been picked up by reddit and lambda-the-ultimate as well so it might be interesting to read the comments there.
There were two major themes at the WRT this year: concurrency and polyglot refactoring.
Concurrency
I actually prefer the term transforming instead of refactoring for converting sequential code to parallel code but I will use the term refactoring here since other people in the community have embraced it.
Two papers were presented that dealt with refactoring to concurrency in the X10 language:
Both papers presented some prototype refactorings. I really liked the presentation of the second paper since it relates directly with the work I am doing on optimization patterns for parallel programming. As you can see from the image above, the tiling operation is one such optimization. It's important to provide such a transformation since you may need to do it to get good performance. Such transformations cannot be done by the compiler since it needs more feedback from the programmer on the size of the tiles which depends on the algorithm and data structures for that particular problem that you are trying to solve. And sometimes tiling might not even solve the problem so you need to know when to tile and when not to tile.
We had a breakout session on the topic of concurrency refactorings and here were the interesting issues (read as future research questions) that came up.
- How to discover what to refactor?
Profilers and trace based executions can help guide you in this area but they aren't always that intuitive to use. And you don't want to introduce concurrency blindly since it only matters if you are optimizing the real bottlenecks. - What are some ways to suggest potential refactorings?
Now that you know where the bottlenecks are, what are some refactorings that you can apply? I believe that parallel patterns are the way to go. - How do you check that your refactoring is correct?
Refactoring engines for sequential code have bugs. And with concurrency refactoring you have to be even more careful to not introduce subtle concurrency bugs that can be hard to track down. How would you check the correctness of your transformations statically? - How do you fine-tune your refactorings?
Unlike sequential refactorings, concurrency refactorings require more feedback from the user. For instance, the dimensions of the tiles (see picture above). It would help if the IDE can suggest some parameters and then run the profiler automatically to give more feedback.
The work on concurrency refactoring is definitely something that my advisor, Ralph Johnson, and his group at UIUC are interested in as part of our vision for an IDE that can help support parallel programming.
Polyglot Refactoring
Polyglot refactoring is not a standard term. It's one that I coined to describe how refactorings must be aware of all the different components that you use in your program - frameworks, libraries, etc. All these different components are described using different mini DSLs. For instance, the Hibernate configuration files are described in XML, your testing framework uses a set of APIs and conventions that you must conform to, and sometimes you use different languages (Groovy, JRuby, etc) that run on the JVM but share data.
It's important that as you perform the traditional refactoring such as rename, move, etc that you preserve the intended behavior in these other components as well. I think this is not an area that many people have looked at. Researchers focus on having new refactorings for the core language but forget that those other components need to be refactored too leaving a broken program that the user has to fix by hand.
There are three papers that deal with this issue:
- Refactoring in Multiple Representations - Code and Statecharts
- Testing-framework-aware Refactoring
- Toward a Language-Agnostic, Syntactic Representation for Preprocessed Code – this deals with preprocessors which essentially can be viewed as a different language on top of your base language
There were three interesting talks that I attended at the DLS this year:
Of Scripts and Programs: Tall Tales, Urban Legends, and Future Prospects
(Unfortunately, I missed the first 10 minutes of the talk where Jan was talking about his experiences with the Pluto language).
Jan presented the investigation that he and his team did to measure how much dynamism programmers used in Javascript – the most ubiquitous scripting/programming language on the web today. He had a good sample size, much bigger than most experiments that I have seen. And definitely not like the paltry, non-representative data that most other research papers have in their evaluation sections. His team surveyed major web applications that utilized Javascript heavily including 280slides, GMail, Facebook, Flickr and Apple Me.
Some aspects of their evaluation include:
- Size of code (in megabytes)
- Prototype chain lengths – Almost like inheritance chains in Object-oriented languages
- Variadity – Javascript allows you to call functions of n arguments with m arguments. So how apps out there use this feature?
- eval(...) – which can used sanely to grab data from JSON or used dangerously to evaluate any string as code.
The conclusion? Some of those apps really use almost every dynamism that Javascript has to provide!
His solution? Yet another programming language (but, of course :-)). His language is called Thorn. I don't have the time to look at it yet, but it reminds me a lot of Strongtalk language with optional typing.
Jan's slides should be available from the DLS website soon.
I also had the chance to ask someone from Google about how they use Javascript. And he basically said that they used a more disciplined approach to it – certain features just aren't used or they are used very judiciously. Some people really like the dynamism of Javascript and others just use it almost like another Java.
Optimization of Dynamic Languages Using Hierarchical Layering of Virtual Machines
Here's a crazy idea: what if you wanted to run Lua on the Lua VM on the ActionScript VM?! Now, why would anyone do this? To test out their optimization technique for layering VMs, of course.
It's a rather circuitous way to evaluate this but it seems to be the easiest route. After all, you don't want to write a VM just to be able to try this out. You just want to use an existing one. And the Alchemy project provides an easy way to translate the original C-based Lua VM to ActionScript.
Of course, the caveat of such an evaluation is that the implementation will be so slow in the first place (the presenter was honest and mentioned this early) that it is relatively easy to get speedups no matter how trivial or naive your technique is.
Hosting an Object Heap on Manycore Hardware: An Exploration
This is a continuation of Dave Ungar's work which he presented at the Squeak BOF at OOPSLA 2008.
In a nutshell, he implemented a simple benchmark (baton passing) between different Squeak Smalltalk VMs running on the 56 (it has 64 cores but some of them are reserved) cores of the Tilera multicore processor.
His goal with this experiment was to investigate what kinds of problems we would run if we are going to use manycore (not just multicore) processors. With manycore processors, you have non-uniform memory access and it becomes infeasible to maintain true cache coherence between those cores. In other words, you do need to be aware of the location of your data (much like what the distributed computing folks have been doing).
This is in contrast to what Intel's multicore chips are doing. Even in Larrabee with 10+ cores, all the cores still maintain cache coherence.
I liked the talk because it presented a different view from all the other research papers that I have been reading where they try to solve the problem (or push the solution as far as it can go) for multicore systems and just implicitly assume that it will scale to manycore. People are trying to hold on to the shared memory model for as long as they can and trying very hard to not use a message passing system.
The panelists: (from left to right) Marjan Mernik, Juha-Pekka Tolvanen, Gabor Karsai, Charles Consel and Kathleen Fisher.
DSLs seem to be a rather popular topic at OOPSLA this year. There was a workshop on it and several tutorials as well. And there was also the DSL panel which I attended this morning. Most of the talks and tutorials on DSLs assume that the audience is using specialized modeling tools to create them. Basically those tools provide a specialized environment for creating the meta-model for your DSL, specifying the grammar of your DSL and helping you specify templates for code generation (which actually makes your DSL useful). Such tools aren't meant to help you create a full-fledged programming language. Instead they help you quickly create a small language that can be refined in an agile and iterative process. One of the panelists commented that this might be more productive (and less intimidating) than using lex and yacc.
So, as a summary of the panel, let me present to you the good, the bad and the ugly about DSLs:
The Good
- Most people are already using DSLs in the industry and it seems that there has been some case studies that strongly suggest that using DSLs actually helps improve productivity. When asked, Juha-Pekka, who presented those results, told the audience that productivity was measured in terms of what the customer told him – so they could be measuring that it used to take 6 hours to complete something and now it takes 1 hour to do it; thus gaining a 6-fold increase in productivity. Such numbers were actually reported on his slides.
- Most panelists agree that using a simplified language like a DSL helps the user avoid certain mistakes that a general-purpose language might incur. After all, it is not possible to express certain constructs in the DSL that would be possible in a normal programming language thus lessening the chances for making those mistakes.
The Bad and The Ugly (we can just merge them)
- As far as I know, it's hard to actually tell what are good qualities of a DSL. So if I am designing a DSL how do I know what direction to steer it to so my customer would benefit more from it? For instance, is DSL A better than DSL B? And in what aspect? The only answer provided to this question is that creating a DSL is an iterative process and depends on what your customers like.
- Which brings me to the second point: how to we duplicate success that we had achieve in using one DSL into another project? If we cannot systematically distill the finer points of each DSL, it would be hard to repeat its success on another project. It is also wasteful to start from scratch every time – though the panelists seem to argue that since it's a domain-specific language, it might better to create very specialized ones for each customer.
- And this leads me to my third point: how to share DSL among different projects? Currently, there is very little being done on researching what is the best way to share DSLs among projects. Also, do we actually need to share the DSL or just the underlying meta-model that the DSL embodies? A simple and naive way might just be to form a standard and have everyone use that. Though, of course, that naturally, leads to a bloated DSL since everyone would have some specific feature that no one else needs.
- The panelist also agree that there are currently very few tools to help DSL developers. Currently there aren't many tools to help a Domain-Specific Environment (DSE) that will include all the features of a normal IDE such as code-completion, debugging, etc. But more importantly, there aren't tools to help domain-analysists distill the features of the domain itself – the most important step in creating an ubiquitous language as a basis for the DSL.
- Also, when asked if they prefer a internal DSL (implemented using the constructs of an existing programming language – common in Ruby) or an external DSL(implementing a new language), the panel seems to agree that it might be better to use an external DSL so that the user will not be tempted to escape from the domain and use constructs outside of the DSL. For instance, if we were to implement an internal DSL using Ruby, we would have at our disposal, all the feature of the Ruby language which can be used in our DSL. This makes it tempting to use existing language features in an ad-hoc manner and pollute the actual DSL.
The interesting part of the panel only happened during the second half when the audience was given the opportunity to ask questions. The first half was wasted (pardon the word) on having each panelists spend 10-15 minutes talking about their work and their position on DSLs. In my opinion, that was a serious mistake since it only gave the audience about 30-45 minutes for the interesting questions.
Coincidentally, I just found out that Martin Fowler actually has a work-in-progress about DSLs. It might be better to read about DSLs from him rather than other DSL enthusiasts since his approach might be a more unbiased view toward how to do DSLs; instead of a DSL-enthusiast who is already too enamored by the very idea.
"Brooks was fooled."
– Dick Gabriel
In OOPSLA 2007, Fred P. Brooks gave a keynote entitled Collaboration and Telecollaboration in Design. I actually wrote a blog entry about it. Overall, I thought that it was a fantastic keynote.
Software Engineering Matters : OOPSLA '07: Collaboration and Telecollaboration in Design:
"There could be multiple architects but there is one chief architect who has the authority to make the final decisions. Even in an open source project like Linux, Linus Torvalds still has the ultimate veto power on what to put in and what not to put in. This almost seems like a dictatorship but if that is what is required for conceptual integrity then it is something that has to be done."
However, there was one over-simplification that Fred Brooks used; he claimed that all of the most innovative products in the world today are created by one individual (or at most two). As examples, he used Albert Enstein, Thomas Edison and the Wright Brothers (the only group of two that Brooks cited).
A couple of people, including Ralph Johnson, pointed out after Brooks's talk that it wasn't necessarily true; in fact, a lot of excellent products today are not created just by one individual. Instead the product usually created by a committee or group and the product would not have been possible without those other individuals.
I definitely agree that Brooks might have oversimplified his examples to get his points across. But then again, he isn't really to blame. Society has always ascribed greatness to one particular individual for each accomplishment. That is just how the world works. And though some might say it isn't unfair for just one individual to claim all the credit, it certainly makes more sense to say that Albert Einstein came up with the theory of relativity than saying that Einstein collaborated with Tom, Dick and Harry and they all helped him to come up with that theory. Besides being a mouthful, it is hard to trace which individuals actually influenced Einstein. If you wanted to, you could even optimistically claim that it was the series of all his interactions with different people that enabled him to formulate his theory. But no one does that because while people realize that such works of marvel aren't the works of an individual, it's best to attribute it to the individual who seemed most responsible for it.
Most people who have left it as that. However, some people might ponder about it for a few more days. And a small minority might even think about it for a few more weeks. But there is likely to be only one individual who would ponder about it for a whole year and write an essay on it – Dick Gabriel : )
So the title of his essay this year is Designed by Designer in which he cites numerous examples (and personal interviews) on why most grand works of art are seldom, if ever, just the work of one careful individual seeing everything from beginning to end. It is insufficient (and unfair) to study the mind of the perceived genius who created that work; instead we need to also study his collaboration with his colleague and how possibly, his work could have just appeared randomly(!) or the work was already there waiting to be discovered and the first person to do so was given the title of genius.
For me, Dick's presentation today was a very interesting one. It was definitely well-planned and well-executed in Dick Gabriel's style – it was artsy, akin to watching a National Geographic or Discovery Channel documentary. It wasn't really a counter-argument to Brooks; rather, I see it as a valid alternative perspective to what Brooks had said. After all, no one really knows what is the best way to create such grand works of art (and similarly no one actually knows how to create complex software perfectly each time). There is always the possibility that a small agile and egalitarian team could produce software of equal quality to that of a big group with organization and bureaucracy. And there is always the possibility that a group wrapped with organizational chains can also produce software of equal quality to that of a small agile group.
Some groups function better with the illusion of a romantic genius to guide them into unknown territories. Other groups prefer to approach everything as a team without a leader – who needs a leaders after all? we could all just take turns since none of us is infallible – and approach each new challenge as a group.
Dick's essay will be available in the OOPSLA proceedings. I will be spending more time reading (and appreciating) it when I get back. There simply isn't enough time during OOPSLA for deep, contemplative reading.
Seaside BOF
I didn't get to take any pictures in this session because I came in late and was sitting at an awkward spot. James Robertson from Cincom was there and has posted some pictures on his blog. I am actually in one of those pictures :)
Michael Lucas-Smith did a demo of WebVelocity – Cincom's new in-your-web-browser development environment for Seaside. I missed the first 10 minutes of it but it's similar to the screencast that he had done before. WebVelocity is cool but there are two things that I really like about it.
First, it has ample documentation provided for Seaside. Besides the base library from Cincom, I think that this is one of the best documented Smalltalk project ever. Not only do they have comments for the classes and method, but they also have a nice getting started guide all built-in and easily accessible. That was really fantastic! And to make it even better, they had an integrated search widget that allowed you to search through the class names, methods names and, now, comments! Something that was missing from Smalltalk before.
Second, WebVelocity bravely goes where no Smalltalk has gone before: it lets you edit your source code inside a single window – in this case, your web browser. You can actually see all your methods in one editor without having to open multiple windows! I think this is one of the most interesting (and smart) approaches that Cincom can take to get people to use Smalltalk. I believe that they have reduced the entry barrier for Smalltalk by presenting it in a more familiar environment to newcomers. Hopefully they get some positive feedback and comments on this and use that to help them structure their tools to suit both new and veteran users.
Squeak BOF
I took the pictures using my iPhone so they are all pretty bad actually. The only way I could salvage them was by turning them into black and white pictures....
There were three presentations in this year's Squeak BOf.
First Goran presented his project on creating a a lightweight Simple-CGi replacement for Seaside development in Squeak. He calls it Blackfoot and at the time of the demo he still had some bugs in getting Seaside to function. However, he is confident that he will be able to fix it and publish the code soon. His primary goal with this project was to create a replacement that was small, simple and fast. And the micro-benchmarks that he had showed that it was about twice as fast.
Next, Dave Ungar presented The Birth of Manycore Squeak. Basically he demonstrated what he and Sam Adams have been working on at IBM Research: writing a new Squeak VM that could run on top of the Tilera 64 multicore chip. Right now he has hacked the VM so that it can actually run the MVC UI in Squeak. It's also able to do simple object migration from core to core. However, as he emphasized, this is still work in progress and there's lots of things to be done. In particular, it might require adding some new primitives to Smalltalk to make multicore concurrent programming easier. And it might also require changing the programming model to make it easier to program things concurrently.
And finally, Jecel Assumpcao Jr. talked about Issues in Smalltalk Hardware Design. He gave a lengthy introduction to the various attempts at creating specialized hardware to execute Smalltalk throughout the years. Most (if not all) of those projects are now dead and obsolete. However, he is interested in creating a modern implementation for Squeak. From the looks of it he already has a draft of the architecture and ISA that he is planning to support. The spec for his Squeak bytecode processor, Plurion, is available from his Siliconsqueak web page. It wasn't clear from his presentation if he intents to create a multicore bytecode processor or just a single core one.
There weren't as many people at this year's BOF as I had expected. It was cool that the Cincom guys were there this time around though.
update: The videos are now available from Goran's site.
Seaside BOF
I didn't get to take any pictures in this session because I came in late and was sitting at an awkward spot. James Robertson from Cincom was there and has posted some pictures on his blog. I am actually in one of those pictures :)
Michael Lucas-Smith did a demo of WebVelocity – Cincom's new in-your-web-browser development environment for Seaside. I missed the first 10 minutes of it but it's similar to the screencast that he had done before. WebVelocity is cool but there are two things that I really like about it.
First, it has ample documentation provided for Seaside. Besides the base library from Cincom, I think that this is one of the best documented Smalltalk project ever. Not only do they have comments for the classes and method, but they also have a nice getting started guide all built-in and easily accessible. That was really fantastic! And to make it even better, they had an integrated search widget that allowed you to search through the class names, methods names and, now, comments! Something that was missing from Smalltalk before.
Second, WebVelocity bravely goes where no Smalltalk has gone before: it lets you edit your source code inside a single window – in this case, your web browser. You can actually see all your methods in one editor without having to open multiple windows! I think this is one of the most interesting (and smart) approaches that Cincom can take to get people to use Smalltalk. I believe that they have reduced the entry barrier for Smalltalk by presenting it in a more familiar environment to newcomers. Hopefully they get some positive feedback and comments on this and use that to help them structure their tools to suit both new and veteran users.
Squeak BOF
I took the pictures using my iPhone so they are all pretty bad actually. The only way I could salvage them was by turning them into black and white pictures....
There were three presentations in this year's Squeak BOf.
First Goran presented his project on creating a a lightweight Simple-CGi replacement for Seaside development in Squeak. He calls it Blackfoot and at the time of the demo he still had some bugs in getting Seaside to function. However, he is confident that he will be able to fix it and publish the code soon. His primary goal with this project was to create a replacement that was small, simple and fast. And the micro-benchmarks that he had showed that it was about twice as fast.
Next, Dave Ungar presented The Birth of Manycore Squeak. Basically he demonstrated what he and Sam Adams have been working on at IBM Research: writing a new Squeak VM that could run on top of the Tilera 64 multicore chip. Right now he has hacked the VM so that it can actually run the MVC UI in Squeak. It's also able to do simple object migration from core to core. However, as he emphasized, this is still work in progress and there's lots of things to be done. In particular, it might require adding some new primitives to Smalltalk to make multicore concurrent programming easier. And it might also require changing the programming model to make it easier to program things concurrently.
And finally, Jecel Assumpcao Jr. talked about Issues in Smalltalk Hardware Design. He gave a lengthy introduction to the various attempts at creating specialized hardware to execute Smalltalk throughout the years. Most (if not all) of those projects are now dead and obsolete. However, he is interested in creating a modern implementation for Squeak. From the looks of it he already has a draft of the architecture and ISA that he is planning to support. The spec for his Squeak bytecode processor, Plurion, is available from his Siliconsqueak web page. It wasn't clear from his presentation if he intents to create a multicore bytecode processor or just a single core one.
There weren't as many people at this year's BOF as I had expected. It was cool that the Cincom guys were there this time around though.
update: The videos are now available from Goran's site.
The Evolution of Lisp
This year marks the 50th anniversary of Lisp. While I am not a Lisp hacker, I have dabbled with it (and lambda calculus) enough that I do take interest in things that happen in the Lisp world. There was the Lisp50@OOPSLA workshop today but I only had time to attend the first talk of the day by Guy Steele and Dick Gabriel.
Guy Steel and Dick Gabriel presented their combo-talk on The Evolution of Lisp. And like every combp-talk by Guy and Dick, it was entertaining and informative. I had never actually realized how many versions of Lisp there were until today! The slides that Guy and Dick showed contain the history of Lisp from the 1960s till now. They could even divide the different implementations geographically across the United States and showed how different version of Lisp from different states influenced one another. While the primary centers for Lips development were at MIT and Stanford, there have been many different efforts outside of those two universities as well.
The presentation must have been endearing for most of the Lisp hackers in the crowd. For me, it was also an insightful look into how one of the oldest programming languages had evolved and to see its impact on other modern programming languages.
For me, the most memorable part of the presentation was when Dick emphasized that though there were so many different versions of Lisp, each with its own little variation (making integration and code sharing hard) the explosion of those different implementations actually fueled a lot of interest and research into making better implementation for Lisp. Now that there are standards for Lisp, fewer dialects have popped up. And so by gaining standardization, you do lose out on some of the innovation because no one is interested in creating something that doesn't conform to the standards anymore. I thought that was something interesting to think about since we usually take it that standardization is always the best route. But Lisp has shown that innovation can often times blossom through many different home-brew implementations.
The Evolution of Lisp
This year marks the 50th anniversary of Lisp. While I am not a Lisp hacker, I have dabbled with it (and lambda calculus) enough that I do take interest in things that happen in the Lisp world. There was the Lisp50@OOPSLA workshop today but I only had time to attend the first talk of the day by Guy Steele and Dick Gabriel.
Guy Steel and Dick Gabriel presented their combo-talk on The Evolution of Lisp. And like every combp-talk by Guy and Dick, it was entertaining and informative. I had never actually realized how many versions of Lisp there were until today! The slides that Guy and Dick showed contain the history of Lisp from the 1960s till now. They could even divide the different implementations geographically across the United States and showed how different version of Lisp from different states influenced one another. While the primary centers for Lips development were at MIT and Stanford, there have been many different efforts outside of those two universities as well.
The presentation must have been endearing for most of the Lisp hackers in the crowd. For me, it was also an insightful look into how one of the oldest programming languages had evolved and to see its impact on other modern programming languages.
For me, the most memorable part of the presentation was when Dick emphasized that though there were so many different versions of Lisp, each with its own little variation (making integration and code sharing hard) the explosion of those different implementations actually fueled a lot of interest and research into making better implementation for Lisp. Now that there are standards for Lisp, fewer dialects have popped up. And so by gaining standardization, you do lose out on some of the innovation because no one is interested in creating something that doesn't conform to the standards anymore. I thought that was something interesting to think about since we usually take it that standardization is always the best route. But Lisp has shown that innovation can often times blossom through many different home-brew implementations.
It seems like John (in the green shirt) is about to use some of his superpowers and fly off into the screen....
Smalltalk Superpowers has to be one of the better workshops at OOPSLA that I have attended - well, I have only attended two so far so that doesn't say too much. What I liked about the workshop was the abundance of actual code (mostly short snippets) that were actually used in real systems. There wasn't the usual nonsense hand-waving; on the other hand we saw actual code that people wrote and had used. Some of the code snippets were beautiful, some were atrocious, and some were just too damn heretical that they should remain as skeletons in the closet. However, all of them had a purpose (though some were rather questionable and were just used to demonstrate the Smalltalk-hackery-kung-fu).
I was already familiar with most of the main concepts that were used but I lacked the ingenuity to use those concepts as others had done. The usual suspects include using become:, changeClassTo:, doesNotUnderstand: and the thisContext variable. So I could easily grasp the main ideas behind those superpowers even though I haven't attempted trying them for myself (I have used doesNotUnderstand and thisContext before though).
Many of the code snippet aren't actually published (for good reason too) since you really don't want to write such code. However, they are useful nonetheless for those dire situations that require a quick throw-away solution.
There were a couple of Javascript, Self and Ruby programmers in the group so we had a good mix of different superpowers. Michael Lucas-Smith made an interesting observation about the state of doing "meta-programming" in Smalltalk and how it differs from what the Ruby (and Rails) people were doing -- transient generated code where we can always return to a clean slate and remove all the generated code from the image (or program). Smalltalk doesn't really encourage such techniques (see the Dynamic Code Generation section of my article on Dwemthy's Array) and it will be nice to see what superpowers people will acquire once Smalltalk makes this easier to do. He suggested something simple like marking/annotating the code that has been generated (I just put mine in a category called generated) and being able to completely clear it when the system is saved/loaded (so it can start from a clean slate). The code should remain for some duration so that we can use the existing Smalltalk browser tools to navigate through the code for testing and debugging.
I only stayed for the morning session but I picked up enough little tricks to add to my bag of tricks. And there is enough interesting things that I should be able to play around for some time.
Goran was doing a video recording of the workshop and that should be on the web some time soon. update: The links to the torrent are already up on his site. The videos (albeit at lower quality) is also available from veoh. Thanks Goran!