The Lurker

On abstraction

In reading the usual blogs tonight I've just across a few insightful (and some infuriating) thoughts:

• Rich Skrenta – tie considered harmful (on overloading in Perl):

  I don't think the syntactic sugar win for the notiational convienence trumps the potential confusion to those who will view the code later, or even the confusingly overloaded semantics for the original programmer. I'd rather just know that %foo is an in-memory perl hash, and if I'm going to stuff something in a berkeley-db it's going to be with an explicit API.

• Wil Shipley – Be inflexible!:

  You are attempting to predict how your application's needs will change in the future, and spending time NOW on your guess, instead of shipping the damn application, getting feedback, and THEN making changes.

• Mark Baker – Forest, trees:

  So if you're writing (or generating) contract/interface-level code which can't late-bind to all resources, everywhere, you're not doing REST

• Patrick Mueller – not doing REST (replying to Mark Baker, above):

  What is the the alternative to describing your services?

  How is anyone going to write code to use these services, if they don't know where to send requests, what verbs to use, what data to send, and what kind of data to expect? Instead of Flickr producing a description of their web services like this, they're simply supposed to say "Flickr is now fully REST-enabled. Start here, and have fun!" ??

Related topics: Web Mindless Link Propagation