7 ms·

A farewell note to a programming language

104 points by fogus 12y ago

speedkills 12y ago
I found your experience closely mirrors mine with scala. At my current shop we write mostly ruby and scala. The ruby code between developers looks much more uniform than the scala code I believe due to the fact that while trying to please everyone scala hasn't yet developed much of "the scala way". I do hope this changes as I really enjoy scala. Currently my team is experimenting with style/punting tools like stylecop to try to bring a little consistency to our code. Too early to say how it will work out but I would love to hear from others how you try to bring a team style to a code base that will happily let a fully functional developer, a fully object oriented developer, a straight imperative developer, and someone who believes in mixing these things all work side by side. Mentally by giving up the possibility of nothing you have to learn everything which means loading a lot of the scala compiler up into your brain before even trying to read a bit of anyone else's code.
- lostcolony 12y ago
  Mixing an imperative developer with a functional developer? That's asking for trouble. You'll have to be converting between mutable and immutable data structures anywhere the two interact. Or forcing the imperative developer to be largely functional due to the immutable data structures everywhere that prevent him from using imperative approaches. Or forcing the functional developer to write in a largely imperative style due to the mutable data structures that prevent copying from being efficient, and can be mutated any time they pass out of his/her code. Or to put it another way; Scala as an idea may be fine; you can mix imperative and functional together, by picking which data structure and approach for a given problem is 'right'. But in a team environment? Touching someone else's code in a particular paradigm means you have to be familiar with, and expect, that paradigm. You can come up with a team that agrees on what paradigm everything must be written in (and that can be anywhere on the continuum), but you can't mix and match and expect developers to not have to learn every paradigm in use.
  - tel 12y ago
    The ST monad would like a work with you :)
    - asdf1234 12y ago
      Pervasive use of ST, or almost any monad for that matter, leads to serious problems in Scala since you basically have to use trampolines and take a massive performance hit. It's also extremely verbose to do it correctly. It's a good solution in Haskell though.
      - runT1ME 12y ago
        This is FUD. You often don't need trampolines and there are better solutions than trampolines.
        asdf1234 12y ago
        It's debatable whether abusing Free is a better solution. Either way, programming like this is disgusting in Scala and comes with tons of caveats compared to Haskell.
    - lostcolony 12y ago
      Which doesn't help the imperative programmer who is having to interact with functional code. And an ST monad makes no sense unless you're interacting with imperative code (obviously, hence your bringing it up), which means you already understand what imperative is, and are still having to convert your immutable structure to a mutable one, for the imperative code to operate on, and to recognize it will be modified in place; to use the ST monad the functional programmer already has to understand imperative programming. It also seems like it would fail to encapsulate the side effects an imperative function may have, since that function is able to interact with state elsewhere, that isn't actually encapsulated. I.e., the ST monad makes sense when dropping into update-in-place for performance reasons, but when there are side effects that are not ensconced within the monad (remember, the function you're calling was written by an imperative programmer, in a language that allows side effects outside of a monad; not Haskell), the ST monad does nothing to make it functional, and oh crap, now your functional programmer has the same problems as an imperative programmer, in having to figure out WTF this function just changed in some other imperative chunk of code, in some other process or object or whatever. So given imperative and functional paradigms, even using the ST monad, if the functional code is to call the imperative, and the imperative is to call the functional, both the functional and the imperative developers have to understand the other paradigm, -and- deal with the considerations of both. You've upped the complexity of your system considerably.
tel 12y ago
If you like Scala but find it too scattered then there's always Haskell* :) (*) Not that there aren't a thousand reasons to not choose Haskell. This is merely obligatory temptation dangling.
- dyeje 12y ago
  Took me a minute to parse that triple negative.
  - tel 12y ago
    Yeah, I don't blame you. English is the worst. let P = let S = { s ∈ Reasons | s : ¬ Choose Haskell } in (S, |S| > 1000) in ¬(¬∃ P)
    - deleted 12y ago
      [deleted]
