Archive for the ‘Programming Language Punditry’ Category
Scala: Post-Functional, Post-Modern, or Just Perl++? March 6, 2010 | 10:30 pm

Let’s start with some background.

I complained that Scala did not seem to be very functional to me, but I didn’t really know how best to express what was fundamentally wrong with it. I did know that if “functional languages have a fixed set of features” like Scala’s creator, Odersky, claims, then it wasn’t simply “first-class functions in there, function literals, closures”, “types, generics, [and] pattern matching”. Scala has missed the functional boat in some basic way.

After a kerfuffle in the comments, Brian enlightened us all by telling us what is a functional programming language. His explanation (while being a self-admitted generalization) is summarized as follows:

So, what is it that differentiates the functional programming languages from all the other programming languages? It is simply this: the functional programming languages use, as their fundamental model of computation, the lambda calculus, while all the other programming languages use the Turing machine as their fundamental model of computation.

Six months later, Odersky responds with a very interesting post, which actually agrees that Scala is not a functional language in Brian’s sense, but instead argues that any language is functional if it “makes programming centered around functions easy and natural”. He then runs through a list of features which is in common with functional languages, noting that Scala has them within handwave enough (more on that later). He ends wishing that people would “stop thinking of functional programming as a different, novel, or exotic way to code”. Even more, though, Scala is apparently “an early example of a new breed of postfunctional languages”.

And that gets us to this blog post.

First of all, Odersky is still missing the point. It’s not about whether you use fold, map, and iter, or whether you can write closures easily. It’s not even really about pure functions vs. side-effects. To code in a functional style is a fundamentally different way of thinking about problems: instead of thinking about problems as nouns that are doing things, functional programming views a problem as a series of transformations to the world which results in an answer. This is why functional programming is considered “a different, novel, or exotic way to code”: it is a different, novel, and (as of yet) exotic way to code. It’s as different, novel, and exotic from OO as OO was from procedural. It’s a different way of thinking about the entire issue. You can check out this snippet of an IRC conversation from #ocaml for more on that.

The paragon of this way of programming is point-free programming, where you are quite literally building up a mega-function that describes how your program works, and then executing that one, single function when you run that program. If your language doesn’t lead people to re-discover point free programming at least in the small, then the language really isn’t taking function manipulation and functional language type conceptions seriously. And that’s the case with Scala: even Odersky admits that in Scala, “currying is more verbose and much less used than in other functional languages”. (Protip to Scala people: If one of the fundamental stunts of a style is pervasive in all the code but yours, you’re not in the same style of programming.)

What really gets me, though, is the claim that Scala is “an early example of a new breed of postfunctional languages”, because aside from the static typing, all the language features that Odersky trots out already exist in Perl. It’s hard to be a vanguard of a new breed of programming languages when there’s prior art from the 1980s.

Don’t believe me? The existence of a book on the topic unconvincing? Then let’s run the list of functional language features from Odersky.

  • Functions as first class values: check.
    sub apply(&$) {  # Take a function as an argument no problem
      $_[0]->($_[1]);
    }
     
    sub times2($) {  # Create a function to take
      print $_[0]*2 . "n";
    }
     
    apply(&times2, 3);
  • Convenient closure syntax: check
    my $x = 2;
    apply { print $_[0]*$x . "n" } 3;
     
    my $times_x = sub($) {
      print $_[0]*$x . "n";
    };
    $times_x->(3);
  • List comprehensions: check. (See perlfunc on list data.)
  • “Curried” function definitions and applications: check-ish.
    Okay, so calling this a “check” on Scala is a bit of a reach (cite, cite, cite, although note thishere is a more sympathetic run-down on Scala currying). Ignoring the foo(2,_:Int) syntax for a moment, we can implement basically the same style of “‘curried’ function definitions” such as Scala’s List#foldLeft.

    sub add {
      my $x = shift;
      return sub { $x + shift };
    }
    add(2)->(3);  # Okay, so you do need an extra ->

    In the case of our apply function above (where we take a function as the first argument), it’s even easier.

    apply { print $_[0]*$x . "n" } 8;

    Now, there isn’t really argument skipping (i.e.: foo(_:Int,3)) as a syntax feature, and there isn’t a built-in curry function, but if you want Scala’s Function.curried in perl, here it is:

    # This code released under Creative Commons 0 and WTFPL.
    sub curry(&@) {
      my($f,@args) = @_; 
      return sub { $f->(@args, @_); };
    }
     
    sub add($$) {
      return $_[0] + $_[1];
    }
     
    my $curried = curry(&add, 2); 
    print $curried->(3) . "n";
  • Lazy evaluation: check. See Scalar::Defer for lazy val equivalents and Tie::LazyList for lazy seq equivalents. People generally use a double-return approach for generators (which I realize are different than lazy seqs and only kinda-sorta lazy).
  • Pattern matching: check (okay, check-ish). See Switch. The decomposition isn’t there, which is the biggest weakness. But the general cumbersomeness and lack of real algebraic data types hamstrings the coolest parts of pattern matching anyway, so I’m calling it a draw. (This should be read as a generous and sympathetic ruling for Scala: Cedric Beust, for instance, rails against pattern matching/case classes and says “it’s hard for me to see case classes as anything but a failure“.)

