Sunday, January 28, 2007

Functional vs OO languages

Passing judgement on this kind of thing is a bit out of my scope, but I was wound up enough by one of the invited talks at POPL to put my opinion to paper (as it were). First of all, there are a few issues, first is imperative vs functional (ie state-less) programming and the other is abstraction using objects (usually classes) vs abstraction using functions (and, in particular, higher order functions). As the two are usually lumped together so will I, as I'm not so much expressing an opinion as expressing my disgust at other peoples'.

So, I have a problem with the "functional languages are better" opinion that seems to be going around a large part of the programming languages community at the moment. First off, we are all engineers to some degree and should realise there is no such thing as 'better' and especially not 'best'. Functional may be better sometimes and imperative at others. Secondly, I know functional languages are easier to reason about for theorists, easy to optimise, easier to parallelise and generally easier to work with (for theorists); BUT, that doesn't mean they are better for programmers (they might be, but there is no logical implication here). Third: there was a big theme at POPL this year to listen to the software engineers, which is for sure a good idea; however, most software engineers want OO languages, not functional ones, because they believe they scale better to large projects. Maybe they are wrong, but it seems odd to want to listen to them, but then ignore this rather large point. Lastly, my personal opinion is that the better language in a given situation is the one that better matches the underlying physical situation. For things like image processing this may well be a functional model. However, we live in a stateful world and most things in it have state (including programmer's brains), it therefore seems like avoinding state in many programming situations increases the mismatch between the physical and abstract models and thus makes the programs harder to write and understand.

On a side note, Chet Murphy's talk at POPL inspired this overlong rant, and it was kind of inspiring; he certainly had good results and it was a novel and practical use for more hi-tec languages. BUT, it wound me up for a few reasons: it had a hint of preaching to the choir about it; I didn't like the blanket statement (unbacked up) that functional languages are better (which set off the above rant); I didn't agree that functional interefaces to a module imply that the module can naturally be written better in a functional way (there may be internal state that is hard to get rid of, further more at the largest level of abstraction, everything has a functional interface, but not all programs can be happily rewritten in a functional language); the result seemed to be that a mess of a program in one language ran like a dog, when rewritten nicely in another language it ran much faster. This seems to miss the point that the rewriting itself (no matter which language was used) would probably result in improved efficency. Basically, a lot of what he said may be both true and impressive, but the implications he drew didn't seem to be warranted.

Thursday, January 25, 2007

Arrays considered harmful

I've come to the conclusion that arrays are bad. They really have no place in a modern programming language and should go the way of the pointer: being considered an implementation detail.

