Mon, 21 Dec 2009 18:01:29 +0100, Daniel de Kok wrote:
> On 2009-12-18 18:02:28 +0100, retard <r...@tard.com.invalid> said:
>> I've only seen how Scala solves problems elegantly. These are from some
>> biased blog posts etc. Can you show one example that looks uglier in
>> Scala, but looks decent in D or some other language?
>
> some random things that I found annoying:
>
> - Types of both worlds get mixed. For instance, Scala has 'functional
> lists', but much of the Java world uses mutable lists (following the
> List interface). If you use the vast amounts of Java class libraries
> around (since the Scala library is still fairly minimal), you either
> have to fall back to Java lists (which do not work with a functional
> style of programming) or convert list back and forth all the time.
This is an unfortunate implementation issue. There's probably a
workaround - some conversion classes such as
scala.collection.JavaConversions._ - one could imagine.
> - You can do functional programming, but it will end up being slow,
> because of the lack of proper tail-call recursion optimization.
Again an unfortunate implementation issue. Will probably be fixed later.
> - Documentation for much of the Scala library is non-existant. There's a
> lot of second-guessing which traits you are expected to use, or which
> self-calling functions are tail-recursive. Since method signatures are
> pretty unreadable as well, you are pretty much on your own.
Agreed. Will be fixed later. Keep in mind that D is older language than
Scala - now tell me what mystruct.tupleof.stringof does - where's the
documentation? From the top of my head I can imagine at least 200
different cases where the D/Phobos's documentation sucks.
> - Classes are ugly. Constructor parameters are part of the class
> definition:
>
> class Something(someString: String)
>
> While this looks like a somewhat typically functional type declaration
> in this simple case, once you start building real classes they pollute
> class declarations, since you have to do non-trivial initialization
> somewhere. Of course, you could do this in functional style, but most
> libraries are not written in this manner.
The idea probably is to make all declarations syntactically uniform:
class foo(bar: T) - class def
def foo(bar: T) - function def
case foo(bar: T) - pattern
new foo(bar: T) - class instantiation
(new) foo(bar: T) - case class instantiation
Did you know you can also use D like explicit constructor functions:
class foo {
def this(...) { ... }
}
The constructor on the first line has a special meaning. It can save a
lot of typing - no getters and setters anywhere.
>
> - Pattern matching with match...case is not particularly elegant
> compared to Haskell (where you just have multiple function definitions).
No, the match-case construct is equivalent to case-of in haskell. You can
also pattern match via overloading:
abstract class A
case class B() extends A
case class C() extends A
def a(b: B) = 1
def a(b: C) = 2
def b = _ match {
case B => 1
case C => 2
}
val foo = a(B())
vs
data A = B | C
a B = 1
a C = 2
a b = case b of
B -> 1
C -> 2
foo = a B
>
> - Currying is not trivial: either you have to define multiple parameter
> lists, or construct a new function that allows for currying
> (Function.curried). And at the call site, you also need two parameter
> lists if you call a 'curryable' function without currying.
This is a larger problem in the language. I'm not sure if anything can be
done without causing problems in other use cases.
> - There's a lot of operator overloading abuse. I like the freeness of
> overloading for DSLs. But using method names such as /: and \: (which
> are just folds) sometimes makes things quite unreadable.
Those are not operator overloads. Abuse?
>
> - Generics are still implemented via type erasure.
Implementation issues..
>
> Scala is to Java what C++ is to C, an old language with new constructs
> forcefully bolted on top. It is powerful, and people will continuously
> find fantastic things you can do with it. But it is also overly complex,
> verbose, and unreadable, and inherits some legacy from Java. If it
> really catches on, most users will probably restrict themself to a
> subset of the language.
JVM has its weaknesses. If you write win32 code in D, you get the shitty
performance and terrible toolchain when using dmd/dmc or give up
exception support (ldc). I wouldn't use D on win32 for anything that
requires high performance - c, c++, and java are much better.
Other than that I'd call your claims big time utter bullshit. First,
scala is less verbose than c++, c, d, or java. You can measure this
yourself - come back when you've done your homework.
Scala is less complex than C++ or D. Count the number of keywords, the
number of constructs, the number of special cases in language grammar or
semantics, built-in types, etc. Try to find even one area where Scala is
*more* complex than D. It has a handful of features that D doesn't - but
my gut feeling is that D3 will get some of those (for instance
implementations in interfaces aka traits).
Unreadable? Ok..
Inherits some legacy from Java? Now build an OOP language that runs on
JVM and looks less like Java. Java is pretty much the common subset of
features most modern mainstream languages (C#, C++, D, Scala, Vala etc.)
comprise of. Scala doesn't look especially Java like. Keywords like
'extends' comes to mind, but it also shares many features with C#,
Pascal, Haskell etc.
