
Scala founder: Language due for 'fundamental rethink' - snydeq
http://www.infoworld.com/t/java-programming/scala-founder-language-due-fundamental-rethink-249845
======
cies
> Essentially, the fusion of [functional and object-oriented programming] can
> have a power that neither of the two paradigms individually can have.

I tend to disagree. OOP can borrow some FP stuff (as we see with
map/each/select/reject in Ruby for instance, or lambda's in Java); or to take
it broader: imperative can borrow some from declarative.

But "fusing" the two will cause FP's ease-of-reasoning ("just functions and
data structures") to be lost. On top of that, when using a strictly typed
discipline (like Scala does), the types will become really messy.

So when it comes to FP, I like it pure-and-typed (a la Haskell), or untyped
(like the Lisps), but not mixed-paradigm.

When it comes to OOP/imperative I like to mix in as much of FP/declarative as
makes sense (like Ruby does for instance).

~~~
tel
I think there's a huge opportunity for FP+OO... but that OO will have to be
rethought from first principles (which are lacking in OO).

More specifically, I think OO-style code interactions are great but that they
need to be separated from ambient mutability, subtyping, subclassing,
inheritance, etc. Late binding/open corecursion is really cool however.

I would like to see a language which starts with ML modules as a base and
build a totally novel semi-OO system into FP. I don't think it would, at the
end of the day, look much at all like OO the way that OO appears today, but I
think it could still gather many of the advantages while maintaining ease of
reasoning, good type inference, etc.

~~~
bunderbunder
_I think there 's a huge opportunity for FP+OO... but that OO will have to be
rethought from first principles (which are lacking in OO)._ _More
specifically, I think OO-style code interactions are great but that they need
to be separated from ambient mutability, subtyping, subclassing, inheritance,
etc._

This has already happened. Ideally, good object-oriented code should always
prefer immutability over mutability, should prefer interface polymorphism over
inheritance polymorphism, should prefer has-a relationships (the OO version of
composition) over is-a relationships (subclassing), and so on. Much of this
was originally figured out a very long time ago.

So the issue isn't that these standards don't exist; it's that they aren't
widely understood among users of object-oriented languages. That, in turn, is
because OO is so widely used by so many programmers, including a lot of people
with very limited formal training in computer science, that most users of OO
languages have very little exposure to any of the literature about what
constitutes well-crafted object-oriented code. Certainly less so than in FP,
which benefits (in this department) from the fact that it hadn't even begun to
escape the ivory tower in any sort of serious way until just a few short years
ago. In short, object-oriented programming is a victim of its own success.

It doesn't help that the first really widespread object-oriented language
wasn't particularly object-oriented, either.

~~~
tel
> _Ideally, good object-oriented code should always prefer_

Really what I'm referring to is a language which outlaws instead of one that
leaves it up to preference. And by outlaw I don't mean entirely, but instead a
language which requires the programmer explicitly opt into these richer
domains as they are needed.

My understanding is that while these principles are understood as valuable, OO
is generally constructed as too permissive to enforce them.

In a similar story, unbounded recursion is generally "bad" in almost every
part of a program---nobody likes mysteriously hanging programs---but only
total languages have a formalism which allows you to profitably outlaw it.

So I'm convinced there are the beginnings of the theory of objects lurking
around out there even if they rarely see the light of day (really) in
practice. But I also recognize that modern functional semantics grew over the
last 80 years. I don't think (maybe I'm wrong) that the whole package of OO
has had so long to mature.

------
aaronharnly
How did Odersky miss Yammer's citing Scala's complexity as a reason for moving
away from it? Odersky said:

> _In terms of complexity, I don 't know whether Yammer featured that, but you
> definitely do hear that a lot [from] many people. _

The first paragraph (after introductory greetings) of Yammer's letter which
explains its action [1]:

> _Scala, as a language, has some profoundly interesting ideas in it. That 's
> one of the things which attracted me to it in the first place. But it's also
> a very complex language._

