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(\×2, 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 thefoo(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
applyfunction 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-incurryfunction, but if you want Scala’sFunction.curriedin 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.
84 Comments
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.
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.
“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.
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.
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
mapandfold).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.
In what ways do Scala’s unififed functions and function values outperform perl?
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).
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.
AFAIK Perl functions are merely lambdas (anonymous subs) that have been assigned to a named value (the code slot of the identifier’s typeglob). Likewise there’s no difference between a scalar holding a reference to a lambda and a scalar holding a reference to a function.
users-computer:~ user$ perl -d -e 42
DB sub function { print(“called a function\n”) }
DB $function = \&function
DB $lambda = sub { print(“called a lambda\n”) }
DB *lambda = $lambda
DB function()
called a function
DB lambda()
called a lambda
DB $function->()
called a function
DB $lambda->()
called a lambda
I don’t see any difference in invocation syntax there. If you want to write all of your subroutine definitions as
*bar = sub { print(“bar”) }
you’re welcome to.
@Cody Koeninger: you missed the discussed point – you are still doing a conversion, when you type:
$function = \&function and *lambda = $lambda. No such conversion is needed in more functional languages, as already argued above by Daniel Spiewak.
Currently evaluating FP alternatives on the JVM… this quote is the best
I’ve found on any blog, tweet or news group post.
So…I can sell it to all our java developers as a way to get more done without
taking off the leather or putting away the whips.
Not sure if Rich Hickey can compete with that kind of allure.
I just don’t know enough Clojure to comment: you’d have to ask Brian about that.
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?
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.
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.
“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.
Yes, I meant procedural.
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.
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+
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.
Amen.
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!
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.
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:
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:
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:
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:
…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.
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.
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.
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.
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.
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.
All of your examples should work with any version of Perl 5, which came out in 1994.
Do they work before that? (Or, rather, would they work before that if I dumped the prototypes?)
Well, I’ve never used Perl 4, but afaik it didn’t have a reference variable type and it didn’t have lexical scoping, so your examples would not have worked in the current form.
Glancing at the Perl 4 manpages it seems that Perl 4 could already pass around code blocks, however it seems to me that you would have had to capture variables manually, which means that closures would have been difficult to do.
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++.
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.
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.
Which languages do you see as missing one of the two qualities?
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.
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.
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.)
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.
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.
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.
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?
If you’re up for not calling Scala a “functional programming language”, tell Odersky.
(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.)
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”.
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.
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).
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.
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
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?
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.).
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.
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.
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.
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.
Robert Fischer Finally Admits That Scala Is Functional (http://james-iry.blogspot.com/2010/03/robert-fischer-finally-admits-that.html)
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.
Thanks anyway for giving me the benefit of the doubt that it’s just misguidedness and not evilness that makes me insist on my ways.
How do you account for this quote?
The Goals of Scala’s Design
Ugh. I need to turn down the maximum comment nesting. It’s getting out of control, and the box is getting REALLY skinny.
Classical fallacy: I said: functional languages have a well-identified, fixed set of features. So being a functional language implies having that fixed set of features (or rather, some part of it because I was talking about the union of all functional languages). You think I said: having that fixed set of features implies being a functional language. But I never said that.
Besides, that quote is not from the article I referred to. When I said “nowhere” I meant nowhere in that article, and I think that was clear from the context.
Okay, sure I’m taking your quotes from both your post on post-functional languages and another one on the design decisions behind Scala. Sorry if I overgeneralized your “nowhere”.
I read that quote as saying, “I went out to implement a functional language. This was easy, because it turns out implementing a functional language means implementing a fixed set of features.” If that’s not what you meant, what did you mean?
I’m uncomfortable with your broad definition because it leads to confusion. Scala’s extreme flexibility is exactly why I’m so resistant to labeling it a functional programming language — people learn the subset of Scala closest to Java and then think they know functional programming. I’m really, really tired of explaining to people that functional programming is more than list comprehensions.
BTW, I want to say it straight to you, since I think things can get lost and there are some misconceptions floating around. I really do appreciate all you’ve done on the JVM languages—especially proving to folks who only know Java that there’s more to static typing than Java’s conception of it. And for all my pedantic resistance to calling Scala a functional language, it is one of my go-to languages for heavy lifting on the JVM. (My own experiments in programming language development have Scala cores.)
Adding functional language constructs was relatively easy, because they are well understood. Making Scala an organic whole was hard. We can disagree whether this succeeded or not.
The other question is, should a functional language force you to program in a functional style? Scala clearly does not, that’s why I prefer to call it postfunctional. I understand your uneasiness that some people might take this as an excuse never to get into real FP at all.
Where we might differ is that I believe that in the long run Scala programmers will recognize the benefits of the functional programming style even if it is not forced down on them.
Let me turn that question around: should object oriented languages impose an object oriented approach?
There is a value to learning, and really using, a paradigm. Is that limit you just hit a limit of the paradigm, or just a limit of your understanding of the paradigm? Until you expand your understanding, you don’t really know- and the siren call of multi-paradigm languages is that they allow you to not expand your understanding by ditching the new paradigm early and often.
There is another comparison (one you’ll like even less) to another multi-paradigm language- C++. The reason C++ “won” was because it was multi-paradigm (procedural and OO), allowing people who didn’t really understand OO to program in it. The reason C++ “lost” was because it was a multi-paradigm language, forcing people to deal with the old paradigm whether it was valuable to or not. The history of popular programming languages 1992-2007 was basically one of going ever less multi-paradigm and ever more pure OO.
In other words, is Scala “post-functional” in the same sense that C++ is “post-Object-Oriented”?
If we’re talking about how to LEARN functional programming, I totally agree that Scala is not the best choice (neither OCaml… the O part is there, lurking in the back…). I would recommend a pure functional lazily evaluated language (i.e. Haskell).
My experience was the opposite of Robert’s fears: I started learning FP with Scala (limiting myself to the functional subset of it) and then moved to learn Haskell (and I try to pick up as much as OCaml as I can on the way), but I guess I’m just weird: I’ve learned OO in C++ :)
But somewhat I agree in the comparison: C++ is to C as Scala is to Java
If Scala had taken all of Java and then added FP to it, a comparison with C++ might have merit. But as it stands Scala
has thrown out or generalized a lot of Java’s more crufty features. Where C++ is clearly much more complicated than C, the situation between Scala and Java is more balanced. Scala’s syntax is a probably a bit simpler than Java’s but its types are richer and more powerful. So you can say that Scala shares C++’s motivation — take a well established programming style and let it branch out into a new paradigm. But it shares neither its approach (to be an almost strict superset of a base language) nor its overwhelming complexity.
I’d say that if a language doesn’t force you to program in a functional style (or at least strongly encourage you that way), I’d consider it suspect as being a functional programming language at all. But I’m running on the stricter definition, as we’ve established.
I hope that your sense of the future is true, and that the functional programming style becomes more widely adopted by way of Scala. And maybe being on the inside of Scala adoption, you’re seeing that. Sitting here on the outside, though, I’ve seen the contrary, which is why I’m such a stick in the mud. Well, that and I’m preternaturally disposed towards being a stick in the mud.
Robert, I was actually talking about this kind of strong encouragement in my previous post when I said that scala was nudging you towards FP.
Well, at least you admit you’re writing about “religious issues”, where arguments are replaced by belief. So by definition I can’t argue with your expression of belief. However I don’t have to agree with you.
Hey Robert,
I found the following in your LinkedIn page:
“Robert Fischer is a multi-language open source developer currently specializing in Groovy in Grails. In the past, his specialties have been in Perl, Java, Ruby, and OCaml. In the future, his specialty will probably be F# or (preferably) a functional JVM language like Scala or Clojure.”
What, did you just call Scala a functional language?!
Ismael
Busted!
Really, that’s exactly what I’ve been discussing with Martin O.—if you know functional programming already, you can do functional programming in Scala. And if you’re on the JVM, like static typing, and want to do functional programming, you really don’t have a better option.
BTW, in Scala, I’m still struggling a bit to do functional programming in a way that’s particularly friendly to Scala’s approach — algebraic data types and function manipulation a la curry/flip are standard stunts for me, and I feel like I’m swimming upstream when I try those in Scala. I really should look more into some open source projects—anyone have one in Scala that’s particularly functional?
(In any case, I should update that since I’m now an .Net/F# developer.)
that is hilarious!
Robert, are you under the employ of Flying Frog Consultancy, perchance?
There is a certain Harropity, if you will, to your blog post.
Ouch. Of all the nasty things people have said about me because of this post (up to and including calling me a “douchebag”), that’s the first one to hit home.
Robert, I am sorry people called you names but I am not sure what you expected. You published a deliberately controversial post (or may I say a very trollish one?) where you wrote off a whole language using standard (and frankly boooring) points like “it’s too complicated, its syntax is weird, it’s too magical, people write in entirely distinct subsets of the language” for one particular issue you have with it and on top of this, you called the given language’s creator a numerous times pretty much clueless when it comes to FP.
Functional programming just means programming with pure functions (no observable side effects). The alternative is imperative programming – programming with observable side effects. OO is orthogonal – you can program using pure functions operating over objects if you like, or your functions operating over objects can have side effects. Of course, most real programs have some mixture of functional and imperative styles.
There are some language features that make programming in a purely functional style more convenient, sure, but basically, with some discipline you can program in this style in any language, Scala (and Perl!) included. My personal opinion is that Scala makes FP pretty convenient – your argument seems to be merely that it’s not as convenient as it could be in some instances and therefore doesn’t get your official “functional language” stamp. I guess that is fine, although the distinctions you are making seem pretty arbitrary to me.
I don’t see what the big deal with Object Oriented languages is. I mean, you can do Object Oriented programming in languages like C and Pascal- yeah, it’s not quite as convenient as doing it in a language like Java or Ruby, but there’s no real reason to switch, is there?
But maybe the only true “popular” OO language is SmallTalk, it could be argued that Java is not really OO, having primitive types and static methods, and many don’t really in a fully OO way…
Perhaps the difference is that C and Pascal don’t have “first class” objects and Java and Ruby have.
They have structures, and function pointers, and you can put the function pointers in the structures giving you virtual methods. Inheritance is a little tricky, but no one is using that anyways these days, so no problem. Yeah, it’s a little bit klunky, but all the important stuff is there, so why do we need to leave C and Pascal again?
If you haven’t figured it out, I’m making one of my little points by adopting this position.
You can’t call a language OO if it doesn’t have objects as “first class citizens” and you can’t call a language functional if you don’t have functions as “first class citizens”. You can draw the line on the other side and define a functional language as one in which you can program ONLY in a functional style.
The middle road is defined in fuzzy terms of “encourages a functional style”, “is easier to program in a functional style”, “makes harder to program in a non-functional style”, etc.
Real FP languages are dominated by parenthesis, prefix notation, and weak type systems.
Scala is dominated by curly braces, infix notation, and a strong type-system.
Ergo, Scala is clearly not an FP language.
Seriously though… to remove all doubt, I propose Scala should introduce a new keyword, “functional”, that when applied to methods or whole classes, guarantees an absence of side-effects within that scope. That should end all discussion!
By this definition, Haskell and Ocaml are not real FP languages. But thank you for playing…
In learning the ways of the FP I’ve tried a handful of languages, and for actual pragmatic use outside of academic circle-jerks I find Scala to be at the top of the list of those I’ve tried though I still have a few more to go (Erlang in 2nd place). Whether it’s a perfect fit for a dictionary definition perhaps not, but does it actually matter?
That aside, I found the Perl examples interesting to see that many FP concepts can be implemented in a handful of lines of [terribly awkward] code. Once again it seems Perl can do anything anyone else can: but in the absolute worst possible way :)