-
Website
http://skydeck.com/blog -
Original page
http://skydeck.com/blog/programming/ocaml-for-the-recovering-java-programmer-part-1-objects-and-subtyping -
Subscribe
All Comments -
Community
-
Top Commenters
-
Kenny Lee
1 comment · 1 points
-
Gustaf Alstromer
1 comment · 1 points
-
Jason Devitt
28 comments · 1 points
-
DupliMark
1 comment · 1 points
-
Metro PCS
2 comments · 1 points
-
-
Popular Threads
-
BlackBerry OS 5.0 and the Storm
3 weeks ago · 2 comments
-
BlackBerry OS 5.0 and the Storm
This proves that hedgehogs are more intelligent than rabbits. So I'd say, Java is a rabbit ;-). And Ruby is a hedgehog ;-)
As someone who is learning ocaml after learning imperative programming (mostly in Java), I am still not really comfortable with the idea of duck typing in a statically typed language, but the idea is growing on me, and this article helped with that.
But this is pretty bad -- I can think of plenty of animals that have legs, but which are NOT pets, and therefore, should NEVER appear in a list of pets. Yet, by this article's contents, it is not possible to enforce this constraint with OCaml's static type system.
Haskell's typeclasses are explicitly defined, and therefore, gives the programmer a much finer grain of control over what people can do, or perhaps more importantly, cannot do, with their types.
(I wasn't sure how this thing would treat angle brackets.)
libraries to do various things,
But take a look at microsoft's F# --
Recently, F# became a first-class citizen
of the .NET
family of langugages. F# compiles ocaml, and provides access to ALL of the .NET
libraries making it powerful. With full
Visual Studio integration and scriping capabilities, there is nothing stopping it.
Of course now that we have generics in Java, we can write your identity function with the proper return type, albeit with way cruftier syntax.
Samuel, what you describe is a like the classic, "Cowboy.draw() vs. Image.draw()" argument in the OO world. In my opinion, structural subtyping promotes unintended reuse. In a real program, the type of the draw() method, at least in a functional setting, should make it clear in which contexts it should and should not be used. I think that using this argument against structural subtyping is a little like arguing against first-class functions, on the basis that two functions with the same signature are not necessarily substitutable.