DISQUS

Skydeck Blog: OCaml for the recovering Java programmer, part 1: objects and subtyping

  • Michael Neumann · 2 years ago
    There is a german (?) story for children about rabbits and hedgehogs. They make a foot race. Of course the rabbit thinks he will win, because he can run faster. But the hedgehog is actually more intelligent, because his woman-hedgehog waits at the goal, and as the rabbit cannot distinguish her from her husband, the rabbit thinks that the hedgehog has won the race.

    This proves that hedgehogs are more intelligent than rabbits. So I'd say, Java is a rabbit ;-). And Ruby is a hedgehog ;-)
  • Paul Butler · 2 years ago
    Good article.

    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.
  • Samuel A. Falvo II · 2 years ago
    This article actually only confuses me further. Although I'm not coding in OCaml, I do code in Haskell, and I fail utterly to see the value of duck typing. In a sense, the closest I can think of is that it is "automatically generated type classes."

    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.
  • Ivan Jager · 2 years ago
    It may be worth mentioning the subclass syntax. Rather than saying you could instead say #pet . This is especially useful when you have more complicated classes.
  • Ivan Jager · 2 years ago
    That should be, "Rather than saying <legs:int; ..> you could instead say #pet."

    (I wasn't sure how this thing would treat angle brackets.)
  • steve · 1 year ago
    The main problem with Ocaml is the lack of
    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.
  • Nels Beckman · 9 months ago
    Interesting! I am fascinated by the co-variance/contra-variance declarations.

    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.