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

121–130 of 184 posts

Re: Why we love Scala at Coursera

#121

Post by vilhelm_s »

brandonbloom wrote: post #105
chimeracoder wrote: post #94

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]) 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…

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

Re: Why we love Scala at Coursera

#122

Post by jcrites »

crystaln wrote: post #101
lbarrow wrote: 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.

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, yo…

That's a great point!

It's also what makes refactoring so much easier. If I need to rename a method obj.f() to obj.g(), then I can do so safely knowing that no lingering references to f() remain in my code base (else they would fail to type as f() is no longer a valid method).

As you say, 100% code coverage is unrealistic. Having maintained large applications in both static and dynamically typed languages, I feel that statically typed programs are far easier to manage for this reason - that if my code compiles then it means there exist no errors of a certain trivial class, such as typos and references to classes or methods that have been removed.

There are still other errors to worry about, but mitigating those errors can be done effectively without needing to approach 100% code coverage.

Re: Why we love Scala at Coursera

#123

Post by kasey_junk »

singingcheese wrote: post #112
wyuenho wrote: post #42

Earlier quoted context omitted.

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

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

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.

Re: Why we love Scala at Coursera

#124

Post by klibertp »

NickPollard wrote: post #66
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…

> The biggest thing that contributes to refactorability has nothing to do with type safety. Instead unit test coverage, by a mile, is the thing that makes code easy to refactor Type Safety is Unit Test Coverage. Typing is a statically checked test of correctness of your program. Languages like C give static typing a bad name. Types are not things like 'float', 'int', 'double'. Types are 'degrees', or 'radians'. Types…

> Types guarantee that your code executes as you expect, and prevent you from writing incorrect code in the first place.

If you write a Rational class and implement it's + method as

    def +(other: Rational):Rational = new Rational(0)
then no amount of static typing will save you. At least without dependent types.

Static typing gives you a knowledge about what kind of object you're dealing with without the need to run the code. It's almost completely useless if the "kinds" supported in type system are as broad as 'int', but it does help quite a lot if the type system let's you differentiate between cm and inches.

It still won't help you at all if you have a logic error - and this is where unit tests are valuable.

Personally I find a mixture of Typed Racket and Racket with contracts and unit tests to be the right thing when it comes to producing as error-free programs as possible. I was also pleasantly surprised with Smalltalk, which has no static typing, but because it runs all the time and every piece of code becomes "live" the moment it's written you can use introspection in place of static typing with very similar benefits.

Anyway, static typing is a valuable tool and one way of making software less wrong but it's important to know there are other tools and to use them all when it makes sense.

Re: Why we love Scala at Coursera

#125

Post by frowaway001 »

mentaat wrote: post #41
atto wrote: post #29

Earlier quoted context omitted.

How large? We have well over 100k lines of code (Scala), and it's not a serious issue. The sbt 0.13 incremental compiler is much better than 0.12's. Also, using sbt multi-projects helps quite a bit (even when running all at once).

much smaller - around 25k+. i gave up after becoming frustrated by the atrociously compile times. haven't used sbt .13 though but i don't expect it to solve miracles given how inherently complex the scala compiler code is. according to paul phillips, core scala committer, there are large portions of the compiler code that nobody touches because nobody understands it. and as per him this along with bunch of other limi…

> there are large portions of the compiler code that nobody touches because nobody understands it

Could you link to one of those "large portions"?

> and as per him this along with bunch of other limitations guarantees that you won't see huge gains in compile times unless they rewrite the whole compiler...

You mean like https://groups.google.com/forum/#!topic/scala-internals/6HL6... ?

Re: Why we love Scala at Coursera

#126

Post by brandonbloom »

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.

GHC's REPL wraps all expressions in a giant do-block with an IO monad. It's practically useless without the meta-language of the colon commands. That said, truly modern versions of GHC have deferred type checking for REPL use, which is impressive, useful and, ultimately, a simple emulation of a dynamic language.

Never mind that not even Python or Ruby, and especially not JavaScript, provide sensible useful REPLs with sane code reloading semantics.

People who shit on crappy type systems turn around and then shit on crappy REPLs in broken dynamic languages. I'd take a statically typed language over a language with a bad REPL any day.

Re: Why we love Scala at Coursera

#127

Post by NickPollard »

saryant wrote: post #117
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…

A for-comprehension from our production code: for { createResult That code asynchronously updates both ElasticSearch and Neo4j. Those functions all return Scala futures containing JSON values. First the new object is created in Neo and then the index in ES is updated accordingly. This is in a controller action in a Play project where it's critical to keep everything non-blocking. If everything is successful, Play ret…

Scala derail: You might have an unintentional happens-before relationship in that example: The deletePersons call will end up being in the flatMap of the putAll[Person] call, which means it wont be started until the putAll finishes, when by the looks of it you could do both at once (only the createPerson needs to happen first).

You might want to do something like this:

  for {
    createResult
(notice starting the computations outside of the second for-comprehension, then just waiting for them inside)

Re: Why we love Scala at Coursera

#128

Post by hawkharris »

ChikkaChiChi wrote: post #80
hawkharris wrote: post #6

My favorite quote from the article: "Python probably takes the cake for being regular. PHP gets cake in the face… Scala is somewhere in-between."

If you have complete control over your programmatic infrastructure and you are getting PHP 'cake in the face' you shouldn't blame PHP. You're just a shitty programmer.

I helped develop a PHP application used by about 30,000,000 people. It consisted of well-organized objects that followed proper design patterns. Our API was easy to use and understand.

Although PHP was an effective, decent language, it wasn't the best tool for our project. It lacked certain functional features, brevity and syntactic sugar that one might find in Python.

The Web is full of emotional, profanity-laden debates pitting one language against another. I don't think those are interesting or useful. But it is productive to critique the languages' relative strengths and weakness based on how they can be applied to a business problem.

Like the engineer from Coursera, I determined that PHP was, indeed, a "cake in the face," considering my needs and circumstances at the time.

Re: Why we love Scala at Coursera

#129

Post by saryant »

NickPollard wrote: post #127
saryant wrote: post #117

Earlier quoted context omitted.

A for-comprehension from our production code: for { createResult That code asynchronously updates both ElasticSearch and Neo4j. Those functions all return Scala futures containing JSON values. First the new object is created in Neo and then the index in ES is updated accordingly. This is in a controller action in a Play project where it's critical to keep everything non-blocking. If everything is successful, Play ret…

Scala derail: You might have an unintentional happens-before relationship in that example: The deletePersons call will end up being in the flatMap of the putAll[Person] call, which means it wont be started until the putAll finishes, when by the looks of it you could do both at once (only the createPerson needs to happen first). You might want to do something like this: for { createResult (notice starting the computat…

Good catch. :) Our production code actually does handle the relationship correctly, I just wanted to simplify in my example.

Re: Why we love Scala at Coursera

#130

Post by singingcheese »

kasey_junk wrote: post #123
singingcheese wrote: post #112

Earlier quoted context omitted.

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

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.

Post reply on HN