I would argue more that Scala is language that invokes strong emotions. Love or Hate. Unfortunately for the Scala community, some members are far to zealous in their arguments, such that it may annoy others. However, I remember the same kinds of taunts from Groovy users at work. Why was that less annoying than Scala?
I think because Groovy is a language that's hard to hate. I mean, it's Groovy. Ruby had some anti-ruby-ists, but once again not really a bunch of haters. Scala on the other hand, appears to have attracted a lot of anti-scala-trolls <http://harrop-highly.blogspot.com/>. So, Reinier.... What is it about Scala that causes you to argue repeatedly with Kevin about it? Why do you feel so strongly if "there are no right answers in programming"? I know personally, when I see something I like discussed on this list, with very erroneous or incorrect facts, I feel I must reply to "uphold the good name of Scala". So again, I ask: What is it about Scala that causes so many to loathe it? - Josh On Tue, Sep 28, 2010 at 1:04 PM, Reinier Zwitserloot <[email protected]>wrote: > "trolling" has really only one meaning: > > An act which is intentionally designed to get a rise out of someone. > > It can be done for two separate reasons; one, just to be an ass, the > other is as the epitomy of satire (this one is excusable but a bit too > deep to get into here). > > Scala seems to fit the latter part of the definition quite well: For > whatever reason, scala developers, and those who've tried it or are > being confronted by it, tend to get into somewhat heated discussions > far more than with other languages. Exhibit A: This newsgroup. > > But is it intentional? I sincerely doubt that. However, _calling_ > scala a troll language armed with a single (albeit compelling) bit of > evidence to do so, that's most likely troll behaviour: I'm guessing > fishdicks wrote this comment to rile people up. So, be warned. Try to > keep a cool head :) > > The gist of the first part of that argument is that this, which is > legal scala code: > > user getAccount accountName isEnabled > > is indicative of a bad language. Its not possible to tell if this is > a golfed version of: user.getAccount().accountName().isEnabled(), or: > user.getAccount(accountName).isEnabled(). Trying to argue that the > distinction is irrelevant sounds like an inherently doomed approach to > me, which leaves the rather uncomfortable truth that this is a > "mistake" in scala's DSL-friendly syntax. That, or, scala shouldn't be > read / written without the use of an IDE smart enough to markup > 'accountName' in such a way that you can tell its a (local) variable > and not another method name in the chain. > > Or at least, that's what the comment was driving at. I basically agree > with this assessment: This is possibly the kind of thing that's being > referred to when the argument is used that scala is a "complicated" > language. It would have been convenient if this example is trotted out > next time, that should help avoid endless discussion about the meaning > of "complex" and "complicated". > > It also highlights something I hold as truth for programming > languages: There's no "right" answer. What seems obvious and fantastic > from one angle (optional dot and parens, makes usage of certain APIs > look so much nicer), seems problematic from another (this is making it > hard to identify what a line of code is doing). > > Though, I believe there might be a way out (have both easy reading and > non-ambiguous syntax) if one moves away from the "code is just a > stream of characters" approach to programming and into "we all use > some sort of intelligent editor anyway". Decouple what something looks > like from its semantic meaning. It worked wonders for the web (html + > css), why are programmers so averse to this model? If the language in > fact guarantees and enforces that editors highlight variables > differently from method calls, I see no problem here. This goes deeper > than mere syntax highlighting. If for whatever reason the "getAccount" > method becomes zero-args, and returns an object that has a > "accountName" method, then the meaning of "user getAccount accountName > isEnabled" would change significantly. Embracing the AST / editor mode > of programming also implies that making such a change will not change > what "user getAccount accountName isEnabled" means. The source knows > that getAccount was meant as a one-arg method, and accountName as a > variable reference, when this code was written. It also know not to > change this meaning. > > > On Sep 24, 7:42 am, GavinB <[email protected]> wrote: > > http://www.reddit.com/r/programming/comments/dhtor/leaving_net/c10bnmu > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
