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

141–150 of 184 posts

Re: Why we love Scala at Coursera

#141

Post by m_gol »

spo81rty wrote: post #69
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…

I've only used static languages and therefore never had to make unit tests. Unit tests should exists for certain business rules, not every line of code.

Lol, never? Types won't check your whole business logic, it's irresponsible to nog write them (unless you're doing something really small).

Re: Why we love Scala at Coursera

#142

Post by thescrewdriver »

kasey_junk wrote: post #137
singingcheese wrote: post #130

Earlier quoted context omitted.

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

Doing an extra object allocation (which will likely be elided by escape analysis in the JVM) is hardly "weird and terrifying behaviour". It is an implementation detail which has absolutely no bearing on the behaviour or functionality of the map.

Re: Why we love Scala at Coursera

#143

Post by deckiedan »

virtualwhys wrote: post #108
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…

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…

Would this be equivalent to:

    plusOne = (x+1 for x in (1,2,3))
And then the second example:

    mult = (x*y for x,y in zip((1,2,3), (4,5,6)))
In python?

Re: Why we love Scala at Coursera

#144

Post by nousernamesleft »

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…

>Over the years I've worked pretty deeply with both static (C++/Java/Scala) and dynamic languages (Python/Ruby). I simply don't agree.

How did you use scala? Did you write java code in scala as most people with a C++/C#/java background do? Because that would completely explain the rest of your post. In particular, this statement:

>In my experience issues of type safety are rare

I've been doing pretty exploratory, "refactor the hell out of it every other day" kind of coding lately. I would literally rather not program than have had to do it in a language other than haskell. If I were to record this process, I am sure I would come up with several hundred type errors being caught over the course of a week.

>The same types of bugs are going to crop up in Scala, Python, Java, or even Fortran unless you have tests to help you discover those issues.

The obvious example of that being a bad assumption is that static type systems can completely eliminate unexpected NULL errors. It can eliminate "oops I used the count as the X co-ord by mistake" style errors. It can eliminate a huge class of errors that java programmers don't recognize are in fact type errors.

>Logic errors are generally independent of type issues

Which is why it is so nice to let the computer deal with type errors and be able to concentrate on logic errors instead of constantly having to worry about type errors manually.

Re: Why we love Scala at Coursera

#145

Post by virtualwhys »

deckiedan wrote: post #143
virtualwhys wrote: post #108

Earlier quoted context omitted.

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…

Would this be equivalent to: plusOne = (x+1 for x in (1,2,3)) And then the second example: mult = (x*y for x,y in zip((1,2,3), (4,5,6))) In python?

yup, not sure what Python does with your examples under the hood, but they're equivalent, and, I must say, nicely concise ;-)

In Scala I guess we could go zip-style and do:

    List(1,2,3) zip List(4,5,6) map{case(x,y)=> x*y}
but I was trying to demo for comprehensions and their relation to map/flatMap for the OP.

Re: Why we love Scala at Coursera

#146

Post by nousernamesleft »

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…

>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

I dunno, I have 11 years of python experience, and almost a year of haskell experience. I am more productive in python when doing small (<100 lines) scripting type tasks. But I am noticeably more productive in haskell when writing bigger things. Haskell has a relatively crappy web ecosystem, yet I'm still more productive with snap+postgresql-simple+digestive-functors then I have ever been with any python framework (from zope way back in the day to django and flask). Tasks that are more skewed to haskell's strengths like highly concurrent network servers make the difference even more pronounced.

Re: Why we love Scala at Coursera

#148

Post by virtualwhys »

frowaway001 wrote: post #125
mentaat wrote: post #41

Earlier quoted context omitted.

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

Nice find! Didn't know they were so far along with Dotty.

Will be interesting to see how a potential merge works out (assume Scala 2.13 at the earliest).

Re: Why we love Scala at Coursera

#149

Post by AnimalMuppet »

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.

Actually, in the original (circa 1968) Pascal, it did.

In Pascal, the size of an array was part of the type of the array. IIRC, You simply could not write an array index out of bounds bug. This made it a somewhat reasonable choice for a medical device, where an array index out of bounds could be catastrophic. However...

You also could not create a variable-sized array. There was no way even to talk about the type of such an object. (Yes, I ran into that professionally once.) I think this is why Turbo Pascal (and maybe others?) softened that.

Re: Why we love Scala at Coursera

#150

Post by nousernamesleft »

virtualwhys wrote: post #98
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.

Well, so what? Simon Marlow, Haskell's lead compiler developer in recent years, quit, leaving arguably a much larger gap than @paulp leaving Tyepsafe since SPJ is wrapped up in leading some English education initiative. Anyway, shit happens, gaps are filled. Languages, once established, are larger than any one developer, no matter how brilliant the individual may be. It's worth noting that @paulp is as active as ever…

>Simon Marlow, Haskell's lead compiler developer in recent years, quit, leaving arguably a much larger gap than @paulp leaving Tyepsafe

Quit what? He is still a ghc developer. He quit his job at Microsoft Research to go work at Facebook, but that doesn't seem quite comparable to quitting a job working at the official scala company on the official scala compiler.

Post reply on HN