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

11–20 of 63 posts

Re: Scala: the Case for Correctness

#11

Post by saosebastiao »

fedesilva wrote: post #6
joegaudet wrote: post #2

Having jumped back into some green field work in Scala in the past few days, I will say I'm quite impressed with the improvements to the SBT, IntelliJ, universe. Compile time seems to be improved considerably (though the project is still quite small so time will certainly tell). One problem, which is also one of the advantages of scala is that the interop with Java often means that all your Option[] etc code can stil…

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)

Thanks for mentioning this. I had no idea. All this time I had been doing null checks...this makes it so much less painful!

Re: Scala: the Case for Correctness

#12

Post by rld »

jakozaur wrote: post #3

Scala gets a lot of things right by default. Also it got a lot of flexibility and power. Almost "a framework" to write other languages within the language. Use it every work day for over two years... Like a lot, but sometimes wishes it would be a bit simpler and more aesthetic.

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

Re: Scala: the Case for Correctness

#13

Post by joegaudet »

fedesilva wrote: post #6
joegaudet wrote: post #2

Having jumped back into some green field work in Scala in the past few days, I will say I'm quite impressed with the improvements to the SBT, IntelliJ, universe. Compile time seems to be improved considerably (though the project is still quite small so time will certainly tell). One problem, which is also one of the advantages of scala is that the interop with Java often means that all your Option[] etc code can stil…

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.

Re: Scala: the Case for Correctness

#14

Post by rco8786 »

rld wrote: post #12
jakozaur wrote: post #3

Scala gets a lot of things right by default. Also it got a lot of flexibility and power. Almost "a framework" to write other languages within the language. Use it every work day for over two years... Like a lot, but sometimes wishes it would be a bit simpler and more aesthetic.

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

Speaking for OP here, but yea. The simple examples are definitely simple. But in practice it can get out of hand really quick.

The type system is crazy powerful, but that also means it's crazy complex.

Re: Scala: the Case for Correctness

#16

Post by zaptheimpaler »

Another thing I like about Scala is its support for duck-typing like python, except it is actually enforced at compile time via traits and magic methods.

e.g you can define your own methods to sugar and desugar for pattern matches, define an apply method to treat a class like a function, or map() on an Option type - it simply behaves as a list of size 0 or 1 and that is all you need to map.

Re: Scala: the Case for Correctness

#17

Post by sinwave »

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

Re: Scala: the Case for Correctness

#18

Post by joegaudet »

The main issue at the end of the day is compile time. They are working hard to address this, and from the first day we started using Scala to now, it's improved dramatically - but definitely lots of room for improvement where that's concerned.

Re: Scala: the Case for Correctness

#19

Post by danellis »

zaptheimpaler wrote: post #16

Another thing I like about Scala is its support for duck-typing like python, except it is actually enforced at compile time via traits and magic methods. e.g you can define your own methods to sugar and desugar for pattern matches, define an apply method to treat a class like a function, or map() on an Option type - it simply behaves as a list of size 0 or 1 and that is all you need to map.

Apart from pattern matching, your example isn't like duck typing: it's all entirely statically typed. Scala does have structural types, which is a bit like duck typing.

Re: Scala: the Case for Correctness

#20

Post by StefanKarpinski »

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 the definition of "lexical scope": a const variable is one that is assigned only once, a non-const variable is one that may be assigned multiple times – this is a straightforward syntactic property. Is there some benefit to marking local lexical variables as constant that I'm missing?
Post reply on HN