4 ms·

I really want to see all this thrash/unreadable Scala code that everyone is talking about. I haven't done any great projects on Scala, only smaller ones. With a

I really want to see all this thrash/unreadable Scala code that everyone is talking about. I haven't done any great projects on Scala, only smaller ones. With a few exceptions (of operator overload and implicits abusing) I've read many Scala sources and after you pass the "functional programming WTF moments" you come to understand pretty much everything.

Maro 15y ago
You can browse Scala code here: https://github.com/languages/Scala https://github.com/languages/Scala
- felipehummel 15y ago
  I know. I've seen it. Can you point to some unreadable code? Preferably one that does not fall into the 'operator overload ing abuse' category?
  - Maro 15y ago
    I've never read or written a single line of Scala code, I was just trying to be helpful by providing a link where there's lots of Scala code..
  - tomjen3 15y ago
    Go look up the sources for the Scala 2.8.0 compiler. Worst and most difficult to understand code I have ever seen. It is simultaneously confusing, hard, badly commented and uses every single Scala feature I have ever seen, including non-root imports in the middle of files, extensions of anonymous classes sometimes with other anonymous classes, and my least favourite: path depended typing (sometimes from non-root imports started in one of several traits that may or may not have circular inherietence patterns). But that said, it has never been a problem outside the compiler.
    - soc88 15y ago
      That's pretty interesting, because I had no trouble reading and understanding the sources of the compiler and writing simple patches for it ... and I'm not really a compiler guy and not a type theorist. The Scala compiler is in my opinion one of the nicest code bases I've seen, considering the low-level stuff happening there.
