Keeping it sharp

Posted on by

Though we’ve exchanged a few emails over the years, I’ve only met Joel Spolsky once, back in 2005, and since he was surrounded by a protective layer of adoring fanboys we didn’t get to chat much. So it was a genuine pleasure to finally spend the better part of an hour chatting with Joel, David, Jay and Alex – them in New York, me in Seattle, Skype is a wonderful thing. If you like long, rambling conversations full of obscure facts about old programming languages, you could do worse than this podcast. The link to the podcast post is here.

A few supplemental links for some of the topics we cover:

15 thoughts on “Keeping it sharp”

    • My last eight castings were successful, and then I started my new job and all my spare mental cycles have been consumed with that. Once the weather gets nicer and I’m established at work I’ll start casting again and write more about it. Thanks for the interest!

      Reply ↓

  3. Having read the monad series with interest including your comment that if you started to design a new language from scratch you would avoid the “null-reference-pattern” in favour of the option-monad, I came across this ineresting text:
    http://java.dzone.com/articles/no-more-excuses-use-null

    Reading all comments of that text, I’m really not sure any more if null references are a good and helpful concept (allowing you to find bugs in your code right on the spot) or if it would be better to hide the null reference concept alltogether (which then might lead to bad default behaviour which might be hidden instead of throwing exceptions in your face).

    I would really apprechiate more of your thoughts on this subject!

    Reply ↓

    • If Hoare hadn’t invented nulls, what should he have done instead? In any language that has an array-of-pointers (or array-of-references) type that allows elements to be read using an arbitrarily-computed indices before every element has been written, it will be in many cases impossible to statically verify that no element can be read without having been written first. Having arrays of pointers default to containing null references imposes relatively little overhead in the case where every element is explicitly written before it is read, while reasonably-effectively trapping (in languages which trap null dereferences) situations where an element which is expected to contain a valid reference does not. Having verifiably-non-null pointer types in addition to implicitly-nullable ones could be a useful addition to a language, but I don’t think a language which lacked null pointers could be as expressive as one which had them without adding more overhead to correctly-written programs.

      Reply ↓

      • Maybe I’m missing the point but my spontaneous answer would be that some kind of new language with no null references should also not allow to use arrays but use generic type of lists all over. I’m not sure what all this would mean in terms of performance, overhead, expense etc. but I tend to think that some smart engeneers could come up with acceptable results.

        If allowing arrays you might need to design the language to
        – have all arrays initialized with the NONE instance of the appripriate maybe (option) monad type or
        – have some index interceptor that returns the NONE instance in case no instance at the index was set before or
        – throw some exception?
        Seems all ugly to me so I would not allow arrays at all.

        As I said: I myself am not too sure if that would be a better solution. But I’d loe to try this out in C#. I hope that the code would get more clear and readable with all this expressiveness (besides better safety) but some tend to think that it gets too verbose.

        Maybe – as you said – having some kind of “nonnull” or “nullable” keywords added to the language could be a good compromise.

        I’m sure Eric could elaborate a new blog series on that…

        Reply ↓

Leave a comment