This post originated from an RSS feed registered with Ruby Buzz
by Rick DeNatale.
Original Post: Essence, Ceremony, and Deja-Vu
Feed Title: Talk Like A Duck
Feed URL: http://talklikeaduck.denhaven2.com/articles.atom
Feed Description: Musings on Ruby, Rails, and other topics by an experienced object technologist.
Stu asks us to consider whether making a Scala object an application by extending a trait, as described by the Scala article, affects the question of essence vs. ceremony. It certainly does cut down on boilerplate code.
Although this appears to be part of the standard Scala library, it is documented in such a way as to discourage its use, for the same reasons given in the article.
What strikes me is that the reasons seem to be tied up in language implementation and in particular the ways of the JVM. Perhaps this is an example of how the JVM, at leastas itis today might be a good, but not the best platform for dynamic language implementation.
Putting on my old curmudgeon’s hat, this strongly reminds me of the early days of PL/I. The earliest PL/I compilers were notoriously bad at generating efficient code for subroutine linkage. PL/I was designed for the IBM/360, which used a subroutine calling mechanism entailing chaining invocation frames in a doubly linked list rather than on a stack. The brute force way to do a call was to perform a system getmain (OS/360 for malloc) at the beginning of a subroutine, and a freemain(free) upon return. This was fairly expensive.
As a result of this, early PL/I programmers were admonished not to use subroutines/functions, or at least to use them sparingly.
This is not bad language design, it is bad implementation.
And perhaps it is just one example, or maybe there are two here, one in Scala and one in PL/I, of how well meaning decisions based on the characteristics of the implementation at hand, particularly when compounded can give us magnificent complexities, that we really don’t need.
Previous Topic
