4 ms·

The two problems I have with Scala are: (1) it tries to be too much by allowing optional types and the clarity of the code suffers- either embrace duck typing o

by hakaaak 14y ago

The two problems I have with Scala are: (1) it tries to be too much by allowing optional types and the clarity of the code suffers- either embrace duck typing or don't, (2) Play v2 killed all chance of it becoming a decent web developer's go-to language. For those that are learning Scala just for the hell of it, great. But, don't intend to make a career out of it unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure, etc.

bretthoerner 14y ago
Can you give concrete examples of both?
coopdog 14y ago
1) The typing isn't actually optional, you just don't have to write it as long as it can be inferred, which is the best of both worlds. If you're ever unsure of which type it is just mouse over in the ide, or specify it and wait for an error 2) not sure what you mean here
millennium2 14y ago
I try to understand what you try to say and have several interpretations, but sadly none of them seem to make sense. What do you mean with 'optional types' and what does that comment about Play have to do with Scala? Care to explain?
- deleted 14y ago
  [deleted]
  - eeperson 14y ago
    1. I'm not sure I understand the complaint about arguments. From you example it looks to me like the problem is that Scala requires type declarations and supports default arguments. I don't understand how this is worse than the equivalent Java example. I also don't understand how the Ruby version is inherently better. The only difference seems to be static vs. dynamic typing. 2. I don't understand how Play 2 screwed over Scala developers. It seems like Play 2 is much better for Scala developers. Scala is now a first class supported language instead of just an add on module. I also don't understand how Play 1 was 'the' thing that was bringing web developers to Scala. It wasn't in any way a core part of the framework. It was just something you could optionally use. Scala is something you could optionally use in any Java web framework.
kickatree 14y ago
> "For those that are learning Scala just for the hell of it, great. But, don't intend to make a career out of it unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure, etc." I did, and am currently making a career out of Scala. > "Play v2 killed all chance of it becoming a decent web developer's go-to language" We're quite happy with Play2, don't know why anyone would even consider picking Play v1 over it...
bad_user 14y ago
(1) when speaking of dynamic typing versus static typing, it's not a black and white issue - it's actually full of color, but if it helps, you can think of it as an axis where languages are the dots. Clojure is a dynamic language, but Ruby is more dynamic than Clojure, hence the machinery for running on the JVM is more complicated, which is why Clojure has better performance. Java is considered a static language, but because it is able of runtime introspection, runtime code generation and runtime dispatch, it is much, much more dynamic than a language like Haskell - which for the moment is the most static language out of all languages known to the mainstream. The issue of dynamic versus static is also not an issue of specifying types. In fact it has nothing to do with that. The real difference comes from what the compiler does at compile-time. By definition compilers using static typing will reject pieces of code that are correct if it cannot prove that the types used support the operations you say they support. With dynamic typing on the other hand you can basically make shit up and have it executed and fail at runtime instead of compile-time ... but where the boundaries lie between compile-time and runtime differs from language to language, a language being considered either static or dynamic depending on which side the balance is inclining ... and btw, ironically languages like Java are somewhere in the middle. I'm seeing programmers making a confusion between duck-typing and structural-typing or type-inferencing - like all the time, even though these concepts are fundamentally different, which shows unfamiliarity with either one or the other, but mostly with duck-typing, as duck-typing is really NOT about the lack of manifest-typing, which is just a side-effect. (2) Play v2 is not a language. I personally don't like it, as I don't like big frameworks, being more the kind of person that prefers smaller libraries that compose well. But Play v2 brings with it some really cool tools - statically type-safe templates, Iteratees for dealing with Comet/WebSockets, etc... if you evaluate Play v2 for building simple apps, like freaking blogs and such, some of the abstractions may seem over the top, but those abstractions are there to help you with other things you may need, as Play's philosophy is to be a "scalable" framework, while still being easy to use, just like Scala is a scalable language. The amount of pain you have to endure if you want to deal with Comet/Websockets in popular Ruby/Python frameworks is really breathtaking, while Play makes all of that easy and natural. Play v2 is more immature than Play v1, but it has better foundations and is just getting started. Play v1 wasn't going anywhere the way it was and sometimes major architectural changes are needed, even though the spirit remains the same - Rails 3 is also architecturally different from Rails 2 and 1, as the needs of web developers evolve and many companies haven't migrated. > unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure I second that argument. You should pick languages that are more suitable to personal style and more optimized for the problems you work on - however you have to be careful about it, as the metrics commonly used (e.g. beauty of syntax) are not so important as the resulting artifacts and also, language choice may be important, but is not as important as everything else (tools, libraries, ecosystem, community, etc...). Also, mentioning particular languages as having priority over Scala is weird. I have problems believing that you learned all of those languages you mention. If you specified 2, maybe 3, then I'd believe you, but why give advice for preferring languages you don't know? In particular, if you like Ruby and Python, you simply cannot mention Haskell in that same sentence as Haskell is everything that Ruby and Python aren't. And if you like Haskell, then placing Ruby and Python in that same sentence is some kind of abomination.