- bunderbunder 12y ago
  Or F#, which is perhaps a more comfortable alternative for people who would otherwise be considering Scala. Incidentally, I've finally started to sink my teeth into Scala with a larger project. So far my impression has been "Very nearly as good a language for functional programming as C#." It's got ML-ish syntax, but the Java-y OOisms are just way too front-and-center for comfort. Case classes and extractor patterns, I'm looking at you.
  - sixbrx 12y ago
    Isn't subtyping OO the principal way to do polymorphism in F#? I ask because the last time I looked, it didn't do type classes, nor ML modules, but maybe that's changed. Scala has a pretty powerful notion of type classes and this is a big part of what gives it a functional feel to me.
    - bjz_ 12y ago
waps 12y ago
A programmer complains that different programmers have different styles of programming in Scala ... and ... switches to a lisp. You know, languages that execute code by rewriting the syntax tree of the running program ... This ought to be good. This is not meant to be disparaging against LISPs. I'm just alluding to the fact that while there are 5-10 ways to do the same thing in Scala, all looking very different, working subtly different, there's 5000 different ways to do the same thing in LISPs.
- lostcolony 12y ago
  Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. And Clojure seems to have developed idioms around simplicity. Scala, on the other hand, has wildly diverging sets of best practices. The feature set is huge, attempting to appeal to pure functional programmers in their academic ivory towers, and the grizzled Java developers who believe OOP is the one true way, and everyone in between. It's easy to -say- that there are 5000 ways to do the same thing in a LISP, and only 5-10 ways to do the same thing in Scala (both statements being hyperbolic, presumably; there are infinitely many ways of doing each, after all), the meaningful variations you are likely to see in the wild are far, far lower in Clojure than Scala. And will likely be based on different understandings/expressions of the problem, rather than on different language subsets that the author prefers.
  - pekk 12y ago
    If macros are agreed by all Lisp users to be a "use rarely" thing, then why is internet Lisp advocacy so strongly focused on macros as an advantage of Lisp over the rest of the world?
    - sls 12y ago
      Rarely isn't never. I'd join in the recommendation above to read pg's "On Lisp" to get a sense of the sort of things one can accomplish with a few small macros. But just as a sampler, if your language has a preprocessor phase where source code is manipulated by source code you provide, you can add control structures. Maybe your language has a loop construct but no way to iterate through a collection without explicit indices. You can add that, and it will be a first-class control structure that gets to control evaluation and everything. You do not have to file a feature request and drum up support and wait five years to get it.
serve_yay 12y ago
Well, OK.
swah 12y ago
fogus, what should I read nowadays? BOOKS??? http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thoughtfulness-in-blogging/ http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thought...
- swah 12y ago
  Ok found the answer http://michaelrbernste.in/2014/10/21/should-i-read-papers.html http://michaelrbernste.in/2014/10/21/should-i-read-papers.ht...
emcrazyone 12y ago
I think the article is fundamentally flawed from this comment alone: "In well over a year of working in Scala teams there hasn’t been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem." So this guy expects a programming language to create a shared mindset? I've been developing software for close to 17 years in more languages than you can shake a stick at and none of them do this for you. It's always about picking the right tool for the job and/or team. A shared mindset comes from other planning type activities like use cases, function/non-functional specifications, and general architecture type planning before you write code. Especially for larger projects. I think software patterns tend to help drive synergy in a team environment. It's not perfect but my experience has shown me and the folks I work with at least, that adopting patterns helps to bring us together but those patterns are usually fleshed out during architecture planning activities.
- cwyers 12y ago
  I think there's a huge contrast between a language like Perl, where There Is More Than One Way To Do It, and say Python, where "There should be one -- and preferably only one -- obvious way to do it."
  - RodgerTheGreat 12y ago
    "The Zen of Python" makes a number of lofty claims like that, but the actual language design doesn't embody them well if at all. To pick an example off the top of my head, there are three syntaxes for string literals (single quote, double quote, triple quote) and three prefixes (raw, binary, unicode) which can be combined in a number of ways. As a result python offers 15 ways(!) to express a string literal.
    - pekk 12y ago
      That's really disingenuous. The "Zen of Python" is not bragging on the part of Python, but an expression of values in a community.
