[adabsurdo]

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

[felipehummel]

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.

[adabsurdo]

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

[kikibobo69]

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.

[zohebv]

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.

[soc88]

??? 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 ...

[finnw]

> ::, :::, ++, :+, ++:, +:

> 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.

[zohebv]

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.

[soc88]

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 ...

[Inufu]

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.

[soc88]

The official style guide says the opposite:

    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.

And searching ... well, every symbolic method name has a searchable string embedded in ScalaDoc.

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 ...