6 ms·

Languages like Ruby and Python allow for expressive, high-level customization, metaprogramming, and DSL creation. However, especially in the latter, the potenti

Languages like Ruby and Python allow for expressive, high-level customization, metaprogramming, and DSL creation. However, especially in the latter, the potential chaos is curbed by a strong culture and encouragement of self restraint, readability, and simplicity. From the sound of it, this is not so true for Scala.

fzltrp 13y ago
Once you start dwelling in the intricacies of a very complex type system, it becomes quite difficult to keep things easy to understand. There's this joke about how a Haskell programmer's style on a hello world programme evolves with experience, starting from a very readable, sort of down to earth implementation, and turning out in its last iteration into a complex "mess" of abstract concepts, for sensibly the same result. It's always possible to keep things simple, even in Scala, and the opposite is also true with a language known as simple, Java, because the type system happens to be quite powerful actually. People are tempted to make things complicated also because there is this prevalent programming style in the community.
- mattangriffel 13y ago
  That's not a very good joke.
  - sordina 13y ago
    It's actually very funny: http://www.willamette.edu/~fruehr/haskell/evolution.html http://www.willamette.edu/~fruehr/haskell/evolution.html
  - fzltrp 13y ago
    If you take it too seriously, it's indeed not very good. I personally take it as a compliment for Haskellers: it means that people from the Haskell (and fp in general)community do think at a higher level than the average programmer, so much that it becomes for them difficult not to. The FP model gives good tools to enable that, and encourage people to think that way. I may also be biased because I feel more confortable thinking that way. Certainly programmers excelling at imperative programming might disagree, but I don't think that the latest trends of "functionalizing" Java, C++ or PHP are coincidental. Javascript opened the way by bringing back that paradigm to a larger audience, and these languages, which already have FP concepts available, but not in a very usable way, are now incorporating them to the core. That's a good thing. Regarding the original topic, Scala is very much an experiental language in my opinion (because of the concepts it involves; the implementation is pretty good), so maybe there's a little bit of thruth in the article in that regard. Perhaps that's the "flaw" of academic languages. Also the comparison with Java is quite pertinent, Java being a language designed from the ground up for engineering: the grammar is fairly simple, which provided a somewhat good compromise between high readability (because of its similarities with C) and easiness at machine processing (not as easy as lisps dialect though).
- deleted 13y ago
  [deleted]
bad_user 13y ago
I'm really curious of what "sound" you're talking about. I've been working with Scala full-time for the past 2 years. Prior to that I worked with Perl, Python and Ruby and I still work with these languages for quick scripting or if the codebase demands it. Scala code-bases tend to be based to a higher degree on good engineering practices. Scala itself is a much more static language than a language like Java, hence it gives you plenty of compile-time safety, with its static type system being one that helps you, instead of staying in your way. Even a tricky feature (now market as experimental SIP-18 and so they have to be explicitly enabled), like implicit conversions, is far more safer than the monkey patching that goes on in Ruby/Python, as it's lexically scoped, doesn't modify anything and the compiler throws errors if there are conflicts.
- vithlani 13y ago
  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.
lmm 13y ago
Scala is pulling out of that phase. Scalaz 7 removes a lot of the less-readable operators (e.g. you now have to write "Kleisli" rather than "☆"). The Requests HTTP library, long mocked for its periodic table of operators, has fallen out of favour (I'm not sure it's even maintained any more). I can't speak for SBT because I don't use it, but Spray is probably the nicest library for defining HTTP APIs I've ever used, in any language. As for type inference, yes it's imperfect, and maybe disappointing for someone used to Haskell, but coming from Python I found the set of type annotations I needed to add to make my Scala compile was a subset of the ones I wanted to document anyway.
- runn1ng 13y ago
  Wait. Scala has unicode operators? Wow.
  - lmm 13y ago
    Scala doesn't make a distinction between operators and methods, and Java has always supported unicode in method names, so they have to be possible for compatibility if nothing else. I think if used carefully, with discipline, they can make code more readable and ultimately more maintainable - e.g. for doing set algebra it's nice to be able to have ∪ and ∩ methods. But yes, if you want to shoot yourself in the foot with them it's very easy.
    - joeygibson 13y ago
      I showed an example of using Unicode operators in a presentation I gave to the Atlanta group back in 2010. It doesn't say it in the slide, but when I gave the talk, I explained that while it sounds like a neat idea, you should probably avoid doing this. You can see the slide here, where I used a Delta as an operator slideshare.net/slideshow/embed_code/2923973?startSlide=9
  - draegtun 13y ago
    Perl6 also has unicode operators - https://news.ycombinator.com/item?id=4942377 https://news.ycombinator.com/item?id=4942377

