1. 2
  1.  

  2. 2

    A great article. When I think about my complaints with various abstractions, I find usually my complaint is that the abstraction hides “surprising” behavior. This is very subjective, but for example let’s say I write:

    Person p = getPerson()
    print p.name
    

    Only to find that p.name throws an exception because .name is actually calling artbitrary complicatepod code and apparently doing network I/O to a relational database.

    So what’s missing? I feel like haskell gets some of this right, you have to annotate types with extra info, the author talks about this in terms of filesystems and timeouts and metaobject protocols and I really think he/she is onto something.

    I’d be much more comfortable with abstractions if they also encoded the possibility of failure. Bonus points if computational complexity is thrown in. I think haskellers get this with their pure functions and IO monad.

    A good example of an abstraction might be a key/value store that is in memory, on disk, or backed by the network.

    interface Map {
    Get(lkey string) string
    }
    

    Might not capture everything I want to know when working with this type, but something like:

    interface Map{
    Get(key string) CancelableIOResult<string>
    }
    

    Might be better. I’m not against the simpler abstraction in all cases, but it seems like when you’re trying to write unsurpising robust code you have to peek a little further and work in terms of the more cumbersome abstraction. A language that made switching between the 2 could be nice.

    1. 1

      So you like Java’s checked exceptions?

      Most people seem to consider them a failure, because programmers swallow exceptions instead of handling them properly. Maybe an optional checker tool would be a better idea than compiler errors?

      1. 1

        I like Java’s checked exceptions more than unchecked ones. I prefer explicit returned errors over both. I do wish that it inferred them instead of requiring explicit annotations.

        1. 2

          I guess by “explicit returned errors” you think about something like Maybe/Option (Haskell, Rust), but not error numbers (C). The good thing is that the type system enforces checking. The problem in C is that returned errors are usually ignored.

          My problem with Maybe/Option is the runtime overhead compared to (zero-cost!) exceptions.

        2. 1

          Actually yes, they’ve grown on me. I used to hate them until I had to implement robust filesystem related Python code and literally anything I did could fail in unknown ways. I have to cross my fingers that someone properly documented all the possible exception types.

      2. 1

        This article should have gotten more votes, it was great