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, couldn't give up Scala)
Scala: the Case for Correctness
21–30 of 63 posts
Re: Scala: the Case for Correctness
#22 When I say correctness, I mean the ability to easily and
consistently write code that works as inteded (not the academic
definition of correctness).
Re: Scala: the Case for Correctness
#23It seems like these points are true of other Java alternatives as well. What about Ceylon, Fantom, and Kotlin?
Fantom: Typesystem is unsound, far away from correctness, only hard-coded Generics, many basic things are not expressions, like if-then-else or try-catch.
Ceylon: if-then-else or try-catch are no expressions, embraces null, unstable software, breaks backward compatibility in minor releases.
Kotlin: Embraces null, inexpressive type system limits the things the compiler can check, unstable software, breaks backward compatibility in minor releases.
Re: Scala: the Case for Correctness
#24I 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…
> 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.
Re: Scala: the Case for Correctness
#25When I say correctness, I mean the ability to easily and consistently write code that works as inteded (not the academic definition of correctness). I'm curious as to what the author believes the academic definition of 'correctness' actually is. Is it something other than code "working as inteded [sic]"?
Thanks for pointing out the typo, I fixed it.
By academic correctness, I mean the formal definition in computer science, i.e. for an algorithm. More here: http://en.wikipedia.org/wiki/Correctness_(computer_science)
By this measure, it's hard to say any language is more or less "correct" than another.
Re: Scala: the Case for Correctness
#26I 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…
> 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.
Re: Scala: the Case for Correctness
#27I 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…
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 makes reasoning far easier than just referential immutability.
Re: Scala: the Case for Correctness
#28When I say correctness, I mean the ability to easily and consistently write code that works as inteded (not the academic definition of correctness). I'm curious as to what the author believes the academic definition of 'correctness' actually is. Is it something other than code "working as inteded [sic]"?
Thanks for pointing out the typo, I fixed it. By academic correctness, I mean the formal definition in computer science, i.e. for an algorithm. More here: http://en.wikipedia.org/wiki/Correctness_(computer_science) By this measure, it's hard to say any language is more or less "correct" than another.
You can get pretty darned close to that kind of correctness in a type-dependent language, but the amount of work involved is tremendous.
Re: Scala: the Case for Correctness
#29It seems like these points are true of other Java alternatives as well. What about Ceylon, Fantom, and Kotlin?
Fantom: Typesystem is unsound, far away from correctness, only hard-coded Generics, many basic things are not expressions, like if-then-else or try-catch. Ceylon: if-then-else or try-catch are no expressions, embraces null, unstable software, breaks backward compatibility in minor releases. Kotlin: Embraces null, inexpressive type system limits the things the compiler can check, unstable software, breaks backward com…
Good summary. New "null-full" languages should be shamed publicly. Null as a bottom-type is a semantic wart.
Re: Scala: the Case for Correctness
#30I 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…
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.