4 ms·
I'll echo all of this (minus scalaz, we don't use that). I'll give an example of the power of Scala's type system. When I first convinced one of our founders
by saryant 13y ago
I'll echo all of this (minus scalaz, we don't use that).
I'll give an example of the power of Scala's type system. When I first convinced one of our founders to give Scala a try, he used it to write the first pass of our analytics service. He'd never written Scala before but once it compiled, it ran correctly on the first try, that's the power of its type system.
- taeric 13y agoNot to be too big of an ass, but this could just be the skill of your founder. Or do you believe it is impossible to have compiling code that does not do as its author intended?
- saryant 13y agoObviously it's possible to write code that compiles while still not meeting requirements. My point is that the by leveraging the type system he was able to offload a lot of those checks to compile time rather than runtime.
- lmm 13y agoIt's not impossible, but it's harder in Scala. Actually the closest comparison I could make would be Python, where I had a similar experience - as soon as my code stopped producing errors, it was doing what I wanted it to (the difference being that the errors were at runtime rather than compile time). Whereas in Java and C and even ML I've written programs that compiled correctly but did something very different from what they were meant to.
- randomdata 13y agoHaving never used Scala before, does its type system provide details about errors that other languages do not? Watching a compile fail because of an incorrect type is not something I have run into very often, if ever, in other languages that provide similar type systems. I mean mistakes can happen and if the type system can catch it for free, so to speak, that is great. I'm not about to argue that it is completely useless. But in terms of probabilities of what kind of bugs might be introduced, type errors seem to be on the low end. To infer that Scala's type system is powerful enough to catch the more common types of mistakes programmers make, that is quite an impressive claim. I am curious to know more.
- jacobgreenleaf 13y agoIn Haskell, and I assume Scala, you can name types of the same form, so I might say a TimeSeries is a list of floating point values. If I use that data type, you can't accidentally pass a different kind of list of floating points even though they're the same type.
- p4lindromica 13y agoYes, you can do this in scala with type aliases
- lmm 13y agoType aliases don't solve that problem. You need to use something like Shapeless' newtype.
- kasey_junk 13y agoType aliases do not solve this. The closest you can get is using the new value classes & those have some very big caveats
- yummyfajitas 13y agoA simple example: consider scalaz's NonEmptyList[T] class, which turns a failure to populate a list into a compile error rather than a runtime error. A more complicated example. In one scala system I worked on we had a master/slave postgres db system. We were replacing a legacy RoR system with a Scala system, and in the RoR system there were all sorts of data inconsistency errors caused by people writing to master and reading from the slaves before replication occurred. In the Scala system which replaced it, we set up a monadic action system. A function which hit the database would have a type signature either PReader[T] or PWriter[T] - this was the only way to access a java.sql.Connection short of manually calling jdbc. Combining the two forms yields a PWriter: for { _ <- putObjectToDB(args) obj <- getObjectFromDB(args) yield (render(obj)) // is a PWriter[_] The whole operation runs in a single transaction against the correct database, and any attempt to do the wrong thing is a compile error.
- 13y ago