I gave a talk about Scala at Last.fm last night (It’s not online: not on Last.fm. At. I physically walked over to their offices and gave the talk to some of their devs).
Depending on how you look at it, it either went moderately well or was a complete disaster. People seemed interested, and went away knowing more about Scala than they came in with, so that part went well. The big issue is that I never actually talked about the subject I went in prepared to talk about. Oops.
I think part of the problem is that I aimed the talk at slightly too high a level. The talk I had designed was about testing with ScalaCheck, as that’s a pretty nice distinguisher of Scala from most of the other JVM languages – it’s something that really takes advantage of the type system in powerful ways, but isn’t too scary. I went in with a set of code I’d already written and was going to live code the tests for it. I still think this would have been a good talk, but I think it would have been a much better second talk on Scala than an introduction.
What happened instead was that we very quickly got diverted onto basic questions of syntax and semantics, and ended up touring Scala through the interpreter and performing a sort of general Q&A about it. This worked reasonably well (at least partly because Miles joined in and backed me up on some of the questions. Thanks, Miles), and would probably have worked even better if I’d come in with a couple small examples to demo this way. So maybe there’s something worth refining in there – certainly the “Here’s the interpreter. Let’s talk about code” model seemed like a pleasant one.
But I feel the talk still sortof missed the mark. It wasn’t a bad introduction to Scala, but it wasn’t a good “Here’s why you should use Scala”. And I’m still not sure how to do one.
The traditional way to present Scala seems to be to present it as a better Java. “Here’s an example in Java. Let’s translate it to Scala. Oooh, look how much shorter it is!”. This seems to go pretty well from what I’ve heard reported. But I have a couple problems with it: Some philosophical, some practical.
The biggest one is that the JVM is not short of languages which are better than Java. I don’t consider the question “Should I use Scala instead of Java” interesting. The answer, as far as I’m concerned, is obviously YES. Except for a few remaining interoperability issues I don’t consider that there’s any good reason to use Java these days (Disclaimer: The one exception I grant is in creating other JVM languages which you don’t want to be burdened with the Scala standard library on top of your language’s runtime). The interesting questions are “Should I use Scala instead of Clojure?” or “Should I use Scala instead of JRuby?”.
And here’s the thing: Rewriting a simple Java example in a better language looks exactly the same with almost any nicer language. You do a straight port, you find opportunities to introduce some functional programming, maybe you take advantage of sequence comprehensions or such like, etc. but basically what you end up with is the original program with a terser syntax and a few obvious abstractions factored in. It’s really not that exciting, and it doesn’t sell the language well. It might, if you’re talking to a group that has no experience of other languages (I wasn’t), but even then you’re basically playing on your group’s ignorance rather than making a compelling argument.
There are a bunch of neat things in Scala that could be used as a compelling argument: Scalacheck, actors, parser combinators, pattern matching in general, etc. but I’m not really how to go from zero to a full fledged example in one of these in only an hour. Perhaps if (rather than starting from a blank slate like I did) I started from a pre written example and disected it, but I’ve no idea if that would work any better.
So, what have you done? Did it work? Any ideas for how to do it better?
Never done a Scala talk myself, but as your audience what I want to hear about is are killer applications. Powerful frameworks and libraries that save me work and improve my business. As Rails does for Ruby, or Seaside for Squeak. I dont want languages features (at least not in the first place), I want to save time and money by (re)using powerful 3rd party code. And if you want to lock me into your language, make sure you have an unported (maybe even, but not required, unportable) library at hand.
Well, again, that’s why I wanted to talk about ScalaCheck. It might not be a killer *application*, but it makes my life as a developer orders of magnitudes easier: It’s great for finding bugs and keeping them found (its approach is very robust to subtle variations in bugginess that traditional testing can miss).
Good question…I don’t think it has a good answer. My impression is that I’ve heard Scala sold in three primary ways:
1. A more concise Java integrates with existing Java code
2. A safer, higher performance Ruby that can use Java infrastructure
3. A Haskell that can be sold to the suit because of its compatibility with Java
Unfortunately these three ways have very little in common beyond compatibility with Java, and the approach depends on your audience. Given a mixed audience it would be even more difficult.
I don’t see how rewriting Java code gives you the same result in any functional language. You’re looking at this from a point of view that’s too abstract and thus glosses over a lot of things that make Scala very appealing.
Scala looks similar to Java, and that’s a good thing: it means that people won’t be turned off immediately by the syntax. I hate clojure’s LISP-like syntax, and I’ve had lots of frustrations with Haskell’s ultra-terse no-redundancy-thank-you approach. A lot of what people refer to as “syntactic sugar” is actually very useful for most people to learn to read a language and not run into a wall of incomprehensible gibberish.
Also, what about classes and objects? I don’t know if clojure has those, but I know Haskell doesn’t. I love the combination of object-oriented and functional programming in Scala, it makes sense for real-world tasks. And that’s actually the second problem I have with your assertion about all functional languages being the same: that may be true for the Fibonacci function and quicksort, but what about more real-world kinds of examples?
What got me interested in functional programming was Python. Seeing how elegant and painless it was to do a lot of things using map and lambda expressions really opened my eyes (that, and I love its syntax – all languages should work like that!). I knew what lambda expressions were, I just had not seen any practical uses of them. And that’s likely true for most of your audience: many programmers only know Java and maybe C++ and have only briefly (if at all) seen functional and declarative languages. They need to be shown how useful these approaches can be, and that they don’t have to abandon everything they know to make use of them.
And that’s the final thing: “batteries included,” as the Python folks put it. With Scala, you’re not left in a sea of parentheses with nothing but basic operators and maybe a print function, but you have access to everything in Java. That means the Java library, Swing, etc., and your own existing Java code. And that’s what makes Scala not just clever and interesting, but practical and useful.
So basically I’m saying that even if your audience is aware of other languages, you have to be careful not to assume that they are functional programming pros. After all, why haven’t they switched? Obviously, they didn’t like those languages for whatever reasons, or didn’t realize what they could do with what these languages offered. But that’s why they need to see relevant examples, not just abstract language concepts that are the same in all languages.
Hi David,
I gave a couple of Scala talks and one thing I found – not only Scala specific though: one shouldn’t stress the audience with one special aspect if you can’t be sure the audience can follow. If there’s no real knowledge of the syntax and the audience isn’t specialized on functional programming concept, you wont get them impressed by showing these things.
You have to get them where they are comfortable and lead the way to useful language features to them.
When I talked in London about Scala and Wicket, I could assume that most of the audience was somewhat comfortable with Wicket. And there were two short introductions into Scala before my talk so the audience knew a bit of Scala’s syntax already. Still, my presentation was slightly too hard to grasp for a few attendees.
The average Java developer needs quite some time to get comfortable with languages like Scala. It’s easy to overestimate what they are capable of. That’s a sad fact. And actually, I’m one of those non-mathematical guys, so I easily get lost, too.
I hope you’ll have lots of more talks, too. Just don’t expect too much from your audience. :-)
Best regards, — Jan.
I should clarify that while essentially all the audience at my talk new Java, most of them also knew at least Python as well. If I were talking to a set of primarily Java only programmers I might be a bit different. But frankly I’m probably not the best person to talk to a set of Java only programmers. :-)
I agree that a rewrite to Haskell or Clojure would probably *look* very different to a rewrite to Scala. But in terms of actual functionality I don’t expect it would: Ok, so I’ve got this data type. In Java it’s a class. In Scala it’s a class. In Haskell it’s a data declaration. Until you start getting into more complicated examples (remember: 1 hour talk) the differences are really rather superficial.
This is particularly true when you compare Scala to other hybrid OO/functional languages. Particularly Python: Python has objects, classes, functions, sequence comprehensions. Scala has objects, classes, functions, for comprehensions. It’s hard to illustrate the differences when you start from an example in Java.
But that’s the point: functionality isn’t everything. If that were the case, we’d only have a handful of languages. There are so many other criteria that make a language (and its “ecosystem”) useful and appealing. You’re focused too much on extracting the underlying concepts and miss the many other things that make Scala the language it is.
Given that every single language I know offers a different set of functionality, I don’t think “functionality is everything” would imply that at all.
Further, I don’t think what you’re saying is in any way in favour of the standard “Here’s how we do it better than Java” talk. It’s designed to show off only the trivial core of the language – it doesn’t really do anything for the ecosystem beyond the utter basics.
I agree with the sentiments that are expressed in the blog article. And after years of working with various programming languages and JVM languages, I am still not 100% sure where to apply a particular programming language to a particular task. I have my theories and there are a certainly a multitude of languages/tools to choose from. But, why use Scala over Clojure. Or Clojure over Scala or JRuby/Jython. And it comes down, “Why use Scala?” Why use Clojure?
Actually, most programmers should at least check out scala, clojure, haskell, factor… a lot of the emerging programming languages. As a learning exercise. The better question is, why use scala, clojure, jruby for a significant project?
The easy answer, it depends.
This is my personal opinion until I do a lot more research on the topic.
Obviously, you can do most general purpose programming tasks in most of the JVM languages and most new programming languages. Even if you haven’t worked with the language very long, you could probably perform X task in Y language.
Right now, I am working with Clojure. I even bought some t-shirts. Why? Because it fits my tasks perfectly. I don’t do much back-end development. I am working with GUIs now and 80% of my time is spent in web development. Clojure’s code is data, works very well for that kind of bottom up programming. I don’t necessarily need the compile time type checks that are ensured by Scala or Haskell.
On a GUI or Web app, if I am not hitting a particular functionality…that may or may not have a bug/invalid clojure code, then it doesn’t necessarily effect the entire application. It is a kind of ‘dynamic’ approach to development.
Obviously you can write web apps in haskell/scala but for what I was doing with clojure, it just seems to fit.
On the other side of the fence, I could see where Scala could be used for back-end server development. For example, darcs was written in haskell. Scala is used Twitter’s messaing queue. Both are popular server applications. I guess the compile time checks reduce a lot of bugs up front. Useful for server apps. Maybe not so much for a event driven gui components. Note: these are not hard and fast rules.
Sorry, I kind of went on a tangent, but that is how I see the new languages that are out there.
Maybe the module system is worth demonstrating. How to deal with a architectural design decisions in Scala, so to speak. I think that’s what attracts Java people. How to use traits to get rid of repetition, or how to configure your app by mixing them. To get natively things that you need dependency injection frameworks in Java.
Scala’s static typing separates Scala from JRuby and Clojure.
Does anyone say “I want to use a JVM language which isn’t Java, and I don’t care whether it’s statically typed”?
If you have decided that you want a statically typed JVM language which has the tool support and momentum to use commercially, is there anywhere else to go than Scala?
@Tom Davies – In many cases I wouldn’t care whether a language is statically typed or not. For me static typing is about efficient defect reduction. The compiler catches errors, and that’s about the most efficient way I know to detect errors. But you can also reduce errors by writing denser code or at a higher level of abstraction. Scala lacks metaprogramming (well, there’s compiler plugins, but I won’t count that), and that lack wipes out whole swaths of abstraction potential that you get with languages like Lisp, Python and Ruby.
“Here’s an example in Java. Let’s translate it to Scala. Oooh, look how much shorter it is!”.
This is something I’m always a little confused about. I know that I’ve spent way too many years working with java to be unbiased, but the ” ohh it’s shorter!” or “more consise!” arguments that come up every time something other than java is brought to the table are hard for me to see as a true advantage.
I know I’m not a hardcore computer scientist, but I’m a pretty good software developer. I look at Scala examples (and many others.. not just picking on Scala here) and it’s just all gibberish to me. I know, I know. I don’t know Scala yet so of course it’s gibberish; but is that really true? With only some very basic understanding of simple programming logic, I had very little trouble following java code before I ever actually learned to program in java. the same is true of most .Net languages. I can “read” this code. In my mind, because it’s readable, it’s easier to maintain, not just by me by by any other developer on the teams that I hand my code off to. Is it more verbose? Oh, hell yeah, but you know what, actually typing in code represents a tiny, tiny portion of the my overall time developing business software, so if I spend 12% of my time actually writing code with java and 10% of my time doing with a more concise language but that code is more difficult to follow and maintain, am I really saving anything?
I know the main point of the original post here was that there were far more reasons why Scala is “better” than Java than just concise code, but I do wish some of the other Scala proponents I follow would move off of this point and on to the others because every time I hear about how much better it is than java because it’s so much more concise, I lose a little more interest.
Matt: It’s a perfectly valid question, and I’m happy to discuss it with you elsewhere if you wish to provide a link, but it’s not a conversation I’m willing to have happen in the comments of this post as it’s wildly besides the point.
Everyone else: I will delete any further comments that attempt to continue said conversation here.
Pingback: Best of drmaciver.com | David R. MacIver