Hacker News new | comments | show | ask | jobs | submit | modersky's comments login

Different languages have different design tradeoffs. I had many profitable exchanges with Andrey Breslav and other Kotlin designers. We can have a technical discussion about the design choices without getting into a fight about who is more competent.

-----


Have to step in here :-). In fact I bet that Scala has fewer features than Kotlin. In retrospect I now think Scala could have had fewer features, and hope we can get to a state where we can remove some of the redundant ones. But that's because (1) hindsight is always easy and (2) I am at heart a minimalist. Almost all programming languages have too many features to my taste.

-----


Yes, Tree[Top] would have been another way to model this. I wanted Tree[Nothing] to make clear that getting the type of an untyped Tree gives a Nothing, i.e. a run-time error. Getting a Top is not quite the same, but it is almost as good, since only a view things can be done with type Any in Scala.

EDIT: There's one thing I did not stress in the talk and that makes Nothing a more attractive choice than Top: We want to do copy on write on these trees. I.e. if we transform an untyped tree to a typed one using "withType", we want to be able to reuse the untyped tree and just set the type (unless somebody else had already added another type). If the tree is of type Tree[Nothing], we can do that safely, even if there are still shared references to the same node as an untyped Tree. Getting the type of the shared untyped tree will give a Nothing, and nothing can be done with it. But if the type would be a Top, we would be able to apply some operations on it, so the copy on write would be unsafe.

-----


It's much older than that. See

https://en.wikipedia.org/wiki/Futures_and_promises

The distinction between futures and promises in the wikipedia article matches Scala's terminology exactly.

-----


Yes, Wikipedia's terminology exactly matches that of Scala, but that's because Wikipedia references a Scala SIP ;)

It's always bothered me that Baker and Hewitt felt the need to coin the term "future" when they were clearly aware of "promise" and "eventual". Their main distinction seems to be that a future is a 3-tuple (process, cell, queue). One can argue that their future meets the "read-only view" definition because cell is only to be written to by the same tuple's process. But they never explicitly distinguish a future as "a read-only placeholder view of a variable," and E was the first publicly-available language to make that very distinction (please correct me if I'm wrong), only they happened to use "promise" in that regard.

In any case, I trust your judgement on the matter more than my own, just wish everyone had picked a nomenclature and stuck with it.

-----


You realize that the sender of this post (a) has been banned from all Scala mailing lists (b) has become one of the strongest Scala haters since?

-----


Doesn't Paul Phillips still use Scala? He's actually forked the Scala compiler: https://github.com/paulp/policy

I think Paul Phillips agree with the overall direction of Scala and thinks it's the best programming language out there, but disagrees on design details and compiler inner workings.

-----


He's still someone one frequently encounters when looking for help or getting started with Scala. He's still pretty high-up in scalaz.

-----


People who actually use Scala love it. For instance, Scala is one of the most loved languages in the recent StackOverflow developer survey. The survey had more than 26'000 respondents, so this is pretty significant.

http://stackoverflow.com/research/developer-survey-2015#tech...

But you are completely right that there's also a lot of negative sentiment around it. Here are two possible reasons I can think of (I am sure there are others).

1. Scala does not form part of an established programming language tribe. It is neither a better Java nor a Haskell on the JVM. So people are challenged in their assumptions; they don't know what it is, and react negatively in order not to have to learn more.

2. Scala is pretty successful. So people in neighbouring language communities sometimes feel frustrated that a seemingly (to them) inferior language gets traction and their perfect language gets less. I saw some of that when Java eclipsed Smalltalk in the 90's. I never met a community as spiteful of Java as the Smalltalk one.

-----


We used Scala for major projects; love the language, hate the infrastructure / documentation / frameworks / sbt / attitudes of many in the community. I believe this is a pretty common sentiment.

-----


We use Scala for major projects too, I love the language and also the documentation, frameworks, (even sbt) and attitude of the MAJORITY of the community. Can you give concrete examples of what caused you to hate all of the above? Especially I'm interested in the community aspect. I've found the community very friendly and helpful, but perhaps I'm going to the wrong (i.e. right) places?

-----


Basically I've seen this in person. Scala was driving the last startup I was in to the ground.

The thing that fascinates me is scala is like an art. It's like a new Obfuscated Perl Contest, but for functional programming. It doesn't really serve a purpose in legitimate business.

Scala code doesn't scale, it compiles too slow due to having too many features in the syntax. They took features normally meant for a standard library / external projects and literally augmented them into the syntax.

Scala, in it's current form, is a pipe dream. It really needs to be start over, but drastically simplified. Perhaps it should try to take a hit from Golang for compiler time advice: Simple languages compile fast and are easier to optimize.

-----


I would think that "people" were driving the company to the ground. I'm working on a large-scale Scala project that has been going on for years. The codebase is clean, methods are easy to reason about. It not as verbose as Java would be, there's no monkey-patching like you might see in Ruby, refactoring is much safer than it would be in JavaScript, and it runs on Linux much better than C# would. And thanks to FP the code is thread-safe and mostly free of side-effects (except where they're explicitly required). I wouldn't trade Scala for any other language, for this kind of work.

-----


What kind of project is it? Genuinely curious.

-----


Web app with complex, distributed back-end processing.

-----


Is it an accident that you picked the worst offenders for each category? :)

