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.
Wow, people who are into these dyinamc languages are really religious about it.I keep looking at these other languages and have yet to find a single area that makes it worth while to switch.Of course I’m a pretty fast typist. If it took me significantly longer to type int i than i I might reconsider.I suppose that’s a little rude. I have been at this programming stuff for a while now and I’ve come to really enjoy understanding the language I’m working in.When I’m working in a new language, I find that the less restrictive language lets me get going quicker. I don’t have to worry about getting certain details right.For instance, when I was starting at Java, I had a lot of trouble remembering how to write inner classes and even catch certain exceptions. The syntax changes a little in those places and makes me learn a little more.I suppose if I were jumping into a new language and had to deal with Java or something I could just dive into, I’d prefer the quicker language.But that’s not the case, I can code java in Notepad almost as well as an IDE except for large refactorings so I guess that’s why I don’t see an advantage to the easier languages.There are Hard parts to programming:unclear documentation: Not knowing what a specific method call will do or not knowing that there is a secret order that methods or functions must be called in Not knowing what calls effect other calls (a common consequence of shared/global variables)Confusing rules: a language should consist of the simplest set of rules possible that gets the job done every new pattern you add is simply something else to remember (damn java typesafe collections). Tricks : Any pattern that is used rarely and not required is a trick. It may be more fun to use, but that makes it even worse it means that someone reading your code might not get it and chances are when you are reading it a year later you’re going to have to puzzle over it for a few minutes. (When this happens, you generally notice that it could have been done MUCH more clearly with no penalty whatsoever if you hadn’t been so enamoured of the trick ).repeating yourself: Horrible. This is one area where Java lacks, but not by much. I’ve seen lots of people choose to repeat themselves and I’ve always been able to go in and refactor the repetitions into a single block of code and some data.Java is actually a serious offender in this area when it comes to anonymous inner classes those things are terrible.Of course more often than not, that’s the wrong structure to be using, you should be creating a separate class, but in cases where what you really want is an anonymous inner class, java’s syntax is awkward, ugly, unreadable and hard to remember.Notice that being verbose and explicit are not problems for larger development teams They are actually huge advantages. If you are explicit it means that people will make less mistakes and have to guess less. If they are a little more verbose it means that your code will be more readable.And by the way, if you are one of the many people posting here that think that Cedric was wrong about refactoring dyinamc languages, you completely missed the point. It’s not that you couldn’t get most of it, or you couldn’t blindly refactor all methods, it’s the fact that you CANNOT for CERTIAN identify EXACTLY every method that might have to be changed.If you are saying java isn’t much better you don’t get it even more. Java is deterministic you know for absolute certain which methods extend/will be replaced by what. This is deliberate. This is a huge advantage. A great thing. Java deliberately doesn’t let you override arbitrary methods from arbitrary classes without knowing SOMETHING about the class you are overriding. that would be ridiculous for certain development projects perhaps most but not all, for sure.I suppose my conclusion would be that if you really don’t want to understand your language, don’t want to/aren’t good at Design or if you just want to throw something together and make it work, you’re great with a dyinamc language, but don’t assume that makes it a great professional team language for huge projects. Issues like Refactoring grow exponentially with project size.
Comment by Dinesh — 2012/12/26 @ 21:52