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

81–90 of 184 posts

Re: Why we love Scala at Coursera

#81

Post by laureny »

lmm wrote: post #43
RyanZAG wrote: post #31

Earlier quoted context omitted.

Just curious, but have you used Java8 much? Or barring that, something like quasar? Qasar in particular is about writing async code as if it were sync code...

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.

Re: Why we love Scala at Coursera

#82

Post by plinkplonk »

edtechdev wrote: post #67
sramsay wrote: post #8

What is the point of articles like this? I'm not trying to be snarky; I really am trying to understand why a company would go out of its way to advertise the technology its using. Sometimes we see blog posts from devs at companies (often pretty senior) who write things like "We went with Clojure, and we've been really happy." That's clearly a geek-to-geek thing. But what is this? I mean, it's also geek-to-geek, but i…

Because the engineers are in charge. Coursera was founded by programmers and is dominated by programmers. I'm not saying that's always a bad thing - Google is dominated by engineers and it is an engineering company. But I have been surprised by how few people (zero, from what I can see) they have hired who specialize in education and learning, which I thought was the business of Coursera.

"Coursera was founded by programmers and is dominated by programmers."

I doubt Daphne Koller or Andrew Ng were (production) programmers. They probably wrote enough Matlab or whatever for their teaching research needs like most academics. (imo, glad to be corrected).

Re: Why we love Scala at Coursera

#83

Post by michaelochurch »

enjo wrote: post #61

"Refactoring a statically typed language is easier than refactoring an interpreted one; modifying existing PHP, and even Python, is a difficult chore that engineers shy away from because modifications are likely to create more bugs than they fix." Over the years I've worked pretty deeply with both static (C++/Java/Scala) and dynamic languages (Python/Ruby). I simply don't agree. The biggest thing that contributes to…

My preferred language these days is Clojure, which is dynamic, but I don't agree that most errors have nothing to do with type safety.

Most errors are fairly random. There isn't a pattern to them. Misspellings, misconceptions. Whether your type system catches them depends on the strength of your type system in addition to how you represent things. (Hashmaps vs. records, whether the get call on a Hashmap returns a nil value or an error when the key's not found.)

A strong type system makes it likelier that errors are caught earlier. This may or may not be justified, depending on the application. For some problems, the reduced error-to-failure distance is considerable and it's a huge win.

Re: Why we love Scala at Coursera

#84

Post by cgrubb »

enjo wrote: post #61

"Refactoring a statically typed language is easier than refactoring an interpreted one; modifying existing PHP, and even Python, is a difficult chore that engineers shy away from because modifications are likely to create more bugs than they fix." Over the years I've worked pretty deeply with both static (C++/Java/Scala) and dynamic languages (Python/Ruby). I simply don't agree. The biggest thing that contributes to…

To put some meat on the discussion, what would be an example of a logic error which would be introduced by a refactoring?

Re: Why we love Scala at Coursera

#85

Post by ChikkaChiChi »

I enjoyed this article because it stated without a whole lot of bias why Scala was the right tool for the job.

Python could have fulfilled some of the requirements such as the lighter concurrency; however it would have come at the expense of the ease of deployment.

I disagree with type safety being integral to refactoring, but each team has their own culture and this seems to fit theirs well.

Re: Why we love Scala at Coursera

#86

Post by okaram »

ChikkaChiChi wrote: post #74
enjo wrote: post #61

"Refactoring a statically typed language is easier than refactoring an interpreted one; modifying existing PHP, and even Python, is a difficult chore that engineers shy away from because modifications are likely to create more bugs than they fix." Over the years I've worked pretty deeply with both static (C++/Java/Scala) and dynamic languages (Python/Ruby). I simply don't agree. The biggest thing that contributes to…

Am I missing a big problem with dynamic typing? Wouldn't clearly defined naming conventions solve part of the problem?

They't need to be not just clearly defined but enforced; wouldn't it be cool if we could write a tool that automatically enforces them ? hmmm ... :)

Re: Why we love Scala at Coursera

#87

Post by lbarrow »

crystaln wrote: post #75
enjo wrote: post #61

"Refactoring a statically typed language is easier than refactoring an interpreted one; modifying existing PHP, and even Python, is a difficult chore that engineers shy away from because modifications are likely to create more bugs than they fix." Over the years I've worked pretty deeply with both static (C++/Java/Scala) and dynamic languages (Python/Ruby). I simply don't agree. The biggest thing that contributes to…

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.

Re: Why we love Scala at Coursera

#88

Post by coolsunglasses »

yan wrote: post #73
coolsunglasses wrote: post #36

Earlier quoted context omitted.

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

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

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.

Re: Why we love Scala at Coursera

#89

Post by RyanZAG »

justinsb wrote: post #52
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…

It is a weird omission, not least because it seems that anyone that wants to use Futures ends up extending it in the same (but incompatible) way. Guava has ListenableFuture, Netty has its own version, etc. I'm not sure how this happened, but I just use Guava's ListenableFuture and am happy again.

It was omitted because it's a complex design issue. Someone using the future would assume that if they added a callback, it would run on the same thread that they called it from. That's not possible in the general case: the thread they called it on may not have an event loop and so could not be directly notified.

It's better to leave this to frameworks or libraries that have their own event loop mechanism to handle callbacks.

Re: Why we love Scala at Coursera

#90

Post by okaram »

lgieron wrote: post #40
wilsonfiifi wrote: post #32

It would be interesting to read a similar article from a company that uses python as their core programming language (Dropbox for instance) to contrast it with this one. Python might not be as popular as Java but I was under the impression that it offered a rich enough platform/ecosystem to accommodate for a wide spectrum of software projects. Concerning the issue of type checking, I understand that it's great to hav…

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)
Post reply on HN