Not as verbose as Java -> Java is probably the most verbose compiled OOP language

Refactoring is safer than it would be in JS -> I think with the IDEs this means almost nothing.

Runs faster on Linux than C# -> I mean seriously, Java's biggest advertised feature was multi-platform support while we know that Redmond guys don't care about other platforms too much.

I feel like you are trying to justify Scala by comparing it to other languages and picking a feature or property of those languages that is the worst or almost the worst.

How about this:

- Scala has such a nice type system that it blows out OCaml from the water - Scala running faster on Linux than C++

etc.

I would expect honesty when it comes to using languages that would drive this twisted and wicked developer world to something better. If we keep using the worst languages to compare to we are not going to improve. This is what I think.

-----


Scala isn't the best at any of these things though. It's great because it's an all-rounder language.

How about this:

Scala doesn't - quite - have the safety and conciseness of Haskell. But it's close.

Scala doesn't - quite - have the enterprise support and tooling infrastructure (monitoring/instrumentation, profiling, debugging, IDEs, library ecosystem) that Java does. But it's close.

Scala doesn't - quite - have the clarity of Python. But it's close.

Scala doesn't - quite - have the performance of C++. But it's close.

-----


Right. Let me take this from a different angle. I like to hear about projects moving away from technology much more than jumping onto a band wagon. Right now, Scala feels to me as a band wagon. Some of the guys who moved to use Scala from Java just simply moved back because they realized that almost all of the features are available (emphasis on almost) in Java (especially in Java 8). On the other hand, learning Scala takes time so for a while you are writing inefficient code. On the top of that you need to make sure everybody is on the same page in your team, that is also additional effort. All of these were driving projects (like Kafka) away from Scala (look at the new producer code).

To summarize: Scala to me is just a better Java with too many trade offs.

-----


To my mind the bandwagon has been and gone, with those companies moving away from Scala being those who arrived on the bandwagon and departed with it. But I guess it looks different from the inside.

If you're treating Scala as "just a better Java" then you're not writing inefficient code; you're writing code that could be better Scala code but is still better than the Java you would otherwise have written. Even if you never move beyond the "Java without semicolons" stage, hey, it saved you writing all those semicolons.

But Scala absolutely is a full language and not just a better Java; Java 8 barely scratches the surface of what you can do in Scala. I don't think I could bear to work in a language without higher-kinded types again.

Kafka has some very particular constraints that I don't think apply in general; remember they're making a framework rather than an application.

-----


That's interesting, because weren't Kotlin and Ceylon created because people wanted to have "just a better Java", which Scala is not really interested in being?

