Live data from Hacker News

Why we love Scala at Coursera

tech.coursera.org

101–110 of 184 posts

Re: Why we love Scala at Coursera

#101
post #87

Earlier quoted context omitted.

Type safety dramatically reduces the number of unit tests required. Since unit tests often depend on the structure of code, that reduces the amount of rewritten and modified test code and the stability of the tests over refactors, which in turn must make refactoring easier.

If you write unit tests that make assertions that would be caught by a type checker, you're writing bad tests.

If you don't understand why a dynamic language needs more tests than a typed one, you probably haven't worked with typed languages. The difference is dramatic and clear.

Just one example, code coverage must be 100% for a dynamic language in order to avoid runtime catastrophic failures due to simple typos - like letter transposition. Sure, 100% test coverage is a nice goal, but it's rarely met. In a typed language, you can be 100% sure this won't happen with zero tests.

Re: Why we love Scala at Coursera

#102
post #87

Earlier quoted context omitted.

If you write unit tests that make assertions that would be caught by a type checker, you're writing bad tests.

All unit test assertions can be caught by a type checker.

Assuming you are sarcastically dismissing typed language defenses, as if people promoting typed languages have the position that tests are not necessary.

Re: Why we love Scala at Coursera

#103

Good to see some love for Scala after all the recent rants. Unfortunately, I think it's going to be short lived. Most shops where Scala would be an option will soon have a production release of JDK8 available to them, at which point Scala's tradeoffs really only become acceptable to those who already have significant investment in the language or who think category theory is a reasonable companion to an industrial la…

Java 8 would make a very poor Scala substitute, and only offers a small subset of what is provided by Scala.

Re: Why we love Scala at Coursera

#104
post #34
post #19

Weird, why say all that about how it's better than Python/PHP/etc but then not say why they chose it over Java?

