HN Theater @HNTheaterMonth

A bit tangential, but

- an ex-Scala core contributor's lament about why compilers have to be incremental: https://www.youtube.com/watch?v=TS1lpKBMkgg&t=42m

- a Rust core team member talking about responsive compilers: https://www.youtube.com/watch?v=N6b44kMS6OM (basically the "low-level" implementation of the talk at the previous link)

Scala's new compiler (dotty) also tries to go that way (first of all using streaming AST-s for better cache locality).

The problem is, that usually this "keep state and just percolate changes" is easier said than done. But we're getting there.

See also:

https://www.youtube.com/watch?v=TS1lpKBMkgg#t=23m38s (scalac performance) https://www.youtube.com/watch?v=TS1lpKBMkgg#t=37m53s (what do we really need from "computing science" to do programming)

https://d-d.me/talks/scalaworld2015/#/49

Really good points.

I expect you're right about the expressiveness, although I don't really know exactly what you mean by this. The "buffet of abstractions" available in Scala actually put me off it. For me, there are too many options available to expect to have readable, maintainable code at the end of it all, especially if you work in a team which regularly creates almost wilfully hard-to-comprehend java.

This video is 2 years old now, but I think it marked the point when I stopped investigating scala. https://www.youtube.com/watch?v=TS1lpKBMkgg&feature=youtube_...

⬐ joostdevries

Before I clicked the link I knew which video it would be. For some reason it's largely the single fact that people on nyc seem remember about Scala.

If you watch the presentation by Odersky you'll find that the new compiler addresses most if not all the things that Paul Philips mentioned.

For instance the new compiler has 5 phases. Just like javac.

⬐ justthistime_

While I agree with many points in the video, it feels kind of disheartening to me how many people just wave it around as if it could be used as an attack against the language and its community.

(A general observation, what you say here is totally fair.)

Of course the video is about Scala, but the problems mentioned are widespread throughout the industry.

What most of those people miss is the fact that Scala is sometime light years ahead of figuring out hard problems. The things considered to be an issue in Scala is often stuff that hasn't even been considered elsewhere.

The video is now 2 years old, and in terms of Scala, that's a lot of time. The strength of the language and the community is that it can adapt pretty fast, and many issues have been/are being addressed.

There are plenty of libraries out there which experiment with different approaches to collections, there is a new, faster and cleaner backend, the new compiler is shaping up nicely, the new IR will solve a lot of binary compatibility/cross compilation/Scala<->Scala.js issues, and scala.meta seems to become one of the best metaprogramming abstractions in languages.

Things are working really well in Scala, so if you have any question or concerns, feel free to voice them, and I'll give you my 2 cents about what's happening in that space! :-)

If you enjoy these types of compiler videos then I would highly recommend the following rants against Scala by Paul Phillips (from TypeSafe and one of the core language contributors). He also talks about wanting to edit abstract syntax trees directly: https://www.youtube.com/watch?v=TS1lpKBMkgg https://www.youtube.com/watch?v=uiJycy6dFSQ

5 years ago, Paul Phillips was still a core contributor to Scala. Anyone seriously considering Scala should listen to his talk, titled “We’re doing it all wrong”, and take a look at Policy, his fork of the Scala compiler.

https://www.youtube.com/watch?v=TS1lpKBMkgg

https://github.com/paulp/policy

Previous discussion:

https://news.ycombinator.com/item?id=8276565

⬐ justthistime_

Yawn

Oh damn, I didn't know they were the same person. All I knew about him beforehand is from watching this video[1], but it's weird to read about a person and then find out that they also were the same person that you knew from somewhere else.

[1] (How Scala [Typesafe] is doing "everything wrong")

https://www.youtube.com/watch?v=TS1lpKBMkgg

a) Martin Odersky has admitted as much[1].

b) The compiler internals are reportedly a mess[2]--likely due at least in part to the extreme number of different syntax variants.

c) I find rule 4.1 in OP interesting ("SHOULD avoid concurrency like the plague it is"). According to Odersky's Coursera course[3], one of the main advantages of functional programming as enabled by Scala is easy, safer concurrency (reduced/absent mutable shared state). Yet here we see a presumably seasoned Scala veteran basically saying that this is a failure and we should avoid concurrency whenever possible because it results in too many bugs.

1. http://www.infoworld.com/article/2609013/java/scala-founder-...

2. https://www.youtube.com/watch?v=TS1lpKBMkgg

3. https://www.coursera.org/course/progfun

