"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 <gb.javou...@gmail.com> 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 javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
