Scala founder: Language due for 'fundamental rethink'

http://www.infoworld.com/t/java-programming/scala-founder-language-due-fundamental-rethink-249845

by snydeq • 12 years ago

174 116 12 years ago

noelwelsh• 12 years ago

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.

Avshalom3• 12 years ago

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

pjmlp10• 12 years ago

And even those have modern standards.

Object Cobol anyone?

rch• 12 years ago

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)

judk2• 12 years ago

Java isn't dead, but it suffered greatly during the hibernation years starting with the Oracle takeover.

VLM2• 12 years ago

"killed" might be a bit strong, but the overall story of "stop working on perl 5 in favor of working on perl 6" contains some aspects of the concept.

mjburgess• 12 years ago

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• 12 years ago

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

_random_2• 12 years ago

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

acjohnson552• 12 years ago

I agree. It hardly sheds any light on what's really going on in the Scala community or why.

bubblicious• 12 years ago

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

EdwardDiego• 12 years ago

Scala can be as readable or as unreadable as you like. Which is the problem with using Scala in a corporate environment, it can become a terrible weapon in the hands of a bad developer.

seanmcdirmid10• 12 years ago

You also have to decide whether to use scala as a functional language or as a better java. Each approach has its merits and drawbacks.

virtualwhys2• 12 years ago

Readability is in the eye of the beholder, which is to say, familiarity breeds content.

yogthos• 12 years ago

I find Clojure to be one of the most scannable languages. The s-expression syntax gives you a visual representation of the relations between different pieces of code. When you see one expression nested inside another, you know they're related. You can tell what branching and relations are there by a quickly scanning the code and looking at the indentation. Having a bit more syntax than traditional Lisps helps break the code up visually as well. For example, things like bindings jump out immediately.

shepardrtc• 12 years ago

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.

dragonwriter• 12 years ago

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.

I don't find that really true; if you've used any structured language with static typing, there's a lot of carryover, especially if you've ever done any formal study of CS, since even when imperative languages are used functional patterns are pretty common.

The biggest problem I see is that there isn't a lot of pragmatic guidance on the bits that are unique to Haskell -- a lot of the documentation is very abstract, without a lot of guidance on solving specific real world problems. The power of Haskell is that you can make very general solutions in it quite easily; the weakness of the documentation of Haskell is that virtually all of it focusses on that highly general facilities and not enough on the kind of specifics that would help people get familiar with it while solving real problems.

tormeh2• 12 years ago

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.

tel7• 12 years ago

I think that has a lot to do with personal familiarity over language design. FP designers are rarely trying to make their languages feel familiar to C/Awk/Python/Lua/Ruby/Java programmers---though it certainly is an influence from time to time.

_random_2• 12 years ago

"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#).

cies10• 12 years ago

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).

seanmcdirmid10• 12 years ago

I agree with this, but I always used scala as a OO language mixed with FP features. I prefer OO, but many in the scala community were adamantly on the FP side (7 years ago, not sure today).

About OO: subtyping leads to semi unification which really complicated type inference. I'm beginning to think it might not be a good idea to combine FP unified features with OO semi unified features.

cies10• 12 years ago

I always used scala as a OO language mixed with FP features

Good point! Must admit that I did not write a lot of Scala, but I always approached it from the FP side :)

pjmlp10• 12 years ago

So you don't use type classes in Haskell?

Neither touch F# or OCaml.

Nor CLOS in Lisps.

cynicalkane• 12 years ago

A major advantage of typeclass polymorphism vs dynamic polymorphism is that typeclasses enable parameteric polymorphism, and parameteric polymorphism enables reasoning that is lost if types can "pretend" to be a supertype.

For instance, in Haskell you can prove a functor instance has at most one implementation (if we disallow diverging values), uniquely given by fmap id === id. GHC can automatically derive it for you. If you have dynamic polymorphism this is lost because now you can have "nonuniform" functor instances that behave differently for different types while still satisfying the functor laws.

More generally, parameteric polymorphism eliminates a large number of "behavior surprises" that can lurk in OO code. And with existential types I never find myself missing dynamic polymorphism. Similarly, in Clojure, if I find myself using dynamic behavior, it's either to interact with Java or as a hacky version of parameteric behavior.

cies10• 12 years ago

So you don't use type classes in Haskell?

Sorry, how does this remark relates to my comment?

the_af8• 12 years ago

Correct me if I'm wrong, but isn't OO in OCaml frowned-upon, or at least not used frequently by seasoned programmers?