> they realized that almost all of the features are available

Interesting too. Looking at the stuff I'm currently doing, there is plenty of stuff which is just impossible in Java.

By the way, isn't "Scala has such a nice type system that it blows out OCaml from the water" already the case?

-----


> weren't Kotlin and Ceylon created because people wanted to have "just a better Java", which Scala is not really interested in being?

Scala was that at first. Arguably that's still Typesafe's primary interest.

> By the way, isn't "Scala has such a nice type system that it blows out OCaml from the water" already the case?

Yes and no. It's more featureful (higher-kinded types are really nice), but less elegant and type inference works less well (in part because scala has both inheritance and typeclasses).

-----


What scala does is sloppily bolt on everything without putting any checks or balances.

I don't doubt your sincerity.

Try to pull yourself out and understand it as an investor:

$500 a day to pay for a scala engineer. Not a word about the bottom line.

Python? Ruby? Are they algorithmically fast? No, but they ship and sell.

-----


Depends what you're making. http://www.joelonsoftware.com/articles/HighNotes.html can apply - what I'm working on right now with Spark I dread to think how you'd do reliably in any other language.

> $500 a day to pay for a scala engineer. Not a word about the bottom line.

Maybe - I don't make that much and I have 5 years' Scala experience. (I have a relaxed environment and great culture though, so I'm not complaining). What I really don't get is Java companies where developers are chomping at the bit to use Scala and management says no - your devs are volunteering to become devs that companies would pay 2x for, the least you can do is let them.

-----


What did it bolt on? Where are the checks missing?

The last major version and the next major version don't ship with any new feature at all, and removing some stuff, so it's a bit hard to see were you are coming from.

-----


http://www.scala-lang.org/download/changelog.html

Python has PEP's. C and C++ have a ISO standards body. JDK has JEP. Adding a new library feature, let alone overhauling core types, is something scala added as if it was no big deal.

In python, when "new classes" were introduced, it was a big honking deal! You can bet it was heard about everywhere, in the documentation, etc. cpython interpreters like python 2.6 have support going back 5 years, and the changes between 2.x python versions are small compared scala.

There's a reason why enterprise languages move like a toad. We can't have legacy systems breaking. We want our legacy libraries to keep working. In 2015, I write python 2.6 code that works in python 3.5-dev, because they carefully planned releases and I write idiomatically.

Ask yourself if uninitiated generalist prorgammers can really grasp those hieroglyphic walls of text. It's encoding too much information too densely, and inside the density, there's so many clever tricks that block could doing.

It entices solipsistic programming. Long evenings and hard work goes into programming blocks of logic that aren't portable or readable as a future consolidation. This is where scala user's get protective. Their mental thought is legitimate, the output however means nothing to fellow coders.

With java, you could say we satisfy the longterm code quality. Even though I'm cynical of the JVM, I realize that my time and effort would hold out on the long term and my team would have code that would be a legacy into the future.

With scala, their is a sense of urgency coupled with a legitimate sense of eureka! But it all ends up looking like schizophrenic scribbling on a napkin to others.

Scala must limit the grammar in your programming language.

-----


I'm not even sure which point you are trying to make.

Did you even read the link you posted? It supports what I said.

You keep writing walls of text which are either wrong or don't relate to the topic at hand. Many of the mistakes should be obvious to a person who has used Scala for more than 5 minutes, so I'm really wondering what's your issue here ...

Not liking Scala is perfectly fine. It's not necessary to make up claims (which don't hold up to 5 seconds of scrutiny).

Edit: Instead of editing you post trying to evoke a more emotional response from people, why not focus on correcting your false claims?

-----


It's amazing that you keep doing edits which are literally begging for an emotional response, but couldn't manage to take a few minutes to check your claims against the reality.

-----


It's a way of saying that I value a language that is not too verbose, that doesn't encourage monkey-patching, that has strong types, and that works on Linux without too much trouble. The languages I listed do not meet at least one of my requirements, that's why I prefer not to work with them.