⬐ bad_user

I really can't reply to that, sorry.

⬐ frowaway001

It's always funny to see how these things get interpreted. :-)

a) There is a lot of work going on at the foundations of the language – most of the stuff is unlikely to be felt by users.

b) Compilers are hard, there is very likely no "nice" compiler out there (except for toy languages). This has almost nothing to do with syntax variants. Nevertheless, there are multiple groups which are working on improving the codebase.

c) Concurrency is hard to get right, especially "traditional" approaches like synchronizing, locks, etc. If it's not necessary, don't use it. Otherwise use the right abstractions for your problem, as mentioned in the next paragraphs.

Paul, why do you say it's wrong that Float(Long.max - Int.max) is equal to Float(Long.max)? Float has less than 32 significant binary digits, and Long.max - Int.max has the same MSBs as Long.max. You would need to use Double to see the difference. I'm not sure what implicit conversions/promotions have to do with that - you want a warning or error when going from Long to Float? That would be reasonable. You can even lose significant digits between Int->Float and Long->Double even though they have the same total number of bits, so you could require those to be explicit. (from a slide in https://www.youtube.com/watch?v=TS1lpKBMkgg )

⬐ extempore

> Paul, why do you say it's wrong that Float(Long.max - Int.max) is equal to Float(Long.max)?

I don't. You have inserted coercions.

I'm aware of how many bits things have. It's hard to make it through five years on a compiler without gaining some awareness of such details. I consider the introduction of lossy type conversions into the global scope to be a kind of insanity. People should be recoiling from such practices, not looking for ways to justify them.

Paul Phillips' 2013 rant/talk: https://www.youtube.com/watch?v=TS1lpKBMkgg

⬐ jbza

That guy is a maniac. Much of the stuff that he was ranting off about are textbook examples of why functional programming and imperative programming ought to be separated from each other

⬐ rch

The slide "What I'm after" may be found around the 38 minute mark.

⬐ None

None

⬐ jfim

It turns into a rant about how he'd wish the compiler and the editor and the source control should be all talking with one another.

It's funny, because there's actually a language just like that: Smalltalk. The development environment is the same as the runtime environment, it has its own source control (Monticello), its own editor and a very regular language.

⬐ pjmlp

Smalltalk lost the spot in the industry thanks to Java, sadly I doubt it will hardly get a second chance.

Back in the mid-90's, before Java was released to the world, I was using VisualWorks for an university project.

IBM was a big enterprise player with Visual Age for Smalltalk.

A small startup (Animorphic) was making Smalltalk faster (StrongTalk).

There were, of course, other companies searching their piece of the pie.

When Sun started pushing Java to the world, many in the Smalltalk world shifted direction.

Visual Age for Smalltalk architecture became the foundation of Eclipse.

Sun eventually bought Animorphic and Hotspot was born out of StrongTalk VM ashes.

Slowly, other Smalltalk players joined the party.

⬐ zak_mc_kracken

Smalltalk is dynamically typed so it's a non starter for most of the Scala and Haskell folks. Same for Lisp.

⬐ pjmlp

Well, there was StrongTalk as well.

⬐ jibal

"It's funny, because there's actually a language just like that: Smalltalk."

I don't see how that's "funny" or relevant, as there are many other things about Scala that Smalltalk isn't just like.

⬐ teacup50

I can assure you of two things:

1) Paul is not ignorant of the existence of Smalltalk

2) Smalltalk is not a replacement for the fruits of modern language research. In fact, the academic work around Smalltalk is nothing more than unsupported opinion, and it's not even remotely useful as a source of research.

⬐ seanmcdirmid

Parent was out of line but there is still plenty of modern academic research occurring around Smalltalk. Not to mention Gilad's Newspeak (which may or may not be academic, you'd have to ask him).

⬐ teacup50

Can you think of a single example that:

1) Posits new conjectures 2) Proves those conjectures 3) Those conjectures can be used to formulate new conjectures that conform to items 1-3?

I've read a great deal of smalltalk literature, and I can't recall any papers that would qualify. There's plenty of empirical exploration of ambiguous hypothesis, but nothing that actually provides anyone in the field anything on which they could actually build.

⬐ a8da6b0c91d

It's hard to decide if his deep emotional investment is inspiring or frightening.

⬐ ionforce

Why can't it be both??

⬐ extempore

I also vote for both.

⬐ jroper

If in doubt, order everything on the menu.

⬐ jpgvm

After watching this talk I don't care what he comes up with in the future, I want to use it.