Not an OCaml programmer myself, but I heard this multiple times. For example, in Real World OCaml [ https://realworldocaml.org/v1/en/html/objects.html ]), and I quote from Chapter 11:

You might wonder when to use objects in OCaml, which has a multitude of alternative mechanisms to express the similar concepts. First-class modules are more expressive (a module can include types, while classes and objects cannot). Modules, functors, and data types also offer a wide range of ways to express program structure. In fact, many seasoned OCaml programmers rarely use classes and objects, if at all.

To be fair, the chapter goes on to explain why you'd want objects. It also states they are very different from objects as understood by other OO languages. I'd say OCaml is therefore a bad example for OO.

How are type classes in Haskell an OO feature?

cokleisli• 12 years ago

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

pron2• 12 years ago

But look at Clojure. It's imperative yet quite FP, but much of the language rests on OO polymorphism. Clojure certainly isn't an OO language (in fact, it is decisively "anti-OOP"), but it does mix an essential OO idea, and that actually helps keep the language simple.

cies10• 12 years ago

I would not call Clojure imperative myself. To my best knowledge it allows imperative style just as much as declarative. And having read some Clojure code before I thought that it's community kind of prefers declarative for most things.

pjmlp10• 12 years ago

Clojure certainly isn't an OO language

Multi-methods and protocols

tel7• 12 years ago

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.

cies10• 12 years ago

I feel that Golang in many ways is on that path, the way it does not allow no-subclassing really got me thinking.

I don't think it would, at the end of the day, look much at all like OO the way that OO appears today

Won't it be more like a Actor-oriented thing then?

bunderbunder• 12 years ago

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.

seanmcdirmid10• 12 years ago

Uhm...you mean like Moby?

http://moby.cs.uchicago.edu/

jberryman2• 12 years ago

What is "open corecursion"?

frowaway0016• 12 years ago

So what are you proposing to prevent functional languages form being a complete nightmare from a modularity point of view? (See Haskell.)

Module systems aren't much more than castrated object systems, so I don't see a real benefit of picking some half-assed module system over a first-class object system.

cies10• 12 years ago

Haskell modules may be lacking in some aspect, but I certainly dont think they are half-assed. They are conceptually very simple and the community got quite far with them.

I also dont think that Haskell-modules and objects are on the same level, for instance: Haskell's modules do not encapsulate state.

tootie• 12 years ago

In Java 7 it was pretty trivial to create a closure with an anonymous class and if that anonymous class implemented Callable or Runnable it was effectively a lambda with strong types.

cies10• 12 years ago

"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• 12 years ago

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.

hippiehippo• 12 years ago

Python is a dynamic language and a compiler can't do much in helping you move from 2 to 3. You really need good test coverage.

Pacabel2• 12 years ago

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.

frowaway0016• 12 years ago

Syntax is absolutely not the issue.

vladsanchez2• 12 years ago

Scala's syntax is a glorious fuckup! YMMV

matwood• 12 years ago

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.

frostmatthew• 12 years ago

Relevant: Will Java 8 Kill Scala?[1] (spoiler: Betteridge's law applies)

[1]http://ahmedsoliman.com/2014/03/26/will-java-8-kill-scala/

pjmlp10• 12 years ago

Depends if the question is targeted to startups using the JVM or the classical bureaucratic enterprise.

virtualwhys2• 12 years ago

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• 12 years ago

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

zak_mc_kracken• 12 years ago

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

TheDom• 12 years ago

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.

stevewepay• 12 years ago

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.

frowaway0016• 12 years ago

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.

eplanit• 12 years ago

If stable longevity for your project's implementation is important (as your question implies), then I think Scala does present additional risk (relative to stable/mainstream languages). It sounds to me, too, that they are thinking of changing fundamentals in the language/system. This could lead to something like the Python2vs3 scenario for a while. If you base on current Scala, you might (likely) later find yourself doing either a re-write, or being relegated to a "compatibility" library. You're wise to ask.

acjohnson552• 12 years ago

It depends on what you're doing. If you're really pushing forward with experimental features, sure, there's some risk. But if you're using common libraries, you probably have more to worry about staying up to date with the library interfaces than the language changes.

tel7• 12 years ago

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.

aaronharnly• 12 years ago

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

the_af8• 12 years ago

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.

tormeh2• 12 years ago

I wonder if that means Odersky's not really listening to criticism, which would be really bad.

EDIT: He does, he just doesn't remember where it's coming from.

VLM2• 12 years ago

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

Scala founder: Language due for 'fundamental rethink'

Related Stories