> Grant Rettke <grettke@acm.org> wrote:
> 
> >> The two books that have made the biggest impact on me -- as one of 
> these
> >> so-called experienced programmers -- have been Meyer's OOSC2 late 
> last
> >> century,
> 
> That is the best book on object-oriented analysis, design, and
> programming that I have ever read. Ironically, that is another book
> that most OO programmers will never, ever read because "it is too
> long".

More personal reminiscences:

After reading OOSC2 in '97 I started thinking in contracts, put mainly preconditions in my Visual Basic 6 code, and saw my debugging times drop by a factor of 10. 

I adopted the method, but not the tools, and got some great gains

At my next job I tried Eiffel (SmallEiffel) and found it personally great, but had no success in evangelizing it.  I did have some success evangelizing Python as a "common scripting language", however.

I was of the view that Eiffel was ~10 years ahead of industry practice and that it was only a matter of time before its features started seeping into the mainstream.  Gratifyingly C# 4 will have some support for contracts.

However, the community had -- let us say -- certain problems.

In subsequent jobs I have gone back to my initial approach of using parts of the method and coding up my own pre-conditions and sometimes post-conditions in other languages (IME explicit invariants aren't worth it without language support).  I have now done this in VB.NET, C#, and more recently ActionScript.

As I have risen in seniority over the years and gained confidence and judgement I have been able to encourage / persuade my team-members about DBC and we have worked on blending it in various ways with test-driven development (TDD) and more recently functional integration testing (FIT).  I really need to write this stuff up ;-)

While I have assigned OOSC2 chapters for reading, I am yet to see anyone else pick up the book and read it several times as I did.

Besides contracts OOSC2 has a lot to offer in terms of understanding other aspects of OO too.

* * *

Reading SICP was relevatory in terms of code/data duality and stratified design.  I have the maths for the examples, so that was no obstacle to me.  In practice my team and I -- the younger ones have some Haskell from Uni.-- have used a bit of functional programming here and there, but more fun has been writing programs that write programs (typically Python or IronPython) as a routine trick.  By stratifying these generated programs into layers, we then do some simple program transformations.

* * *

So, my experience has been one of learning cool / advanced things and then trying to apply them with more accepted tools.  It's a nice trick if your team is smart and open to new ideas.

It's a bit like how I felt going from doing a mathematics PhD to working in industry.  A little mathematics goes a _long_ way in the commercial world.  Same with "sophisticated" programming ideas.  The trick is to apply them judiciously.


P.S. If someone can do a Scheme -> ActionScript 2 or AVM2 compiler that could be impactful in the RIA-space.  (AS2 is the language of Flex / Flash and is very similar to JavaScript.)   Similar idea to Clojure on the JVM.