In addition, perl’s got a few features in its favor for functional programming, like more flexible arguments, autovificiation, list/argument coercion, and dynamic symbol table mangling. Since perl also has OO capabilities, perl is at least as convincing a “post-functional language” as Scala. But there’s even more in common between the two than that.

Odersky’s “post-functional language” is really a subtype of Larry Wall’s “post-modern language”: it’s an attempt to create a language that is a grab-bag of multiple paradigms. And when you do that, you’re just begging for the complaints that you hear leveled against both perl and Scala: it’s too complicated, its syntax is weird, it’s too magical, people write in entirely distinct subsets of the language, etc. (cite, cite, cite) Now, those who master the language (or master their favorite subset of it) love the TIMTOWTDI aspect. But it also means that the language is left as a jack-of-all-trades, master of none. Yes, Scala and perl integrate a lot of powerful tools from functional languages—but learning OCaml still blew my mind, despite knowing perl for years. As I started off saying, Scala is not a functional programming language. It is a statically typed object oriented language with closures.

Now, there is a sense in which Odersky is really onto something. The world of programming is forever transformed with closures and list comprehensions as being mandatory for new high-level languages, even if they’re otherwise object oriented. And software developers are going to need how to work with them effectively if they want to read code moving forward. Yes, after 20+ years, the rest of the programming world finally caught up to one of perl’s fundamental insights.

My question on Go November 22, 2009 | 11:27 pm

So, Google has released a new programming language, which turns out to be a slightly cleaned up version of Algol-68. While depressing, this doesn’t come as a large shock to me- if your prime requirement for a new language is that it doesn’t force you to learn something new, as it seems to be for most programmers, than the ability of the industry as a whole to move forward is limited at best. Radical advances require radical changes.

I’ve taken a couple of swings at writing about Go before this, but nothing stuck. Most everything I had to say I’ve said before, and when even I am bored with my ranting, it’s time to change the subject or shut up. But I’m left with one outstanding question I’d like an answer to, before I move to blissfully ignoring Go:

Why is it that still, today, it’s considered an advantage if not a requirement for a new language to be capable of writing an operating system?

Read the rest of this entry

New PeriodicalUpdater Feature, and, Mutable Data Sucks: A Case in Point November 6, 2009 | 01:47 pm

The jQuery PeriodicalUpdater, which has been getting lots of love because of feedback and support over here, has a new feature. The “data” configuration argument now will work properly with numbers and anonymous functions. This means that you can have your periodical updater send different information across in different runs.

I’ve said before that null sucks, but now I’ve got a case in point for why mutable data sucks, too.

One of the things that made this somewhat tricky was the fact that jQuery modified the configuration arguments passed in. The configuration arguments are just a map, and jQuery uses that map’s entries as scratch space for its calculations. This is really a problem if you want to use the map over and over again (as the PeriodicalUpdater wants to), because it means that the previous version of the data is ruined. (More description of the probem in this comment). The result was that I had to clone the arguments that I passed in so that I could reuse the arguments next time!

Note that there’s no documentation about this happening—in fact, it’s purely an implementation detail. But it’s an implementation detail which leaked out and caused bugs. I think there’s a real point to Clojure’s seemingly neurotic tie to immutability. It prevents a lot of problems like this.

null Sucks: A Case in Point October 17, 2009 | 02:30 pm

Take a look at this API: ClassNode#addProperty. Turns out that if you pass null into getterBlock and setterBlock, you get the default implementations. Maybe1. Normally passing null around blows up in unhelpful ways, but here null is a useful value. How is a programmer to know?

I’m increasingly convinced that immutability2 and strong type systems in languages aren’t just about concurrency or letting the computer optimize or catching bad code early. Increasingly, I’m convinced that the key value they provide is clear, meaningful, and maintainable code. Which is really the key problem in software development these days, isn’t it?

1 As of this writing, it’s an outstanding question if the compile phase of the AST transformation impacts whether or not the null values are translated: mailing list conversation.
2 See this nice presentation from Rich Hickey, author of Clojure.

