Scala founder: Language due for 'fundamental rethink' • Hacker News Board

Re: Scala founder: Language due for 'fundamental rethink'

#51

Post by frowaway001 » Sat, Sep 06, 2014, 6:18 PM UTC

cynicalkane wrote: post #28

pjmlp wrote: post #21

Earlier quoted context omitted.

So you don't use type classes in Haskell? Neither touch F# or OCaml. Nor CLOS in Lisps.

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…

> For instance, in Haskell you can prove a functor instance has at most one implementation

How would one do that?

Re: Scala founder: Language due for 'fundamental rethink'

#52

Post by frowaway001 » Sat, Sep 06, 2014, 6:21 PM UTC

stevewepay wrote: post #41

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.

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.

Re: Scala founder: Language due for 'fundamental rethink'

#53

Post by frowaway001 » Sat, Sep 06, 2014, 6:24 PM UTC

cies wrote: post #10

> 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…

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.

Re: Scala founder: Language due for 'fundamental rethink'

#54

Post by frowaway001 » Sat, Sep 06, 2014, 6:26 PM UTC

cies wrote: post #11

"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 (…

Syntax is absolutely not the issue.

Re: Scala founder: Language due for 'fundamental rethink'

#55

Post by frowaway001 » Sat, Sep 06, 2014, 6:28 PM UTC

judk wrote: post #39

seanmcdirmid wrote: post #8

Earlier quoted context omitted.

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.

Do you think Scala could succeed with a "Scala--" fork: "Java, the good parts". Just a few things like type inference and implicits and case classes would be enough to make Java devs drool without getting scared by FP or performance scares.

That exists: http://en.wikipedia.org/wiki/Pizza_%28programming_language%2...

Re: Scala founder: Language due for 'fundamental rethink'

#56

Post by eplanit » Sat, Sep 06, 2014, 6:59 PM UTC

stevewepay wrote: post #41

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.

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.

Re: Scala founder: Language due for 'fundamental rethink'

#57

Post by tootie » Sat, Sep 06, 2014, 7:14 PM UTC

cies wrote: post #10

> 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…

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.

Re: Scala founder: Language due for 'fundamental rethink'

#58

Post by TheDom » Sat, Sep 06, 2014, 8:13 PM UTC

zak_mc_kracken wrote: post #27

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

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.

Re: Scala founder: Language due for 'fundamental rethink'

#59

Post by cies » Sat, Sep 06, 2014, 8:30 PM UTC

tel wrote: post #45

cies wrote: post #10

> 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…

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…

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?

Re: Scala founder: Language due for 'fundamental rethink'

#60

Post by cies » Sat, Sep 06, 2014, 8:33 PM UTC

pron wrote: post #32

cies wrote: post #10

> 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…

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.

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.