Yes. Invoking strong emotions is an aspect of trolling. That was my point. It's a necessary but not sufficient condition.
Time to get meta: You're asking people to actually list out the reasons for why they dislike Scala while at the same time asking why those same people tend to 'argue repeatedly with [a strong scala supporter], while ALSO threatening to reply by insinuating that erroneous facts have been stated without giving an example of this. Now THAT is trolling. Stop it. On Sep 29, 3:20 am, Josh Suereth <[email protected]> wrote: > 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%2bunsubscr...@googlegroups > > .com> > > . > > 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.
