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

Scala: the Case for Correctness

arthur.gonigberg.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Scala: the Case for Correctness

#51

Post by nrinaudo »

StefanKarpinski wrote: post #40
ma_mazmaz wrote: post #34

Earlier quoted context omitted.

In Scala, most variables should be val (i.e. constant) from a design perspective. That is, it is better, in Scala, to write code that does not have changing variable. Thus, using val instead of var is simply a check on the code, much in the same way that static typing provides a benefit over dynamic typing.

> much in the same way that static typing provides a benefit over dynamic typing. A non-trivial number of people would dispute that ;-)

I don't think so, actually: in all the heated discussions I've had with people on the subject of static / dynamic typing, everybody agreed that static typing had significant benefits. What people don't agree on is whether these benefits are worth the cost.

It's hard to argue in good faith that having the compiler catch mistakes rather than finding about them at runtime is a bad thing. It's perfectly possible to argue that it's not worth the perceived development speed slowdown.

Re: Scala: the Case for Correctness

#52

Post by actsasbuffoon »

nrinaudo wrote: post #51
StefanKarpinski wrote: post #40

Earlier quoted context omitted.

> much in the same way that static typing provides a benefit over dynamic typing. A non-trivial number of people would dispute that ;-)

I don't think so, actually: in all the heated discussions I've had with people on the subject of static / dynamic typing, everybody agreed that static typing had significant benefits. What people don't agree on is whether these benefits are worth the cost. It's hard to argue in good faith that having the compiler catch mistakes rather than finding about them at runtime is a bad thing. It's perfectly possible to argue…

Keep in mind that all of this is just my opinion. I'm not going to append "IMHO" to each sentence, as to save the reader the tedium of reading it. I'm not saying that I'm correct or that people should agree with me.

I would go so far as to say that I think overly simplistic static type systems don't have much benefit. C's static typing drives me crazy, as there's almost nothing of use that I can express with it. It's the same with Go; I almost never pass an Int when I meant to pass a Bool. In exchange for thoroughly unhelpful type errors I now have to jump through flaming hoops to parse JSON.

It ends up being a bit like JavaScript or Python where both languages lack the ability to specify that something is truly private (though in JS you can use closures to hide things). You generally just use a naming convention to mark a thing as private, and hopefully people have the decency to respect that. It's like that with types in dynamic languages; I can express pretty complex relationships with types and keep the whole thing in my head with out many problems.

That said, languages with powerful type systems like Scala and Haskell are thoroughly worth the effort. I can express almost anything with these type systems, usually with a minimum of fuss. They can protect me from the dreaded NPE, and that's a bug I encounter quite often. They can help me write simpler code that deals with complex shapes of data with their support for pattern matching and TCO. This one is more Haskell related, but the guarantee that everything is immutable and lazy makes it possible for the compiler to do some insanely impressive optimizations.

Scala, Haskell, and Rust have taken a dyed-in-the-wool lover of dynamic languages and made a convert of me. They finally followed through on the promises of safety and productivity that other languages failed to deliver on.

In closing, I'll repeat one last time that all of these are merely the opinions of an insufferable neck beard (me). Even if we disagree, I'm sure you're a very nice person, and I approve of you using whatever languages and tools make you happy and productive.

Re: Scala: the Case for Correctness

#53

Post by nrinaudo »

actsasbuffoon wrote: post #52
nrinaudo wrote: post #51

Earlier quoted context omitted.

I don't think so, actually: in all the heated discussions I've had with people on the subject of static / dynamic typing, everybody agreed that static typing had significant benefits. What people don't agree on is whether these benefits are worth the cost. It's hard to argue in good faith that having the compiler catch mistakes rather than finding about them at runtime is a bad thing. It's perfectly possible to argue…

Keep in mind that all of this is just my opinion. I'm not going to append "IMHO" to each sentence, as to save the reader the tedium of reading it. I'm not saying that I'm correct or that people should agree with me. I would go so far as to say that I think overly simplistic static type systems don't have much benefit. C's static typing drives me crazy, as there's almost nothing of use that I can express with it. It's…

I can't help but wonder whether you're that circumspect with everyone or if I come off as crazy-kill-you-you-phillistine and need to work on my communication skills?

Aside from the fact that I've never felt scarier, I agree entirely with every single point you just made and thank you for qualifying my broad generalisation.

Re: Scala: the Case for Correctness

#54

Post by emergentcypher »

Been working with Scala for 1.5 years and loving it. sbt feels easy to work with, compile times have improved (and you can improve it further by modularizing your app). Scala gets a lot right. Type inference makes it feel dynamic while still being safely typed at the compiler. Pattern matching and everything-is-an-expression are really the killer features for me that makes my code much more expressive.

