8 ms·

One reason I would love to see this succeed which has almost nothing to do with the particulars of the Frege project itself is the effect it would have on the S

One reason I would love to see this succeed which has almost nothing to do with the particulars of the Frege project itself is the effect it would have on the Scala community. There is a significant portion of the Scala community which desperately wants Scala to be the Haskell they can get their bosses buy in for. IMO the result is unsatisfactory, both for those people and the Scala community as a whole. If a straight Haskell variant in the JVM ecosystem were to "take off" then Scala could be its own thing.

MrBuddyCasino 11y ago
So thats the reason most Scala code reads like badly written Haskell fanfic.
- dudul 11y ago
  I think most scala code reads like badly written Java code, mostly because people use at as a "better Java". FP fanatics try to use it as Haskell for JVM, but they are definitely not the majority. Most scala users have no f-ing clue what a monad is :)
  - Nadya 11y ago
    To be fair, most programmers have no clue what a monad is. To understand what a monad is you first have to understand what a monad is. (No, that wasn't a typo.)
    - dudul 11y ago
      Ha true :) I was making a jest to say that most scala programmers don't know anything about FP and just use it for the type inference and stick to OO practices, vars, etc.
      - threeseed 11y ago
        No I think almost all Scala programmers understand the basics of FP. They just don't understand / have much interest in the intermediate/advanced parts. I've seen lots of beginners take to for comprehensions, maps, filters etc pretty quickly. The problem with Scala is that at an advanced level the code can become pretty unreadable.
      - k3d3 11y ago
        To be fair, I'd hardly say that not knowing what a monad is = not knowing anything about FP.
      - sanderjd 11y ago
        I'm honestly curious why Kotlin hasn't gathered more steam amongst this (gigantic) group of people. It seems like there's definitely room for a "Java, but a bit nicer", but that's not what Scala is intended to be. Did Scala just start winning before Kotlin was around?
        mindcrime 11y ago
        Did Scala just start winning before Kotlin was around? I think so. By the time I heard of Kotlin, I mentally lumped it in the basket of "just another JVM language". I mean, there are so many now, and you already had Groovy, Clojure, Scala, JRuby, and Jython pretty well established, along with a couple of dozen other niche players. Then Kotlin comes along... I don't know about most people, but I never heard anything about Kotlin that was so compelling that I felt the need to go mess with it. I mean, why what instead of Nice, or Fantom, or Gosu, or Beanshell, or Mira, etc., etc... Same thing for Ceylon. It looks like just another "also ran" to me. If the people behind these languages want people to use them, they are going to have to work hard to get the word out about whatever advantages (purported or real) they have.
        pron 11y ago
        I'll tell you why. Because right now Kotlin is the JVM language made by the largest company outside Java and Oracle. Well, technically, Ceylon is a Red Hat project, but Red Hat is a company that's basically built on lots of very loosely-related projects (Red Hat also fund JRuby, I believe), and one cannot say "Red Hat has Ceylon's back", while Kotlin certainly has JetBrains' back. As a result, it is also the non-Java JVM language with the best IDE support, best Android support and best build-tool support.
        mindcrime 11y ago
        Because right now Kotlin is the JVM language made by the largest company outside Java and Oracle Truth be told, I don't really find that very compelling. I mean, do programming languages always need "big company" support to be successful? I don't know. So far Scala, Clojure and Groovy have done pretty well, with varying degrees of commercial support. As a result, it is also the non-Java JVM language with the best IDE support, best Android support and best build-tool support. I guess, but here's the thing... the languages I use now (mainly Groovy and Java) have at least good enough IDE support, Android support (ok, I don't really care about that) and build-tool support. So even if Kotlin is incrementally better, or hell, even dramatically better, that stuff doesn't do a lot to sway me to Kotlin. That said, like most geeks, I like dabbling with new languages, and I am sure I'll try out Kotlin (and Ceylon) at some point. And maybe then one or the other will "wow" me. But for now, it isn't a high priority. And I expect a lot of other people are approaching it with a similar mindset.
      - coldtea 11y ago
        >don't know anything about FP Depends on how we define FP. Until 2010, when Haskell started to emerge as a HN fad, people were OK to define FP as what LISP programmers do, and didn't demand FP programmers know what a modad is, type theory or even use "immutability" everywhere... If you read discussions from 2000-2005 for example, very few people define FP as "what Haskell does".
        tome 11y ago
        Has Haskell really been a fad here for five years? It feels like just a year or two ...
    - david-given 11y ago
      I think a lot of the problems with monads is that they're way too low level to really get a grip on what they're for --- it's like trying to explain algebra by talking about manipulating pixels on a screen. Once I finally saw some of the things you can do with a monad rather than those useless examples based around Maybe, I had an 'aha!' moment as everything went click. No sodding idea what a monoid is, though.
      - rarepostinlurkr 11y ago
        Ooo! Something I think I can answer! A monoid is just a thing that knows how to add to itself!
        Nadya 11y ago
        My understanding of a monad is that it isn't currying or recursion though. E: I shouldn't even call it an understanding of monads. I've read at least 15+ explanations of what a monad is and still don't grok it.
        skwosh 11y ago
        Apologies in advance for the unsolicited monad tutorial (it's my turn to be that asshole)... Firstly, saying "`X` is a monad" is the same as saying "class `X` implements the monad interface". The monad interface is usually defined with `return` and `bind`, but I think it's more instructive to borrow the terminology from JavaScript's `Promise`... * `Promise#resolve(value)` is the same as `return`, also known as `pure`. It just wraps the given value in a promise. * `Promise#then(function)` combines both `bind` (when a new Promise is constructed and returned) and the functor method `map` (when a plain value is returned). To provide a unified monad/functor interface for both `Promise` and `Array` (using `wrap` instead of `resolve): // `then` provides both `bind` and `map` depending on the return type of the given function: Promise.prototype.map = Promise.prototype.then Promise.wrap = Promise.resolve // f maps elements to arrays of elements: Array.prototype.then = function (f) { return [].concat.apply ([], this.map(f)) } Array.wrap = function (x) { return [x] } There's no intrinsic value beyond that shared interface, it just allows you to write abstractions without knowing specifically what kind of monad you're dealing with (like the "do" syntax). EDIT: BTW, I've purposely skipped a few things in this description, it's meant to be illustrative, not definitive...
    - coldtea 11y ago
      I don't see why that should be the case though (apart from the prolification of bad, overwrought, explanations). Monads are not that exotic. People present it as "deep math" but for a mathematician for example it's kids stuff at the level you need to understand them for Haskell et al. It's like saying differential equations are some "deep voodoo math" (only monads are even simpler).
      - jbooth 11y ago
        I think the bad, overwrought explanations are the whole reason. Yes, they're much simpler than differential equations. But the difference is, differential equations are the simplest way to solve some difficult problems -- monads are often the gratuitously complex way to solve simple problems.
        iopq 11y ago
        Monads are simple ways to solve simple problems. Consider the Maybe monad - it encodes optional values in a simple way. The approach before this is to have something called "null" that would wreck your programs. Maybe monad is one of the best improvements to day-to-day programming tasks that I've personally experienced in my lifetime.
        mafribe 11y ago
        I agree, the concept of monads is very simple, actually trivial. It's just a generalised form of function composition. But thinking monadically and abstracting monadically is extremely different from what programmers normally learn, for a start because important monads like state and exceptions are built-in features of most programming languages. Seeing that these things have a common pattern, and seeing that it may be worthwhile to abstract this common pattern takes a lot of time. The mismatch between the utter simplicity of the concept of monads, and the complicated explanations one comes across doesn't help.
    - kika 11y ago
      To be fair, (I think) you don't need to know category theory to successfully apply FP principles and/or use any functional language. I had a great (GREAT) success at using erlang not only not knowing what monad is, but even not knowing about existence of category theory at all, leave aside monads, monoids, functors, etc. You also don't need to know category theory to understand what monad is [0] This video is all you, as a practicing programmer, need to know about monads and it's just 1 hour long. [0] https://www.youtube.com/watch?v=ZhuHCtR3xq8 https://www.youtube.com/watch?v=ZhuHCtR3xq8
    - OnleMeMeMe 11y ago
      Monads, Monoids, Applicatives, all very simple things. Most people make it seem difficult just to show off and feel as part of an elite. Which is a shame as it prevents wider usage. James is one of the few people who don't make Monads into a mythical being. http://james-iry.blogspot.de/2007/09/monads-are-elephants-part-1.html http://james-iry.blogspot.de/2007/09/monads-are-elephants-pa...
  - mafribe 11y ago
    There is nothing wrong with using Scala as a better Java. Indeed that's what I recommend to Scala beginners with a background in OO. That's the beauty of multi-paradigm languages: pick and choose the language subset that works for you. Indeed I often program in a way that could be called "locally stateful, globally pure-functional". It's a good approach!
    - krisajenkins 11y ago
      "locally stateful, globally pure-functional" Can you expand on that, please? Because it seems to me that state fulness propagates up through the system. I can't imagine a system that was pure in the large but side-effecting in the small. I'd be interested to hear how that works...
      - dragonwriter 11y ago
        One way is to use local mutable state within functions that are implemented so as to be not rely on external state, which are then indistinguishable to calling code from pure functions.
        mafribe 11y ago
        Yes, that's what I had in mind. If only there was an effect system that could guarantee purity and at the same time not be in the way (i.e. allow full or Scala-like type inference). Then purity would be guaranteed by types, like it is in Haskell. (N.B. I'm not asking for Haskell's purity by default. I advocate impure as default, with a type guarantting purity.)
- idobai 11y ago
  Most Haskell code reads just ugly. No offense, but still true, unfortunately...
- hugofirth 11y ago
  Out of interest - are you talking about the use of symbolic operators? Or something else (like the prevalence of the Typeclass pattern)?
  - zak_mc_kracken 11y ago
    Probably that Scala is extremely verbose and boiler platey compared to Haskell as soon as you start playing with higher kinds. And when you use just regular Scala syntax, it's just pretty ugly code overall IMO (and one of the slowest compilers of the 21st century too).
Fiahil 11y ago
One particular "annoying" feature of Scala is the Java interoperability. It's obviously great because you have a large quantity of tools usable from the Java world, but it leads to large quantities of time spent wrapping them into clean Scala interfaces (or dealing with unmelodious APIs, pick your curse). I would love if I could avoid this with Fredge. But, in the end, I would probably be better off using Haskell directly.
- hugofirth 11y ago
  I agree that when, in the process of learning Scala, you get beyond the "better Java" stage the interop can feel frustrating. On the other hand Scala gains so much from it. Its a huge net-positive IMHO. As long as you are only bringing things in from Java-land, rather than going the other way though, the wrapping can be fairly minimal.
- voxfrege 11y ago
  > I would probably be better off using Haskell directly. This is certainly true. You can see Frege as a subset of Haskell 2010 plus some GHC extensions plus the native interface (i.e. the Java FFI). Unless you really need the JVM, Haskell (i.e. GHC) is the probably the better choice. Frege is just an offer for the minority that wants pure FP specifically on the JVM. Those people had no real choice until recently, given that CAL is dead, and E. Kmett's "ermine" not yet there.
- rozap 11y ago
  This is about 50% of the pain of Scala for me. I want to like scala, and some of the concepts behind it are neat, but in reality the act of writing it with the java interop, opaque unrepeatable errors, and compiler slowness makes it a fantastically unpleasant experience.
  - Fiahil 11y ago
    I'm sharing the same thoughts. I'm relieved I'm not alone in this world :)
pron 11y ago
There's an excellent implementation of OCaml for the JVM, which is, sadly, not well advertised (its author is a bit on the shy side): http://www.ocamljava.org/ http://www.ocamljava.org/
lmm 11y ago
The Haskelly parts of Scala are some of its best parts. It's always been a hybrid language, and it's always had a compromised design as part of that. But the result is wonderful, and either half alone would be diminished. And frankly any "boss-friendly Haskell" would have to have Scala-level Java interop, i.e. full support for inheritance, existentials and so on, at which point you end up going down the same path as Scala. If you want Java you know where to find it. Likewise with Haskell. Scala draws from both and that's its greatest strength.
- jbooth 11y ago
  Hopefully any future languages that prioritize java interop will do things like implement java.util.List rather than insist on renaming "add" to "+=" along with ":+", "+:", "+", "++", "++:" so that I have to constantly call .asScala, .asJava on collections while passing them around.
  - yawaramin 11y ago
    Why not just import the implicit Java-Scala list conversions?
    - hugofirth 11y ago
      This obviously comes down to personal preference but I personally prefer the explicit conversions for the added clarity.
  - lmm 11y ago
    Disagree. The collections are different and behave differently (e.g. the Scala ones are immutable), they should look different. Explicit .asScala and .asJava make the intent clear. They should only be necessary at the boundary.
- hugofirth 11y ago
  This is true - I love Scala for its hybrid nature. I'm just saying that I wish prominent members of its community would too. For example if you go on to the #scala IRC channel half the regulars on their will be complaining about how terrible Scala is ... For a variety of reasons that can be summed up as: its not Haskell. If you spend a bit of time there it fades to background noise and #scala is actually a really friendly and helpful place - but "x is hard to do in Scala because Scala [sucks]" is an odd impression to give a newcomer.

MrBuddyCasino 11y ago

So thats the reason most Scala code reads like badly written Haskell fanfic.

dudul 11y ago
I think most scala code reads like badly written Java code, mostly because people use at as a "better Java". FP fanatics try to use it as Haskell for JVM, but they are definitely not the majority. Most scala users have no f-ing clue what a monad is :)
- Nadya 11y ago
  To be fair, most programmers have no clue what a monad is. To understand what a monad is you first have to understand what a monad is. (No, that wasn't a typo.)
  - dudul 11y ago
    Ha true :) I was making a jest to say that most scala programmers don't know anything about FP and just use it for the type inference and stick to OO practices, vars, etc.
    - threeseed 11y ago
      No I think almost all Scala programmers understand the basics of FP. They just don't understand / have much interest in the intermediate/advanced parts. I've seen lots of beginners take to for comprehensions, maps, filters etc pretty quickly. The problem with Scala is that at an advanced level the code can become pretty unreadable.
    - k3d3 11y ago
      To be fair, I'd hardly say that not knowing what a monad is = not knowing anything about FP.
    - sanderjd 11y ago
      I'm honestly curious why Kotlin hasn't gathered more steam amongst this (gigantic) group of people. It seems like there's definitely room for a "Java, but a bit nicer", but that's not what Scala is intended to be. Did Scala just start winning before Kotlin was around?
      - mindcrime 11y ago
        Did Scala just start winning before Kotlin was around? I think so. By the time I heard of Kotlin, I mentally lumped it in the basket of "just another JVM language". I mean, there are so many now, and you already had Groovy, Clojure, Scala, JRuby, and Jython pretty well established, along with a couple of dozen other niche players. Then Kotlin comes along... I don't know about most people, but I never heard anything about Kotlin that was so compelling that I felt the need to go mess with it. I mean, why what instead of Nice, or Fantom, or Gosu, or Beanshell, or Mira, etc., etc... Same thing for Ceylon. It looks like just another "also ran" to me. If the people behind these languages want people to use them, they are going to have to work hard to get the word out about whatever advantages (purported or real) they have.
        pron 11y ago
        I'll tell you why. Because right now Kotlin is the JVM language made by the largest company outside Java and Oracle. Well, technically, Ceylon is a Red Hat project, but Red Hat is a company that's basically built on lots of very loosely-related projects (Red Hat also fund JRuby, I believe), and one cannot say "Red Hat has Ceylon's back", while Kotlin certainly has JetBrains' back. As a result, it is also the non-Java JVM language with the best IDE support, best Android support and best build-tool support.
        mindcrime 11y ago
        Because right now Kotlin is the JVM language made by the largest company outside Java and Oracle Truth be told, I don't really find that very compelling. I mean, do programming languages always need "big company" support to be successful? I don't know. So far Scala, Clojure and Groovy have done pretty well, with varying degrees of commercial support. As a result, it is also the non-Java JVM language with the best IDE support, best Android support and best build-tool support. I guess, but here's the thing... the languages I use now (mainly Groovy and Java) have at least good enough IDE support, Android support (ok, I don't really care about that) and build-tool support. So even if Kotlin is incrementally better, or hell, even dramatically better, that stuff doesn't do a lot to sway me to Kotlin. That said, like most geeks, I like dabbling with new languages, and I am sure I'll try out Kotlin (and Ceylon) at some point. And maybe then one or the other will "wow" me. But for now, it isn't a high priority. And I expect a lot of other people are approaching it with a similar mindset.
    - coldtea 11y ago
      >don't know anything about FP Depends on how we define FP. Until 2010, when Haskell started to emerge as a HN fad, people were OK to define FP as what LISP programmers do, and didn't demand FP programmers know what a modad is, type theory or even use "immutability" everywhere... If you read discussions from 2000-2005 for example, very few people define FP as "what Haskell does".
      - tome 11y ago
        Has Haskell really been a fad here for five years? It feels like just a year or two ...
  - david-given 11y ago
    I think a lot of the problems with monads is that they're way too low level to really get a grip on what they're for --- it's like trying to explain algebra by talking about manipulating pixels on a screen. Once I finally saw some of the things you can do with a monad rather than those useless examples based around Maybe, I had an 'aha!' moment as everything went click. No sodding idea what a monoid is, though.
    - rarepostinlurkr 11y ago
      Ooo! Something I think I can answer! A monoid is just a thing that knows how to add to itself!
      - Nadya 11y ago
        My understanding of a monad is that it isn't currying or recursion though. E: I shouldn't even call it an understanding of monads. I've read at least 15+ explanations of what a monad is and still don't grok it.
        skwosh 11y ago
        Apologies in advance for the unsolicited monad tutorial (it's my turn to be that asshole)... Firstly, saying "`X` is a monad" is the same as saying "class `X` implements the monad interface". The monad interface is usually defined with `return` and `bind`, but I think it's more instructive to borrow the terminology from JavaScript's `Promise`... * `Promise#resolve(value)` is the same as `return`, also known as `pure`. It just wraps the given value in a promise. * `Promise#then(function)` combines both `bind` (when a new Promise is constructed and returned) and the functor method `map` (when a plain value is returned). To provide a unified monad/functor interface for both `Promise` and `Array` (using `wrap` instead of `resolve): // `then` provides both `bind` and `map` depending on the return type of the given function: Promise.prototype.map = Promise.prototype.then Promise.wrap = Promise.resolve // f maps elements to arrays of elements: Array.prototype.then = function (f) { return [].concat.apply ([], this.map(f)) } Array.wrap = function (x) { return [x] } There's no intrinsic value beyond that shared interface, it just allows you to write abstractions without knowing specifically what kind of monad you're dealing with (like the "do" syntax). EDIT: BTW, I've purposely skipped a few things in this description, it's meant to be illustrative, not definitive...
  - coldtea 11y ago
    I don't see why that should be the case though (apart from the prolification of bad, overwrought, explanations). Monads are not that exotic. People present it as "deep math" but for a mathematician for example it's kids stuff at the level you need to understand them for Haskell et al. It's like saying differential equations are some "deep voodoo math" (only monads are even simpler).
    - jbooth 11y ago
      I think the bad, overwrought explanations are the whole reason. Yes, they're much simpler than differential equations. But the difference is, differential equations are the simplest way to solve some difficult problems -- monads are often the gratuitously complex way to solve simple problems.
      - iopq 11y ago
        Monads are simple ways to solve simple problems. Consider the Maybe monad - it encodes optional values in a simple way. The approach before this is to have something called "null" that would wreck your programs. Maybe monad is one of the best improvements to day-to-day programming tasks that I've personally experienced in my lifetime.
        mafribe 11y ago
        I agree, the concept of monads is very simple, actually trivial. It's just a generalised form of function composition. But thinking monadically and abstracting monadically is extremely different from what programmers normally learn, for a start because important monads like state and exceptions are built-in features of most programming languages. Seeing that these things have a common pattern, and seeing that it may be worthwhile to abstract this common pattern takes a lot of time. The mismatch between the utter simplicity of the concept of monads, and the complicated explanations one comes across doesn't help.
  - kika 11y ago
    To be fair, (I think) you don't need to know category theory to successfully apply FP principles and/or use any functional language. I had a great (GREAT) success at using erlang not only not knowing what monad is, but even not knowing about existence of category theory at all, leave aside monads, monoids, functors, etc. You also don't need to know category theory to understand what monad is [0] This video is all you, as a practicing programmer, need to know about monads and it's just 1 hour long. [0] https://www.youtube.com/watch?v=ZhuHCtR3xq8 https://www.youtube.com/watch?v=ZhuHCtR3xq8
  - OnleMeMeMe 11y ago
    Monads, Monoids, Applicatives, all very simple things. Most people make it seem difficult just to show off and feel as part of an elite. Which is a shame as it prevents wider usage. James is one of the few people who don't make Monads into a mythical being. http://james-iry.blogspot.de/2007/09/monads-are-elephants-part-1.html http://james-iry.blogspot.de/2007/09/monads-are-elephants-pa...
- mafribe 11y ago
  There is nothing wrong with using Scala as a better Java. Indeed that's what I recommend to Scala beginners with a background in OO. That's the beauty of multi-paradigm languages: pick and choose the language subset that works for you. Indeed I often program in a way that could be called "locally stateful, globally pure-functional". It's a good approach!
  - krisajenkins 11y ago
    "locally stateful, globally pure-functional" Can you expand on that, please? Because it seems to me that state fulness propagates up through the system. I can't imagine a system that was pure in the large but side-effecting in the small. I'd be interested to hear how that works...
    - dragonwriter 11y ago
      One way is to use local mutable state within functions that are implemented so as to be not rely on external state, which are then indistinguishable to calling code from pure functions.
      - mafribe 11y ago
        Yes, that's what I had in mind. If only there was an effect system that could guarantee purity and at the same time not be in the way (i.e. allow full or Scala-like type inference). Then purity would be guaranteed by types, like it is in Haskell. (N.B. I'm not asking for Haskell's purity by default. I advocate impure as default, with a type guarantting purity.)
idobai 11y ago
Most Haskell code reads just ugly. No offense, but still true, unfortunately...
hugofirth 11y ago
Out of interest - are you talking about the use of symbolic operators? Or something else (like the prevalence of the Typeclass pattern)?
- zak_mc_kracken 11y ago
  Probably that Scala is extremely verbose and boiler platey compared to Haskell as soon as you start playing with higher kinds. And when you use just regular Scala syntax, it's just pretty ugly code overall IMO (and one of the slowest compilers of the 21st century too).

Fiahil 11y ago

One particular "annoying" feature of Scala is the Java interoperability. It's obviously great because you have a large quantity of tools usable from the Java world, but it leads to large quantities of time spent wrapping them into clean Scala interfaces (or dealing with unmelodious APIs, pick your curse). I would love if I could avoid this with Fredge. But, in the end, I would probably be better off using Haskell directly.

hugofirth 11y ago
I agree that when, in the process of learning Scala, you get beyond the "better Java" stage the interop can feel frustrating. On the other hand Scala gains so much from it. Its a huge net-positive IMHO. As long as you are only bringing things in from Java-land, rather than going the other way though, the wrapping can be fairly minimal.
voxfrege 11y ago
> I would probably be better off using Haskell directly. This is certainly true. You can see Frege as a subset of Haskell 2010 plus some GHC extensions plus the native interface (i.e. the Java FFI). Unless you really need the JVM, Haskell (i.e. GHC) is the probably the better choice. Frege is just an offer for the minority that wants pure FP specifically on the JVM. Those people had no real choice until recently, given that CAL is dead, and E. Kmett's "ermine" not yet there.
rozap 11y ago
This is about 50% of the pain of Scala for me. I want to like scala, and some of the concepts behind it are neat, but in reality the act of writing it with the java interop, opaque unrepeatable errors, and compiler slowness makes it a fantastically unpleasant experience.
- Fiahil 11y ago
  I'm sharing the same thoughts. I'm relieved I'm not alone in this world :)

pron 11y ago

There's an excellent implementation of OCaml for the JVM, which is, sadly, not well advertised (its author is a bit on the shy side): http://www.ocamljava.org/ http://www.ocamljava.org/

lmm 11y ago

The Haskelly parts of Scala are some of its best parts. It's always been a hybrid language, and it's always had a compromised design as part of that. But the result is wonderful, and either half alone would be diminished. And frankly any "boss-friendly Haskell" would have to have Scala-level Java interop, i.e. full support for inheritance, existentials and so on, at which point you end up going down the same path as Scala. If you want Java you know where to find it. Likewise with Haskell. Scala draws from both and that's its greatest strength.

jbooth 11y ago
Hopefully any future languages that prioritize java interop will do things like implement java.util.List rather than insist on renaming "add" to "+=" along with ":+", "+:", "+", "++", "++:" so that I have to constantly call .asScala, .asJava on collections while passing them around.
- yawaramin 11y ago
  Why not just import the implicit Java-Scala list conversions?
  - hugofirth 11y ago
    This obviously comes down to personal preference but I personally prefer the explicit conversions for the added clarity.
- lmm 11y ago
  Disagree. The collections are different and behave differently (e.g. the Scala ones are immutable), they should look different. Explicit .asScala and .asJava make the intent clear. They should only be necessary at the boundary.
hugofirth 11y ago
This is true - I love Scala for its hybrid nature. I'm just saying that I wish prominent members of its community would too. For example if you go on to the #scala IRC channel half the regulars on their will be complaining about how terrible Scala is ... For a variety of reasons that can be summed up as: its not Haskell. If you spend a bit of time there it fades to background noise and #scala is actually a really friendly and helpful place - but "x is hard to do in Scala because Scala [sucks]" is an odd impression to give a newcomer.