Scala: Post-Functional, Post-Modern, or Just Perl++?

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 this—here 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.

Comments

• March 7, 2010, Barry Kelly wrote: Functional programming optimizes for different things than OO does. That means for different problems, you want to take different approaches, depending on your level of familiarity with the problem domain and the solution strategies. And thus for a language that supports both paradigms, different people will often end up using different subsets of the language. But I don't think this is necessarily a damning criticism. Our problems are bigger and more compositional. We need languages that have the semantic richness to support different solution strategies. An example. There's an isomorphism between OO polymorphism / dynamic dispatch, and algebraic data types / pattern matching and destructuring. OO lets you add subclasses as late as dynamically at runtime. ADT lets you add functions freely, and such functions are more composable that they're dealing with well-defined quantities. More generally, OO is about defining loosely bound protocols, while FP is more about flexibly defining transformations over tightly defined structures. But if you want to write a solution that's natural for one paradigm in the other, you end up re-inventing and poorly reinventing the other paradigm. In a comment somewhere else out in the ether, I made an argument that getting FP to work as well as a dynamically typed late bound language like Ruby for fast-iterating web solutions that join together multiple independently developed and fast-iterating modules, you'd end up writing what amounted to a dynamic language just to avoid the brittleness that comes from the over-specification that naturally falls out of static typing. I will agree that e.g. currying is useful, as it decomposes the concept of functions of arbitrary arity into what amounts to a linked list of unary functions; and this is particularly handy for programming in a point-free style. But point-free mostly helps (I would assert) on problems where what you need to do is create an algorithm, where little helpers like fold, map, memoize etc. are your bread and butter. But not all problems are like that, not by a long shot.
• March 7, 2010, Ittay wrote: "because aside from the static typing, all the language features that Odersky trots out already exist in Perl" That is a big 'aside'. You also forgot that Scala runs on the JVM and Perl not. Not to mention that I think it is common consensus that Perl code is very unreadable. So Scala is a language that combines some FP characteristics with OO, running on the JVM and with a readable (and scalable) syntax. That's a big win for me.
• March 7, 2010, Robert Fischer wrote: I will freely grant that there's a lot to be gained by having some flexibility, but languages that end up trying to play in multiple sandboxes end up either doing one part badly (e.g. OCaml and OO, Scala and functional). The answer seems to be using multiple languages for different contexts, not trying to create the One True Language with all the features of the world in it. That's why when I encounter a programming problem, I will generally reach for perl, Groovy, or OCaml/F#: which one I go for depends on the nature of the problem. But I don't long for a day when there's a language that has all the features of perl, Groovy, and OCaml, because they're fundamentally incompatible takes on the process of programming. The strongly opinionated natures of these languages is precisely what makes them so good. Scala's lack of strong opinions is what's frustrating me. Well, that and having to explain to Java devs over and over again at No Fluff events that learning Scala does not mean learning to program in a functional style. I mean, you can code Scala in a functional style, but I can code Java in a functional style. And yes, it's a bit easier to code in a functional style in Scala, but learning Scala is no more learning functional programming than learning perl is learning functional programming.
• March 7, 2010, Robert Fischer wrote: The "readable (and scalable) syntax" bit is a big assumption—at least to my ear, there's as much concern about the readability of Scala code as there is about perl code. And how much Scala's static typing really helps vs. how much it gets in the way is a matter of contention. But both of those are an aside. The purpose of this post was not to say that people should stop coding Scala and start coding perl: if you're still futzing around in Java-land, Scala (like Groovy and JRuby) is a productivity huge win that can leverage your existing infrastructure. Groovy's probably the semantically closest, JRuby's the conceptually cleanest, and Scala keeps the fetishized complexity and the BDSM aspects of Java. No, this wasn't a call to go back to perl. The purpose of this post is to show that the idea of merging closures with imperative isn't a new idea, and that Scala is no more a functional language than those languages (like perl) which merged the concepts beforehand.
• March 7, 2010, Richard Vowles wrote: I've been saying this for 6 months at least now - Scala and Perl have way more in common than Scala has in common with any other language. Including a tendency towards unreadability.
• March 7, 2010, Marc wrote: "It’s as different, novel, and exotic from OO as OO was from imperative." OO is as imperative, if not more so, than C. I assume you meant procedural? Also, there is nothing new in programming languages, period. Everything you see in "new" languages was figured out at least 20 years ago. So, all language designers are just mixing and matching as they see fit. So it's unfair to single out Scala in this regard. While you're at it, go after Groovy, Clojure, Boo, F#, etc.
• March 7, 2010, Nick Bauman wrote: I find the description "combines some FP characteristics with OO" problematic when discussing hybrid Functional / OO languages. The more I use one of my favorites of these languages, Python, the more I find the OO aspects receding into the background and the functional ones coming to the fore. It seems to me that Functional is OO "done right" where when I do use OO in them, it's not as heavyweight and seems more natural. I think the key is that in most traditional OO languages the concept of what a type is tends to be much narrower. Can you confirm this in your experience?
• March 7, 2010, Thomas Heywood wrote: Robert, I admire your ability to "professionally blog." You delivered no useful content, but you did it with inspiring attention to page hits and comment controversy. Yes, Scala is a multiparadigm language. Yes, Perl is one too. Yes, they both share features from Common Lisp. That's not really worth my or your time. But you cleverly used the confrontational tone to make the blatant non-issue into a controversial issue. You cleverly used Blogosphere's beloved "Scala" and "Perl" tags in a single article. You nagged about a minor syntax issue like it was life-or-death as only a true master-of-functional-programming-who-blogs-more-than-he-actually-programs can. Bob, you're my hero - a true Dilbert's Wally in flesh. A guy without any real code to show - but who "realigns the tone of existing projects" and whose "technical leadership focuses on pragmatic communication" like there's no tomorrow. Wally - sorry, Robert - do you think you could write some posts on how to professionally sell bull and call it "technical accomplishments?" Many of us CompSci majors would like to get in on this money for nothing scheme. Unless, of course, you're not comfortable writing about things you actually do know a little about.
• March 7, 2010, Nilanjan Raychaudhuri wrote: Well I believe it is possible to write unreadable code in any language and I am not sure blaming any programming language for that is a good idea.
• March 7, 2010, Daniel Spiewak wrote: Throwing out static typing fundamentally changes what Scala has to offer. In a sense, I agree with you that if we completely threw out Scala's type system (and all that it entails), then we would end up with a language which improves very little (if at all) over languages like Perl or Ruby. However, that first step is a doozy and not really fair. Consider a snippet like this:

  "123".to[Int] // => 123
  ".+".to[Regexp] // => /.+/
  true.to[Regexp] // compile error!

  There's a lot of magic going on here, all of which is made possible by the static type system. In fact, while this sort of thing is *possible* in a dynamic language with open classes (like Ruby), the implementation will be ugly, unscoped, brittle and difficult to extend. In Scala, the implementation looks something like this:

  trait Converter[-A, +B] { def apply(a: A): B
  } implicit object StringToInt extends Converter[String, Int] { def apply(str: String) = str.toInt
  } implicit object StringToRegexp extends Converter[String, Regexp] { def apply(str: String) = Regexp(str)
  } implicit def toSyntax[A](a: A)= new { def to[B](implicit conv: Converter[A, B]) = conv(a)
  }

  This is taking advantage of a feature which Scala inherits from Haskell called typeclasses. This is an feature which is inherently tied to static typing and is often very difficult to emulate in dynamic, so-called "more flexible" languages. The real magic of this is two-fold. First, it's scoped, and so we actually have to import these members before they start messing with our objects. It's hard to over-state how important this is to keeping such extensions from devolving into intractable monkey-patching. Second, it's extremely extensible. What if we want to add another conversion from Foo to Bar? Just define it ourselves as an implicit value in scope! Or, if we don't want the implicit syntax, we can always specify the conversion explicitly:

  // off in *our* code, separate from the converter lib
  implicit object StringToBool extends Converter[String, Boolean] { def apply(str: String) = str.toBoolean
  } "true".to[Boolean] // => true
  "false".to(StringToBool) // => false

  I'm not even going to try to imagine how to do this sort of thing in Perl. Even in Ruby, which usually makes monkey-patching quite simple, the implementation still ends up extremely nasty:

  class Object def to(target) case target when :fixnum if self.class == String self.to_i else raise "Unknown conversion: String -> :fixnum" end # ... end end
  end

  ...and, you get the picture. You could probably do this in a nicer way, but it would still end up being fragile, unscoped and virtually impossible to extend. This is what you're throwing away when you discard the type system, not some unreliable correctness "guarantee". And if I can throw together an example like this in a blog comment in just a few lines of Scala, imagine what can be done in a non-trivial system with real requirements. The type system is an intrinsic part of Scala's power and expresivity. Remove it and you're not even looking at the same language.
