Recommendations, Reviews

An interesting article on Gopher

Six Apart has a great interview with Paul Lindner one of the creators of Gopher. It is an interesting exploration into Internet history. I also like the “we’re Hiring” plug at the end. Working with interesting and talented people is always a plus. It you are into software development check out the “worse is better” link, it’s an article by Richard Gabriel titled The Rise of “Worse is Better”.

So check it out it’s all worth reading.

Links Summary:
Six Apart interview with Paul Lindner

The Rise of “Worse is Better” by Richard Gabriel

One thought on “An interesting article on Gopher”

  1. I have a major problem with the article ‘The Rise of “Worse is Better’.’’

    An abstraction, the interface, should be a simplification of the underlying implementation. Any domain language should compile down to primitives in the underlying language that are much more complex than what is said in the domain language. Take Ruby on Rails as an example. Where would Rails fall in the article that you point to?

    I think that the author has mixed a lot of ideas and dismissed elegance too easily. Unix isn’t an example of Jersey design. Unix follows a very simple interface where everything is a file and everything is tied together through pipes. This is no different that the Lisp/Scheme philosophy. I’m thinking that the only failing is with the author and his ability to see the similarities in what he sees as two unrelated, though similar, schools of design.. It’s not a matter of being too difficult or to perfect. It’s a matter of discipline.

    I do agree that in the beginning you don’t try to be perfect given that you don’t know what perfect is. Once you do though, anything short is a sign of either laziness or a lack of insight to the problem that you’re solving.

    Once you understand a problem the interface, or abstraction, breaks into two parts:

    1. the vocabulary of the problem
    2. the interface for describing problems in the problem vocabulary

    Once you understand the problem in that way there is no excuse for the interface not to be simple. If it’s not simple, you haven’t properly defined your problem.

Comments are closed.