kev6168 12y ago
No offense to the author, but this reads like a 16 old claiming he finally find the girl who is 'the one' for life. __only two years later__, that Another girl shows up and OMG the new chick definitely is the 'true' one. To put it another way, under extreme circumstances, Mr. Martin Odesky can use even the $&^%$#$ PHP to write safe and efficient airplane flying control software. The point is the language is hardly matter as much as your kids think. There are far more important things for good software. But language is not only a tool but also a toy and a passion, so I can appreciate the urge to talk about it. :-)
- nickik 12y ago
  > No offense to the author, but this reads like a 16 old claiming he finally find the girl who is 'the one' for his whole life. I think thats what he was going for. > There are far more important things for good software. Everybody knows this, but people still like to talk about programming languages.
  - matthiasn 12y ago
    Yes, I was experimenting with exactly that style of writing, guess it worked ;)
  - thekingofspain 12y ago
    Additionally, I think what's key is to note that he wasn't pumping Clojure too hard in the post. It was more a post about why he's leaving Scala. And in that analogy, you can be pretty certain that the girl you're leaving is definitely not "the one".
covi 12y ago
There are three and only three vague points conveyed in the article: (1) Scala has "immense" syntax, (2) Scala tries to support too many paradigms, and (3) the Iteratee library is hard to grasp. For (1): I disagree -- Scala's syntax is relatively easy to grasp. Perhaps the author meant constructs. For (2): people keep saying this but why not just stick with the way you are comfortable with? For (3): I don't see how this is a language issue; at the very least it shows that the author is unable to grasp a particular functional programming abstraction.
- jbergens 12y ago
  (1) I think you can safely assume that he means constructs. If he has spent years writing Scala he has surely grasped the syntax. (2) A team may have many people with different feelings about what they are comfortable with. This raises problems in an enterprise environment. (3) I can only guess that he feels the library is so hard that many developers with struggle with it. I think Go is an interesting language partly because they seem to keep it simple by choice.
swah 12y ago
His Clojure implementation is here: https://github.com/matthiasn/BirdWatch/tree/master/Clojure-Websockets https://github.com/matthiasn/BirdWatch/tree/master/Clojure-W...
noelwelsh 12y ago
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.
saosebastiao 12y ago
Interesting. I've followed Matthias' project as I've tried learning the Play framework as well as front end development, and it has been incredibly useful. Incidentally, I learned Scala after I knew Clojure reasonably well, and I feel like I could apply the same arguments in the reverse direction. When it comes to the back end, I'll likely choose Scala 100% of the time. I really believe there is no substitute for a strongly typed ML-derivative for that type of environment. Additionally, there are a strong set of robust scala libraries (Typesafe mostly) that are completely production ready, and java interop is much more natural when you need it. For the front end, I'm currently using Javascript, but I have toyed with the idea of both Scala.js and Clojurescript. This is where Clojure really makes me mad. I feel as though the dynamically typed Clojurescript should be a better fit as a compile-to-javascript language, but in every instance I've tried, Scala.js just works better. It compiles correctly, error messages make sense, much better documented, and there are fewer deviations from the core language. And the clojurescript libraries are mostly terrible in this regard...even the super-hyped ones like Om. My biggest pet peeve are the tutorials that force you to learn unrelated things (like Datomic, Emacs, Ring, etc) to be able to walk through them. I really feel like Clojurescript had a chance to shine here, but I find it far less inspiring than the relatively immature Scala.js. Oh well.
deleted 12y ago
[deleted]

