5 ms·

I would take some issue with that. I think if you see the dual goal of creating a very strong, pervasive type system and trying to maintain OO compatibility, th

I would take some issue with that. I think if you see the dual goal of creating a very strong, pervasive type system and trying to maintain OO compatibility, the features that are “thrown in” make a great deal of sense as a cohesive whole. It's certainly a complex language, but there is a coherent vision behind the features it has, IMO. That said, Scala certainly ain't perfect. It's certainly got its warts. And I'm not going to compare it to Clojure, as I haven't played with Clojure enough yet ;)

cgag 13y ago
I just think that dual goal is messy and not really a good goal. Can anyone comment on how possible it is to just ignore any OO stuff in Scala and just treat it like a normal statically typed functional language that happens to be on the JVM?
- pohl 13y ago
  Why wouldn't you be able to? That's sort of what they're getting at when they say (if you follow the link) right under the headline: "Or anything in-between." Your discriminated unions would be "in drag" as case classes, of course. You would want to be aware of the OO parts of the language, but there's little that obligates you to use them.
  - cgag 13y ago
    I'm not sure, I haven't looked very deeply at the language, I'm not sure if most of the libraries and culture and such make use of OO, or if it's just baggage for Java interop.
- kasey_junk 13y ago
  Quite easy with a couple of caveats: 1. You don't care about working with java libraries. 2. You don't care about generating tons of memory overhead. Personally, if you don't have dependencies on java and if your goal is to do a pure functional application, I would stay away from the JVM as it just wasn't built for it.
  - cgag 13y ago
    I haven't had any trouble doing mostly pure FP with Clojure, as the general pattern is to wrap Java libraries to present a functional interface, I guess I'm curious if this is the attitude in Scala, or if you're sort of forced to embrace OO.
- ericssmith 13y ago
  It's quite possible, up to a point. In fact, there is a new book "Functional Programming in Scala" that shows precisely how to do that. However, Scala is a fusion of OO and FP. Even its functional features are written in terms of objects. What you don't particularly need is mutable objects. But Scala's OO features -- notably traits -- are arguably useful for structuring code. As the language designer himself has said: Scala is not a better Java, it is not Haskell on the JVM. I would add that it isn't just SML on the JVM either. It is much better, in my opinion, to embrace Scala for what it is, a powerful, expressive, pragmatic language for industrial use.
mindcrime 13y ago
(Disclaimer: I'm pretty much a n00b at Scala) My biggest problem with Scala, to date, is all the optional syntax. On one hand, making things optional sounds nice, and it can be handy... but in Scala, you can have a line of code where there are 3 or 4 different ways to write it. Sorry, don't have a good example handy, I'd have to go through my "learning Scala" workspace to dig something up and I don't have that stuff nearby. Anyway, the point is, I sometimes feel like Scala can easily lead to a situation where one is writing "write only" code. I do not relish the idea of taking a large base of Scala code, written by somebody else, and trying to understand it well enough to work on it.

cgag 13y ago

I just think that dual goal is messy and not really a good goal. Can anyone comment on how possible it is to just ignore any OO stuff in Scala and just treat it like a normal statically typed functional language that happens to be on the JVM?

pohl 13y ago
Why wouldn't you be able to? That's sort of what they're getting at when they say (if you follow the link) right under the headline: "Or anything in-between." Your discriminated unions would be "in drag" as case classes, of course. You would want to be aware of the OO parts of the language, but there's little that obligates you to use them.
- cgag 13y ago
  I'm not sure, I haven't looked very deeply at the language, I'm not sure if most of the libraries and culture and such make use of OO, or if it's just baggage for Java interop.
kasey_junk 13y ago
Quite easy with a couple of caveats: 1. You don't care about working with java libraries. 2. You don't care about generating tons of memory overhead. Personally, if you don't have dependencies on java and if your goal is to do a pure functional application, I would stay away from the JVM as it just wasn't built for it.
- cgag 13y ago
  I haven't had any trouble doing mostly pure FP with Clojure, as the general pattern is to wrap Java libraries to present a functional interface, I guess I'm curious if this is the attitude in Scala, or if you're sort of forced to embrace OO.
ericssmith 13y ago
It's quite possible, up to a point. In fact, there is a new book "Functional Programming in Scala" that shows precisely how to do that. However, Scala is a fusion of OO and FP. Even its functional features are written in terms of objects. What you don't particularly need is mutable objects. But Scala's OO features -- notably traits -- are arguably useful for structuring code. As the language designer himself has said: Scala is not a better Java, it is not Haskell on the JVM. I would add that it isn't just SML on the JVM either. It is much better, in my opinion, to embrace Scala for what it is, a powerful, expressive, pragmatic language for industrial use.

mindcrime 13y ago

(Disclaimer: I'm pretty much a n00b at Scala) My biggest problem with Scala, to date, is all the optional syntax. On one hand, making things optional sounds nice, and it can be handy... but in Scala, you can have a line of code where there are 3 or 4 different ways to write it. Sorry, don't have a good example handy, I'd have to go through my "learning Scala" workspace to dig something up and I don't have that stuff nearby. Anyway, the point is, I sometimes feel like Scala can easily lead to a situation where one is writing "write only" code. I do not relish the idea of taking a large base of Scala code, written by somebody else, and trying to understand it well enough to work on it.