Scala founder: Language due for 'fundamental rethink'
infoworld.com
infoworld.com
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).
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.
Good point! Must admit that I did not write a lot of Scala, but I always approached it from the FP side :)
Neither touch F# or OCaml.
Nor CLOS in Lisps.
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.
How would one do that?
Sorry, how does this remark relates to my comment?
There are a few places where this chain is weak.
They never occurred to me as OO. Could someone explain this?
Sorry if I misassume your OOP experience.
Many think about OOP as introduced by Simula/Smalltalk, or how it is served by Java/C#... ones.
However there are many other ways of doing OOP, which many of us in the old (early 90's) experimented with, while OOP was striving to become mainstream.
Type classes in Haskell and their use, can be easilly mapped to interfaces/protocols/traits/... in the OO world.
From the OOP point of view, type classes are a group of operations that can be applied to a given type and refereed to by a specific name.
Which allows writing polymorphic operations over types that support a specific a specific group of functionality.
Polymorphism and data hiding are the common concepts across all OOP proposals.
As for the remaining concepts, there are lots of languages that agree to disagree, between mainstream, academia and lost OOP battles.
And I can call one of the many Simon Peyton Jones talks that describe this, http://yow.eventer.com/events/1004/talks/1054, starting at 00:42.
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?
Consider an example:
let a = object method f x = 1 end;;
val a : < f : 'a -> int > = <obj>
Define another object
let b = object method f x = 2; method g x = x end;;
val b : < f : 'a -> int; g : 'b -> 'b > = <obj>
let f obj = obj#f ();;
val f : < f : unit -> 'a; .. > -> 'a = <fun>
f a;;
- : int = 1
f b;;
- : int = 2
That said, I think, the authors of "Real World OCaml" are right, encouraging the use of Modules rather than Objects. But they do so primarily because in many mainstream languages the main means of abstractions are objects, and they are used for everything. OCaml has functors, modules, it has records, it has ADTs, it has functions, so the need for objects is very limited, and so the new users must get this message very clearly.
An article on objects in OCaml: http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/
I think I understand the appeal of structural typing: you are defining implicit anonymous interfaces as you write objects, and automatically grouping objects that share structure. But in which case is this more useful than, say, defining type classes or using explicit interfaces in mainstream OO languages? Or is it a case of preferences?
I can see a difference with objects: in most mainstream OO languages you cannot retrofit an object to comply with the interface you want if you don't control the source code and the object only differs from what you need on a triviality such as naming. But what about type classes? Isn't this what they are there for?
See https://news.ycombinator.com/item?id=8280613
There are so many ways of doing OO.
So, what OO is all about will depend which researcher gets asked.
Yes, we can use less currently mainstream (note: not less correct) definitions of OO, but that doesn't help the Scala=OO+FP position.
Jump dump what is being worked on at any given point in time?
For me it is hard to grasp how youngsters see OO or FP, because I was part of the initial mainstream waves. So I got to see the things in a different perspective.
The world at companies was procedural, and lots of experimentation was going on.
Multi-methods and protocols
As someone that likes multi-paradigm languages, I tend to dislike that many FP guys "forget" their languages also do have first class support for OO when needed.
Somehow, I did not read you comment properly and spitted out a bad comment.
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.
> 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?
I'm pretty decent in Haskell and fluent in Go at this point, and it really depends on what you mean by that. Is Go a certain brand of very refined OO? Yes. I've even found certain ideas from PF are surprisingly adaptable [1], the "surprise" being that it's not the usual "Look, Ma, I can map/filter/reduce!" that an OO language borrows from the FP world, which Go is actually really hostile to. (Go does have closures and they are important, but the type system precludes a lot of the "good stuff".)
However, is Go headed in the direction of Haskell? No. It's definitely not. Trying to turn it into Haskell would be nothing but pain. Mutability is pretty fundamental in Go, and while there's a culture of isolating it to goroutines, the language itself does little to help with that.
Indeed that's what I meant.
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.
But we're talking about language design. I think enforcing constraints is much (maybe all, from a certain point of view and definition of "constraint") of what a programming language ought to do. Haskell code is principled because the language is principled, not because of conventions passed from an ivory tower.
Also do you know of any languages built around those principles you mention? It sounds like studying such a language might make OO click for me a little more.
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.
x -> F x
newtype Stream = Stream { runStream :: (X, Stream) }
The similar game in a recursive function might be defining face like so
fact :: (Int -> Int) -> (Int -> Int)
fact recur n = n * recur (n-1)
fix f = f (fix f)
fix fact :: Int -> Int
let term recur n = if n == 0 then 1 else recur n
> fix fact 3
-- infinite loop
> fix (term . fact) 3
6
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.
I also dont think that Haskell-modules and objects are on the same level, for instance: Haskell's modules do not encapsulate state.
> 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.
"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.
EDIT: He does, he just doesn't remember where it's coming from.
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.
Object Cobol anyone?
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".
THE END.
(sadly, as I really liked Borland Pascal)
Interesting how the interpretation can vary.
[1]http://ahmedsoliman.com/2014/03/26/will-java-8-kill-scala/
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.
CLOS, Smalltalk, and Objective C (before it was cool) were for a long time very popular on Wallstreet.
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.
There seem to be several drivers: the FP part appeals to the algo guys, immutability is attractive when looking at concurrency, and they can interop with the extensive existing Java codebase easier than some of the alternatives.
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#).
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.
I don't think the community wants to go in that direction though. Who Scala attracted was a lot of FP programmers (Haskell/ML) who wanted to do work on the JVM; not Java programmers looking for a better alternative to Java on the JVM.
So is life.
(1) i.e. my coworkers, and people I know in other companies.
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.
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.
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".
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), 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.
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 :)
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 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).
OCaml code, on average, has less symbol-based infix functions and tends to be more readable (for me). But I'm not a Haskell programmer, so maybe that's a matter of getting used to, like parens in Lisps...
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!
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.
Comparing to a series of "Apocalypses" (the term used early in perl6 development to refer to radical breaking changes) is not great evidence that python3 is non-disasterous.
Do you really think python3 being 6 years in limbo (and counting) is a good thing? Probably not fatal, but I don't see how it's good.
From the very start its goals were clear. Yes, it took some time to implement them, but this was done rather efficiently and quickly.
Unless you were using one of a handful of libraries that didn't put forth the effort to be compatible with Python 3, it was very easily to adopt Python 3 early on, and to use it effectively.
I worked with a group that adopted Python 3 relatively soon after its official release. This would've been around early 2009. We developed a number of large systems using Python 3, without any major problems. Sure, we ran into bugs now and then, but we reported them and they were fixed soon enough. We helped port some libraries to Python 3.
We didn't regret the decision to go with Python 3 then, and the last I talked to people still involved with those projects, they don't regret the choice now. They're glad that their millions of lines of code are targeting Python 3, which is without doubt the future of the Python language at this point.
I don't know why people such as yourself continue to portray Python 3 as a "disaster", when all of the evidence and much of the experience with it shows the complete opposite to be true.
It was a smooth transition for Python 2 users who didn't want to or need to upgrade. It was a smooth transition for Python 3 early adopters. It's a rather smooth transition now for Python 2 users who want to use Python 3. "Disaster" just isn't the sort of term to describe a transition that goes well for all involved.
You're speaking in the past tense about a present problem. Many large projects that would like to migrate to Python 3 cannot because the library support isn't there.
This is in no way meant to disparage the motivations that led to Python 3, because it's better in every way than its predecessor. Only that the transition problems are still present, and the larger the project, the more difficult the transition.
Sage (http://www.sagemath.org/), a project I'm involved in, is just one example -- a large, complex project, it relies on dozens of mathematical and other libraries, and to transition to Python 3, all the libraries would have to be available in Python 3 versions -- even one exception would prevent the transition.
It's safe to say that everyone involved would like to see a transition to Python 3. But it's not possible, and for the foreseeable future it's not even likely.
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.
I don't think that's true anymore, and for some subset of people, hasn't been true for a while now. If you consider performance the big blocker, that's getting better all the time[1],and is close to being competitive with Perl 5 ins some areas.
[1]: http://jnthn.net/papers/2014-yapceu-performance.pdf -- Start at slide 76 for performance graphs
I read it, I'm just asserting it! Any issue with that?
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.