Excellent talk.

⬐ mdaniel

Are you familiar with JetBrains MPS?

http://www.jetbrains.com/mps/

It sounds very much like what he is describing.

⬐ jpgvm

I don't think an IDE is the answer to the problem.

I think making Scala more correct and more modular is the answer. Hygienic macros and syntactic extensions are more what I had in mind. Rust seems to be a solid contender here but it's much more of a systems language.

⬐ extempore

Yes, MPS and "language workbenches" in general are chasing something similar. Ideas like these are entirely in the details though, and so far I haven't found anything which does it for me. I could easily be missing it, in part because systems like MPS have a high up-front investment, and I have regretted such investments more often than not.

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 http://www.slideshare.net/extempore/keynote-pnw-scala-2013

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

Other critiques of Scala collections have been made with the Typelevel library 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.

Very True. I'm pretty sure that quote wasn't meant to be a critique of the Groovy language, just an expression of interest in Scala. Yet its brought out every time somebody wants to dismiss Groovy.

Compare that quote to this[1] presentation where Paul Phillips lays in to scala for 50 minutes. Even when somebody does criticize their own creation I doubt they mean "Hey everybody, that thing I spent a bunch of time on? Throw it all in the garbage, its pointless".

[1]https://www.youtube.com/watch?v=TS1lpKBMkgg

What is Scala doing in the same list with Rust, Julia, Nimrod, and C++? You do realize there is a JVM preventing it from being a systems level language, right?

Also, you should need no more reason to avoid Scala than this: https://www.youtube.com/watch?v=TS1lpKBMkgg

If you're interested in Scala, learn Haskell. It's faster, its design is re-enforced with proven mathematical concepts, and it doesn't have the worst syntax ever.

⬐ dom96

Perhaps his intention is not to just compare system level languages.

⬐ stormbrew

Holy crap the music in that video's intro makes me feel like I'm about to watch the Hunger Games. And then it's just a guy talking.

⬐ bsaul

This video you've linked shows many general and philosophical statements but really not that many concrete examples... I stopped before the end because i got a bit fed up with general sentences like "complexity is the ennemy". From what i've read about the astonishing number of scala features, i am more than ready to believe him, but i would really need more examples...

⬐ joehillen

He does go into detail. Keep watching.

⬐ saryant

He also goes on to say that no language meets his expectations today and despite that speech, he's still active in the Scala community.

https://github.com/paulp?tab=activity

⬐ nomad42184

Except that Paul Phillips has stated many times that he still programs routinely in Scala and, despite its flaws, considers it to currently be the best option. His arguments about what's wrong with Scala are compelling, but his continued use of it and desire to create his own collections library also speaks volumes.

⬐ pjmlp

> You do realize there is a JVM preventing it from being a systems level language, right?

You do realize there are quite a few commercial JVMs that generate native code AOT like any of the referenced languages, right?

⬐ joehillen

That's too terrifying to imagine.

⬐ pjmlp

I fail to see why.

⬐ sixbrx

I presume they still have a largish runtime attached with complicates FFI especially if callbacks are involved. I've found Java FFI to generally be a pain.

Also, I think a lot of organizations would never approve using these in production, too likely that behavior will differ vs Oracle's or the OpenJDK VM's, the company won't be around in a few years, etc., and the gcj is very out of date from what I gather.

⬐ pjmlp

I did not mention gcj, it is a dead project since 2009.

I don't know, but I guess enterprises do trust Aicas, Aonix, IBM, Excelsior and quite a few others.

⬐ andrewflnr

It's a language that "attempts a speed-elegance unification", as the author specified before that list. It's not as if Julia is a systems language at all, but it also definitely belongs there.

⬐ barchar

Nimrod's syntax is quite similar to scala (and Pascal!). Haskell can be really fast but fast Haskell and easy/safe Haskell tend not to overlap as much as one would like

⬐ codygman

"fast Haskell and easy/safe Haskell tend not to overlap"

I'm sorry, but the only people I've heard say this are those who are slightly open-minded about Haskell but truly believe it usually can't be remotely as efficient as imperative alternatives. None of the people I've heard make these statements have had even a few months experience writing Haskell.

If you can qualify this, I'd be pretty interested. Or if you've had an experience with Haskell that led you to believe this, I'd like to see if there is another solution.

I'm very interested in these limitations people always talk about with Haskell, but none of them have held up so far. I've been evaluating Haskell for a while and am very interested in testing any limitations you've faced.

