Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we love Scala at Coursera

tech.coursera.org

Post reply on HN
Print view View original

131–140 of 184 posts

Re: Why we love Scala at Coursera

#131

Post by virtualwhys »

basman wrote: post #99
cia_plant wrote: post #93

Earlier quoted context omitted.

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

Your type checker catches array indexing bugs? Impressive.

No, but Scala encourages FP, so when you:

    val fooList = List(1,2,3)
    fooList.map(...)
you'll _never_ hit the types of bugs you're referring to.

If you fooList(3), then of course you're hosed, but that's not the type checker's fault ;-)

Re: Why we love Scala at Coursera

#132

Post by donjigweed »

kasey_junk wrote: post #109
donjigweed wrote: post #96

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.

Which is why I said "Scala's tradeoffs" would become unacceptable. Java 8 is basically "close enough" to "The Good Parts" of Scala that most people probably won't be willing to tolerate all of Scala's warts.

Re: Why we love Scala at Coursera

#133

Post by singingcheese »

vilhelm_s wrote: post #121
brandonbloom wrote: post #105

Earlier quoted context omitted.

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…

You can have a REPL in a statically typed language too---Haskell has one.

> You can have a REPL in a statically typed language too---Haskell has one.

And so does Scala...

Re: Why we love Scala at Coursera

#134

Post by kasey_junk »

basman wrote: post #99
cia_plant wrote: post #93

Earlier quoted context omitted.

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

Your type checker catches array indexing bugs? Impressive.

I don't agree even with the sentiment of the original post, but there is an argument that while you can't get rid of array indexing bugs with a type checker (contracts might help here) you can design your collection types such that things like indexing above or below an array are compile time caught, as is indexing into the "wrong" array location.

Whether it is worth the trouble to do this in the type system probably depends on how good your language's type system is and how expensive array indexing bugs are to catch/fix.

Re: Why we love Scala at Coursera

#135

Post by basman »

chimeracoder wrote: post #94
brandonbloom wrote: post #70

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…

So yes, they would be runtime errors in Python. But that's not such a catastrophe, actually. The way I write Python is by being in an IPython shell, writing short functions, unit-testing them as I go. So the development-time cost of those runtime errors is not very high, and in my experience offset by the flexibility and interactiveness. Writing in a functional style without much mutable state is really the thing that I find saves development/debugging time.

Re: Why we love Scala at Coursera

#136

Post by lmm »

etrain wrote: post #56
thescrewdriver wrote: post #44

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.

I was a python guy before I found scala FWIW

Re: Why we love Scala at Coursera

#137

Post by kasey_junk »

singingcheese wrote: post #130
kasey_junk wrote: post #123

Earlier quoted context omitted.

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…

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

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.

Re: Why we love Scala at Coursera

#138

Post by lmm »

laureny wrote: post #81
lmm wrote: post #43

Earlier quoted context omitted.

Java's future API is inadequate - you can only block on a future or poll it, not ask to be notified when it completes, so you end up needing a thread for each future which loses a lot of the benefits. I haven't used Qasar specifically but I did use other java extensions that add some scala features for a while (Lombok and the Checkers Framework). The thing is, once you're using those you're effectively using a differ…

> not ask to be notified when it completes This is trivial to add (Guava offers it as ListenableFuture), but either way, it's a library concern, not a language one, so I don't think it makes sense to pit Java and Scala over this.

The standard library matters, particularly because Java doesn't let you smooth over these incompatibilities with implicits.

But you're right, I should've said that the syntax (while a vast improvement over previous Java) is not as nice as for/yield, and the lack of higher-kinded types in Java means you can't write functions that handle Futures and other types with similar semantics generically.

Re: Why we love Scala at Coursera

#139

Post by lgieron »

okaram wrote: post #90
lgieron wrote: post #40

Earlier quoted context omitted.

I'd say having automatic compile-time checks and vs having to be "extra careful" + necessity for more umit tests is a world of difference. AFAIK, Google doesn't use dynamic-typed languages for any of its projects (except where their hand was forced - they inherited the codebase in an acquisition) and they sure as hell are experienced in large-scale software development (for small to medium projects, the drawbacks of…

I'm not sure what you consider google 'projects'; from what I heard, a lot of their 'sysadmin' type of scripting is in python (probably moving to go now)

By "projects" I mean code delivering actual software products (like for example the search, gmail etc.), not some auxiliary admin scripts.

Re: Why we love Scala at Coursera

#140

Post by Sharlin »

singingcheese wrote: post #107
dmunoz wrote: 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.

I don't think the target audience of the blog post was experienced Scala developers (that would just be preaching to the choir!) so the use of unexplained jargon should be kept at minimum to actually reach the audience.
Post reply on HN