7 ms·

On Monday I'm giving a talk at Scala Exchange on my take on idiomatic Scala. For those of you who can't make it, I'll give a quick rundown. You basically need f

On Monday I'm giving a talk at Scala Exchange on my take on idiomatic Scala. For those of you who can't make it, I'll give a quick rundown. You basically need four patterns: - algebraic data types - structural recursion - fold, map, and flatMap - type classes That, in my experience, will cover the majority of code you need to write in Scala and give a solid basis for a robust and comprehendible code base. It's unfortunate that in Scala algebraic data types and type classes require a bit more code than in most other functional languages. E.g. sealed trait Foo final case class Bar(...) extends Foo final case class Baz(...) extends Foo vs something like data Foo = Bar ... | Baz ... for an algebraic data type, but it's really not so onerous to type. These patterns are really truly shockingly simple to use. We teach them in introductory courses and the majority of people get them. It's true that Scala has some warts, but as software engineers we ought to make decisions based not on our personal biases but on a consideration of the problem domain and tradeoffs involved. If you want 1) static typing, 2) a modern language, and 3) JVM compatibility then Scala is the best choice at the moment IMO. Remove one of those restrictions and other choices come into the picture. Update: If you're interested in learning more about these patterns, on Friday we're going to send a free excerpt of our "Essential Scala" book to our mailing list. The excerpt will include material on algebraic data types and structural recursion. You can sign up here: http://underscore.io/newsletter.html http://underscore.io/newsletter.html

