Eppur si sugat

Bengt Kleberg eleberg@REDACTED
Tue May 27 13:44:05 CEST 2003


(when i find myself disagreeing with someone that is obviously much
more intelligent and experienced than i am, i really try to understand
where i am going wrong. perhaps i will get my mistake if i try to
explain how i read oosc)



> X-Authentication-Warning: enfield.sics.se: joe owned process doing -bs
> Date: Tue, 27 May 2003 13:06:57 +0200 (CEST)
> From: Joe Armstrong <joe@REDACTED>

...deleted
 
>   Since I have the book in question in my bookshelves I thought I'd check ...
> 
>   Part I - is "Issues and principles" 
>   Part II - is "Techniques of OO design and programming"
> 
>   Part I is general, Part II is stuffed full of Eiffel
> 
>   Part I is full of rather general statements about good ways to program.
> 
>   Lot's of general statements like:

...deleted

>   Part II - *is* Eiffel. The book  reeks Eiffel - Part II shows how to
> achieve the goals in part I (nothing wrong with that) - But since I is
> so  general then  part  II could  equally  well have  been written  in
> Erlang/C/anything - the goal being  to show how good design principles
> (like  minimal  interfaces,  ADTs  etc)  can  be  implemented  in  any
> language.

i read oosc part 2 as an attempt to _find_ ''the best possible''
design/notation to achieve the goals in part I. i think it is clearly
stated that while any turing complete language would do, it is the
intention that this way of designing should be ''the best possible''.

there is a book, ''objects unencapsulated'' that explains where oosc
goes wrong, so ''the best possible'' definitly needs the quoutes.


>  I would not call this a "oo book without language" and I think Meyer's
> title is misleading.

it was i that called oosc "oo book without language". and i really
think the title is good. i parse it like this
((OO software)construction). meaning that he is constructing a 
oo software system/language/notation. see below.

>  It's not about OO software construction. It's more
> 
>  "generally good design principles" + how to code things in Eiffel.

i experience the book as an example of
1 stating good ideas (part 1).
2 trying to achive these good ideas (part 2).

where i beg to differ from joe is that i do not find that the good
ideas are implemented straight off in eiffel (part 2).

instead i read part 2 as a attempt to formulate various ways of
achiving these good ideas. most ways are rejected as not beeing good
enough. the ideas that are kept are then formalised into a notation, a
oo language. when the book is done, the total amount of formalised ideas
''happens'' to amount to a language, eiffel.


bengt, who have this sinking feeling that he has been brainwashed by a very 
persuasive author and fails to get his thought processes back on line...




More information about the erlang-questions mailing list