1024 by 2012! September 14, 2009 | 09:43 pm

This will be a short blog post, but I just wanted to point out this article from El Reg on the future roadmap of the Sparc CPU. Especially check out the graphic associated with that article.

Here we have Sun/Oracle’s roadmap for the Sparc processor- and we see that by 2012, Cascade Falls will have 8 sockets, each socket having 16 cores, each core running 8 threads in parallel. Kittens, cats, sacks, wives, that’s 1024 threads going to St. Ives. Of course, this is less impressive when you consider that the Niagra Falls line already has 256 threads, and the changes are just 2x the number of cores per chip (or one generation of Moore’s law, if you care to look at it that way), and 2x the number of sockets supported.

And it’s not just Sun that’s in this market- Intel is there as well, with the Larrabee Processor. They’re using the P54C as the basis for the CPU, which is superscalar (pipelined) but doesn’t do out of order execution (sound familiar yet?). Each chip will house 32 of these P54C cores, and each core will have 4 threads executing on it. That’s the same number of threads per chip (128) as Sun’s Cascade Falls chip. Put 8 of them in a server, and you’ve got yourself 1024 threads again.

Massive parallelism is coming.

Read the rest of this entry

We Aren’t Too Stupid for Polyglot Programming August 7, 2009 | 09:00 am

As those who listened to my WebDev Radio interview know, I am working on a book on polyglot programming. This has me asking smart people what they think about polyglot programming, and one of the most surprising pieces of feedback I’ve gotten (from Grails podcast, among others) is that polyglot programming is somehow “too hard”: that developers aren’t smart enough to handle it. This strikes me as an odd complaint.Bible Polyglot

Polyglot programming, defined most simply, is the use of multiple languages in software development. Although Neal Ford claims to have “accidentally coined” the term, the term predates Neal Ford’s Dec 2006 blog entry: for evidence, see a 2002 Dr. Dobbs article on .Net polyglotism, and a 2004 DARPA presentation on the Babel polyglot support system, which has whitepapers dating back to 1998. So the term itself has been around for a while.

The idea that underlies the term has been around in some form or another since C became the Universal Assembly Language: interoperability with C has always been critical for projects like mod_* (perl, php, rails, caml), which bring non-C code into the Apache web server. Now we’re rediscovering interoperability by having languages interoperate on the JVM. This opens up a new freedom to pick the right language to solve the problem at hand for Java development.

The reality, though, is that we all do polyglot programming all the time. Read the rest of this entry

What is a functional programming language? July 23, 2009 | 09:58 am

Today, I want to talk about a topic I’ve been meaning to drag up for a while. A couple of weeks ago, Robert started a kerfluffle by stating that Scala was not a functional programming language. One of the things that became clear in the responses was that many people who were debating whether a given language X was or was not a functional programming language didn’t have a good idea of what a functional programming language was. The situation was made worse, I think, by the fact that many of the key terms in the programming industry do not come with rigorous definitions, and thus tend to shade into buzzwords at the edges. This is not the case with functional- there is a very rigorous definition of what is meant by “functional”, and I’d like to introduce people to it.

Read the rest of this entry

Geek Baiting for Fun and Profit July 22, 2009 | 08:00 am

Curious to hear people’s thoughts on this assertion:

SOAP is an internal DSL of XML.

According to my favorite DSL check-list, it’s not a DSL. That matches with my gut, yet I’m having trouble coming up with a real justification for why not.

Scala is Not a Functional Programming Language May 14, 2009 | 06:19 pm

Having now worked a fair amount with Scala, I can now unequivocally make this assertion:

Scala is not a functional programming language. It is a statically typed object oriented language with closures.

So, I’d appreciate it if people would stop the bogus sales pitch. Read the rest of this entry

What killed Lisp could kill Haskell as well. May 9, 2009 | 07:25 pm

This blog post is mainly aimed at the functional programmer readership of this blog. There is a video out there on the web from a recent conference that brings up a number of good points, that I think needs to be more widely disseminated in the functional community.

Now, before I link to the video and have you go watch it, I need to do a little bit of explaining. Because, you see, the conference was RailsConf. And the presenter doesn’t even mention functional programming, and his discussion, well, mention really, of static typing encompasses Java, C#, and C++, and that’s it. In fact, the original title is “What killed Smalltalk could kill Ruby as well”. But as you listen to the video, I want you to do the following: when he says “Smalltalk”, think “Lisp”. When he says “Ruby”, think “Haskell”. And when he says “Test Driven Development/Design”, think “Static Typing”. Some of the details don’t map perfectly, but his main points are, I think spot on.

So, with that in mind, go watch.

That is all.