
Scala: Next Steps - jfb
http://scala-lang.org/news/roadmap-next
======
juliangamble
Some context - the lead developer on the Scala Compiler, Paul Phillips, went
slightly AWOL last year, and presented the talk "We're doing it all wrong"
[https://www.youtube.com/watch?v=TS1lpKBMkgg](https://www.youtube.com/watch?v=TS1lpKBMkgg)
[http://www.slideshare.net/extempore/keynote-pnw-
scala-2013](http://www.slideshare.net/extempore/keynote-pnw-scala-2013)

He still seems slightly burnt by the whole thing:
[https://twitter.com/extempore2/status/493633548994097154](https://twitter.com/extempore2/status/493633548994097154)

Other critiques of Scala collections have been made with the Typelevel library
[https://github.com/scalaz/scalaz](https://github.com/scalaz/scalaz) which
aims to fix these issues.

This post, 'Next Steps', seems to have come out of Martin Odersky's response
to the situation. I commend him for taking practical and thought out action.

------
thescrewdriver
Summary:

Scala 2.12: Focus on leveraging JDK8 features and interop

Scala next: Collections framework simplification

Scala next next: Language improvements

~~~
CmonDev
It's a shame they are not focusing on the most lagging bit - CLR/Mono support.

~~~
thescrewdriver
There doesn't seem to be much demand or interest for that overall. They
recently discontinued the .NET support. Almost everyone was using it on the
JVM. Any specific reason why you'd need CLR instead of the JVM?

------
tormeh
I love how they don't take backwards compatibility so seriously. A lax
attitude to backwards compatibility means they can actually have the syntax
get less bad over time, instead of becoming C++. Scala does have some less-
than-obvious things that need to be fixed.

~~~
PopsiclePete
It's a double-edged sword. C++ is C++ partly _because_ the language doesn't
change willy-nilly from underneath you. I could probably still compile C++
code from 1996, you can't even compile Scala code from 2012.

To you, that's a feature. To me, it's a sign that the language designers don't
know what the heck they're doing and are throwing everything at the wall,
watching what sticks and what doesn't.

I have _very_ little faith in Scala because of this. It's a language that
doesn't know what it is now, what it wants to be tomorrow, what it wants to
look like to act like...I _despise_ C++ but I'd never, in a million years,
start a new project in Scala. I'd have to rewrite it in a year.

Maybe once the Scala gurus figure out what they're doing and release some kind
of stable "spec", it'd be worth checking out. Until then, it's just a cool
toy.

On how that's done, look at Go. Go 1 was released over 2 years ago and there
have been no backwards-breaking changes yet, nor will there be. _That 's_ how
you build a community.

My 2 cents.

~~~
frowaway001
Did you just make that up, or is there any actual experience backing up your
claims?

Sorry, but that just reads like the usual "let's throw some random claims
together I have read on the Internet from people who never actually used the
language either" which everyone knows by now.

Do you have anything worthwhile to add to this discussion?

~~~
coldtea
> _Do you have anything worthwhile to add to this discussion?_

Do you?

For one, he mentions what he wrote is just his "2 cents", and he is entitled
to his opinion.

Second, he provides factually true statements to support his opinion, e.g that
you need to make syntax changes to compile previous Scala code on later
versions of the Scala compiler.

You might agree or not agree with him, but he states what he believes, and
supports it with arguments and counter-examples (e.g the Go reference).

OTOH, besides the insult to the parent, your comment is content-free.

~~~
frowaway001
>> Do you have anything worthwhile to add to this discussion? > Do you?

I already have?

> he is entitled to his opinion

This doesn't mean he should be immune to scrutiny when making claims which are
intended to drag the discussion into boring flame-wars.

> he provides factually true statements to support his opinion

Like "I'd have to rewrite it in a year."? Have a look at how long Scala
releases are supported, both officially and with commercial support. That
statement is just factually false.

Apart from that it's the usual comparison with C++ which don't provide any
interesting insight except showing that the author has not much clue about the
topic.

> release some kind of stable "spec"

Scala, like Java or C++, are evolving languages. While having some kind of
mechanically checked spec (which is what Scala developers are working on)
would be great, we have to accept that almost no language manages to do that.

All three languages (and most other languages as well) have compilers which
differ from the spec in some cases, and specs which leave out important
details important to compiler implementations. I don't see the reason for
singling out one language.

> Go [...]

Well, it's not kind of hard to have a stable language (let's just ignore all
the changes in Go which broke programs for a minute (Go's runtime and its "GC"
are probably the largest offenders)) if it could have been rightfully called
obsolete in the 1970ies.

What's missing in this comparison is the level of usefulness achieved by the
language. As an example, whitespace and brainfuck have probably been stable
right after their creation, it's just they are no that useful to solve today's
problems.

More expressive language are harder to keep stable, but it's not that you
don't gain anything in return.

------
benjaminjackman
I really wish they'd stop grouping procedure syntax in with things like xml
literals and forSome syntax. Procedure syntax is still used a majority of the
time when able judging by the commits on github and it has several benefits
whereas the others are rarely if ever used. Removing it while leaving things
like postfix operators in, but behind a -feature flag is senseless.

~~~
frowaway001
Compared to the other features you mentioned, procedures are actively harmful.
That's the reason why they are (slowly) going away.

~~~
kasey_junk
In what possible way is the procedural syntax harmful?

~~~
frowaway001
People want to write methods, but forget the =. In the worst case, the result
is silently swallowed and the bug manifests itself only later at the use-site,
not at the point of declaration.

~~~
kasey_junk
The exact same complaint could be registered about any function that doesn't
have an explicit return type, yet there is no move to make that mandatory.

~~~
frowaway001
No. If the method has no explicit return type, it is inferred. It's really
reducing the usefulness of type inference if a trivial error can flip the
switch from "the return type is computed from the last expression of the
method body" to "the method body is ignored completely, and () is returned
instead".

Apart from that, there is a move to make explicit return types mandatory in
some places; for instance when defining implicit conversions or when declaring
abstract methods in traits.

~~~
kasey_junk
And yet, if there is an idiomatic Scala (and the lack of one is a huge problem
with the ecosystem) it's that nobody uses function syntax for Unit return
types. So in order to get rid of a class of bug that is minuscule compared to
others you are going to require hundreds of thousands (millions?) of lines of
code to be changed. It's that kind of lack of real world perspective that
causes the Scala community to be derided.

The most recent version of the Xlint/future features are useless because of
this blind spot making so much noise in the output.

~~~
dragonwriter
> And yet, if there is an idiomatic Scala (and the lack of one is a huge
> problem with the ecosystem) it's that nobody uses function syntax for Unit
> return types. So in order to get rid of a class of bug that is minuscule
> compared to others you are going to require hundreds of thousands
> (millions?) of lines of code to be changed.

If there's an automated conversion tool, who cares?

~~~
benjaminjackman
Will the tool scan github, epfl papers, and the rest of the internet and fix
the Scala there, which is still being produced using procedure syntax?

~~~
dragonwriter
It will scan the code you clone, copy, etc. from those places.

------
programminggeek
It feels like a faster complier is still a ways out.

That's really too bad.

~~~
kasey_junk
I really do not understand this continued complaint about Scala compilation.
I've been developing in Scala for over 4 years full time and have never had
compile times be the major bottle neck in my workflow. Between incremental
compilation and good modularity test times dominate my "waiting" cycles and
that is on the order of seconds. Hardly noticeable given my think/type loop is
much slower than that.

I have any number of complaints about Scala but compile times is way down on
my list. I'm generally interested in what sort of compiler performance is
expected.

That said, it might be a generational difference as I've worked on projects
where full compiles happen overnight...

~~~
harryh
How much code are you compiling? At Foursquare (with 100s of thousands of
lines in our bigger servers) compilation times are awful. We're solving this
by better modularizing, but it's a long journey.

~~~
oelang
It's too easy in scala to create a giant mudball codebase where every file
depends on half the project. Managing the compile graph is almost impossible
when you have 20 hackers on the same codebase.

Sometimes I wish that scala had some compiler-flag that signals these
problems, maybe a restricted mode or something with annotations.

~~~
frowaway001
Like this:
[https://github.com/lihaoyi/acyclic](https://github.com/lihaoyi/acyclic)?

~~~
oelang
I tried it, it's not flexible enough for my needs.

~~~
frowaway001
File issues and describe your use-case! :-) The author usually seems to be
quite responsive.