• March 7, 2010, Daniel Spiewak wrote: While currying and point-free aren't as syntactically clean as they could be in Scala, they are certainly still used (I use those features all the time). Does this make Scala less "functional" than Haskell or ML? Yeah, probably (I've made that argument in the past). Does it mean that Scala is no more functional than Perl? Absolutely not. Theoretically speaking, currying is possible in any language which supports closures (alblue, if you're reading, yes I do mean "closure" and not "lambda"). You can even define a curry function in C++, though the obfuscated template mess it entails makes it nigh unreadable. Lambdas ("closures" if you will) and function values do not a functional language make. C has function values, and I don't think anyone who understands the debate will argue that it is "functional". Ruby has function values and lambdas, but they are fundamentally different constructs and produce different values (just like in Perl). Again, not a functional language (though you can use many patterns which find their roots in FP, like map and fold). My point is this: you can't go out of your way to link FP to point-free and lambda calculus and then turn right around and claim that Perl and Scala are in the same league. Scala's unified functions and function values alone should be sufficient to overturn that one.
• March 7, 2010, Robert Fischer wrote: Yes, I meant procedural.
• March 7, 2010, Martin wrote: You really can't claim "perl has had _____ since the 80's" and then point to books about Perl 5. Perl 25 years ago is *very* different than it is now. Your point that Scala and perl are similar is well taken, but I'm not totally clear why this is bad for Scala or Perl. The way Perl 6 is going towards a virtual machine, I wouldn't be surprised to see Perl and Scala and Java running together on a JVM sometime soon.
• March 7, 2010, Robert Fischer wrote: I'm not saying it's bad for either Scala or perl to be similar to each other — on the point of similarity, I'm simply saying that in the ways Odersky argues Scala is "functional", perl is just as functional, and so I'm still unconvinced that Scala deserves to be called a "functional language". You don't hear people listing off the functional languages like: "Haskell, OCaml, perl, Lisp...". So to hear people say "Haskell, OCaml, Scala, Clojure" just gets my goat. I'm also saying that on the point of similarity, it shouldn't be a surprise that we're getting similar unreadability/complexity complaints about Scala as we got about perl, since they are so similar. I heard something about perl getting onto the JVM for AppEngine, but can't find additional info on it.
• March 7, 2010, Robert Fischer wrote: In what ways do Scala's unififed functions and function values outperform perl?
• March 7, 2010, Robert Fischer wrote: Note the point I'm arguing: I'm arguing that Scala is no more a functional language than perl is. Functional languages can be dynamic (e.g. Clojure), so static vs. dynamic typing is irrelevant to the point I'm trying to make.
• March 7, 2010, Robert Fischer wrote: You've earned a special spot in my heart: this is my new favorite flame of all time. I mean, the fact that you say I don't have "any real code to show" just goes to show that you're not paying attention, because you've somehow managed to miss my long trail of open source projects. And you kinda missed the boat on the entire fundamental question: "Is Scala a functional programming language?" But still, the Dilbert references, the accidentally-on-purpose "slip of the keyboard", and the general long-suffering tone is really nicely done. A+
• March 7, 2010, Robert Fischer wrote: Oh, and you're fair on the dating thing. It's hyperbolic to conflate Perl 1 with Perl 5, although I honestly have no idea how far back I can go in perl and still have my code samples work. If you find out, let me know.
• March 7, 2010, Robert Fischer wrote: Brian Hurt, the co-blogger here on EnfranchisedMind, is theoretically working on a post about how OO is fundamentally broken. I'll leave that to him. My experience has been that many of the Gang of Four design patterns just aren't relevant anymore, and inheritance is something I'm extremely reluctant to use and much more aware of its difficulties. I'm not sure exactly what it would mean to say that "the concept of what a type is tends to be much narrower", but I certainly have a much thinner type hierarchies in the world of functional programming.
• March 7, 2010, Robert Fischer wrote: Oh, not to mention the cite of enterprise-ese from SmokejumperIT.com. I mean, that's some real attention to detail for the zingers. In all seriousness, this is my favorite flame of me of all time. Thanks!
• March 7, 2010, Dave wrote: FWIW, I really dug this post. As to the topic at hand, I'm not even sure what point there is to saying Scala is or isn't "functional". The only real purpose seems to be to make it easy to show how awesome Haskell is by point out Scala's perceived shortcomings as a functional language. For my money, Scala is simply "Java: The Next Generation". A general-purpose, statically-typed, object-oriented language that has broad applicability to many problem domains. Arguing "what is functional" might be a fun exercise, but it's not really going to lead us anywhere; look at most n-tier Java applications: to say they are object oriented would be a vast overstatement. Java is object-oriented in that it's main means of organizing code are around classes and objects (which is exactly the same as in Scala), but most systems still end up using OO only when it helps, and throwing it for imperative/procedural stuff when it makes sense to do so. I would be willing to bet that Scala will be much the same way; the code inside our classes might be much more functional (simply because its' simply worth-it to do in Scala, whereas it's not terribly so in Java), but I don't see it ushering in some functional utopia (LISP has had, oh, I don't know, the entire history of the field of computer science to usher this in and largely failed [no offense to LISP]). Scala is an escape route from Java's cruftiness without having to bend your mind or prejudices too much. Much as Java was to C++.
• March 7, 2010, Tracy Harms wrote: The most interesting sentence in your post, to me, was this: 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. This has me wondering, though, about your agreement with Brian that the key quality is reliance on lambda calculus as the model of computation. Not that I'm convinced we need a "key quality." It just looks to me that the range of languages you have in mind would not be identified through this criterion.
• March 8, 2010, joe poki wrote: what's up with these groovy people nowadays? groovy++ is 10 trillion times faster than scala actors, now this piece. your rant could be summarized like I Do Not Like Scala. Look, I get that. But I must say it's funny that you use this patronizing tone with Odersky as he was a n00b who has no idea about languages and then once you get a trollish comment, you go on and post it everywhere: OMG somebody was responding to my trollish post in a trollish manner, what a surprise? as for your post: just because a language can be used in a certain way (or certain language toolsets can be simulated in that language) that does not mean that the users will find that specific style idiomatic. What matters is the style you will meet the most while reading or writing code in that specific language (hack, even java has various functional libraries: lambdaj, functionaljava etc. but how many people would consider code written with these library java-like?). When people say that scala is "kinda functional", what they really mean is that the language is nudging you into that direction (preference for pattern matching, option type, final variables, map, foreach,closures, partial functions etc.). And this nudging towards the functional style is what makes scala "postfunctional". (other features responsible for the "scala feel" but not directly related to the functional thing: static typing w/ type inference, a powerful type system, xml literals, implicit converions, case classes, mixins + various actor libs etc.)
• March 8, 2010, Robert Fischer wrote: My issue isn't with people saying Scala is "kinda functional". It's saying it's a "functional language". I've heard people say they want to learn Scala b/c then they'll know functional programming, and that's just wrong. Worse, I've heard people write off functional programming because they didn't like Scala. This means that the misconception that Scala is a functional language is hurting real functional language adoption and hindering people's advancement as software developers by making them think they know functional when they don't. So I'm trying to reinforce the barrier between real functional languages and languages with closures. I'm not particularly knocking Odersky here: what he's done with Scala is pretty impressive. But he's clinging to a title that Scala doesn't deserve. While I appreciate the move with "postfunctional", I'd be a big fan if it also meant he'd give up "functional" — but he's just taking both titles on. In so doing, he's diluting what we mean by a "functional language", and that's just not helpful to anyone involved. The evidence does seem to be that Odersky doesn't really know functional languages. Or, if he does know them, he knows them academically or intellectually, and doesn't really grok them. But you can't be an expert on everything, and I get that. This whole conversation is really kind of sad. There's such an extreme dichotomy here: the assumption seems to be that if you criticize a language, you must hate it. I don't hate Scala: Scala is what Java should be. It's finally a competitor to C# on the JVM — the advanced capabilities of C# have been downright embarrassing for a long time, and Scala evens the playing field. I'm just criticizing the way we talk about this language, and providing counter-evidence to some of the claims made about it.
• March 8, 2010, Robert Fischer wrote: Which languages do you see as missing one of the two qualities?
• March 8, 2010, Robert Fischer wrote: As I will say below, my issue is mainly one of vocabulary and pedagogy, because I'm frustrated with the murky waters that such marketing-speak has created.
• March 8, 2010, Robert Fischer wrote: PS: From someone who has been there (remember: I'm a static typing fan, too): If you want to debate static typing usefulness vs. dynamic typing usefulness, don't argue that it's hard to implement type safety in a dynamically typed language. It doesn't win you any points with the dynamic language crowd, because they've already accepted they don't need it.
• March 8, 2010, Peter Lewerin wrote: Daedalus and his son Icarus were imprisoned by King Minos, and made themselves wings out of wax and feathers to escape. Before they took off from the island, Daedalus warned his son not to fly too close to the sun. The sensation of flying made Icarus forget the warning and he soared higher and higher. Eventually the wax melted and he fell into the sea. A programmer can escape the prison of procedural programming using functional programming, but going for the purest form of FP isn't really a sustainable goal. Most likely, these wonktional programmers will melt their wings by straying too close to the realm of mathematics and plunge to their deaths.
• March 8, 2010, Thomas Heywood wrote: And you kinda missed the boat on the entire fundamental question: “Is Scala a functional programming language?" Scala is a multiparadigm language that supports procedural, functional and object-oriented programming. We've had that since 1950s and Lisp. Now, what was the fundamental question again?
• March 8, 2010, Thomas Heywood wrote: (Mea culpa: we've only really had it supplied with the language since 70s, when Lisp machines took off. Still, a blatant fact is blatant, no matter how much you blog it into shape.)
• March 8, 2010, Vassil Dichev wrote: Robert, if you like Perl, that's nothing to be ashamed of :-) Seriously, I think your article is thought-provoking, if a little controversial. Still, there are several things I disagree with. First of all, I have interpreted Odersky's article in the spirit of: "OK, I don't insist on calling Scala a functional language". One important piece you didn't mention was immutable data structures. Perl doesn't scale very favorably here. Was this on purpose? I find it important not just what a language *can* do, but also what it *cannot* (easily) do. Mutation and scoping are some of the things Scala restricts rather successfully. I also don't find how the fact that Perl has flexible arguments, autovivificiation, list/argument coercion, and dynamic symbol table mangling makes it more functional. Does Haskell have these? Do you consider Haskell functional? Then I also don't see many people argue that Java is object-oriented. By the same reasoning, it's not- it certainly has types that are not objects, and you can certainly write in a procedural style in Java (unfortunately some people really do). Also, I don't see you arguing that OCaml is not object-oriented, because it's also considered a multi-paradigm language. I see that in one of your comments you agree that OO is poor in OCaml, which is fair enough, but I think some OCaml users wouldn't agree with you on this count either. I most emphatically agree that if you "know" how to write working Scala code, this doesn't mean you know all about functional programming. But I disagree that this harms "real" (read purer) functional languages any more than Java harms "real" object-oriented languages (whatever they are). In the end, I'm also fine with the definition of "statically typed object oriented language with closures".
• March 8, 2010, Vassil Dichev wrote: I've just read some of the blog posts you've linked to, and it's quite telling that two of them complain that Scala is too functional, while you complain that it's not functional enough. I think this is the problem with Scala: you can't appease everybody without any mental effort on their part to get used to the new style of programming. And I think the same can be said of OCaml. I also think OCaml would be a wonderful language to learn (and I might try it soon).
• March 8, 2010, Paul Kaletta wrote: All of your examples should work with any version of Perl 5, which came out in 1994.
• March 8, 2010, Martin Odersky wrote: Robert: Your blog and even more so your comments make it sound as if I have no clue about what functional programming is. So, it must be because of a series of freak accidents that I organized ICFP, am a member of the IFIP working group on functional programming and am a member of the editorial board of the Journal of Functional Programming. And I even published quite a bit on lambda calculus, too :-). Seriously, I stand completely by my article on postfunctional programming. I believe your post here has added nothing of substance to the discussion. http://www.scala-lang.org/node/4960
• March 8, 2010, joe poki wrote: if you cite every single well-known post that dismisses scala one way or another and you go on and say "it’s too complicated, its syntax is weird, it’s too magical, people write in entirely distinct subsets of the language", then people will rightly assume you do not like scala, I do not get it why you are surprised (notice, I did not say you hate it, just that you dislike it). see, the patronizing stuff again "Odersky doesn’t really know functional languages". As I tried to point out: what matters is how a language is used and what's considered idiomatic and in that sense scala definitely has some functional feel to it (and no, it's not just about closures or foreach, but preference for pattern matching, option types, final variables, map, foreach,closures, partial functions etc. etc.).
• March 8, 2010, Tracy Harms wrote: To the best of my knowledge, Factor, Joy, FL, and J are languages that favor anonymous arguments (and/or emphasize composition of functions) while lacking reliance on lambda expressions.
• March 8, 2010, Robert Fischer wrote: If you're up for not calling Scala a "functional programming language", tell Odersky.
• March 8, 2010, Robert Fischer wrote: It's not patronizing to say someone doesn't know something, or to disagree with the way someone is using language. That's just not what patronizing speech is. It'd be patronizing if I started explaining to Odersky what closures are and how they're supposed to work, or if I sent you off to look at this link. That would be patronizing.
• March 8, 2010, Thomas Heywood wrote: Your blog and even more so your comments make it sound as if I have no clue about what functional programming is. Martin, hate to break it to you, but all you ever did was bring effective functional programming to a mainstream platform for the benefit of industry and academia. Call me back when you write a wrapper library or two, learn the persistence API of a web framework, or realign the tone of existing projects.
• March 8, 2010, Robert Fischer wrote: That's cool that you're so involved. Ultimately, though, our problem is boiling down to one of language. If Scala and perl are functional languages, how do we differentiate them from languages like Haskell, OCaml, and Lisp, where the fundamental way of tackling problems is different? I'd like to use the term "functional programming language" for the latter, and I'm more than happy to stick to "postfunctional programming language" or "multi-paradigm programming language" for the former. But that means we stop calling Scala a functional programming language, as most of the commenters here on the post already have. Deal?
• March 8, 2010, Robert Fischer wrote: Yeah, that's the general issue with these multiparadigm languages like Scala and perl. If OCaml narrowly avoided that fate (and I think it has), it was by completely subjugating the OO aspect to the functional aspect, and not really using the OO aspect much.
• March 8, 2010, joe poki wrote: If you think saying somebody does not know squat about a subject while that person is supposed to be some sort of an expert on the topic is not condescending, then I do not know what is. By the way, it seems I was not alone, see Odersky's comment above.
• March 8, 2010, Robert Fischer wrote: The immutability is a good point, and it's an area where Scala certainly pulls ahead. Actually, the Ruby (and, to a lesser extent, C#) people regularly say that Java isn't really OO, because a lot of things in Java weren't either objects or messages. I think Ruby inherited that criticism from the old SmallTalk people. And I'll happily argue that OCaml isn't object oriented: while it has objects, it's certainly not oriented towards them. What harms functional programming languages is when Java people learn Scala and then think they know functional programming languages. Or, worse, when they decide they don't like Scala and then conclude they don't like functional programming. This happens a lot because Scala was lauded as a functional programming language on the JVM which was comfortable for Java people. It's the murkiness in the water that's the issue.
• March 8, 2010, Daniel Spiewak wrote: In Perl, functions and lambdas are fundamentally different. If nothing else, this can be seen by the different invocation syntax. You can convert between functions and lambdas (just like in Ruby and Groovy), but they are very different constructs as far as the language is concerned. To me, one of the essentials of a functional language is that functions are merely lambdas which have been assigned to a named value. OCaml and Haskell encourage this notion with their syntax for function declaration (in fact, Haskell's function decl syntax is exactly the same as its value decl syntax). Perl doesn't even come close to meeting this qualification. Scala does substantially better, though I'll admit that it does have its gotchas (methods are sometimes tricky).
• March 8, 2010, Robert Fischer wrote: While that's a bit hardcore of a comparison (and somewhat damning on people's ability to learn), I definitely agree with your point. And Scala's great in this regard—as I said a number of times, I think Scala is where Java should be if Java's growth hadn't been stunted. If you look at how C# has evolved, Scala's basically right in line with that kind of development. And so a Java developer learning Scala in order to push their way of thinking about types and functions is a great move.
• March 8, 2010, Robert Fischer wrote: True — I'm oversimplifying the world into imperative and functional. There are other paradigms out there (e.g. Factor's stack-based approach) which also can lead to point free programming.
• March 8, 2010, Robert Fischer wrote: Do they work before that? (Or, rather, would they work before that if I dumped the prototypes?)
• March 8, 2010, Robert Fischer wrote: True: there are conversions that need to be made between functions and lambdas in perl. This suggests for Scala (as a multiparadigm language) having a somewhat stronger functional aspect than perl, but it still doesn't make it a functional programming language a la OCaml and Haskell.
• March 8, 2010, Alicia wrote: Wouldn't it be awesome if you really could make money writing b.s.? People won't even donate a dollar towards valuable open source projects...the suggestion that you could make money for being good at b.s. is hilarious.
• March 8, 2010, Robert Fischer wrote: Amen.
• March 8, 2010, Robert Fischer wrote: True enough. I'm just trying to wrap my head around how Odersky can really grok functional programming and then assert that it's simply bolt-on features of a language. The difference between Haskell and Java is not simply one of syntactic sugar. Claiming he's mistaken about how FP works is actually a generous take—claiming he's clinging to the FP title for Scala for some ulterior reason when he should know better is much less generous. I was trying to give him the benefit of the doubt.
• March 8, 2010, James Iry wrote: Robert Fischer Finally Admits That Scala Is Functional (http://james-iry.blogspot.com/2010/03/robert-fischer-finally-admits-that.html)
• March 8, 2010, Martin Odersky wrote: Robert, please, read my post again: http://www.scala-lang.org/node/4960 Nowhere did I define functional programming exclusively by a list of features. Instead I had as my central definition: "A functional language makes programming centered around functions easy and natural." A good test of this would be: is it common to write functional programs in the language in question? It's usually far easier to tell whether a program is functional than whether a programming language is functional. By that standard Scala is clearly functional; many of the classes and modules written in it are purely functional and every cool idea from Haskell seems to be implemented sooner or later in Scala (not that we don't invent some cool ideas of our own as well). I don't know Perl well enough to be able to tell whether there are many functional programs written in it, and whether the expression of such programs is easy and natural.