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

31–40 of 63 posts

Re: Scala: the Case for Correctness

#31

Post by frowaway001 »

StefanKarpinski wrote: post #26
frowaway001 wrote: post #24

Earlier quoted context omitted.

> It's easy for a parser or a person to scan the local scope and see if a variable is ever possibly mutated or not. "what the parser figured out" != "what the author intended" > this is a straightforward syntactic property Not for the reader.

No, seriously, it's easy: Is there exactly one assignment location that's not in a loop or a conditional? yes => constant ; no => non-constant This is neither hard nor unintuitive.

So you are recommending to create a special case just for declarations in local scope?

So "var" in global places means "variable", but "var" in local places means "variable or value"?

Re: Scala: the Case for Correctness

#32

Post by StefanKarpinski »

frowaway001 wrote: post #31
StefanKarpinski wrote: post #26

Earlier quoted context omitted.

No, seriously, it's easy: Is there exactly one assignment location that's not in a loop or a conditional? yes => constant ; no => non-constant This is neither hard nor unintuitive.

So you are recommending to create a special case just for declarations in local scope? So "var" in global places means "variable", but "var" in local places means "variable or value"?

I'm not recommending anything. I'm wondering what the point of declaring something that's obvious from a simple syntactic analysis is. The author of this post makes a big deal of it and I don't see why it's useful. If the motivation is that constness is the right default in global scope and you want to make local and global scope more similar (even though they are still radically different), that's cool, but then don't make it out like local variables defaulting to const is the best thing ever invented.

Re: Scala: the Case for Correctness

#33

Post by rld »

StefanKarpinski wrote: post #30
rld wrote: post #27

Earlier quoted context omitted.

At least in Java, non-final variables can't be used inside anonymous inner classes. Also, it's easier for me as a developer to read "final" and know that (referential) immutability is guaranteed by the compiler instead of having to read the local scope, which likely contains method calls that may or may not modify that variable. val and final have stronger meanings when your objects are immutable. True immutability m…

> At least in Java, non-final variables can't be used inside anonymous inner classes. Aren't those members/fields not variables? If so, then those are effectively global not local, so that's a completely different story – I'm talking strictly about local variables. > True immutability makes reasoning far easier than just referential immutability. Yep, immutable types and constant global bindings are great.

No, it applies for local variables as well: http://stackoverflow.com/questions/7423028/java-local-variab...

I still don't understand why you consider having a compiler-enforced restriction on mutation worse than letting readers figure out what was the developer's intent.

In Java, the only "downside" is having to add "final" as a modifier, which is negligible.

In Scala, the alternative is to declare that variable as "var" instead of "val". When would you ever choose var over val if your object isn't supposed to mutate?

Re: Scala: the Case for Correctness

#34

Post by ma_mazmaz »

StefanKarpinski wrote: post #20

I don't get the business of marking variables as const in local scope (aka "val" aka "final" for local variables). It's easy for a parser or a person to scan the local scope and see if a variable is ever possibly mutated or not. This is very different from the situation with globals where it's generally intractable to prove that something is never mutated. In local lexical scope you can see all possible mutations by…

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.

Re: Scala: the Case for Correctness

#35

Post by ma_mazmaz »

rld wrote: post #33
StefanKarpinski wrote: post #30

Earlier quoted context omitted.

> At least in Java, non-final variables can't be used inside anonymous inner classes. Aren't those members/fields not variables? If so, then those are effectively global not local, so that's a completely different story – I'm talking strictly about local variables. > True immutability makes reasoning far easier than just referential immutability. Yep, immutable types and constant global bindings are great.

No, it applies for local variables as well: http://stackoverflow.com/questions/7423028/java-local-variab... I still don't understand why you consider having a compiler-enforced restriction on mutation worse than letting readers figure out what was the developer's intent. In Java, the only "downside" is having to add "final" as a modifier, which is negligible. In Scala, the alternative is to declare that variable as "…

In Scala, there are both mutable and immutable data structures. Immutable data structures are preferred, however there are some cases in which a dash of mutability can simplify the code, especially in cases where Java inter-op is a must.

Re: Scala: the Case for Correctness

#36

Post by defpan »

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.

Re: Scala: the Case for Correctness

#37

Post by StefanKarpinski »

rld wrote: post #33
StefanKarpinski wrote: post #30

Earlier quoted context omitted.

> At least in Java, non-final variables can't be used inside anonymous inner classes. Aren't those members/fields not variables? If so, then those are effectively global not local, so that's a completely different story – I'm talking strictly about local variables. > True immutability makes reasoning far easier than just referential immutability. Yep, immutable types and constant global bindings are great.

No, it applies for local variables as well: http://stackoverflow.com/questions/7423028/java-local-variab... I still don't understand why you consider having a compiler-enforced restriction on mutation worse than letting readers figure out what was the developer's intent. In Java, the only "downside" is having to add "final" as a modifier, which is negligible. In Scala, the alternative is to declare that variable as "…

That's just a weird wart of Java – not allowing anonymous inner classes to close over non-final variables was just a cheat to avoid having to implement proper closures; I have no idea what the technical impediments to doing so were when that decision was made, but plenty of languages, including Scala, have real closures.

> In Scala, the alternative is to declare that variable as "var" instead of "val". When would you ever choose var over val if your object isn't supposed to mutate?

It's an extra keyword, an extra complication in the language – one more binary choice to multiply with all the other options. It would be nice to get rid of the distinction altogether.

Re: Scala: the Case for Correctness

#38

Post by Animats »

sinwave wrote: post #17

I would pay good money to see Paul Philips' reaction to the sentence > "the biggest benefit with Scala is correctness." ...before the author goes on to say > "When I say correctness, I mean the ability to easily and consistently write code that works as inteded (not the academic definition of correctness)"

As someone who used to work on automatic proof of correctness systems, that irked me too.

It's quite reasonable to have a language where certain classes of errors cannot be generated from the source code. There are languages which can reliably detect or prevent subscript out of range errors, null pointer errors, dangling pointer errors, and race conditions. (C and C++ detect and prevent none of the above, which is the cause of most of the troubles in computing.) That's not full correctness; it's just language safety. It means you can't break the language model from inside the language. Most of the "scripting languages" have this property, or at least are supposed to.

Scala takes the null pointer issue a bit more seriously than most languages. That's good, but not enough to justify a claim that it offers "correctness".

Re: Scala: the Case for Correctness

#39

Post by rld »

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.

Just out of curiosity, which libraries or frameworks do you feel abuse implicits?

Re: Scala: the Case for Correctness

#40

Post by StefanKarpinski »

ma_mazmaz wrote: post #34
StefanKarpinski wrote: post #20

I don't get the business of marking variables as const in local scope (aka "val" aka "final" for local variables). It's easy for a parser or a person to scan the local scope and see if a variable is ever possibly mutated or not. This is very different from the situation with globals where it's generally intractable to prove that something is never mutated. In local lexical scope you can see all possible mutations by…

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

Post reply on HN