The reason is that lists are just simply better: they are more flexible, allow for a wider variety of implementaion, give the compiler more room to optimise, are easier to type (this is probably the best reason here, consider the grief Java arrays cause to the type system), integrate nicely into an object-oriented model, etc, etc. All that is needed is some syntactic support so they are as easy to use as arrays and allow the compiler to optimise lists to arrays as it sees fit (as far as I'm aware this is fairly easy to do). Of course we can still let systems programmers have arrays just as they have pointers, but 99% of programmers should never use them.

I hope to never have to deal with arrays again (not that I do already), and never have to answer questions about how such and such a feature will work with arrays. If I can type generic collections that should be enough.

Wednesday, January 24, 2007


I was privileged to attend the POPL conference in Nice last week, followed by the FOOL/WOOD workshop on the saturday. I had a great time (especially enjoying the sunny weather, I managed to fall asleep in the sun on the beach at one point), it was my first 'proper' conference experience and once I got into the swing of things a bit, I really enjoyed talking to lots of interesting and reputable people and soaking up all the brain waves floating around.

Most of the talks were excellent and very interesting, even in topics from which I normally run away from screaming. A lot of the subject matter at POPL was a out of my usual scope and went a bit over my head, and that I was still interested in the talks is a real credit to the presenters. FOOL on the other hand was so spot on, topic wise, that I was pretty much in research heaven. Almost every talk was relevant, interesting and well-presented.

I'll go over some of the talks/papers that interested me below. Links to the papers can be found here or here.


  • Invited talk: Advanced Programming Language Design in Enterprise Software: A lambda-calculus theorist wanders into a datacenter

    I thought this was going to be inspiring, but actually it was a bit disappointing. In the end it just made me angry and I'll have a rant on the functional vs imperative (OO, more to the point) thing in another post.

  • Operational Semantics for Multi-Language Programming

    An interesting (and necessary) idea is how to integrate type systems between programming languages or calculi. This seems like the first paper in a series building up to do this properly, but even so, it is well developed and a good solution to this problem.

  • Semantics of Static Pointcuts in AspectJ

    Although I loathe aspects from a software engineering prespective, they seem to be fairly hot right now, and they do allow for some nice programming techniques. This is a formalism of the pointcut language of AspectJ as does just what it says on the tin. The use of Datalog as an 'intermediate language' adds a bit of spice to the mixture. I admit to being surprised that somthing like this has not been before.

  • A typed Intermediate Language for Compiling Multiple Inheritance

    Again, I'm surprised this hasn't been done before, and, in a way, I wasn't sure why this was so important. But, I think to compiler people it is quite cool. Anyway, I really liked the talk and hope one day to be able to understand the paper as it sounded interesting.

  • Cork: Dynamic Memory Leak Detection for Garbage-Collected Languages

    Very cool use of profiling/dynamic analysis of programs. I liked the talk because dynamic analysis is something I've not really come across before and profiling and instrumentation stuff has always interested me. I will go back and try to understand the theory in detail, but the intuitive stuff was quite exciting.

  • Scrap Your Boilerplate with Xpath-like Combinators

    This really got me thinking. XSLT and Xpath are pretty intersting subjects and there has to be a better way to deal with these and XML in programming languages (in fact its getting a lot of attention at the moment). Other than the motivation the talk and paper were pretty heavy going (at least with my lack of knowledge about FPLs), but I'll definitly be reading the paper in some detail.

  • Towards a Mechanized Metatheory of Standard ML

    A 'rather than you than me' bit of research this. It is important and necessarywork, but it looks like really dull stuff to actually do! The talk, though, was far from dull.

  • Extracting Queries by Static Analysis of Transparent Persistence

    Another interesting paper on integrating queries/databases with programming languages, a bit of a hot topic at the moment, me thinks. The idea here is to use transparent persistence, but extract queries during compilation for the sake of efficency. It sounded like a really good idea and the details seem interesting. Another talk, that 'sucked me in'.

  • Assessing Security Threats of Looping Constructs

    I enjoyed this talk as the subject matter was interesting from a non-academic perspective. I always find information theory-style stuff quite cool, I don;t really know well. The talk was really well presented too.

  • Javascript Instrumentation for Browser Security

    Again, an interesting talk due to the subject matter, browser security being relavent to pretty much everyone. The scheme presented here seemed solid and straightforward (in a good way). The complications due to the nature of Javascript were well explained and solutions presented. I was not completely convinced that it dealt with 100% of cases correctly, in the question and answers there seemed a degree of reliance on conservatism and the fact that no legitimate program would use techniques that appeared to be obfuscation. Still, I should read the paper more thoroughly before passing judgement.


  • Generic Universe Types

    Werner gave a really good talk, reminding me that ownership is awsome, and convincing me that universe types are a pretty good idea. The contribution itself (extending universe types to type parameters) seems very nice: a slight extension to generics and universes that produces an elegant system and some real benefits for the programmer.

  • Fine-Grained Api Evolution for Method Deprecation and Anti-Deprecation

    This seemed like one of those really useful things that people have been struggling with for a long time. This solution sounds like a good one, although interface evolution seems to be one of those problems that will never be properly solved. Its part of the Scala project so should get some real world testing, I'll be interested to see how it performs in practice. The talk itself was good, and got me interested in something I'd normally just skip over.

  • Invited talk: Fortress and Object-Oriented Programming

    It was good to hear about Fortress without all the parallelism stuff that (although important) I'm not really intersted in. The syntax thing wasn't too over-played for a change either. Instead Eric focussed on the object model and related elements. The talk was good and it was nice to see some large scale, real world, innovative language design in action (I've been following Fortress for a while now). Fortress has some interesting ideas in the object model, an (almost) class-less system with traits for reuse and some practical
    looking details. Its looking like a fairly innovative and practical system, although not as radical as it sounded at first.

  • Variant Path Types for Scalable Extensibility

    A topic close to my heart, being related to virtual classes and similar mechanisms. The authors have an approach that has classes belonging to classes as opposed to classes belonging to objects (as in Tribe and VC etc.). This approach is attractive because it is simple and does not require a dependent type system, but the loss of flexibilty and expressiveness is considerable. They go someway to addressing that with this paper, the system vastly increases the flexibilty with a simple and low overhead type system (an extension of exact types). It is impressive work, but I can't help thinking that when they work this to its logical conclusion they'll end up with something very similer to the Tribe/VC model....

  • On Decidability of Nominal Subtyping with Variance

    Interesting stuff again, and closely related to my work on wildcards. Andrew Kennedy gave a really good talk on decidabilty for simpler variance systems; starting off with examples that crashed the Java and Scala compilers (good for getting your attention!). The result seemed to be that these systems (pretty much what C# and Scala have) are theoretically undecidable, but are saved by unintentional tweaks in the specifications. How this crosses over to Java remains to be seen.

  • Formalizing and Extending C# Type Inference

    Probably the best talk of the conference, Gavin Bierman had amazing energy and presentation skills. The talk basically went over his exprience in writing a type inference algorithm for C# 3.0, which to be honest sounded like a nightmare. The reasons for the complications were not obvious and it was interesting subject matter. The future work also sounds tricky...

  • Combining Structural Subtyping and External Dispatch

    This is an idea for combining structural and nominal subtyping. The motivation was good and it looks like an interesting concept, I'd be interested to see how it works out in practice (or at least a more fleshed out theory). Although the syntax looks quite similar to standard OO languages, I think the truth is that there is a big difference arising from the typing that would affect how programs are written etc. I'll be going back and reading the paper in
    detail soon.

  • LazyJ: Seamless Lazy Evaluation in Java

    Not coming from a functional background, I don't really know if lazy evaluation is a good idea for OO languages or practical programming. But, it is an interesting concept, and if it were to be a good idea then this is how it should be done! The language was simple and yet seemed to do everything it needed to; the extensions fitted nicely into Java and the details had been thought through (even though there were a lot of ideas from the audience).

Looking forward to next year already...