fzltrp 13y ago

Once you start dwelling in the intricacies of a very complex type system, it becomes quite difficult to keep things easy to understand. There's this joke about how a Haskell programmer's style on a hello world programme evolves with experience, starting from a very readable, sort of down to earth implementation, and turning out in its last iteration into a complex "mess" of abstract concepts, for sensibly the same result. It's always possible to keep things simple, even in Scala, and the opposite is also true with a language known as simple, Java, because the type system happens to be quite powerful actually. People are tempted to make things complicated also because there is this prevalent programming style in the community.

mattangriffel 13y ago
That's not a very good joke.
- sordina 13y ago
  It's actually very funny: http://www.willamette.edu/~fruehr/haskell/evolution.html http://www.willamette.edu/~fruehr/haskell/evolution.html
- fzltrp 13y ago
  If you take it too seriously, it's indeed not very good. I personally take it as a compliment for Haskellers: it means that people from the Haskell (and fp in general)community do think at a higher level than the average programmer, so much that it becomes for them difficult not to. The FP model gives good tools to enable that, and encourage people to think that way. I may also be biased because I feel more confortable thinking that way. Certainly programmers excelling at imperative programming might disagree, but I don't think that the latest trends of "functionalizing" Java, C++ or PHP are coincidental. Javascript opened the way by bringing back that paradigm to a larger audience, and these languages, which already have FP concepts available, but not in a very usable way, are now incorporating them to the core. That's a good thing. Regarding the original topic, Scala is very much an experiental language in my opinion (because of the concepts it involves; the implementation is pretty good), so maybe there's a little bit of thruth in the article in that regard. Perhaps that's the "flaw" of academic languages. Also the comparison with Java is quite pertinent, Java being a language designed from the ground up for engineering: the grammar is fairly simple, which provided a somewhat good compromise between high readability (because of its similarities with C) and easiness at machine processing (not as easy as lisps dialect though).
deleted 13y ago
[deleted]

bad_user 13y ago

I'm really curious of what "sound" you're talking about. I've been working with Scala full-time for the past 2 years. Prior to that I worked with Perl, Python and Ruby and I still work with these languages for quick scripting or if the codebase demands it. Scala code-bases tend to be based to a higher degree on good engineering practices. Scala itself is a much more static language than a language like Java, hence it gives you plenty of compile-time safety, with its static type system being one that helps you, instead of staying in your way. Even a tricky feature (now market as experimental SIP-18 and so they have to be explicitly enabled), like implicit conversions, is far more safer than the monkey patching that goes on in Ruby/Python, as it's lexically scoped, doesn't modify anything and the compiler throws errors if there are conflicts.

vithlani 13y ago
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.

lmm 13y ago

Scala is pulling out of that phase. Scalaz 7 removes a lot of the less-readable operators (e.g. you now have to write "Kleisli" rather than "☆"). The Requests HTTP library, long mocked for its periodic table of operators, has fallen out of favour (I'm not sure it's even maintained any more). I can't speak for SBT because I don't use it, but Spray is probably the nicest library for defining HTTP APIs I've ever used, in any language. As for type inference, yes it's imperfect, and maybe disappointing for someone used to Haskell, but coming from Python I found the set of type annotations I needed to add to make my Scala compile was a subset of the ones I wanted to document anyway.

runn1ng 13y ago
Wait. Scala has unicode operators? Wow.
- lmm 13y ago
  Scala doesn't make a distinction between operators and methods, and Java has always supported unicode in method names, so they have to be possible for compatibility if nothing else. I think if used carefully, with discipline, they can make code more readable and ultimately more maintainable - e.g. for doing set algebra it's nice to be able to have ∪ and ∩ methods. But yes, if you want to shoot yourself in the foot with them it's very easy.
  - joeygibson 13y ago
    I showed an example of using Unicode operators in a presentation I gave to the Atlanta group back in 2010. It doesn't say it in the slide, but when I gave the talk, I explained that while it sounds like a neat idea, you should probably avoid doing this. You can see the slide here, where I used a Delta as an operator slideshare.net/slideshow/embed_code/2923973?startSlide=9
- draegtun 13y ago
  Perl6 also has unicode operators - https://news.ycombinator.com/item?id=4942377 https://news.ycombinator.com/item?id=4942377