Scala does provide you with enough rope to hang yourself with. What's the solution to this? A. Don't hang yourself. New Scala shops should definitely abide by the style guide that is provided at scala-lang.org to help with this.

Also, use implicits and multiple inheritance very judiciously. One thing that is quite true from the OP, is that the "cake pattern" is indeed "the bakery of doom". If you have to use dependency injection, use something sane, like Guice. Or just ol' constructor injection.

My only big gripe with Scala is that OO syntax is a blight on the world. They should have provided multi-methods instead, so everything could be done with functional syntax.

    map :: [a] -> (a -> b) -> [b]

    class Functor f where
      fmap :: f a -> (a -> b) -> f b

    method fmap<a,b>(as: Functor<a>,f: a -> b): Functor<b>

    override fmap<a,b>(as: List<a>,f: a -> b): List<b>

In Scala, rather than doing that, we would just define Functor[A] as a trait:

    trait Functor[A] self => {
      def map[B](f: A => B): self[A]
    }

http://www.cs.washington.edu/research/projects/cecil/www/cec...

* Cecil divides its type system from its object-inheritance-overriding system. Huh?

* Cecil is dynamically typed with static sprinkles on top. So we have dynamic vtables, and also F-bounded polymorphism.

* Methods are referred to as being attached to objects, even though they are multimethods. This appears to imply asymmetric multimethods. Again, huh? What a strange design decision to make!

* Cecil offers nothing for dealing with ad-hoc polymorphism (ie: operator overloading). Admittedly, when Cecil was published, type-classes didn't even exist yet.

Method dispatching is done symmetrically on the arguments in Cecil.

This means you've got to either use qualified module names, make sure never to import two modules that export an identically-named method, or (if the methods have similar signatures) resort to a type-class.

I guess I just don't understand where you are coming from. It's been pointed out to you that Clojure hackers don't mind importing the generic functions. You replied that then your worry is that it would be hard to preserve type information in a statically typed language that works like Clojure. I mentioned that Cecil is statically typed and preserves type information, with a multi-method system that is somewhat similar to Clojure's. At least as I understand it.

If your entire worry is that you have to import every generic function you want to use, then I guess you and I just don't worry about the same things at all. To me, importing the functions that you use is a feature, not a bug! In fact, when I program in Python, I generally program a lot more with functions than with classes, and yes, in every module I explicitly import every single externally defined function that that module needs. Again, I consider this a feature, not a bug.

What I would object to is having to explicitly import all the method definitions that implement the generic functions used in a multi-method system. That would be insanity, but that's a moot point, as that is never required, as far as I am aware.

Also, common generic functions, however, such as map(), could clearly be automatically imported by the language. E.g., in Predef in Scala, or in built-ins in Python. In fact, in Python, map() is in built-ins, and you don't have to import it. Though, in Python's case, map() doesn't preserve the original container type

Again: dot-notation lets me write:

    import scala.collection.immutable.List

    def addn(n: Int) = (list: List[Int]) => list.map(_ + n)

    import scala.collection.immutable.List

    def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n)

You cannot define map() as a generic function, at least not in the sense that Common Lisp and Clojure use the term "generic function".

It can be conveniently expressed as a type-class method of a class 'Functor f :: * -> * ' or a trait method for a Functor[A]. Not a generic function.

I know that many people think that this is not a problem worth worrying about, but I think that in a large program it is. Accidentally calling a method that means something completely different from what you thought it meant is much less of a problem if you have to explicitly import the interface that the method you aim to call is supposed to be implementing.

> the generic functions.

I don't see how this is either here or there. I can import modules and then qualify functions within the modules, or I can import functions directly from the modules, renaming then if I want to. There's no difference, between these options, other than a minor difference in what name I use to refer to the function once its been imported.

> Again: dot-notation lets me write:

> import scala.collection.immutable.List

> def addn(n: Int) = (list: List[Int]) => list.map(_ + n)

> Instead of:

> import scala.collection.immutable.List

> def addn(n: Int) = (list: List[Int]) => List.map(list,_ + n)

It isn't dot notation that lets you do that; it's the semantics of how functions are located that lets you do that. Many languages support statically overloaded functions using functional notation. It's also quite easy to imagine a language which uses the syntax f(a) to mean what a.f() means in Scala.

Also, why is this to be considered so desirable? For the performance gain that comes from eliminating dynamic dispatch? In that case, it is certainly possible for a language that supports multiple dispatch to dispatch statically when it can infer that it is safe to do.

> See the difference?

Yes, I quite understand the concept, but it has nothing intrinsically to do with dot notation.

> And then, remember that map() is not a multimethod.

> It doesn't actually do dynamic dispatch on its first argument,

> or on any other argument. It's a type-class method; it does static dispatch

> on the functor type List[].

In Scala? I don't believe that this is correct. As far as I understand, there's a single implementation of map for the entire collection library in TraversableLike, which uses virtual functions provided by the concrete class (and a builder object which gets passed in implicitly) to construct the new container, loop over the old container, and add elements to the new container.