104 points by fogus 12y ago

I found your experience closely mirrors mine with scala. At my current shop we write mostly ruby and scala. The ruby code between developers looks much more uniform than the scala code I believe due to the fact that while trying to please everyone scala hasn't yet developed much of "the scala way". I do hope this changes as I really enjoy scala. Currently my team is experimenting with style/punting tools like stylecop to try to bring a little consistency to our code. Too early to say how it will work out but I would love to hear from others how you try to bring a team style to a code base that will happily let a fully functional developer, a fully object oriented developer, a straight imperative developer, and someone who believes in mixing these things all work side by side. Mentally by giving up the possibility of nothing you have to learn everything which means loading a lot of the scala compiler up into your brain before even trying to read a bit of anyone else's code.

lostcolony 12y ago
Mixing an imperative developer with a functional developer? That's asking for trouble. You'll have to be converting between mutable and immutable data structures anywhere the two interact. Or forcing the imperative developer to be largely functional due to the immutable data structures everywhere that prevent him from using imperative approaches. Or forcing the functional developer to write in a largely imperative style due to the mutable data structures that prevent copying from being efficient, and can be mutated any time they pass out of his/her code. Or to put it another way; Scala as an idea may be fine; you can mix imperative and functional together, by picking which data structure and approach for a given problem is 'right'. But in a team environment? Touching someone else's code in a particular paradigm means you have to be familiar with, and expect, that paradigm. You can come up with a team that agrees on what paradigm everything must be written in (and that can be anywhere on the continuum), but you can't mix and match and expect developers to not have to learn every paradigm in use.
- tel 12y ago
  The ST monad would like a work with you :)
  - asdf1234 12y ago
    Pervasive use of ST, or almost any monad for that matter, leads to serious problems in Scala since you basically have to use trampolines and take a massive performance hit. It's also extremely verbose to do it correctly. It's a good solution in Haskell though.
    - runT1ME 12y ago
      This is FUD. You often don't need trampolines and there are better solutions than trampolines.
      - asdf1234 12y ago
        It's debatable whether abusing Free is a better solution. Either way, programming like this is disgusting in Scala and comes with tons of caveats compared to Haskell.
  - lostcolony 12y ago
    Which doesn't help the imperative programmer who is having to interact with functional code. And an ST monad makes no sense unless you're interacting with imperative code (obviously, hence your bringing it up), which means you already understand what imperative is, and are still having to convert your immutable structure to a mutable one, for the imperative code to operate on, and to recognize it will be modified in place; to use the ST monad the functional programmer already has to understand imperative programming. It also seems like it would fail to encapsulate the side effects an imperative function may have, since that function is able to interact with state elsewhere, that isn't actually encapsulated. I.e., the ST monad makes sense when dropping into update-in-place for performance reasons, but when there are side effects that are not ensconced within the monad (remember, the function you're calling was written by an imperative programmer, in a language that allows side effects outside of a monad; not Haskell), the ST monad does nothing to make it functional, and oh crap, now your functional programmer has the same problems as an imperative programmer, in having to figure out WTF this function just changed in some other imperative chunk of code, in some other process or object or whatever. So given imperative and functional paradigms, even using the ST monad, if the functional code is to call the imperative, and the imperative is to call the functional, both the functional and the imperative developers have to understand the other paradigm, -and- deal with the considerations of both. You've upped the complexity of your system considerably.

tel 12y ago

If you like Scala but find it too scattered then there's always Haskell* :) (*) Not that there aren't a thousand reasons to not choose Haskell. This is merely obligatory temptation dangling.

dyeje 12y ago
Took me a minute to parse that triple negative.
- tel 12y ago
  Yeah, I don't blame you. English is the worst. let P = let S = { s ∈ Reasons | s : ¬ Choose Haskell } in (S, |S| > 1000) in ¬(¬∃ P)
  - deleted 12y ago
    [deleted]