The one thing that does bother me, as mentioned elsewhere, is operator overloading. There is a veritable soup of operators and you're never quite sure what an operator is actually doing. Worse, there aren't any plaintext equivalents. scala.collection.List doesn't have any "prepend/unshift" or "append/push" methods... all you have are ::, :::, +:, :+, /:, :\, :::, ++:, :++, ++ and so on.

Re: Scala: the Case for Correctness

#55

Post by frowaway001 »

defpan wrote: post #36

I totally agree with the author. The one's mentioned in the article are really the key benefits. I really wish scala didn't have implicits. People go crazy with implicits resulting in very difficult to read code. Sometimes I feel like going back to java just for the readability and then I remember these nice features of scala. We need a scala minus implicits.

> We need a scala minus implicits.

I don't find the idea of programming without typeclasses appealing – at all.

Re: Scala: the Case for Correctness

#56

Post by frowaway001 »

joegaudet wrote: post #45

Fair Warning, I worked with the other for some time, and have been having an out of band convo with him. One of the things I absolutely HATE about scala is operator overloading - and the excessive abuse of it. I ran into it just now using some library that used ==. A Case: List(1,2) == List(1,2); true Array(1,2) == Array(1,2); false The reason for this is obvious, list implements equals and does a deep compare. While…

> The lack of a universal idea about what == means is pretty dangerous IMO.

There is an universal idea what == means, it's quite simple and more consistent then the mess Java has.

It's just that the JVM's idea cannot be brought in line with it consistently.

If you look at the history of Scala, you'd see that they tried to make Arrays work this way for 5+ years.

The blood being shed just wasn't worth the quirks it caused in other parts and in the end trying to fix the JVM's idea of arrays was abandoned.

Re: Scala: the Case for Correctness

#57

Post by actsasbuffoon »

nrinaudo wrote: post #53
actsasbuffoon wrote: post #52

Earlier quoted context omitted.

Keep in mind that all of this is just my opinion. I'm not going to append "IMHO" to each sentence, as to save the reader the tedium of reading it. I'm not saying that I'm correct or that people should agree with me. I would go so far as to say that I think overly simplistic static type systems don't have much benefit. C's static typing drives me crazy, as there's almost nothing of use that I can express with it. It's…

I can't help but wonder whether you're that circumspect with everyone or if I come off as crazy-kill-you-you-phillistine and need to work on my communication skills? Aside from the fact that I've never felt scarier, I agree entirely with every single point you just made and thank you for qualifying my broad generalisation.

No, not in the slightest, though you've made me laugh like a maniac in front of my co-workers. So there's that, you fiend.

It was more of a general butt-covering sort of thing. People like to take offense to things on the internet.

Re: Scala: the Case for Correctness

#58

Post by frowaway001 »

jakozaur wrote: post #46
rld wrote: post #12

Earlier quoted context omitted.

What do you mean by "more aesthetic"? As in syntax?

There are sometimes too many ways of doing the same thing. E.g. - syntax: def func() { and def func(): Unit = { - collection library

> def func() {

That's already deprecated (under -Xfuture):

  :1: warning: Procedure syntax is deprecated. 
  Convert procedure `func` to method by adding `: Unit =`.

Re: Scala: the Case for Correctness

#59

Post by fedesilva »

joegaudet wrote: post #13
fedesilva wrote: post #6

Earlier quoted context omitted.

You can always use Option() as in: scala> Option(System.getProperty("kaboom")) res1: Option[String] = None then map, getOrElse or fold at will. (edited format)

For sure you can, but the internals of the libraries can also cause NPEs because of turtles all the way down :P We've been running scala in production for 4 years, and had our share of NPEs in our code and in the libraries we host. My point I guess was just that it's not entirely true that they will not boil to the surface on occasion.

It's true what you say about libraries and turtles. Still it's rare the event when I get an NPE from my/our code.

Sometimes think I would love to have a layer between us and Java. Some sort of FFI which returned everything on an Option.

Probably too cumbersome, but still ...

Re: Scala: the Case for Correctness

#60

Post by ddossot »

eranation wrote: post #21

I see Scala as an alternative to Java/Go for Ruby web developers who want a statically typed language that feels more dynamic. Yes, you can go crazy with Scala, but if you are responsible, I would say that migrating from Ruby to Scala is easier than to Java or Go. (I use Scala at work commercially for 3 years now and I have my issues with it, but I don't have an alternative, tried Kotlin and Java 8, and some Go, coul…

Interestingly, the Ruby developers I know seem more inclined towards Clojure than Scala. One stated he was more attracted by immutability than type safety, hence Clojure over Scala.
Post reply on HN