I suspect most of their target audience has a dim view of Java. Also, scala's official website has the advantages over Java. (If you're asking what Scala's advantages over Java are: less verbose to read (general lack of syntactic noise, case classes, UAP), covariance/contravariance for generics, code that's much more explicit about mutability (thanks to val/var), pattern matching, more flexible syntax (particularly f…

But one of the Scala drawbacks they cite is "arcane syntax". Another one is all the "advanced features" than can "weave a tangled web of code undecipherable to even its authors".

That's very much against the usual alleged benefits of Scala vs. Java that you've listed.

That's why I was very interested in the article, a "real world" take on Scala that really felt doctrine-free.. but found it odd that they didn't mention anything about Java. Java would seem at first blush to solve all of the concerns they listed: compile time, arcane syntax, counterproductive advanced features, primitive IDE support, training needs. While at the same time preserving most of the benefits: type safety, concurrency with Play/Akka, JVM ecosystem.

So it was just a little weird to not mention the elephant in the room.

Re: Why we love Scala at Coursera

#105

Earlier quoted context omitted.

> usually work correctly after they compile I still don't buy in to this trope. Q: What is true of every single bug in production? A: It passed both your type checker and your tests.

Look at it the other way. In fact, you can do a blind test. Try writing in a strongly, (well[0]) statically-typed language for a while, and count the number of times your code fails to compile due to a type error. Each of those would likely have been a runtime error in a language like Python. Just earlier today, I had to write a short Python script (I normally write Go), and I was bitten by this. I'm used to the comp…

Look at it the other way. In fact, you can do a blind test. Try writing in a strongly, (well[0]) dynamically-typed language for a while, and count the number of times your code fails at the REPL due to a type error.

Each of those would likely have been a compile time error in a language like Haskell.

Just earlier today, I was writing some C++ (I normally write Clojure) and I was bitten by this. I'm used to evaluating code in the REPL as I work, telling me up front when I try to concatenate a string and an integer, or when I misspell a variable name.

Yes, there are other ways around this (and proofreading your code before you write it is a good practice, in addition to tests). But dynamic typing can make development much faster[1].

Even if you claim that you would have caught all of those bugs in a type system (which I simply don't believe - no real-world project has types that are that precise), it's much better to catch bugs at run-time, because (unless you're writing Go) your compiler takes much longer to run than your REPL does to eval.

[0]: I qualify this to rule out Python, which has weak typing as well as mutability issues to complicate things, and JavaScript, which just has a terrible REPL period.

[1]: In some sense this is all a moot point, because any difference in development speed between statically-typed and dynamically-typed languages is dwarfed by one's familiarity with the languages in question. The only real way to test this would be to use a dynamically-typed language that has an optional type system as an external tool, luckily quite a few languages do this in a way that'd be straightforward to do a blind test (Typed Racket, Typed Clojure, Erlang w/ Dialyzer).

Re: Why we love Scala at Coursera

#106

Earlier quoted context omitted.

> usually work correctly after they compile I still don't buy in to this trope. Q: What is true of every single bug in production? A: It passed both your type checker and your tests.

That's a tautology. By that reasoning, don't bother writing any tests, because all your bugs in production will get past them anyway! My bugs got past my type-checker, but only 100 of them. You have 1000 because the 900 my type checker caught, your dynamic language didn't. Then you go and write unit tests for them, and spend a day writing code that my compiler generated automatically for me.

> By that reasoning ...

My reasoning in no way implies that. I simply said that I'm sick of this argument that "if it compiles, it works!" Nobody who knows what they are talking about actually believes that, especially not people who design and build statically typed languages!

Re: Why we love Scala at Coursera

#107
post #97

I enjoyed reading this article, but does anyone who doesn't already understand what they're saying understand after reading something like: "Play's reactive core and asynchronous libraries (e.g. WS) integrate seamlessly with other powerful concurrency primitives in the ecosystem such as Akka’s actors. Combining for-comprehensions with composable futures makes asynchronous concurrency look like straightforward synchro…

It made perfect sense to me, perhaps because I code in Scala for a living (even though I don't use either Akka or Play (yet)). It reminds me of the old comment about how unreadable French is because it looks nothing like English.

Re: Why we love Scala at Coursera

#108
post #97

I enjoyed reading this article, but does anyone who doesn't already understand what they're saying understand after reading something like: "Play's reactive core and asynchronous libraries (e.g. WS) integrate seamlessly with other powerful concurrency primitives in the ecosystem such as Akka’s actors. Combining for-comprehensions with composable futures makes asynchronous concurrency look like straightforward synchro…

    val plusOne = for(x 
desugars to:

    List(1,2,3).map(_+1) // or longhand, map(x=> x+1)
and:

    for(x 
desugars to:

    List(1,2,3).flatMap(x=> List(4,5,6).map(_*x))
So, composable futures means you can chain a bunch of futures together in a for comprehension and yield the successful or failing result without blocking.

The essential point is that if you have some Thing that implements map and flatMap, it can be chained through a for comprehension.

Only just dipping my toes in Haskell, but I must say that Scala is a truly wonderful language, one that makes my daily dev a whole lot of fun.

Re: Why we love Scala at Coursera

#109

Good to see some love for Scala after all the recent rants. Unfortunately, I think it's going to be short lived. Most shops where Scala would be an option will soon have a production release of JDK8 available to them, at which point Scala's tradeoffs really only become acceptable to those who already have significant investment in the language or who think category theory is a reasonable companion to an industrial la…

JDK8 is a very nice release and I hope it will bring Java a few years ahead, but there are so many things still missing from Java that every time I shriek. From big things like no type class support to tiny things like 1 file per interface/class the Java experience continues to be frustrating in the extreme.

Re: Why we love Scala at Coursera

#110
post #56

Earlier quoted context omitted.

We've had the same experience with Scala. It's the most enjoyable language I've ever coded in. We switched away from Java for most new development a while back already. The anti-Scala rants are just confusing to us. Most of the people complaining just seem to be random non-Scala developers recycling other peoples' criticisms.

I hear Java people say "I love scala" a lot. I do not hear people coming from other environments saying this.

My team at a previous job went from perl / c / python to scala, and liked it better.
Post reply on HN