bunderbunder 12y ago
Or F#, which is perhaps a more comfortable alternative for people who would otherwise be considering Scala. Incidentally, I've finally started to sink my teeth into Scala with a larger project. So far my impression has been "Very nearly as good a language for functional programming as C#." It's got ML-ish syntax, but the Java-y OOisms are just way too front-and-center for comfort. Case classes and extractor patterns, I'm looking at you.
- sixbrx 12y ago
  Isn't subtyping OO the principal way to do polymorphism in F#? I ask because the last time I looked, it didn't do type classes, nor ML modules, but maybe that's changed. Scala has a pretty powerful notion of type classes and this is a big part of what gives it a functional feel to me.
  - bjz_ 12y ago

waps 12y ago

A programmer complains that different programmers have different styles of programming in Scala ... and ... switches to a lisp. You know, languages that execute code by rewriting the syntax tree of the running program ... This ought to be good. This is not meant to be disparaging against LISPs. I'm just alluding to the fact that while there are 5-10 ways to do the same thing in Scala, all looking very different, working subtly different, there's 5000 different ways to do the same thing in LISPs.

lostcolony 12y ago
Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. And Clojure seems to have developed idioms around simplicity. Scala, on the other hand, has wildly diverging sets of best practices. The feature set is huge, attempting to appeal to pure functional programmers in their academic ivory towers, and the grizzled Java developers who believe OOP is the one true way, and everyone in between. It's easy to -say- that there are 5000 ways to do the same thing in a LISP, and only 5-10 ways to do the same thing in Scala (both statements being hyperbolic, presumably; there are infinitely many ways of doing each, after all), the meaningful variations you are likely to see in the wild are far, far lower in Clojure than Scala. And will likely be based on different understandings/expressions of the problem, rather than on different language subsets that the author prefers.
- pekk 12y ago
  If macros are agreed by all Lisp users to be a "use rarely" thing, then why is internet Lisp advocacy so strongly focused on macros as an advantage of Lisp over the rest of the world?
  - sls 12y ago
    Rarely isn't never. I'd join in the recommendation above to read pg's "On Lisp" to get a sense of the sort of things one can accomplish with a few small macros. But just as a sampler, if your language has a preprocessor phase where source code is manipulated by source code you provide, you can add control structures. Maybe your language has a loop construct but no way to iterate through a collection without explicit indices. You can add that, and it will be a first-class control structure that gets to control evaluation and everything. You do not have to file a feature request and drum up support and wait five years to get it.

serve_yay 12y ago

Well, OK.

swah 12y ago

fogus, what should I read nowadays? BOOKS??? http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thoughtfulness-in-blogging/ http://blog.fogus.me/2011/03/27/the-long-lost-art-of-thought...

swah 12y ago
Ok found the answer http://michaelrbernste.in/2014/10/21/should-i-read-papers.html http://michaelrbernste.in/2014/10/21/should-i-read-papers.ht...

emcrazyone 12y ago

I think the article is fundamentally flawed from this comment alone: "In well over a year of working in Scala teams there hasn’t been a single day where I felt that there was a shared mindset about how to develop a system or even approach a problem." So this guy expects a programming language to create a shared mindset? I've been developing software for close to 17 years in more languages than you can shake a stick at and none of them do this for you. It's always about picking the right tool for the job and/or team. A shared mindset comes from other planning type activities like use cases, function/non-functional specifications, and general architecture type planning before you write code. Especially for larger projects. I think software patterns tend to help drive synergy in a team environment. It's not perfect but my experience has shown me and the folks I work with at least, that adopting patterns helps to bring us together but those patterns are usually fleshed out during architecture planning activities.