by hakaaak 14y ago

bretthoerner 14y ago

Can you give concrete examples of both?

coopdog 14y ago

1) The typing isn't actually optional, you just don't have to write it as long as it can be inferred, which is the best of both worlds. If you're ever unsure of which type it is just mouse over in the ide, or specify it and wait for an error 2) not sure what you mean here

millennium2 14y ago

I try to understand what you try to say and have several interpretations, but sadly none of them seem to make sense. What do you mean with 'optional types' and what does that comment about Play have to do with Scala? Care to explain?

deleted 14y ago
[deleted]
- eeperson 14y ago
  1. I'm not sure I understand the complaint about arguments. From you example it looks to me like the problem is that Scala requires type declarations and supports default arguments. I don't understand how this is worse than the equivalent Java example. I also don't understand how the Ruby version is inherently better. The only difference seems to be static vs. dynamic typing. 2. I don't understand how Play 2 screwed over Scala developers. It seems like Play 2 is much better for Scala developers. Scala is now a first class supported language instead of just an add on module. I also don't understand how Play 1 was 'the' thing that was bringing web developers to Scala. It wasn't in any way a core part of the framework. It was just something you could optionally use. Scala is something you could optionally use in any Java web framework.

kickatree 14y ago

> "For those that are learning Scala just for the hell of it, great. But, don't intend to make a career out of it unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure, etc." I did, and am currently making a career out of Scala. > "Play v2 killed all chance of it becoming a decent web developer's go-to language" We're quite happy with Play2, don't know why anyone would even consider picking Play v1 over it...

bad_user 14y ago

(1) when speaking of dynamic typing versus static typing, it's not a black and white issue - it's actually full of color, but if it helps, you can think of it as an axis where languages are the dots. Clojure is a dynamic language, but Ruby is more dynamic than Clojure, hence the machinery for running on the JVM is more complicated, which is why Clojure has better performance. Java is considered a static language, but because it is able of runtime introspection, runtime code generation and runtime dispatch, it is much, much more dynamic than a language like Haskell - which for the moment is the most static language out of all languages known to the mainstream. The issue of dynamic versus static is also not an issue of specifying types. In fact it has nothing to do with that. The real difference comes from what the compiler does at compile-time. By definition compilers using static typing will reject pieces of code that are correct if it cannot prove that the types used support the operations you say they support. With dynamic typing on the other hand you can basically make shit up and have it executed and fail at runtime instead of compile-time ... but where the boundaries lie between compile-time and runtime differs from language to language, a language being considered either static or dynamic depending on which side the balance is inclining ... and btw, ironically languages like Java are somewhere in the middle. I'm seeing programmers making a confusion between duck-typing and structural-typing or type-inferencing - like all the time, even though these concepts are fundamentally different, which shows unfamiliarity with either one or the other, but mostly with duck-typing, as duck-typing is really NOT about the lack of manifest-typing, which is just a side-effect. (2) Play v2 is not a language. I personally don't like it, as I don't like big frameworks, being more the kind of person that prefers smaller libraries that compose well. But Play v2 brings with it some really cool tools - statically type-safe templates, Iteratees for dealing with Comet/WebSockets, etc... if you evaluate Play v2 for building simple apps, like freaking blogs and such, some of the abstractions may seem over the top, but those abstractions are there to help you with other things you may need, as Play's philosophy is to be a "scalable" framework, while still being easy to use, just like Scala is a scalable language. The amount of pain you have to endure if you want to deal with Comet/Websockets in popular Ruby/Python frameworks is really breathtaking, while Play makes all of that easy and natural. Play v2 is more immature than Play v1, but it has better foundations and is just getting started. Play v1 wasn't going anywhere the way it was and sometimes major architectural changes are needed, even though the spirit remains the same - Rails 3 is also architecturally different from Rails 2 and 1, as the needs of web developers evolve and many companies haven't migrated. > unless you've checked into other languages first, like Ruby, Python, Haskell, Go, Clojure I second that argument. You should pick languages that are more suitable to personal style and more optimized for the problems you work on - however you have to be careful about it, as the metrics commonly used (e.g. beauty of syntax) are not so important as the resulting artifacts and also, language choice may be important, but is not as important as everything else (tools, libraries, ecosystem, community, etc...). Also, mentioning particular languages as having priority over Scala is weird. I have problems believing that you learned all of those languages you mention. If you specified 2, maybe 3, then I'd believe you, but why give advice for preferring languages you don't know? In particular, if you like Ruby and Python, you simply cannot mention Haskell in that same sentence as Haskell is everything that Ruby and Python aren't. And if you like Haskell, then placing Ruby and Python in that same sentence is some kind of abomination.