[1]
[https://gist.github.com/anonymous/1406238](https://gist.github.com/anonymous/1406238)

~~~
the_af
Indeed. Another example from the fourth paragraph of the letter:

 _" Scala, as a language, has some profoundly interesting ideas in it. That's
one of the things which attracted me to it in the first place. But it's also a
very complex language. The number of concepts I had to explain to new members
of our team for even the simplest usage of a collection was surprising:
implicit parameters, builder typeclasses, "operator overloading", return type
inference, etc. etc."_

It seems very clear the language's complexity was a major problem for Yammer.

------
tel
I find Odersky's comments on Swift very apt. I think both Scala and Swift are
aimed at being mergers between FP and existing OO systems and both of them
feel a little warty for the effort.

I really applaud trying to merge the benefits of FP and OO. I think it's going
to be a much larger and harder project than either Scala or Swift will benefit
from, but I'm really glad that they're exploring the design space.

------
noelwelsh
It's reassuring to see that the various groups working on Scala seem to have
the same broad goal in mind. I also think it is important to not let the
language ossify due to legacy -- which is the problem that kills many
languages.

~~~
Avshalom
Outside of maybe Fortran and Cobol I can't think of anything that was A)alive
enough to be killed B)killed by ossification.

~~~
rch
> Each new release of Delphi attempts to keep as much backwards compatibility
> as possible to allow developers to continue to use existing code without
> incompatibility of interfaces or functionality.