⬐ joehillen

> Nimrod's syntax is quite similar to scala

What are you talking about!? Have you even looked at either?

Nimrod:

    for i in 1..100:
        if i mod 15 == 0:
            echo("FizzBuzz")
        elif i mod 3 == 0:
            echo("Fizz")
        elif i mod 5 == 0:
            echo("Buzz")
        else:
            echo(i)

Scala:

    for (x <- 1 to 100) println(
        (x % 3, x % 5) match {
            case (0, 0) => "FizzBuzz"
            case (0, _) => "Fizz"
            case (_, 0) => "Buzz"
            case _      => x
        })

In nimrod you'll notice a lot less parens, curly braces, and '=>'.

> fast Haskell and easy/safe Haskell tend not to overlap as much as one would like

Not even remotely true. Where did you even get that idea?

⬐ dom96

It really depends on what part of Nimrod and Scala you look at. The similarities are perhaps more apparent when looking at the function declaration syntax, generics and/or the variable declaration syntax.

⬐ nomad42184

Also, Julia has no business as a systems language either. I think it's a more general language comparison.

⬐ frowaway001

If your plan was to make Haskell users look like douches, you are doing a pretty good job around here.

⬐ kasey_junk

There are lots of reasons to choose Haskell over Scala, but a blanket statement that it is "faster" is idiotic.

⬐ joehillen

But it is faster. It's both faster to compiler and faster to run. I think it's a valid reason to prefer Haskell.

⬐ nomad42184

Except that it isn't faster at runtime (http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...).

⬐ profdemarco

Almost all the Haskell entries in the shootout are just using the FFI to call into C libraries. None of them are remotely close to idiomatic Haskell.

⬐ nomad42184

Everyone knows, of course, that these benchmarks don't tell the whole story. However, it's ludicrous to assert that providing no evidence is better than providing a array of microbenchmarks across a variety of different languages, machines and implementations. Further, the assertion that Haskell is "faster" (in some blanket sense) than Scala is completely evidence-free.

⬐ nomad42184

@profdemarco --- sure; and they're still not faster than their Scala counterparts.

⬐ Pacabel

If you want to prove your point, using totally unrealistic micro-"benchmarks" such as those is by far the worst way about doing so. You're better off giving no evidence whatsoever than you are referring to those.

⬐ igouy

"[B]etter off giving no evidence" than pointing to measurements that provide a known context -- source code, implementation version, command lines, measurement scripts...

Nonsense.

⬐ yen223

Are there any more realistic benchmarks that we can refer to? Because I've read a lot about how Haskell supposedly runs faster because of its purity, but I've not seen a lot of evidence actually supporting that notion.

This is a thing about Scala which gives me pause: it looks like gazing into the guts of the compiler puts one on a course towards a nervous breakdown.

http://www.youtube.com/watch?v=TS1lpKBMkgg

⬐ noelwelsh

I asked someone in the know, and apparently Paul Phillips is always like that. He has an interesting background -- was a pro poker player for a while.

⬐ wyuenho

Also happened to be the guy who wrote the most Scala code on the planet, and he quit Typesafe last year.

⬐ singingcheese

> Also happened to be the guy who wrote the most Scala code on the planet

I love the way he assumes that. I think he may be surprised to learn the sheer scale of some production Scala systems which aren't part of the Scala class library or compiler.

Besides, he put together a list of obscure corner cases that no practicing Scala developer actually seems to care about.

⬐ kasey_junk

I think the Paul Philips stuff is both overblown by people outside of the Scala community and dismissed too freely by those inside of it. Paul has a very pessimistic world view, a very high standard of perfection and he's spent tons of time in the guts of an extremely complicated system. Listening to some of his talks it is easy to make the assumption that he thinks Scala should be nuked from orbit.

On the other hand, while the ParSeqViewLike example is a bit of an inside joke (I think). It doesn't take a whole lot of doing to push the Scala collections library into weird and terrifying behaviour. I'm a practising Scala developer and I do it at least monthly. For people with experience with other better designed collections systems the Scala collections library feels heinous to use, and if you ever have to dig into the code, good luck.

If the Java stream api is implemented well and has a high take up rate, I expect lots of people to come to Paul's point of view with regards to the terribleness of the standard Scala library.

⬐ singingcheese

> It doesn't take a whole lot of doing to push the Scala collections library into weird and terrifying behaviour

I'm genuinely curious to see examples you've seen in production code. I've used the collections for years coding full-time and haven't encountered anything like that.