cwyers 12y ago
I think there's a huge contrast between a language like Perl, where There Is More Than One Way To Do It, and say Python, where "There should be one -- and preferably only one -- obvious way to do it."
- RodgerTheGreat 12y ago
  "The Zen of Python" makes a number of lofty claims like that, but the actual language design doesn't embody them well if at all. To pick an example off the top of my head, there are three syntaxes for string literals (single quote, double quote, triple quote) and three prefixes (raw, binary, unicode) which can be combined in a number of ways. As a result python offers 15 ways(!) to express a string literal.
  - pekk 12y ago
    That's really disingenuous. The "Zen of Python" is not bragging on the part of Python, but an expression of values in a community.

kev6168 12y ago

No offense to the author, but this reads like a 16 old claiming he finally find the girl who is 'the one' for life. __only two years later__, that Another girl shows up and OMG the new chick definitely is the 'true' one. To put it another way, under extreme circumstances, Mr. Martin Odesky can use even the $&^%$#$ PHP to write safe and efficient airplane flying control software. The point is the language is hardly matter as much as your kids think. There are far more important things for good software. But language is not only a tool but also a toy and a passion, so I can appreciate the urge to talk about it. :-)

nickik 12y ago
> No offense to the author, but this reads like a 16 old claiming he finally find the girl who is 'the one' for his whole life. I think thats what he was going for. > There are far more important things for good software. Everybody knows this, but people still like to talk about programming languages.
- matthiasn 12y ago
  Yes, I was experimenting with exactly that style of writing, guess it worked ;)
- thekingofspain 12y ago
  Additionally, I think what's key is to note that he wasn't pumping Clojure too hard in the post. It was more a post about why he's leaving Scala. And in that analogy, you can be pretty certain that the girl you're leaving is definitely not "the one".

covi 12y ago

There are three and only three vague points conveyed in the article: (1) Scala has "immense" syntax, (2) Scala tries to support too many paradigms, and (3) the Iteratee library is hard to grasp. For (1): I disagree -- Scala's syntax is relatively easy to grasp. Perhaps the author meant constructs. For (2): people keep saying this but why not just stick with the way you are comfortable with? For (3): I don't see how this is a language issue; at the very least it shows that the author is unable to grasp a particular functional programming abstraction.

jbergens 12y ago
(1) I think you can safely assume that he means constructs. If he has spent years writing Scala he has surely grasped the syntax. (2) A team may have many people with different feelings about what they are comfortable with. This raises problems in an enterprise environment. (3) I can only guess that he feels the library is so hard that many developers with struggle with it. I think Go is an interesting language partly because they seem to keep it simple by choice.

swah 12y ago

His Clojure implementation is here: https://github.com/matthiasn/BirdWatch/tree/master/Clojure-Websockets https://github.com/matthiasn/BirdWatch/tree/master/Clojure-W...

noelwelsh 12y ago

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.

saosebastiao 12y ago

Interesting. I've followed Matthias' project as I've tried learning the Play framework as well as front end development, and it has been incredibly useful. Incidentally, I learned Scala after I knew Clojure reasonably well, and I feel like I could apply the same arguments in the reverse direction. When it comes to the back end, I'll likely choose Scala 100% of the time. I really believe there is no substitute for a strongly typed ML-derivative for that type of environment. Additionally, there are a strong set of robust scala libraries (Typesafe mostly) that are completely production ready, and java interop is much more natural when you need it. For the front end, I'm currently using Javascript, but I have toyed with the idea of both Scala.js and Clojurescript. This is where Clojure really makes me mad. I feel as though the dynamically typed Clojurescript should be a better fit as a compile-to-javascript language, but in every instance I've tried, Scala.js just works better. It compiles correctly, error messages make sense, much better documented, and there are fewer deviations from the core language. And the clojurescript libraries are mostly terrible in this regard...even the super-hyped ones like Om. My biggest pet peeve are the tutorials that force you to learn unrelated things (like Datomic, Emacs, Ring, etc) to be able to walk through them. I really feel like Clojurescript had a chance to shine here, but I find it far less inspiring than the relatively immature Scala.js. Oh well.

deleted 12y ago

[deleted]