Scala future, Sing#

[Walter Bright]

Jari-Matti Mäkelä wrote:
> bearophile wrote:
> 
>> As Sing# (http://en.wikipedia.org/wiki/Sing_sharp ) and Chapel, Scala is
>> one of the languages to be followed more, because they share some of
>> future purposes of D2/D3.
>>
>> A small presentation about the close future of Scala (it's not a general
>> introduction to Scala): "Scala -- The Next 5 Years" by Martin Odersky:
>> http://www.scala-lang.org/sites/default/files/odersky/scalaliftoff2009.pdf
> 
> Scala is an impressive language and overall well designed. There are 
> certainly truckloads of features that could be taken from Scala to D. But 
> I'm afraid that the desire to have familiarity and compatibility with the 
> C/C++ family is more important in this community than cool new functional 
> features. Here's a quick comparison of some factors:
> 
> - community: From what I've gathered, the Scala community mostly consists of 
> much more experienced computer scientists and programmers (I don't mean 
> industrial boiler-plate experience but experience with different kinds of 
> languages, PL concepts and e.g. sound argumentation). These programmers 
> aren't afraid of radical new ideas if it helps every day coding. These guys 
> hate unorthogonality and love rigorous definition of semantics. They also 
> want to discuss language issues and unlike Walter, Odersky doesn't lurk 
> silently when important things are being discussed. This is a huge ++ to the 
> PR. He also welcomes academics and doesn't ask them to go back to their 
> ivory tower like most in D's community do. I understand embracing the 
> industry, too, but it hasn't brought much money to D's development yet.
> 
> - bloat: Scala is more lightweight. I've heard Walter say that he doesn't 
> like e.g. library defined control structures -

Actually, you can do them with "lazy" function arguments. There was an 
example somewhere of doing control structures with it.

> it's double-edged sword, and 
> D and Scala have taken different paths here (in D if something is commonly 
> used and it can be made built-in, it will be added to the compiler, in Scala 
> it's the opposite).

That's not quite right. I'll add things to the core if there is a good 
reason to - the compiler can do things a library cannot. For example, 
string literals.

> Scala has a very lightweight language core, and many 
> additional features are defined in libraries. Several optimizations that 
> improve the performance of HOFs are already known, but the compiler and 
> virtual machine are not yet as good as they can be. In theory a good 
> supercompiler can make Scala as fast as D.

I've been hearing that (about Java, same problem) for as long as Java 
has been around. It might get there yet, but that won't be in the near 
future.

> I personally find it funny that 
> the meta-programming features in D are perfect for shrinking the language 
> core, but every year new features still keep creeping it.

Actually, some features are being removed. Imaginary and complex 
variables, for one. There's some work being done to rewrite D forms into 
simpler D forms, saving hundreds of lines of code in the compiler.


> - dynamics: Scala is more dynamic (reflection, class loaders etc.) Thanks to 
> JVM.

Yes, but an interpreter or JIT is required to make that work. That makes 
the language binary not lightweight.


> - OOP: Scala supports dynamic OOP optimizations unlike D (unless a VM is 
> used).

Do you mean knowing a class or virtual method has no descendants? Sure, 
you need to know the whole program to do that, or just declare it as final.

> Thanks to the JIT compiler. The new 2.8 supports new static 
> optimizations similar to what C++ & D have had.
> 
> - syntax: Scala has a consistent and orthogonal syntax. Syntactic sugar is 
> used sparingly and when it's being used, it shaves off boilerplate quite a 
> bit.
>   * e.g. (_._2 * _._1) is something like (tuple a, tuple b) { return a(1) * 
> b(0); } in D.. I leave the definition of the tuple type as an exercise to 
> the reader. 
>   * (A => B) => (C => D) vs (B function(A)) function (D function(C))
>   * case class foo(val a: Int, var b: String) is somewhere between 10-30 LOC 
> in D
>   * In D syntactic sugar often saves only a couple of characters (like the 
> new template T!X syntax)
> 
> - modularity & types: Scala supports modularity much better IMO (pure OOP, 
> self types etc.). The abstractions are well suited for most tasks. But this 
> is a bit hard to compare objectively.
> 
> - high level features: Scala unifies OOP and FP. It also has novel new OOP 
> concepts.
> 
> - low level features: D wins here, OTOH a low level language isn't good for 
> e.g. sandboxed environments

Sure, but there's the Safe D subset, and also D isn't intended for 
non-programmers to download untrusted source code from the internet and run.

> - memory management: the JVM's GC is pretty mature, but of course manual 
> memory management isn't as easy as in D
> 
> - compatibility: D wins (?) here if C/C++ compatibility is important, but 
> Scala is compatible with the large existing code base of Java, though

You can mechanically translate Java to D, but it still requires some 
manual touch-up.

> - bugs: IMHO the unspecified parts of D and the huge amount of bugs made it 
> unusable for me. Luckily I found Scala and have been really happy with it. 
> I've only found maybe 1-2 bugs in it during the last 1.5 years. I usually 
> find about 5-10 bugs in DMD in 15 minutes after coming back to D.

I couldn't find any bugs you've submitted to the D bugzilla. If you 
don't submit them, they won't get fixed <g>.

> And I'm 
> also so happy to find that thanks to authors' knowledge of type systems 
> (dependent types, HM, System F, etc.) Scala is a genius at inferring types. 
> D doesn't really have a clue.

Can you give an example?

> Especially the array literal type inference is really naive.

How should it be done?

> - to summarize: I use Scala for high level tasks, and came back to D when I 
> need to see the actual machine code and optimize some tight inner loop. D is 
> sometimes more suitable for this than C/C++ since it has a bit saner syntax 
> and high level abstractions. But in general I nowadays write 90% of my code 
> in Scala. I'm much happier and more productive writing Scala. YMMV

I appreciate you taking the time to tell us your impressions on this.