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

41–50 of 63 posts

Re: Scala: the Case for Correctness

#41

Post by aikah »

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…

> Yes, you can go crazy with Scala, but if you are responsible

The problem is not so much the code you write but the one you have to read/use.Languages that are more rigid are often easier to work with,they are predictable,as you wont have to deal with strange apis.

I believe Java8 or Kotlin are good enough. Scala is sometimes just unreadable when you have to read other people's source code.

but maybe it's just me.

Re: Scala: the Case for Correctness

#42

Post by mzl »

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…

When it comes to helping a programmer understand code, every little bit helps. Humans are not good at parsing and keeping complex state in our minds, computers are. The less clutter I need to keep track of, the more interesting stuff about the code I can concern myself with.

As for marking local variable bindings as non-changing, I think it is tremendously helpful. In the (mostly Java) code base I work in daily we use this throughout. The net result is that I can just assume that property for everything, and whenever I see a variable not marked as non-changing I immediately know that something less than obvious is happening.

Given the above, I am naturally a big fan of making non-changing variable bindings (final/cons/val/...) the default and updatable variable bindings the case that should be marked. I would also like to work in a language where immutability of not just the variable binding but also the values themselves was better handled by the language.

Re: Scala: the Case for Correctness

#43

Post by defpan »

rld wrote: post #39
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?

Sorry, I don't want to blame any frameworks in particular. There's already too much bad blood in scala land. Let's just say there have been many instances where I had a really hard time understanding a piece of code and it turned out there was an implicit conversion hidden somewhere out of sight that was the missing piece of the puzzle, and in most instances there would have been a simpler design without implicits. Most great pieces of software, such as unix, are great not because they use very complicated concepts but because of how simple they are. Finding that simplicity is the key. Very frequently people don't see the importance of simple things like the presence of hints in code to where the related pieces are. Implicits break this flow. The number of places implicit conversions can be defined at is mind boggling. And even when some code doesn't use implicits the possibility of implicits does harm. When you don't understand some code, well who knows there may be an implicit conversion in play.

Re: Scala: the Case for Correctness

#44

Post by MichaelGG »

aikah wrote: post #41
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…

> Yes, you can go crazy with Scala, but if you are responsible The problem is not so much the code you write but the one you have to read/use.Languages that are more rigid are often easier to work with,they are predictable,as you wont have to deal with strange apis. I believe Java8 or Kotlin are good enough. Scala is sometimes just unreadable when you have to read other people's source code. but maybe it's just me.

Is it really worse than the pattern/OO folks that end up creating dozens of one-member interfaces, namespaces galore, even separate compilation units for absolutely no reason other than it feels "enterprisey"?

Re: Scala: the Case for Correctness

#45

Post by joegaudet »

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 Array.equals is a pointer compare (like how java do).

This would be obvious in Java because that would look like.

ArrayList a = ArrayList(); ArrayList b = ArrayList(); a.equals(b); // equal because it's a value compare

versus

int[] a = new int[5] int[] b = new int[5] a == b; // obviously false because it's a reference compare.

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

*edited for spelling

Re: Scala: the Case for Correctness

#46

Post by jakozaur »

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?

There are sometimes too many ways of doing the same thing.

E.g.

- syntax: def func() { and def func(): Unit = {

- collection library

Re: Scala: the Case for Correctness

#47

Post by virtualwhys »

joegaudet wrote: post #18

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.

> The main issue at the end of the day is compile time

For deployment, sure, but for daily dev the vast majority of one's time should be spent taking advantage of sbt's incremental build feature; there the compile hit is pretty neglible (particularly when you break out your application into sub projects/modules).

Even after the proposed Scala overhaul (i.e. Dotty in around 4 years time) it's unlikely that clean builds will be blazing fast.

To put in perspective, right now scalac is roughly 10X slower than javac. Scala compiler team is banking on getting a speed up by generating Java 8 closures under the hood with Scala 2.12; that will mean less code for scalac to generate.

Beyond that, trimming down language features and streamlining the type system will provide further compile time reduction. As you say, lots of room for improvement ;-)

Re: Scala: the Case for Correctness

#48

Post by hrjet »

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…

Purely from a reader's perspective, yes, an IDE can probably parse and highlight mutable variables automatically.

But from a writer's, modifier's or refactorer's perspective, what counts is the intent. Was a particular local variable meant to be mutable or immutable? Everytime I write a line of code, I need to watch out whether I mutated a variable which was not meant to be mutated. Or even the case where I myself mutate it unintentionally (by a typo, for example).

In a non-trivial project having a code-base with 100K lines of code, the time and effort spent in this manual analysis can be an overhead that might be well worth avoiding.

Re: Scala: the Case for Correctness

#49

Post by hrjet »

frowaway001 wrote: post #23
skybrian wrote: post #5

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

I am not sure what you mean by "embraces null". It sounds like a good thing (from what I know about the languages) but you have clubbed it in a list of cons.

Re: Scala: the Case for Correctness

#50

Post by maest »

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.

Look forward to dotty, then, Odersky's new project.

http://jaxenter.com/dotty-scala-without-the-backwards-compat...

Post reply on HN