[https://en.wikipedia.org/wiki/Delphi_(programming_language)](https://en.wikipedia.org/wiki/Delphi_\(programming_language\))

~~~
Avshalom
I'm pretty sure Delphi died from having to compete with essentially free C#
and its better integration with Microsoft's ecosystem.

And a little bit from the shifting of the overton window away from paying for
languages.

And mismanagement of Borland/Inprise.

And about a dozen other factors before "lack of (breaking) change in the
language".

~~~
Roboprog
It's 1996. Java runs on Linux, Delphi doesn't. Java also runs where Delphi
runs. Java is free. Java 1.1 with inner classes looks much like recursive
blocks in Pascal (albeit without procedural types -- function pointers to C
folks).

THE END.

(sadly, as I really liked Borland Pascal)

------
zak_mc_kracken
Funny, when I read the headline, I thought this was referring to Paul Phillips
saying that "Scala is unfixable" [1] in the other thread. He's also a Scala
founder and he's also saying the language needs a fundamental rethink.

Interesting how the interpretation can vary.

[1]
[https://news.ycombinator.com/item?id=8277626](https://news.ycombinator.com/item?id=8277626)

~~~
TheDom
Paul is not a "Scala founder". Martin Odersky started to create Scala, the
language, by himself 10 years ago. Typesafe, the company around it, was
founded 5 years ago and Paul was one of the co-founders.

------
matwood
With the release of Java 8 I wonder if Scala is getting squeezed from both
sides. Java 8 on one and Clojure on the other.

~~~
virtualwhys
Unlikely, Clojure is very much its own thing, won't draw those that are drawn
to Scala (rich type system, (G)ADTs, performance, etc.). That branch of
potential adoption is minisicule anyway (even compared to Scala which relative
to Java is itself tiny).

So, the elephant in the room is indeed Java 8. Will Scala at long last be
killed? Perhaps, but highly unlikely, Scala lives and dies on its ecosystem
(Akka, Play, Spark, Spire, Spray, etc.) which are seeing ever increasing
_enterprise_ adoption.

If anything Java 8 and the JVM improvements made and coming will aid _all_
languages on the JVM that are different enough from Java 8+, which Scala,
Ceylon, and of course, Clojure, are. The only JVM language made vulnerable by
Java 8 is, IMO, Kotlin.

~~~
pps
Clojure is becoming increasingly popular in banks in the UK. (as I heard from
trusted person)

~~~
seanmcdirmid
What's up with the UK? Scala is also becoming increasingly popular in banks in
the UK (as I heard from trusted persons).

CLOS, Smalltalk, and Objective C (before it was cool) were for a long time
very popular on Wallstreet.

~~~
seanmcdirmid
Supposedly, Haskell and F# are also big in UK banks. Wow.

~~~
ckarmann
For what it worth, this website ranks the popularity of some keywords in UK's
IT job ads: [http://www.itjobswatch.co.uk/](http://www.itjobswatch.co.uk/)
Bank jobs are a big part of UK's IT jobs.

There is a category "Programming Language", in which you can see Scala and
Clojure has taken steam since 2010, even if interest in Clojure seems to have
waned a bit this year (and now it trails COBOL or Delphi). Interestingly, the
salary advertised for Scala and Clojure jobs are also larger than for the more
popular programming languages.

------
_random_
"Essentially, the fusion of [functional and object-oriented programming] can
have a power that neither of the two paradigms individually can have."

Very aligned with my opinion. I would add that having strong static type
system with opt-in dynamic types system (syntax integrated) adds even more
power (e.g. C#).

------
mjburgess
What a confused interview. If the audience is for people who are interested in
knowing scala's timeline then saying "isnt Java 8 functional now because it
has lambdas" is either dumb or trying to be dumb on behalf of a java audience
who doesnt care about the scala timeline.

~~~
mseepgood
Or "another language that's becoming popular, Node.js"

~~~
_random_
Lol - "language", it's not even a platform.

~~~
seanmcdirmid
Libraries, frameworks, and languages are actually quite similar; it was long
ago that when people said "Ruby" they actually meant "RoR".

------
bubblicious
I'm really hoping that functional languages will evolve in a way that they
become more readable at a glance.

~~~
shepardrtc
Haskell is very clean and readable. The problem, however, is that its such a
departure from imperative languages that you can't bring much of anything you
already know over to it. You really do have to forget everything you're
learned about programming and start from scratch. Until then, its all alien.
That being said, I think that Haskell is the most clean looking of all the FP
languages, but that's purely my opinion.

~~~
tormeh
Haskell suffers from people who want to make things look clean and achieve it
by using symbols and very short names. These things have to be memorized
before you can understand anything.

Basically, people are trying to make Haskell code look like math and the truth
is that math's symbolic notation is optimized for hand writing speed, /not/
reading comprehension.

Take a look at Ada code. Maybe they're taking it a bit far, but it's very
readable. Spelling words out and being very very sparing with symbols is a
very good thing, I think.

~~~
the_af
I don't think this is true. I think Haskell's notation is the way it is
because it emphasizes the "look" of certain abstract patterns that would be
obscured by the notation used in other languages (I believe this is the case
for math as well... I doubt it's that way for hand writing speed, since I
doubt that's the bottleneck in maths). This is not what many of us who come
from other programming languages are used to, and therefore we identify it as
"more difficult", but it actually is lack of familiarity. Not only with
Haskell itself, but with the abstractions and the way of looking at programs.

I doubt the majority of Haskell programmers would prefer a more verbose
notation. I think that, like the parent post, they consider Haskell very clean
and readable.

A friend of mine who is a proficient Haskeller told me he often struggles to
understand new Haskell libraries. Then the library "clicks" for him and he can
begin to use it. I -- who program in Java for my day job -- have trouble
understanding this, because this is seldom the case for Java: you may not
understand what problem a Java library is intended to solve, but _using it_ is
usually trivial (and mis-using it is trivial as well, of course!). I think
it's unfair to compare both languages this way, because in Java there is a
fairly low use of general abstractions, and Java's syntax (and coding
practices) have evolved to reflect this. The verbose syntax that works (1) for
Java is not suitable for other kinds of programming.

(1) for some values of "works".

~~~
klibertp
> since I doubt that's the bottleneck in maths

I'm not a mathematician, but I heard that math is most frequently written on a
whiteboard. If that's true, then optimizing for speed and space efficiency of
hand-writing suddenly makes sense.

> I doubt the majority of Haskell programmers would prefer a more verbose
> notation

The exact same thing can be said about PERL programmers. But why stop there,
take a look at APL, J, K languages. J, for example, ships with all standard
verbs aliased to words, like "under", "behead", "curtail" etc. Of course,
nobody uses those, they write "&.", "}.", "{." instead.

The difference is that in J you have small, consistent core vocabulary
([http://www.jsoftware.com/help/dictionary/vocabul.htm](http://www.jsoftware.com/help/dictionary/vocabul.htm)),
and once you learn it and it "clicks", you very much are ready to do anything
with the language. Haskell way makes you go through the same process again and
again with almost every library. The sad thing is that you _could_ write
Haskell in a way which wouldn't require you to internalize large numbers of
new symbols, but you generally don't. Is it really because of how much better
the abbreviated, symbol-based notation is so much better, I have to wonder.

~~~
the_af
> I'm not a mathematician, but I heard that math is most frequently written on
> a whiteboard. If that's true, then optimizing for speed and space efficiency
> of hand-writing suddenly makes sense.

But a lot of math is read from papers as opposed to written. Math and logic
papers employ the concise notation we're talking about. You'd think
mathematicians would have evolved a better notation for paper-writing if one
was lacking (there being already many conventions and style guides that apply
exclusively to paper writing and that are odd for everything else).

> The exact same thing can be said about PERL programmers. But why stop there,
> take a look at APL, J, K languages. J, for example, ships with all standard
> verbs aliased to words, like "under", "behead", "curtail" etc. Of course,
> nobody uses those, they write "&.", "}.", "{." instead.

Indeed, the same could be said about other languages. I was even going to
write in my original post "of course, Haskell programmers are self-selecting".
There are problems with the syntax of some of the languages you mentioned,
probably because they require a special keyboard, which is an obvious hurdle.
Others may not have prevailed because they were jarring to programmers _that
also had to program in mainstream languages_ (therefore, the familiarity
argument all over again). Yet others are arguable -- PERL for example is joked
about as a "write only" language, but how much of that is _truly_ because of
its syntax? Maybe idiomatic PERL merely leads to barely understandable
programs. Maybe PERL is simply not a good language, no matter what (note: I'm
not arguing this is the case, not being a PERL programmer myself). And maybe
it's not true that PERL programmers find no fault in its syntax; maybe they
have trouble reading their own code, which would put them in a different
category than Haskell programmers!

In the end, all of this amounts to: a language syntax is aimed at its intended
audience, programmers using that language and familiar with its intended
degree of abstraction and with the problems it aims to solve. Programmers from
other languages will often find it weird (and in Haskell this problem is
increased by the fact it seems to belong in a different category than
languages such as Java/C++/C#/etc.). It is a mistake to say that, because of
this, language X has a "harder syntax"; the more correct claim would be
"language X has a syntax that will likely be harder to learn for programmers
used to F-inspired languages". This is probably related to the Blub paradox :)

~~~
klibertp
> It is a mistake to say that, because of this, language X has a "harder
> syntax"

Yeah, I mostly agree. But I believe there _is_ some objective notion of
readability and that syntax can be objectively more or less readable. However,
that's only my belief, as we have no objective way to measure readability yet.
(There's this wiki article:
[http://en.wikipedia.org/wiki/Readability](http://en.wikipedia.org/wiki/Readability)
but as far as I can tell nobody bothered to apply methods mentioned there to
code)

So, as it's almost impossible to have a meaningful discussion on readability,
I don't try to argue that Haskell is or isn't readable at all. However, the
fact(? seems intuitive enough, but maybe it's wrong?) that it's easier to
associate meaning to words than to abstract symbols and the frequent use of
abstract symbols to name things in Haskell makes me argue that Haskell is
harder to learn than for example J (btw, J and K use only ASCII characters).
But that, too, is open to discussion - one can claim that names like <*> are
easier to learn and more precise, because they come without any prior
associations in the reader's mind.

In the end, the only thing I can say is that for me - probably because of a
whole lot of factors and influences - word-based identifiers are easier to
learn and use than symbol-based ones. It's entirely possible that a majority
of Haskell programmers are different in this regard (and yes, they - as for
all languages - are most certainly self-selecting).

------
cies
"The language is the code's biggest API" \-- my own words.

Breaking that API will result in a new language.

Scala, like several other languages (JS, PHP, Perl), has had very little time
to iterate on it's syntax before it got widely used. All these languages
want/need to make breaking changes to their syntax, at which point they are at
risk of becoming fragmented.

Python3 was not even so much different, still it was (and still is) a hard
upgrade for the community.

I really hope Scala manages though, it's the largest FP-on-JVM community I
guess, so good luck!

~~~
MetaCosm
Well -- they have the Python 3 disaster to learn from... you can't break
backwards compatibility for minor gains -- if you are going to break it --
break everything you must and make the new thing much better -- half measures
in this regard suck.

~~~
Pacabel
It's really absurd when people call Python 3 a "disaster". There was nothing
disastrous about it. In fact, hindsight shows us that it was actually a very
good path to take.

Python 3 didn't negatively affect Python 2 or earlier users. Their code still
runs fine, and is well supported by a huge number of libraries. They weren't
forced into upgrading against their will at any point.

Python 3 allowed the Python developers to make some breaking changes to the
language and libraries. These have, without a doubt, improved the language.

Much Python 2 code, especially well-written code, can be automatically
converted to Python 3 code with little to no effort. Anyone with any
sensibility who has been writing new Python 2 code within the past few years
has been keeping an upgrade to Python 3 in mind. Their transition should be
quite painless.

Over time, more and more existing Python libraries have supported Python 3, or
been replaced with significantly better replacements, as the need arose.

The fact that we see so many libraries simultaneously supporting both Python 2
and Python 3 goes to show that the community is not "divided" or anything like
that.

The only downside is that it took a few years longer than people may have
initially been expecting for certain libraries or frameworks to support Python
3. But at this point in time, Python 3 is a clean, usable language with very
good third-party library support. Existing users weren't forced into using the
new version, yet those developing the new version weren't constrained by
compatibility concerns. The end result is an improved and usable language,
achieved with minimal disruption.

Perl 6 is an example of a real disaster, on the other hand. It still doesn't
have a truly good implementation, even after 10+ years. Not only is Perl 6
pretty much unusable in practice today, but the uncertainty it caused stunted
the growth and development of Perl 5 for quite a while. It is only recently
that we've seen people finally realize that Perl 6 is a lost cause, and get
back to using and evolving Perl 5. Compared to Perl 6, the Python 3
development process was perfection.

~~~
orangecat
_Python 3 allowed the Python developers to make some breaking changes to the
language and libraries. These have, without a doubt, improved the language._

Sure. But the improvements aren't really that great, and IMO they weren't
enough to justify breaking everything. Some combination of a JIT compiler, GIL
removal, and optional typing might have been.

 _The end result is an improved and usable language_

And this is why I view Python 3 as instance of choosing purity over
practicality. Python 2 was and is a very usable language. It's vastly better
than JavaScript, which took over the world by virtue of being available
everywhere and having halfway decent performance, which ended up outweighing
its huge flaws as a language. I can't help but think that we'd be better off
if the effort spent on the Python 3 migration had instead been directed toward
speed and browser support.

 _Perl 6 is an example of a real disaster, on the other hand._

Certainly can't argue with that.

~~~
bwilliams
It's a major release and the language does need to evolve at some point. I'd
agree that Python maybe got a little too ambitious with the upgrade but it was
definitely a good thing.

------
stevewepay
Are there any risks to adopting Scala as a language for a project knowing that
it will change over the next few years? It sounds like as opposed to an
evolution, they are going to change the language itself, which sounds like
backwards incompatibility and refactors within a few short years if you don't
want to be considered legacy.

~~~
frowaway001
No, not really.

There might be a few changes, but probably nothing which can't be fixed
automatically by a tool/IDE. (They are investing in that currently.)

Additionally, if your code compiles with version X without warnings, it should
compile with version X+1, too. (Otherwise that would be a bug.)

Apart from that, stable versions are supported for a long time, so just like
in Java you can migrate when you feel comfortable with it.

------
VLM
Comments on compiler speed as a problem? I find it sometimes to be a bit slow.