adabsurdo 15y ago
no. the problem is that scala allows almost any string of characters as identifiers, and this encourages programmers to use symbols instead of english words for their function names. So you end up with identifiers that convey no meaning whatsoever, like /:\ or >>:. Sure, this can be in fact very nice if you are writing a DSL for a problem that already has its own well-known set of symbols, like a branch of mathematics. However, what happens in reality is that most programming is "business" programming. But still programmers use it for everything (because we're lazy and typing :: seems faster than "append"). The scala api leads the way here. For example the list class: http://www.scala-lang.org/api/current/scala/collection/immutable/List.html http://www.scala-lang.org/api/current/scala/collection/immut... The following are all subtle variations on append and prepend: ::, :::, ++, :+, ++:, +: Can any non-scala programmer guess which one is which? When you move on to the Map or Set class, it's a little bit the same and a little bit different. Sure, at one point you will remember all of this by heart, but the same pattern repeats itself when you try to use another library: it defines its own little language, instead of using the one common to us all: english. Note another huge drawback, for me at least: you can't google such symbols because of course search engines will treat them as noise. Even searching for them with regexes is tricky because you can't use word boundaries. The argument I heard over and over is that you can make non-sense function words even if you're restricted to alpha-numeric. This is true, and it happens. However, if I call my function "append" or "xyz", and what it does is "prepend", it's obviously the wrong name and you can point it out. Symbols, on the other hand, are arbitrary, and it becomes a question of taste. edit: removed some list operators added in error, thanks Inufu
- Inufu 15y ago
  imho, this is the programmer's fault, not the language's. Or would you say it's the gun's fault if you shoot somebody with it? So if some programmers write unintuitive code with Scala, don't use their code. It's still an awesome language. edit: where did you find +++ and :++ ? They are not in the List api.
- felipehummel 15y ago
  I also believe it is nonsense to overuse symbols for methods. I think even Martin Odersky agrees (I've read somewhere). I guess this is something that will settle down eventually. And programmers will stop using so much random symbols instead of English. For the specific case of Lists, I don't think is that much trouble. It is the most important class of the language. You better get used to it anyway.
gtani 15y ago
For anything cited as a shortcoming of the language or dev environment, there's going to be some tooling. There's a search engine for those symbolic "operators" (they're methods, not operators, but that's how most devs think about them - (Scalex)[http://scalex.org/ http://scalex.org/] search engine should cover most of them. Generally, you know if that "operator" comes from the collections API, scalaz, sbt, akka, or wherever, so it's not that hard to locate the scaladoc and the source. - (Staircase book, first edition)[http://www.artima.com/pins1ed/book-index.html#indexanchor http://www.artima.com/pins1ed/book-index.html#indexanchor] covers most the built in and standard lib symbolic operators - aliases like foldLeft and foldRight are built into List class, for example, for /: and \: Implicits: - you can look at them using ":implicits" in the 2.9 REPL and the IDEA plugin and (I think) new eclipse plugins popup bubbles when you cursor over an object or class that has implicits, and shows you the implicit's source - implicit conversions of method receivers (as opposed to implicit parameters) are useful as typeclasses are used in haskell, or structural typing in other languages. A best practice is to have all implicits declare a return type, and there was a discussion of having the compiler enforce this, or at least issue warnings. [http://scalatips.tumblr.com/post/101578787/add-explicit-return-types-to-all-implicits http://scalatips.tumblr.com/post/101578787/add-explicit-retu...]

Maro 15y ago

You can browse Scala code here: https://github.com/languages/Scala https://github.com/languages/Scala

felipehummel 15y ago
I know. I've seen it. Can you point to some unreadable code? Preferably one that does not fall into the 'operator overload ing abuse' category?
- Maro 15y ago
  I've never read or written a single line of Scala code, I was just trying to be helpful by providing a link where there's lots of Scala code..
- tomjen3 15y ago
  Go look up the sources for the Scala 2.8.0 compiler. Worst and most difficult to understand code I have ever seen. It is simultaneously confusing, hard, badly commented and uses every single Scala feature I have ever seen, including non-root imports in the middle of files, extensions of anonymous classes sometimes with other anonymous classes, and my least favourite: path depended typing (sometimes from non-root imports started in one of several traits that may or may not have circular inherietence patterns). But that said, it has never been a problem outside the compiler.
  - soc88 15y ago
    That's pretty interesting, because I had no trouble reading and understanding the sources of the compiler and writing simple patches for it ... and I'm not really a compiler guy and not a type theorist. The Scala compiler is in my opinion one of the nicest code bases I've seen, considering the low-level stuff happening there.

adabsurdo 15y ago

no. the problem is that scala allows almost any string of characters as identifiers, and this encourages programmers to use symbols instead of english words for their function names. So you end up with identifiers that convey no meaning whatsoever, like /:\ or >>:. Sure, this can be in fact very nice if you are writing a DSL for a problem that already has its own well-known set of symbols, like a branch of mathematics. However, what happens in reality is that most programming is "business" programming. But still programmers use it for everything (because we're lazy and typing :: seems faster than "append"). The scala api leads the way here. For example the list class: http://www.scala-lang.org/api/current/scala/collection/immutable/List.html http://www.scala-lang.org/api/current/scala/collection/immut... The following are all subtle variations on append and prepend: ::, :::, ++, :+, ++:, +: Can any non-scala programmer guess which one is which? When you move on to the Map or Set class, it's a little bit the same and a little bit different. Sure, at one point you will remember all of this by heart, but the same pattern repeats itself when you try to use another library: it defines its own little language, instead of using the one common to us all: english. Note another huge drawback, for me at least: you can't google such symbols because of course search engines will treat them as noise. Even searching for them with regexes is tricky because you can't use word boundaries. The argument I heard over and over is that you can make non-sense function words even if you're restricted to alpha-numeric. This is true, and it happens. However, if I call my function "append" or "xyz", and what it does is "prepend", it's obviously the wrong name and you can point it out. Symbols, on the other hand, are arbitrary, and it becomes a question of taste. edit: removed some list operators added in error, thanks Inufu

Inufu 15y ago
imho, this is the programmer's fault, not the language's. Or would you say it's the gun's fault if you shoot somebody with it? So if some programmers write unintuitive code with Scala, don't use their code. It's still an awesome language. edit: where did you find +++ and :++ ? They are not in the List api.
felipehummel 15y ago
I also believe it is nonsense to overuse symbols for methods. I think even Martin Odersky agrees (I've read somewhere). I guess this is something that will settle down eventually. And programmers will stop using so much random symbols instead of English. For the specific case of Lists, I don't think is that much trouble. It is the most important class of the language. You better get used to it anyway.

gtani 15y ago

For anything cited as a shortcoming of the language or dev environment, there's going to be some tooling. There's a search engine for those symbolic "operators" (they're methods, not operators, but that's how most devs think about them - (Scalex)[http://scalex.org/ http://scalex.org/] search engine should cover most of them. Generally, you know if that "operator" comes from the collections API, scalaz, sbt, akka, or wherever, so it's not that hard to locate the scaladoc and the source. - (Staircase book, first edition)[http://www.artima.com/pins1ed/book-index.html#indexanchor http://www.artima.com/pins1ed/book-index.html#indexanchor] covers most the built in and standard lib symbolic operators - aliases like foldLeft and foldRight are built into List class, for example, for /: and \: Implicits: - you can look at them using ":implicits" in the 2.9 REPL and the IDEA plugin and (I think) new eclipse plugins popup bubbles when you cursor over an object or class that has implicits, and shows you the implicit's source - implicit conversions of method receivers (as opposed to implicit parameters) are useful as typeclasses are used in haskell, or structural typing in other languages. A best practice is to have all implicits declare a return type, and there was a discussion of having the compiler enforce this, or at least issue warnings. [http://scalatips.tumblr.com/post/101578787/add-explicit-return-types-to-all-implicits http://scalatips.tumblr.com/post/101578787/add-explicit-retu...]