This page is no longer maintained — Please continue to the home page at

problems of scala complexity

101 replies
Joined: 2010-06-04,
User offline. Last seen 5 weeks 15 hours ago.
Re: problems of scala complexity

On 2011-11-21 9:23 AM, Gary Pampara wrote:
>> Note that Scala doesn't have operator overloading, the problem we're
>> discussing is that methods can be named using arbitrary UTF characters.

The confusion over operator overloading was my fault as I was comparing
my experiences with operator overloading in C++ (not being able to
recognize what was going on) against my experiences with Scala where
there can be many new operators (that can also make it hard to recognize
what is going on).

> I'm sorry, but how is this a problem? Even remotely? Symbols are used
> everywhere, in all kinds of fields. Where does it say that symbols
> cannot be used in a coherent manner that will aid the description of
> logic or a solution?
> This is purely a familiarity problem.
>> IDE's already support this, it's called Javadoc :-)
>> But the problem with symbols is much deeper than this. For example, suppose
>> you come across |@| in Scalaz code and you have never studied Haskell, much
>> less applicatives. Your first reflex will be to google it. Searching for |@|
>> alone yields no result (unsurprisingly) but "scalaz |@|" shows more promise.
>> However, the first two links point to Scalaz' main project page, and none of
>> them even contain "|@|" anywhere.
>> This result should be obvious if you know how Google search works (it
>> probably simply discarded |@| form the query) but it's one of the main
>> problems with symbols: they're hard to look up.
>> Google code search is of no help either, by the way.
>> You're pretty much dead in the water at this point.
>> So your only hope is to dive into the Scalaz code. Finding the definition of
>> |@| is pretty easy, but take a look at the source... Yup, not a single
>> comment, and a strong warning at the top telling you not to use it directly.
>> To make things worse, "applicative builders" don't exist in Haskell, so even
>> if you decided to bite the bullet and educate yourself in Haskell (never a
>> bad idea, but not everybody has the time), walking the ladder from functors
>> to applicatives and finally to monads will be a long and arduous climb.
> It might be a climb, but the end results speak for themselves.
> Additionally, there is a "culture" with programming these days that
> the IDE seems to do more than the developer. This is truly concerning.

I would disagree and say that the IDE should do more than the developer,
and that they still don't do enough. The more the IDE does for me, the
more I can focus my thoughts and intent of solving the problem at had,
the less I can worry about the language, libraries/APSs, etc.

> An IDE is nothing more than a tool (as is everything else) you need to
> use it correctly. you can be just as productive with Scaladoc and a
> text editor. Perhaps the issues are with how things are defined,
> rather with how people expect that new and important concepts that
> need to be understood require a little effort?

Again I disagree. To me using Scaladoc and a text editor is similar to
using a horse and buggy, where as using and IDE is like using a car
which can get me where I need to be faster.

Lately I have been writing some Scala code in Eclipse, and I am
constantly reminded that the Scala editor is like a Model T Ford
compared to the SUV that the Java editor is. From my perspective, the
Java editor in Eclipse significantly reduces the complexity of Java for
me - the complexity of the process of writing code.

Cheers, Eric

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland