4 ms·

Good engineering practise? 1. Lack of documentation 2. Breaking backwards compatibility 3. Opaque error messages 4. Encourages ad-hoc syntax that makes sens

Good engineering practise? 1. Lack of documentation 2. Breaking backwards compatibility 3. Opaque error messages 4. Encourages ad-hoc syntax that makes sense to one person (or team) but does not to the next -- maintenance nightmare. 5. Lack of general stability in language and libraries serving to confuse the eco-system. Hmmm....

bad_user 13y ago
> 1. Lack of documentation Again, in my experience, the documentation in Scala land is very good. The standard library has a really good API documentation, also checkout the documentation project at http://docs.scala-lang.org/ http://docs.scala-lang.org/ plus there are several very good books available; then there are the libraries in Scala's ecosystem, like Play2, or Akka, or Slick for example that do have good documentation. The online documentation for Play2 does not match the online documentation for Ruby on Rails or Django, but it's newer and it's improving and I remember a time when Rails was several years old and lacked online documentation. I did find undocumented features in Play2's online documentation, but nothing that couldn't be solved with a question on its mailing list. These are open-source libraries, with strong communities that communicate a lot on mailing lists, you know. The great thing about Scala is that you can also use any Java library you want and wrapping Java libraries in Scala-ish interfaces is actually easy and a great learning experience. I wished you'd be more explicit about this point, because for me I don't feel like there is a lack of documentation. > 2. Breaking backwards compatibility This is a point that comes up a lot, but I don't think it's that important for people actually using Scala. Scala is a compiled language, the libraries get distributed / deployed as compiled bytecode packaged up as Jars. This means that breaking compatibility is really easy, as all you have to do is to change an interface, like adding, removing or changing the signature of a method and boom, all code that depends on that interface needs to be recompiled, even for code that's not using the method in question. Dynamic languages that get interpreted or compiled on-the-fly, like Python or Ruby, are distributed as source-code. So by their nature don't have this disability. The alternative to breaking backwards compatibility in Scala is to freeze the standard library. Personally that's not a compromise I want, because for this very reason Java's standard library is full of idiosyncrasies, broken interfaces, broken behaviour and various other artefacts going back to Java 1.0, that were never fixed in order to preserve backwards compatibility. Scala has improved a lot though, compared to the 2.8 days. Nowadays you've got a guarantee that minor versions aren't breaking backwards compatibility. Code compiled with Scala 2.10.0 is guaranteed to be compatible with Scala 2.10.3 at least. The next version free to break compatibility with 2.10 is Scala 2.11. The tooling in Scala's ecosystem, like SBT, is also friendly to supporting multiple versions. To compile, test and deploy versions for multiple Scala versions is often just a configuration change, assuming you don't use APIs that aren't available in older Scala versions, in which case the back-ports are hard to accomplish in any language. > 3. Opaque error messages That's in the eye of the beholder. Sometimes the error messages are not so good, especially when triggered by the new macro support in Scala 2.10, but you know, those macros are experimental and improving by leaps and bounds. 90% of the time I have no problem understanding the given error messages and many times you get really helpful errors or warnings about code that you think it's correct, but isn't, like when pattern-matching on an ADT and missing a case. And I prefer opaque compile-time error messages to subtle or non-deterministic runtime error messages. In Python I used to suffer from null pointer exceptions all the time. In Scala null pointer exceptions are very rare. > 4. Encourages ad-hoc syntax that makes sense to one person (or team) but does not to the next -- maintenance nightmare. This is a thing that gets repeated by people that haven't used Scala, either personally or in a team. The syntax, even for libraries that go over the top on DSLs, is quite sane. It's much saner than in Ruby. And I prefer the succinctness of it, compared to code written in Java that often feels like a puke of useless crap that you have to read through in order to get to the bottom of whatever the piece of code you're reading actually does. Code written in more powerful languages feels like being harder to read, simply because each line of code does more. It's not the syntax that's the problem dude. Having worked with Scala in a team, the real problem are the functional programming concepts involved. In Scala you end up using recursion, error-handling without exceptions (e.g. Either/Option/Try), lazyness, monads, applicative functors, iteratees or other forms of doing stream processing and the list can continue. But it's hard because most developers are not familiar with these concepts, because many of the techniques involved are like death by a thousand cuts to apply in more mainstream languages. Then there's the type system. Scala is much more static than languages like Java or C#. It's great for users of properly designed libraries. It's not so great for language designers themselves, as people sometimes end up jumping the shark on static type safety, digging themselves into a corner. When you're seeing libraries that are hard to read because of all the generic types involved, well, on the flip side, Scala allows you to do things that are impossible to do in Java. That's why you're seeing a lot of type-casts in Java, whereas in Scala type-casts are more like an anomaly. Plus, Java uses wildcards for covariance/contravariance, which suck. Java libraries are often not generic because generic types in Java suck so badly. > 5. Lack of general stability in language and libraries serving to confuse the eco-system. I think at this point, you're being redundant, for the lack of better criticism. I disagree of course.
- vithlani 13y ago
  Thank you for taking the time to reply in such detail. I can see that you are a committed Scala dev and what I write below will probably not make a difference to you. However, for anybody else: I think what I want to say is, Scala is not a mature platform. I believe the language was originally conceived to address the deficiencies of the JAVA language while retaining the versatility of the JVM as a platform. If you look at the history of JAVA, it was a 'halfway successful attempt to drag C++ programmers towards Lisp'. Clearly this did not work well as it was not a well reasoned effort (syntax, semantics and so on) and went further downhill from the introduction of Generics in 1.5. Scala incorporates all the features of JAVA, adds halfway-to-Haskell-FP, OO-FP, XML-DSLs, some other very funky concepts stretching Generics and then...Macros...and probably stuff from JAVA 8. I humbly submit that this mixture is too much for a reasonable brain to handle. Also in the mix goes the backwards compatibility breakages. How many concepts can you cram into a semantic that in itself is not sound? Is there a standard for the language? Can I implement core Scala in C? Scala improved a lot from previous proves that point that it is still "improving" i.e. not a mature platform as yet. Functional programming concepts are not a problem for myself (and I believe any other reasonable programmer) it is the sensory overload of fitting it all into a model: all the language rules that you need to juggle to read a 15 line block of code that can jump between Scala, JAVA, DSL, Generics, operator overloading, etc. Code written in more powerful languages feels like being harder to read, simply because each line of code does more...hmmm, is this a good thing? Because I have some Perl that you might wanna look at. Succinctness is power, not sensory and mental overload. If I want the power of OO/FP/DSLs/MACROS all in one bundle, I would prefer a reasonable modern Lisp: coherence and maturity being the deciding factor in that choice. Maybe Clojure?
  - frowaway001 13y ago
    > Scala incorporates all the features of JAVA, adds halfway-to-Haskell-FP, OO-FP, XML-DSLs, some other very funky concepts stretching Generics and then...Macros...and probably stuff from JAVA 8. I humbly submit that this mixture is too much for a reasonable brain to handle. Also in the mix goes the backwards compatibility breakages. Most of the core assumptions here, on which you base your opinion, are not correct. For instance, Scala removes tons of crazy stuff which plagues Java. I'm also not sure how one can add Scala's first-class OOP-FP integration as a minus. Have a look at all the other languages which only managed to do that in a lot more terrible way (F#, Java). Generics as well. Why is the fact that scalac doesn't try and throw obstacles at you when programming with Generics bad? (Have a look at Java or C#, where tons of reasonable code is rejected by the compiler, because those compiler devs were too lazy to implement things properly.) Same with macros. Have a look at the state of art in Java. It's a terrible mess with various black magic tools and invocations combined with poor IDE and tooling support. If you can handle Java, I don't see an issue with Scala. Most of the stuff in Java is done in a better, more consistent and better designed way. > How many concepts can you cram into a semantic that in itself is not sound? I'm not seeing that at all. Care to explain? > Scala improved a lot from previous proves that point that it is still "improving" i.e. not a mature platform as yet. So Java is not mature, too? They are painfully adding mediocre lambda support right now. I'd call a language which was designed with lambdas in mind from the beginning and shipped with them since in 2005 more mature. The language in question is Scala. > all the language rules that you need to juggle to read a 15 line block of code that can jump between Scala, JAVA, DSL, Generics, operator overloading, etc. I have never seen that in practice. I often wished code written in other languages would adhere to the standards of code written in Scala. That would make things a lot more readable, maintainable and understandable. > Is there a standard for the language? Yes, there is. > Can I implement core Scala in C? Yes, why not? > If I want the power of OO/FP/DSLs/MACROS all in one bundle, I would prefer a reasonable modern Lisp: coherence and maturity being the deciding factor in that choice. > Maybe Clojure? Too bad, they are currently trying to add a half-baked static type-system to core. Again, I think a language which shipped with such basic things in mind since 2003 is a lot more mature.

bad_user 13y ago

> 1. Lack of documentation Again, in my experience, the documentation in Scala land is very good. The standard library has a really good API documentation, also checkout the documentation project at http://docs.scala-lang.org/ http://docs.scala-lang.org/ plus there are several very good books available; then there are the libraries in Scala's ecosystem, like Play2, or Akka, or Slick for example that do have good documentation. The online documentation for Play2 does not match the online documentation for Ruby on Rails or Django, but it's newer and it's improving and I remember a time when Rails was several years old and lacked online documentation. I did find undocumented features in Play2's online documentation, but nothing that couldn't be solved with a question on its mailing list. These are open-source libraries, with strong communities that communicate a lot on mailing lists, you know. The great thing about Scala is that you can also use any Java library you want and wrapping Java libraries in Scala-ish interfaces is actually easy and a great learning experience. I wished you'd be more explicit about this point, because for me I don't feel like there is a lack of documentation. > 2. Breaking backwards compatibility This is a point that comes up a lot, but I don't think it's that important for people actually using Scala. Scala is a compiled language, the libraries get distributed / deployed as compiled bytecode packaged up as Jars. This means that breaking compatibility is really easy, as all you have to do is to change an interface, like adding, removing or changing the signature of a method and boom, all code that depends on that interface needs to be recompiled, even for code that's not using the method in question. Dynamic languages that get interpreted or compiled on-the-fly, like Python or Ruby, are distributed as source-code. So by their nature don't have this disability. The alternative to breaking backwards compatibility in Scala is to freeze the standard library. Personally that's not a compromise I want, because for this very reason Java's standard library is full of idiosyncrasies, broken interfaces, broken behaviour and various other artefacts going back to Java 1.0, that were never fixed in order to preserve backwards compatibility. Scala has improved a lot though, compared to the 2.8 days. Nowadays you've got a guarantee that minor versions aren't breaking backwards compatibility. Code compiled with Scala 2.10.0 is guaranteed to be compatible with Scala 2.10.3 at least. The next version free to break compatibility with 2.10 is Scala 2.11. The tooling in Scala's ecosystem, like SBT, is also friendly to supporting multiple versions. To compile, test and deploy versions for multiple Scala versions is often just a configuration change, assuming you don't use APIs that aren't available in older Scala versions, in which case the back-ports are hard to accomplish in any language. > 3. Opaque error messages That's in the eye of the beholder. Sometimes the error messages are not so good, especially when triggered by the new macro support in Scala 2.10, but you know, those macros are experimental and improving by leaps and bounds. 90% of the time I have no problem understanding the given error messages and many times you get really helpful errors or warnings about code that you think it's correct, but isn't, like when pattern-matching on an ADT and missing a case. And I prefer opaque compile-time error messages to subtle or non-deterministic runtime error messages. In Python I used to suffer from null pointer exceptions all the time. In Scala null pointer exceptions are very rare. > 4. Encourages ad-hoc syntax that makes sense to one person (or team) but does not to the next -- maintenance nightmare. This is a thing that gets repeated by people that haven't used Scala, either personally or in a team. The syntax, even for libraries that go over the top on DSLs, is quite sane. It's much saner than in Ruby. And I prefer the succinctness of it, compared to code written in Java that often feels like a puke of useless crap that you have to read through in order to get to the bottom of whatever the piece of code you're reading actually does. Code written in more powerful languages feels like being harder to read, simply because each line of code does more. It's not the syntax that's the problem dude. Having worked with Scala in a team, the real problem are the functional programming concepts involved. In Scala you end up using recursion, error-handling without exceptions (e.g. Either/Option/Try), lazyness, monads, applicative functors, iteratees or other forms of doing stream processing and the list can continue. But it's hard because most developers are not familiar with these concepts, because many of the techniques involved are like death by a thousand cuts to apply in more mainstream languages. Then there's the type system. Scala is much more static than languages like Java or C#. It's great for users of properly designed libraries. It's not so great for language designers themselves, as people sometimes end up jumping the shark on static type safety, digging themselves into a corner. When you're seeing libraries that are hard to read because of all the generic types involved, well, on the flip side, Scala allows you to do things that are impossible to do in Java. That's why you're seeing a lot of type-casts in Java, whereas in Scala type-casts are more like an anomaly. Plus, Java uses wildcards for covariance/contravariance, which suck. Java libraries are often not generic because generic types in Java suck so badly. > 5. Lack of general stability in language and libraries serving to confuse the eco-system. I think at this point, you're being redundant, for the lack of better criticism. I disagree of course.

vithlani 13y ago
Thank you for taking the time to reply in such detail. I can see that you are a committed Scala dev and what I write below will probably not make a difference to you. However, for anybody else: I think what I want to say is, Scala is not a mature platform. I believe the language was originally conceived to address the deficiencies of the JAVA language while retaining the versatility of the JVM as a platform. If you look at the history of JAVA, it was a 'halfway successful attempt to drag C++ programmers towards Lisp'. Clearly this did not work well as it was not a well reasoned effort (syntax, semantics and so on) and went further downhill from the introduction of Generics in 1.5. Scala incorporates all the features of JAVA, adds halfway-to-Haskell-FP, OO-FP, XML-DSLs, some other very funky concepts stretching Generics and then...Macros...and probably stuff from JAVA 8. I humbly submit that this mixture is too much for a reasonable brain to handle. Also in the mix goes the backwards compatibility breakages. How many concepts can you cram into a semantic that in itself is not sound? Is there a standard for the language? Can I implement core Scala in C? Scala improved a lot from previous proves that point that it is still "improving" i.e. not a mature platform as yet. Functional programming concepts are not a problem for myself (and I believe any other reasonable programmer) it is the sensory overload of fitting it all into a model: all the language rules that you need to juggle to read a 15 line block of code that can jump between Scala, JAVA, DSL, Generics, operator overloading, etc. Code written in more powerful languages feels like being harder to read, simply because each line of code does more...hmmm, is this a good thing? Because I have some Perl that you might wanna look at. Succinctness is power, not sensory and mental overload. If I want the power of OO/FP/DSLs/MACROS all in one bundle, I would prefer a reasonable modern Lisp: coherence and maturity being the deciding factor in that choice. Maybe Clojure?
- frowaway001 13y ago
  > Scala incorporates all the features of JAVA, adds halfway-to-Haskell-FP, OO-FP, XML-DSLs, some other very funky concepts stretching Generics and then...Macros...and probably stuff from JAVA 8. I humbly submit that this mixture is too much for a reasonable brain to handle. Also in the mix goes the backwards compatibility breakages. Most of the core assumptions here, on which you base your opinion, are not correct. For instance, Scala removes tons of crazy stuff which plagues Java. I'm also not sure how one can add Scala's first-class OOP-FP integration as a minus. Have a look at all the other languages which only managed to do that in a lot more terrible way (F#, Java). Generics as well. Why is the fact that scalac doesn't try and throw obstacles at you when programming with Generics bad? (Have a look at Java or C#, where tons of reasonable code is rejected by the compiler, because those compiler devs were too lazy to implement things properly.) Same with macros. Have a look at the state of art in Java. It's a terrible mess with various black magic tools and invocations combined with poor IDE and tooling support. If you can handle Java, I don't see an issue with Scala. Most of the stuff in Java is done in a better, more consistent and better designed way. > How many concepts can you cram into a semantic that in itself is not sound? I'm not seeing that at all. Care to explain? > Scala improved a lot from previous proves that point that it is still "improving" i.e. not a mature platform as yet. So Java is not mature, too? They are painfully adding mediocre lambda support right now. I'd call a language which was designed with lambdas in mind from the beginning and shipped with them since in 2005 more mature. The language in question is Scala. > all the language rules that you need to juggle to read a 15 line block of code that can jump between Scala, JAVA, DSL, Generics, operator overloading, etc. I have never seen that in practice. I often wished code written in other languages would adhere to the standards of code written in Scala. That would make things a lot more readable, maintainable and understandable. > Is there a standard for the language? Yes, there is. > Can I implement core Scala in C? Yes, why not? > If I want the power of OO/FP/DSLs/MACROS all in one bundle, I would prefer a reasonable modern Lisp: coherence and maturity being the deciding factor in that choice. > Maybe Clojure? Too bad, they are currently trying to add a half-baked static type-system to core. Again, I think a language which shipped with such basic things in mind since 2003 is a lot more mature.