-----


The problem with a survey asking people how much they love their language is that people will employ all kinds of biases to suppress the cognitive dissonance of choosing a terrible language.

The harder something was to succeed at, the harder you'll try to convince yourself it wasn't wasted effort.

-----


Erlang is a pretty big omission in that list

-----


We have data to contradict this argument: Over 400'000 people have enrolled in an online Scala course with a success rate twice the industry average. "Almost vertical learning curve?" Please!

-----


I think you got that wrong by a factor of 10. I get between 500 and 1000 lines / sec on my laptop. It depends on the code style. The more straightforward the code the faster the compile. Still with incremental compilation it means I wait rarely more than a couple of seconds.

-----


Thanks Martin, unfortunately it's past the point where I can edit my original comment or I'd go back and fix it. As I recall you said it off-mike in Bill Venners' talk, otherwise I would have fact-checked it!

Anyway, details aside I thought it was a great illustration of the impact on compiler performance that code complexity can have.

-----


The one line per minute was observed when trying to compile a query over an HList backed record with more than 300 columns. The problem was a polynomial increase of the size of the implicit search tree. This is due to the way implicits are used in shapeless HList library. Slick has a different approach which is much faster, but slightly less general.

The gist is that once you have [edit: recursive] typeclasses or implicits your search can become arbitrarily large and slow. There's nothing that can be done about it by the compiler except arbitrarily pruning the search tree. Or otherwise put, you should factor in implicit search complexity when designing your libraries.

-----


I think the Twitter school is pretty up-to-date. Scala-by-Example is older. There are also a large number of good books teaching Scala. I believe it's worth investing in one or two. And, there's my Coursera course, if you want a more rigorous introduction not just to Scala but to functional programming in general.

-----


The Coursera Functional Programming Principles in Scala[0] course is definitely worth the time. Coming from being a Java programmer in my day job, it's made my Scala I've written since a lot cleaner, in my opinion. It's also had the side effect of making Java a bit more unbearable. It's definitely not to be approached as a beginner to programming though.

[0] - https://www.coursera.org/course/progfun

-----


Wow, I didn't expect to receive a reply from you! Thanks, I'll check out the Coursera course. I did start reading "Functional Programming in Scala" by Paul Chiusano and Rúnar Bjarnason, but wanted something a bit more beginner-friendly. Then again I was recovering from a concussion at the time, so perhaps I should revisit it now. :)

-----


While Functional Programming in Scala is great, it focuses on areas of Scala that I think are better tackled once you're more familiar with the core language - pattern matching, traits, case classes, variance, for comprehensions...

I find that the best book if you want a deep understanding of the language is Odersky's Programming in Scala. Complete, thorough, well written. It does expect you to have some programming experience, and some bits are perhaps over-detailed, but as long as you allow yourself to skip the bits that bore you, you're in for a treat.

-----


I would definitely recommend Martin's Coursera course, it's incredibly well structured and very well delivered, with enough difficulty to be challenging but it guides you through very gently. Well worth it for learning both Scala and Functional Programming.

-----


In retrospect I found it to be more of a "functional programming which happens to be using scala" class and less an "intro to scala". That's not a bad thing (nor a good thing, it's just a thing) but it's not necessarily what is most useful for a person.

A few years ago I joined a group which had been using scala for a while (since '09ish IIRC) and I took the coursera class to get up to speed. It definitely helped but the reality was that their code base was closer to being java++ than to haskell and a lot of the early habits I picked up from the coursera class were immediately beaten out of me once I got rolling there.

One could argue that they were in the wrong, but I disagree - Scala is a multi-paradigm language and not everyone is going the FP route (I recently heard Venners refer to Scala as a "reform movement for OO, which is how I personally treat it, but that's neither here nor there).

All this said, I don't have a better suggestion. As I mentioned I took the Coursera class and read the Staircase book. The Twitter stuff online was useful but mainly I just read as much as I could online, tracked down conference videos, etc.

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: