Runar Bjarnason writes about functional programming, type systems and Scala, with posts on Java, Haskell-style iteratees and type theory.
HN commenters link his post that the Liskov Substitution Principle is contravariance, and his structural pattern matching in Java as a pattern for avoiding isinstance checks.
So, Java's HashMap.get() should throw a checked exception whenever the value is not found in the map? That would sure eliminate a lot of boilerplate code :)
Aren't exceptions meant to be used for, well, exceptional cases only, i.e. when no matter what, execution really can't be continued? It makes sense for a lot of functions to return some sort of "Nothing" value instead of raising an exception, but the problem is that in many languages there is no explicit "Nothing" value, so people just abuse null.
You can have Maybe in Java too, but getting out a value or a Nothing out of a Maybe value is just not enforced by the compiler due to the lack of algebraic data types and pattern matching; still, it is an improvement over null hell. On a side note, Maybe is called Option in Scala.
By the way, exceptions are monads, they are just predefined in most languages in a way you can not change. If you want a lengthy Java centric read about that I would strongly recommend checking out [1]. Ant here's another if you're ok with reading Haskell [2].
Also for the record, in Haskell you can use the ErrorMonad in place of the Maybe monad if you want precise error reporting capabilities.
[1] http://apocalisp.wordpress.com/2008/05/16/thrower-functor
[2] http://www.haskell.org/haskellwiki/Exception
When I get a compiler error in Scala it's almost always something that would cause a runtime error in a non statically typed language. The downside is that the error messages can be difficult to parse and resolve for beginners. Once I got over the learning curve, I realized that in almost all cases the compiler was trying to tell me something very useful. I do get a little annoyed at all the Haskell/OCaml type nerds trying to do things with the type system that are not particularly practical, for instance: http://apocalisp.wordpress.com/2010/06/16/type-level-programming-in-scala-part-4a-peano-number-basics/
That is not a simple type. And people who still remember the original Pascal will know that you do not want to encourage people to make the size part of the collection type. And it doesn't buy you much if you cannot prove at compile time that the type you use to index into the collecton cannot overflow the collection bounds. Use Ada if you need that.
But if you want you can also encode the sizes in binary or decimal numbers:
http://apocalisp.wordpress.com/2010/06/24/type-level-programming-in-scala-part-5a-binary-numbers/ http://www.ict.kth.se/forsyde/files/tutorial/apas03.html
Well, Scala has advantages and disadvantages over Haskell, but I wouldn't say it is more "powerful" than Haskell.
Consider the implementation of a properly lazy "const" function in Haskell:
const x _ = x
And in Scala:
http://apocalisp.wordpress.com/2010/04/21/a-proper-constant-function-in-scala/
Not sure about Coq, but Agda is Turing Complete (you just need to turn off termination checks) and Epigram also supports general recursion as well as structural recursion with total functions.
This may be a useful pattern to you. The example is in Java but you should be able to achieve the same in Python https://apocalisp.wordpress.com/2009/08/21/structural-pattern-matching-in-java/.
It’ll get rid of the ‘isinstance’ and give exhaustive matching. I used to use this pattern a lot when wanting ADT’s in a language without ADT’’s.
apparently LSP is just a contravariant functor https://apocalisp.wordpress.com/2010/10/06/liskov-substitution-principle-is-contravariance/
But I don't see how the relationship of contravariant functors to OO-style subclasses is as clear as the DI <-> function abstraction example (functions are just functions in OO or FP)