This is similar to how map() works in Python and Clojure, where there is a single implementation of map() which uses dynamic dispatch to loop over the elements of the container. The downside to the way that Python and Clojure doing things is that you get iterators or streams back, not the original container type. But they could return the original container type if containers in Python and Clojure were to have virtual constructors. Then map() could call these virtual constructors to return a container of the same type.

> You cannot define map() as a generic function, at least not in the sense that

> Common Lisp and Clojure use the term "generic function".

Clearly in a statically typed language, you also need some form of parametric polymorphism in addition to what Common Lisp and Clojure provide in order to preserve types. I see no reason why this should be insurmountable.

I've often done things in C++ that wrapped dynamic lookup in a generic function or class, to achieve the types of things that you say require type classes. Another thing you can easily do in C++ is to write template adapter classes to provide something similar to Scala's structural types.

Also, type classes surely don't require dot notation. Haskell is from where type classes originate, and Haskell doesn't have dot notation.

To avoid namespace pollution.

The reason that it is a non-issue is how often do you need to import two external functions with the same name that have different meaning into the same file at the same time? It does happen, but not so much that it is an issue.

With Python, for instance, there is sys.path and os.path. So what? I refer to one as sys.path and the other as os.path. BFD. And there's the join method on strings and os.path.join. Since one's a method and the other's a function in Python, you're right that if methods were called like functions in Python, there'd be a potential namespace conflict, but I'd just continue to refer to one as join and the other as path.join. I do that now anyway, so nothing would change!

Or let's take the example of draw. If we're only talking about drawing to the screen, then all of the draw methods can implement a common generic function. There's no problem. On the other hand, if I need to use both the "draw on the screen" draw and the "draw your gun" draw, then I'd import one as drawOnScreen and the other as drawYourGun.

If overloading in supported, then there's no need even to do renaming. You can just use draw all the time and the type system will know which draw is applicable for the type in question.

Once again, no problem.

In summary, your worry is just not a problem!

I don't find that to be a problem. In fact, I love Python's module and import system. And the worst thing about Python is it's OO dot notation. I wish that Python had multi-methods too, and no OO-style method calls.

Polymorphism doesn't need to be tied to the first argument's type, it can depend on any number of properties of any number of arguments (see CL's and Clojure's multimethods).

We could use some form of static overload resolution (like type-classes). However, it really does seem (to me) to be easier to just resolve the static overload based on the static type of the first argument, and then throw the rest of the overloading problems at dynamic dispatch.

When you think of a class as both a type and a module, it gets clearer. Many classes in the Scala collections library have a `map()` method. We could code `map()` as a single, universal generic function that dynamically dispatches on its first argument type... but nobody ever cared to override map as a virtual method anyway and that doesn't give us a consistent return-type at all. All we really want to say is that calling map over a `[a]` with a function `a -> b` returns a `[b]`.

You'll get no argument from me, but that doesn't mean that there should be an unfortunate syntactic distinction between the three.

In "classical" OOP, the type of the "dotted" parameter, the this pointer, the method receiver, tells the compiler to look in its own module/namespace for the method name.

If we just write getOrElse(herp,Darpity), then we now have to either make getOrElse a type-class method (type-classes are equivalent to certain usages of modules) to recover the same functionality of looking up the appropriate method, or we have to write herpModule::getOrElse(herp,Darpity).

So, yes, your code does need more import statements. I don't consider this to be a problem. Your code, however, does not need to qualify the functions that it calls with the module where the function is defined.

Sorry about that!

If you spend too much time reading Scala blogs, you may get the impression that 6 (the type babel) is how many people write scala. A lot Scala bloggers like to write articles that exploit or examine clever aspects of the type system but it can be pretty impenetrable at times. At least to a blub like me.

The things to be careful of are the advanced features such as implicit conversions, they seem like a great feature and in a small code base they work great. But if your code base grows at all it can be next to impossible to be sure what your code is going to do.

Not trying to repeat a cliche but as with most things, "With great power comes great responsibility," and Scala gives you a lot of power but it also puts the onus on you to know how and when to use it.

3) was true until a few months ago. Or maybe its because I switched from a remote source repo mounted via Samba to a local flash HDD :-) I have been using Eclipse trouble free for a few months now, no issues whatsoever, except for some magic required during the initial maven setup.

4) Is an issue Scala outsiders complain about, but I have never seen this as an issue with people actually using Scala.

Build times are high compared to Java projects, though this could simply be because I am using scalac instead of fsc to build projects via maven. However, compilaton is incremental, so crazy build times should never occur in practice and the IDE highlights mistakes in less than a second.

In my experience, the language is built by people who really want to make things work. They do all the painful work to make even the most exotic corner cases work as people would expect it. So developers can be confident that the language doesn't break down suddenly, like when you overuse Generics in Java and just hit the wall where the compiler decides that it won't let you do that for no good reason.

The best thing about Scala imho is that they deliver. People are constructive and when valid issues are brought up, they will be fixed. (Better IDE support, more documentation, faster compilation, smaller standard library, better performance ...)