Scala as EJB 2: feedback (incl. Fantom comparison,funny comments(blog.joda.org)
blog.joda.org
Scala as EJB 2: feedback (incl. Fantom comparison,funny comments
http://blog.joda.org/2011/11/scala-ejb-2-feedback.html
6 comments
Best summary on this whole discussion.
If anyone is interested in looking at a medium sized scala project and deciding for themselves what they think about the language you might want to check out rogue, a MongoDB query DSL that we developed at foursquare. You can see it, source and all, here:
https://github.com/foursquare/rogue/
https://github.com/foursquare/rogue/
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.
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/] 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] 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-retu...]
- (Scalex)[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] 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-retu...]
You can browse Scala code here:
https://github.com/languages/Scala
https://github.com/languages/Scala
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?
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.
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.
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.
The Scala compiler is in my opinion one of the nicest code bases I've seen, considering the low-level stuff happening there.
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..
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/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
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/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
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.
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.
my point is that this style of writing is pervasive within the scala world, including the official api. and it's not just the list class. look at the base xml class, NodeSeq:
http://www.scala-lang.org/api/rc/scala/xml/NodeSeq.html
http://www.scala-lang.org/api/rc/scala/xml/NodeSeq.html
The xml stuff is more the exception than the rule. They've moved away from that approach. Whether to keep it at all has been discussed quite a bit. It would be more fair to look at the newer code in the collection framework to paint what is considered "best practice" by the creators of Scala.
These operators such as ++ (concatenation) etc are uniformly available in all collections. It has inherited these operators from base sequence classes/traits specifically TraversableLike.
http://www.scala-lang.org/api/rc/scala/collection/Traversabl...
If you write a fancy skiplist and add a TraversableLike trait you will get these operators and the associated methods for free!
Check the source code for NodeSeq. https://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_...
It does not implement any of these operators. It just inherits some features extends immutable.Seq[Node] with SeqLike[Node, NodeSeq] with Equality
provides an equality operator and a builder and gets all the other collection operators for free. These operators have the same semantics and implementation across all collection classes unless you specifically override them.
http://www.scala-lang.org/api/rc/scala/collection/Traversabl...
If you write a fancy skiplist and add a TraversableLike trait you will get these operators and the associated methods for free!
Check the source code for NodeSeq. https://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_...
It does not implement any of these operators. It just inherits some features extends immutable.Seq[Node] with SeqLike[Node, NodeSeq] with Equality
provides an equality operator and a builder and gets all the other collection operators for free. These operators have the same semantics and implementation across all collection classes unless you specifically override them.
???
These are the same methods. It is common in languages with inheritance that classes implementing the same types have pretty much the same methods available ...
> ::, :::, ++, :+, ++:, +:
> Can any non-scala programmer guess which one is which?
I have read the documentation and I still do not know which one is which. Specifically the summary documentation is the same for both ++ and ++: Can you explain the difference to a non-scala programmer? I can see that the answer must be in the type signatures, but I have no idea how to decipher those.
> Can any non-scala programmer guess which one is which?
I have read the documentation and I still do not know which one is which. Specifically the summary documentation is the same for both ++ and ++: Can you explain the difference to a non-scala programmer? I can see that the answer must be in the type signatures, but I have no idea how to decipher those.
In scala the use of : changes the associativity of the operator, so a ++ b ++ c is equivalent to (a.++ b).++ c while a ++: b ++: c is equivalent to (c.++: b).++: a
However fear not :-) the arguments are always evaluated left to right i.e. a,b,c and never c,b,a. It might be useful to think of (c.++: b).++: a as a ++ (b ++ c) except that ++ has c as the "this" parameter in the inner expression and not b.
Easy. The first one returns the collection type of the left collection, the second one the type of the right collection.
Appending : to a method name makes makes the method right-associate. That's a very general rule, nothing to do with collections ...
Appending : to a method name makes makes the method right-associate. That's a very general rule, nothing to do with collections ...
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.
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.
The official style guide says the opposite:
Additionally, you can also click on the index and get every symbolic method with the place where it is defined.
I don't really understand what's so hard about that ...
Avoid! Despite the degree to which Scala facilitates
this area of API design, the definition of methods with
symbolic names should not be undertaken lightly,
particularly when the symbols itself are non-standard
(for example, >>#>>). As a general rule, symbolic
method names have two valid use-cases:
Domain-specific languages (e.g. actor1 ! Msg)
Logically mathematical operations (e.g. a + b or c :: d)
The definition of methods with symbolic names should be
considered an advanced feature in Scala, to be used only
by those most well-versed in its pitfalls. Without care,
excessive use of symbolic method names can easily
transform even the simplest code into symbolic soup.
Additionally, you can also click on the index and get every symbolic method with the place where it is defined.
I don't really understand what's so hard about that ...
I am wondering why there is no response to this post for such a long time. Did scala guys decided to show their disappointment by ignoring this post here?
Colebourne's attitude reminds me of an attitude I encountered a lot when I used Perl. Some people would spend a lot of time complaining about how bad Perl is. Meanwhile, lots of people would be happily producing clean and maintainable code with Perl. People who like Perl will probably nod acknowledgingly, and people who don't like it will think I'm an idiot for thinking that Perl isn't so bad.
It's best not to get caught up in the language wars and just focus on getting things done. Which reminds me, I should be getting back to work.
It's best not to get caught up in the language wars and just focus on getting things done. Which reminds me, I should be getting back to work.
Apt comparison. It's easy to see how both perl and scala can degenerate into "line noise", both are quite powerful and both have their religious adherents and detractors. While I would refrain from using punctuation characters in method names, I think it's an asset that scala allows it. Colebourne's desire for version awareness in class loading is one I'd agree with with but I've wanted that in just about every language. The rest of his complaints just sound like crabby BS to me. FWIW, my experience with scala was a short project last year where it was essentially just a "better java" with smatterings of implicits and FP, I enjoyed it and plan on using scala again in the future.
I think quite a few java devs, myself included, are starting to use scala as a 'better java'. After a decade or more of java coding we're looking for something more expressive which isn't a scripting language.
well said
This is one of the lamest "things" on HN/the Internet in a while.
You have one guy who says he doesn't like Scala, provides almost no actual reasons apart from hand waving, and pretty much says he's never actually used it for anything. He then points to a language which has zero traction, and will never gain any, as his ideal language.
That's great. It really is. So this guy doesn't want to use Scala. That's good for him. Why do you care?
If this was an interesting analysis of the language, or the libraries, or some actual code, that would be something to talk about. But it's more a whiny "why are all you guys switching to Scala! I don't like it! Come back!" pseudo-"debate" than anything else.
You have one guy who says he doesn't like Scala, provides almost no actual reasons apart from hand waving, and pretty much says he's never actually used it for anything. He then points to a language which has zero traction, and will never gain any, as his ideal language.
That's great. It really is. So this guy doesn't want to use Scala. That's good for him. Why do you care?
If this was an interesting analysis of the language, or the libraries, or some actual code, that would be something to talk about. But it's more a whiny "why are all you guys switching to Scala! I don't like it! Come back!" pseudo-"debate" than anything else.
Great and accurate summary.
Does Fantom have any traction? It sounds interesting.
Fantom is an interesting language go and try it out! I don't think it has much traction but it is simple, easy to understand and contains some thought provoking ideas. You can get to know most of the language and most of the built in libraries with a few evenings playing with an editor and reading the online documentation.
Also go and look at Ceylon and Kotlin (please, please JetBrains get some code out for Kotlin soon!), they both also contain lots of interesting ideas but are more complex than Fantom.
In fact Fantom, Kotlin and Ceylon all have two features that I like, null safety and a module and dependency system baked into the language.
Also go and look at Ceylon and Kotlin (please, please JetBrains get some code out for Kotlin soon!), they both also contain lots of interesting ideas but are more complex than Fantom.
In fact Fantom, Kotlin and Ceylon all have two features that I like, null safety and a module and dependency system baked into the language.
my idea of traction/participation for a language is some nontrivial volume on github, stackoverflow, mailing list and IRC. OP talks about fantom, scala, Groovy, Ceylon, Kotlin, Xtend, Clojure in the article (doesnt' mention JRuby or gosu, but they're worth looking into too)
No, not really.
And it just broke backward compatibility, one thing all these Scala critics get so worked up about.
And it just broke backward compatibility, one thing all these Scala critics get so worked up about.
There were a lot of interesting perspectives, both for and against Scala's design decisions, and I learned a lot.
1. Scala is a complex language, with many tools aimed at library authors. There are drawbacks to this approach (witness the headaches of C++), but also advantages (witness the massive commercial success of C++).
2. Plenty of Scala developers are happy to use it as a "better Java." A small but vocal minority are engaged in hard-core functional programming, which can occasionally lead to both cool libraries and minor conflict within the community.
3. Some of Colebourne's original criticisms were acknowledged by Scala developers, especially those pertaining to module systems. However, opinions on whether Scala should limit mutability (as Clojure and Haskell do) were divided.
This followup post is less interesting. He goes out of his way to quote people who made insightful comments that agreed with his views, but only quotes snark and mockery from those who disagreed.