⬐ wyuenho

I encountered them on a daily basis when I was doing Scala, and you see these Scala collections WTFs pretty much on every other line when you are prototyping in the REPL. I've come to the conclusion that the only way the Scala collections library will give me confidence is when my head can reason more than 100 types at the same time while having distinct types for every value in the universe.

Scala's problems are real and structural. There's very little you can do about it now that all these innocent newcomers buying into the lies of the vested interests.

Speaking of lies, besides those Paul Phillips points out, you hear these nonsense about how great Scala's explicit type declarations are, that they make your function's signature clearer and etc. These are all lies, the truth is the type inference algorithm can't unify a type because of all these type variance, type bounds and type views. All these funny emoticon symbols are actually hints to tell the type inferencer to go up or down or sideways when looking for the most generic type that satisfies a type signature.

Another lie is that Odersky will keep showing you kiddy pictures and extolling how small Scala's grammar is while sweeping under the rug that Scala's many features are orthogonal, or halfway in-betweens GCDs or have surfaces of interaction with other features that are too large.

To list a few, these are my favorites:

1. implicits. Explicitness in function decl is good but when you call them it's better to hide all these unknown implicit params/type conversion from you so you can't reason your code.

2. _. There are 12 different ways you can use them. They are not shortcuts, they are conflation of concepts.

3. The interplay between classes, case classes and traits. It's very hard for me to put this one in word, there are just so many corner cases.

4. Java/Scala interop. There's no interop. There's only 1 way op from Scala to Java.

5. case classes are just ADTs. Nope, not letting me have a param-less case class or subclass a case class doesn't make them ADTs.

6. Companion objects are sold as singleton replacements. They are only singleton replacement as a side effect of having no other suitable place to put your implicit kludges.

7. Type safety. You can't guarantee type safety if you allow mutability. Period.

8. Java compat is simultaneously sold as an advantage and blamed when problems arise. Why can't Scala just use the damn bytecodes and avoid the entire Java standard lib?

⬐ frowaway001

It would actually be more convincing if it wouldn't sound exactly like the last dozen "I never used Scala, let's just point out some things I read on the internet about it" people.

Why not just try Scala for a while, instead of making things up?

⬐ wyuenho

> I encountered them on a daily basis when I was doing Scala.

Your assumption that my criticism over Scala is because I hadn't tried it is as valid as my assumption of your disagreement with me is because you haven't tried hard enough.

I had tried Scala on multiple occasions since 2.8 came out. Every time for about 1 month to 5 months. It's impossible to explain how messed up Scala is without writing a whole book about it so I admit it's hard for me to convince you. God I miss SML and Haskell.

Maybe this guy can:

http://yz.mit.edu/wp/true-scala-complexity/

⬐ frowaway001

So how would you solve his "issue"? (Assuming that you have understood his problem at all.)

⬐ wyuenho

I wouldn't bother. I'd just go ahead and use 2 distinct APIs directly, and then after a while, I'll realize my code look more and more Javaish, and then I'll switch back to Java.

⬐ frowaway001

Ah, ok. So you haven't understood the problem, but wanted to say something. Great.

⬐ wyuenho

I mean I wouldn't bother to shoehorn a Scala wrapper on Java's array.

⬐ frowaway001

Yes, but that's not the point of the article, right?

⬐ kasey_junk

An example I use a lot because it is terse:

From MapLike.scala def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value }

From HashMap.scala def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }

That is to say that the default behaviour of a Scala hash map is to create a new object for every access (notice I say access, not for every insert) even when I ask it to pretty please give me the one that doesn't have the null safe Option code involved.

⬐ frowaway001

apply?

⬐ singingcheese

apply is the function called when you use brackets and nothing else e.g. val x = myMap("myKey")

⬐ thescrewdriver

Doing an extra object allocation (which will likely be elided by escape analysis in the JVM) is hardly "weird and terrifying behaviour". It is an implementation detail which has absolutely no bearing on the behaviour or functionality of the map.

⬐ kasey_junk

In my use cases escape analysis does not elide these accesses out (and I was unable to reason about why not). Further, I had an immutable map that had ~hundreds of items in it that was generating hundreds of millions of objects. I found that weird and terrifying especially given that I was specifically asking it not to give me Options back.

I frequently hear that memory/performance are "implementation" details and don't have bearing on functionality. For my use cases that isn't true.

Even if it was, the surprising upside down nature of that API (de reference the option, instead of wrap the reference) is of itself weird.