lomnakkus 12y ago
I think you just described Haskell in your four bullet points (which I'm sure you know, or at least know of.) Of course it comes with the baggage of pervasive laziness, so there's that potential objection... It can't run on the JVM, but to be honest, I've never actually observed in practice what's so great about the JVM (if you're running functional code). Everyone I hear claims that the JVM is great (left & right), but I just don't see it. Maybe I'm just ignorant.
- pjmlp 12y ago
  The JVM ecosytem is great, because of tools like this: http://visualvm.java.net/ http://visualvm.java.net/ http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html http://www.oracle.com/technetwork/java/javaseproducts/missio... https://www.jetbrains.com/idea/ https://www.jetbrains.com/idea/ https://wiki.openjdk.java.net/display/Graal/Main https://wiki.openjdk.java.net/display/Graal/Main http://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-2157684.html http://www.oracle.com/technetwork/java/javase/downloads/java... All in one package. Plus since JVM is actually a specification, there are JVMs for almost all CPUs and OS that matter, from embedded platforms all the way to the data center.
  - lomnakkus 12y ago
    The thing is (from my experience): The things you list are actually not that important. VisualVM: Great, surely any VM should provide all of this through metrics or profiling? I can count the number of times VisualVM has told me anything I didn't already know or diagnose through other means on one hand. Mission Control: Can't speak about it yet, haven't tried. (But I will!) IDEA: Meh. It's a Java IDE. (Well, it does Scala too and some other stuff, but the thing is I don't actually miss that when programming in, say, Haskell. I do have some auto-compile stuff in my Emacs, but frankly I get along fine without it.) Graal? Experimental at best. AFAIUI it's actually quite a lot slower than State of the Art JS engines. Don't get me wrong, it's still great to have, but it's not exactly a game-changer if I could just shell out to another JS engine and communicate via sockets. (Don't get me wrong, it's great research. It's also a new thing. I've been hearing this "JVM is great" meme for years and years.) SceneBuilder? Seriously? If you've got OpenGL, why would you bother? Yes, it's all in one package, but at what cost? You're having to program on a VM which lack even such basics as tail-call-optimization, value types, etc. (I realize some of these things may be coming, but I'm talking about now). Standardization, I'll give you, but frankly, has the level of standardization actually been tested seriously? Can you take any old compiled-for-1.5 app and run it on Azul's JVM? Can you do the reverse? (I'm not actually sure what kind of guarantees the TCK does provide. In any case and in my experience, most "ordinary" admins are running the unverified OpenJDK on their servers.) EDIT: Sorry, my spelling and grammar are atrocious when slightly drunk. I can only apologize. EDIT#2: Sorry, if there were any ninja edits. I'll try to stop now.
    - nickik 12y ago
      What is the alternative? Haskell has a ok compiler and some fast weblibrary (I hear) but everybody agress that it cant compete on library and tooling. What else is there? That compets in performance, langauge and tooling?
      - pjmlp 12y ago
        > What else is there? That compets in performance, langauge and tooling? Only .NET, I would say.
- noelwelsh 12y ago
  The true benefit of the JVM is the ecosystem. There is a load of ancillary stuff like database drivers and web frameworks, to more exotic stuff like rendering PDFs, that every application needs. It doesn't add value to work on this stuff yourself but you can just about guarantee there will be on the library on the JVM that does what you want. It might not be pretty but it will exist somewhere. This is particularly the case in the big data space, where all the major frameworks are run on the JVM. For many people, interfacing with legacy Java code is also important. And yes, I advocate using Scala much like Haskell. (There is also the performance of the JVM, which is pretty good, but this is only a point worth mentioning when comparing to languages like Ruby and Python. Most functional languages have good compilers and runtimes.)
  - lomnakkus 12y ago
    Honestly, the IME the JVM ecosystem isn't that great. I think you could probably find a bigger/better ecosystem for C/C++ at this point in time. (Even going as far as Big Data or PDF support, but I know nothing of the former.) I recognize that the JVM has (for several years at least) been sold on this premise, but I just don't think it's true, or at least not true to the extent that the PR says. Don't get me wrong... it's good but not great (in my conception of things). Even if you find some indispensable JVM-based library, then why not just shell out to an executable jar (or whatever) that does what you need? At least you'll avoid classpath-hell that way.
    - nostrademons 12y ago
      Outside of Google, the big-data options for C++ are actually pretty disappointing. There are some toy MapReduce frameworks, but nobody's really put the work into building a solid, production-ready big-data framework the way Hadoop or Spark has. In some ways it's a little surprising and disappointing, as C++ really does have significant efficiency advantages over Java for big-data work, and a company that did invest in this could easily realize a factor of 3x or so improvement in their data-processing costs. (Perhaps that's why we haven't seen it, and there are companies that have developed their own frameworks internally but don't want their competitors to use them.)
    - 12y ago

lomnakkus 12y ago

I think you just described Haskell in your four bullet points (which I'm sure you know, or at least know of.) Of course it comes with the baggage of pervasive laziness, so there's that potential objection... It can't run on the JVM, but to be honest, I've never actually observed in practice what's so great about the JVM (if you're running functional code). Everyone I hear claims that the JVM is great (left & right), but I just don't see it. Maybe I'm just ignorant.

pjmlp 12y ago
The JVM ecosytem is great, because of tools like this: http://visualvm.java.net/ http://visualvm.java.net/ http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html http://www.oracle.com/technetwork/java/javaseproducts/missio... https://www.jetbrains.com/idea/ https://www.jetbrains.com/idea/ https://wiki.openjdk.java.net/display/Graal/Main https://wiki.openjdk.java.net/display/Graal/Main http://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-2157684.html http://www.oracle.com/technetwork/java/javase/downloads/java... All in one package. Plus since JVM is actually a specification, there are JVMs for almost all CPUs and OS that matter, from embedded platforms all the way to the data center.
- lomnakkus 12y ago
  The thing is (from my experience): The things you list are actually not that important. VisualVM: Great, surely any VM should provide all of this through metrics or profiling? I can count the number of times VisualVM has told me anything I didn't already know or diagnose through other means on one hand. Mission Control: Can't speak about it yet, haven't tried. (But I will!) IDEA: Meh. It's a Java IDE. (Well, it does Scala too and some other stuff, but the thing is I don't actually miss that when programming in, say, Haskell. I do have some auto-compile stuff in my Emacs, but frankly I get along fine without it.) Graal? Experimental at best. AFAIUI it's actually quite a lot slower than State of the Art JS engines. Don't get me wrong, it's still great to have, but it's not exactly a game-changer if I could just shell out to another JS engine and communicate via sockets. (Don't get me wrong, it's great research. It's also a new thing. I've been hearing this "JVM is great" meme for years and years.) SceneBuilder? Seriously? If you've got OpenGL, why would you bother? Yes, it's all in one package, but at what cost? You're having to program on a VM which lack even such basics as tail-call-optimization, value types, etc. (I realize some of these things may be coming, but I'm talking about now). Standardization, I'll give you, but frankly, has the level of standardization actually been tested seriously? Can you take any old compiled-for-1.5 app and run it on Azul's JVM? Can you do the reverse? (I'm not actually sure what kind of guarantees the TCK does provide. In any case and in my experience, most "ordinary" admins are running the unverified OpenJDK on their servers.) EDIT: Sorry, my spelling and grammar are atrocious when slightly drunk. I can only apologize. EDIT#2: Sorry, if there were any ninja edits. I'll try to stop now.
  - nickik 12y ago
    What is the alternative? Haskell has a ok compiler and some fast weblibrary (I hear) but everybody agress that it cant compete on library and tooling. What else is there? That compets in performance, langauge and tooling?
    - pjmlp 12y ago
      > What else is there? That compets in performance, langauge and tooling? Only .NET, I would say.
noelwelsh 12y ago
The true benefit of the JVM is the ecosystem. There is a load of ancillary stuff like database drivers and web frameworks, to more exotic stuff like rendering PDFs, that every application needs. It doesn't add value to work on this stuff yourself but you can just about guarantee there will be on the library on the JVM that does what you want. It might not be pretty but it will exist somewhere. This is particularly the case in the big data space, where all the major frameworks are run on the JVM. For many people, interfacing with legacy Java code is also important. And yes, I advocate using Scala much like Haskell. (There is also the performance of the JVM, which is pretty good, but this is only a point worth mentioning when comparing to languages like Ruby and Python. Most functional languages have good compilers and runtimes.)
- lomnakkus 12y ago
  Honestly, the IME the JVM ecosystem isn't that great. I think you could probably find a bigger/better ecosystem for C/C++ at this point in time. (Even going as far as Big Data or PDF support, but I know nothing of the former.) I recognize that the JVM has (for several years at least) been sold on this premise, but I just don't think it's true, or at least not true to the extent that the PR says. Don't get me wrong... it's good but not great (in my conception of things). Even if you find some indispensable JVM-based library, then why not just shell out to an executable jar (or whatever) that does what you need? At least you'll avoid classpath-hell that way.
  - nostrademons 12y ago
    Outside of Google, the big-data options for C++ are actually pretty disappointing. There are some toy MapReduce frameworks, but nobody's really put the work into building a solid, production-ready big-data framework the way Hadoop or Spark has. In some ways it's a little surprising and disappointing, as C++ really does have significant efficiency advantages over Java for big-data work, and a company that did invest in this could easily realize a factor of 3x or so improvement in their data-processing costs. (Perhaps that's why we haven't seen it, and there are companies that have developed their own frameworks internally but don't want their competitors to use them.)
  - 12y ago