This is just the most terse example of oddities in the library I've encountered. Other's include streams being created (and not GC'd) when they weren't necessary, collections losing performance characteristics due to the monadic calls (IndexedSeq's passed into functions as Seq's use LinkedLists for builders instead of Vectors), etc.

Finally, I fundamentally disagree with the idea that eager evaluation should be the default in the collection library. Views mitigated this somewhat, but after working with more sane libraries, have to remember that every time is tedious (though I'll grant that is a debatable point).

If your software is not performance critical, or you aren't implementing your own collections libraries, maybe you don't encounter these problems. But for the standard library, it is a problem.

⬐ thescrewdriver

So to summarize the collections library has "weird and terrifying behaviour" because there are cases where the performance is not quite as good you expected?

You might be interested in the AnyRefMap work being done here: https://groups.google.com/forum/#!topic/scala-internals/R4fT... Perhaps you could add your voice to the discussion if you have concerns around performance.

⬐ kasey_junk

Another way to summarize might be to say, "If you discount the many examples of incorrect behaviour that paulp mentions, and you don't care about performance, and you are comfortable enough looking through the extremely deep collections hierarchy code to diagnose the reasons for these problems, then the standard scala collections library is almost as good as collection libraries available in other languages".

The AnyRefMap may be a good solution to many of my issues with the default map implementation once it is widely available. It won't help with the more general lack of cohesion in the library though.

⬐ virtualwhys

Well, so what? Simon Marlow, Haskell's lead compiler developer in recent years, quit, leaving arguably a much larger gap than @paulp leaving Tyepsafe since SPJ is wrapped up in leading some English education initiative.

Anyway, shit happens, gaps are filled. Languages, once established, are larger than any one developer, no matter how brilliant the individual may be.

It's worth noting that @paulp is as active as ever in Scala, working on his new collections library and contributing to Scala now from the outside -- he may have left Typesafe but has not in anyway left Scala. As he says, he has a "sickness" for language perfection, and fortunately for we Scala users, Scala is the target of his illness ;-)

⬐ nousernamesleft

>Simon Marlow, Haskell's lead compiler developer in recent years, quit, leaving arguably a much larger gap than @paulp leaving Tyepsafe

Quit what? He is still a ghc developer. He quit his job at Microsoft Research to go work at Facebook, but that doesn't seem quite comparable to quitting a job working at the official scala company on the official scala compiler.

⬐ virtualwhys

Marlow is _full-time_ at Facebook, bye bye. There's a difference between being a ghc developer and THE ghc developer. He's more of an advisor now than a committer, look at his ghc commit history, lots of comments, few commits.

Not saying he's joined the dark side like Erik Meijer, but he's also not actively _working_ on the compiler as he did before; that's for the new guy(s).

⬐ nousernamesleft

>Marlow is _full-time_ at Facebook

And? Before that he was full time at Microsoft. He was never an employee of any sort of official ghc company working on ghc full time.

>Not saying he's joined the dark side like Erik Meijer

What dark side and what is wrong with Erik?

⬐ grey-area

Thanks for the link; if you can ignore the somewhat hysterical delivery, that talk is really fascinating. It's more about what a programming language should be (in his opinion) than what Scala is not. He quotes my favourite aphorism from Wittgenstein as well:

The limits of my language define the limits of my world

⬐ None

None

⬐ wyuenho

Here are the slides if anyone is interested. I love the ParSeqViewLike trait on the 3rd slide. There are tons and tons of these Scala WTFs throughout the talk. It's really interesting.

http://www.slideshare.net/extempore/a-scala-corrections-libr...

⬐ Patient0

Wow that talk is an eye-opener. Thanks for the link.

⬐ psuter

Please don't miss the larger point of this talk (and others by the same speaker); programming languages in general are not what they should be according to this speaker. If anything, though, he seems to agree that Scala is a good choice compared to the plausible alternatives:

    "At the very least, I can endorse Scala relative to the set of existing
     alternatives pretty strongly."

    "I judge things compared to what could be, and not what is. [...] It's not
     good enough to be the strongest of the little kids brawling when you could
     be the big kid next door."

⬐ coolsunglasses

Actually Haskell is quite nice and does a better job. Practical too.

⬐ yan

I'm curious, what languages do you consider impractical?

⬐ coolsunglasses

Assuming practical is some kind of bar for "I'd use this at a company where I'd be deploying the project into some kind of online production" - there are a number of experimental/research languages that are better for offline research/analysis and don't have the ecosystem Haskell has.

I'm not going to mention them by name because if you don't know of them, then it doesn't matter and I don't want to slur them.

⬐ polymatter

I am a great fan of Haskell.

But the tooling and libraries of the JVM is a significant real-world practical benefit. Scala can get away with a lot of nasties for that. (In fairness Scala is very well designed, nastiness is normally all to do with Java compatibility)

Plus it allows Java programmers to start writing code almost immediately.

⬐ nousernamesleft

And yet the whole first part of his talk was problems with scala that are not problems in haskell. And many of those problems exist precisely because of java compatibility, which he acknowledges and says is not a good enough reason to do things poorly. By his own measure it seems like he should be using haskell.

>Edward Kmett is a Haskell evangelist

Really? Could you point me to some of his evangelizing? Or did you mean "he uses haskell and is quite happy with it"? Because that isn't the same thing.

>inconsistencies that the average programmer will never even realize exist.

Do you honestly believe that? http://www.youtube.com/watch?v=TS1lpKBMkgg

>Scala that only when you leave it's confines do you realize, shit, I miss

But the very point Edward makes is that you don't give up those things when you leave scala. You only give up those things if you leave scala for something worse. You could leave for something better, keep all those things, and get tons of important things that you also won't realize you are missing until you get used to them and then try to live without them.

⬐ virtualwhys

There's nothing wrong with language evangelism, if you love the language you work in you'll evangelize it without even thinking about it.

Kmett has, I believe, taken on a larger role in Haskell, perhaps officially with FP Complete. At any rate he does mention in one his videos (maybe on www.haskellcast.com) that he is coding less now due to his new obligations, which includes [completely from fallible memory] promoting [read: evangelizing] the language.

>inconsistencies that the average programmer will never even realize exist.

Referring to a presentation by Paul Phillips, an absolute Scala giant, and equating that with what the average Scala programmer encounters in their daily work does not negate my argument...in the slightest.

When you leave Scala and remain on the JVM there is no better statically typed alternative, IMHO. When you leave the JVM, then yes, you can dive into Haskell and experience (compared to Scala) longer compile times, yelp o_O, poor to non-existent (IDE) tooling (just type :t in the REPL to see the inferred type, AKA beginner's joy), lack of an enterprise ecosystem, and yes, purity in all its glory, with a superior type system and quite a friendly community of mostly brilliant minds.

In the end I'd say there's some degree of PITA everywhere, even in Haskell. Just getting my feet wet, maybe I'll learn to love it, but for now, to get shit done in the real world, it's Scala and the JVM.

⬐ asdasf

>There's nothing wrong with language evangelism

He says, after suggesting you can't trust what someone says because they are an evangelist.

>Kmett has, I believe, taken on a larger role in Haskell, perhaps officially with FP Complete

FP complete is an independent company and has no official involvement in GHC or any other haskell implementation. Edward is not involved with FP complete. Edward is involved in the haskell community and the scala community. In neither case is he anything like an evangelist (which would make no sense anyways, you can't convert the converted). It seems odd that you are so adamant about inventing a fictional promotional context for him after claiming there's nothing wrong with that.

>Referring to a presentation by Paul Phillips, an absolute Scala giant, and equating that with what the average Scala programmer encounters in their daily work does not negate my argument...in the slightest.

Perhaps you should actually take the time to listen to it. A significant part of what he was saying was "this stuff matters". Just because the person doing the presentation knows scala very well, does not mean the problems he points out do not effect people who know scala less well.

>When you leave Scala and remain on the JVM there is no better statically typed alternative, IMHO

I am not sure how that is relevant. I don't care about the JVM.

>Just getting my feet wet, maybe I'll learn to love it, but for now, to get shit done in the real world, it's Scala and the JVM.

Or this. Do you remember the part where I tried to convince you to use haskell? Neither do I.

⬐ virtualwhys

> He says, after suggesting you can't trust what someone says because they are an evangelist.

What the hell are you talking about? I provided a counterpoint to Kmett's detailing all that is wrong with Scala, by providing some of the good. Kmett is a living legend, I'm not questioning the guy's integrity; he went off in that reddit thread based on his [deep] experience of the language, which is entirely non-average.

re: Paul Phillips, he's knows Scala probably better than anyone else on the planet; yes, the soundness of the compiler affects everyone, but those who are most bitten and bothered by it are library authors (read: advanced users), not end users who remain, for the most part, unaware of whatever issues may lie under the hood.

> Or this. Do you remember the part where I tried to convince you to use haskell? Neither do I.

Other than Haskell, given the context of the thread, which language might you be referring to as the better alternative to Scala?

> You could leave for something better, keep all those things, and get tons of important things that you also won't realize you are missing until you get used to them and then try to live without them.

That sounds great! I am curious about leaving Scala for something better -- please name this better alternative that is presumably not Haskell.

⬐ asdasf

>What the hell are you talking about?

Exactly what I said. You can go read your post if you have forgotten its contents.

>not end users who remain, for the most part, unaware of whatever issues may lie under the hood.

You are simply repeating yourself. Paul Phillips contradicts you, and I find him to be much more credible.

>Other than Haskell, given the context of the thread, which language might you be referring to as the better alternative to Scala?

Ocaml, F#, SML and clean.

>please name this better alternative that is presumably not Haskell.

Why would it not be haskell? Haskell is pretty obviously the best option.

⬐ raiph

Hi virtualwhys

> I am curious about leaving Scala for something better -- please name this better alternative that is presumably not Haskell.

With apologies if you think this is too OT and/or if you are uninterested in immature languages/ecosystems, let me mention Rakudo and its increasingly capable JVM backend.

Today's Rakudo Star release (Star means "batteries included") is expected to be the last to ship without Rakudo's JVM backend. Almost certainly there'll be a February Rakudo Star release and it is expected to support the JVM backend out of the box.

I would be happy to say more about why I think P6 is going to become relevant again one day, perhaps this year, to folk at least interested in Scala.

My sample size is small, but the sentiment mainly comes from this: "Pacific Northwest Scala 2013 We're Doing It All Wrong by Paul Phillips - YouTube" [1]

[1] https://www.youtube.com/watch?v=TS1lpKBMkgg

⬐ frowaway001

While I usually agree with most things Paul Phillips says, that talk was mostly an exception.

There is nothing which can't be fixed by focused work on all the bits and pieces which need work, and that's exactly what the scalac compiler developers are doing most of the time.

So many improvements are coming in every week that I can hardly stand using an older compiler version, because I always know that so much stuff has already substantially improved.

Despite what some people say, life in Scala-land is pretty damn good.

Right, and how well do subtyping and implicits get along?

This is the problem, everything and the kitchen sink is tossed into Scala without any consideration for how well things work together because they've let it be a PLT grad students playground.

http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...

http://www.youtube.com/watch?v=TS1lpKBMkgg

The Scala community didn't lose one its best core developers for nothing.

I mention Clojure and Haskell in the same breath because FP and immutability are what I care about and Scala fails to be a nice functional language.

⬐ frowaway001

> This is the problem, everything and the kitchen sink is tossed into Scala without any consideration for how well things work together because they've let it be a PLT grad students playground.

I'd love to see a concrete example for that!

⬐ seanmcdirmid

No idea who your demigod is, but Martin is probably the best programmer I've worked with. How subtyping is combined with type inference in Scala is quite workable, not perfect, but not a train wreck either.

Scala isn't really the best functional language, but it might be the best OO language out there, especially with traits, no other statically typed language has done mixins as well.

⬐ coolsunglasses

Then please stop selling Scala as being about type-safety or FP, because it makes them look bad.

Edit:

Also the demigod is paulp who worked on the Scala compiler team for five years. Hard to miss if you watch Scala dev at all.

⬐ frowaway001

Sean did a PhD at the EPFL while working on Scala. I think he is allowed to have an opinion on that.

⬐ seanmcdirmid

I did a post doc, worked on the IDE for a couple of years, and haven't been following Scala that closely for 5 years or so.

⬐ frowaway001

Thanks for the correction!

5 years is a long time in terms of Scala, maybe the Scala community has the chance to welcome you back some time in the future and show you how much stuff has been improved since back then? :-)

⬐ asdf1234

That demigod also has a very long list of complaints about Haskell and Clojure. He doesn't think either of them are worth using either.

⬐ seanmcdirmid

Many PL enthusiasts aren't satisfied with any language (me included); there is plenty of critique to go around.

And why should we be satisfied?

Before you think about using scala watch this:

http://www.youtube.com/watch?v=TS1lpKBMkgg

⬐ asdf1234

Paul could do a similar talk for basically every mainstream language. Better not learn anything!

Correctness is the dog. Everything else is tail.

Don't know who said that first, might have been this guy http://www.youtube.com/watch?v=TS1lpKBMkgg

⬐ None

None