From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,2ff5c149712ec0eb
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!news.germany.com!newsfeed.utanet.at!newsfeed01.chello.at!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 28 May 2007 11:52:22 +0200
From: Georg Bauhaus <bauhaus.rm.tsoh@maps.futureapps.de>
Organization: #
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Ada Interfaces and the Liskov Substitution Principle
References: <Pine.LNX.4.64.0705232101220.20072@th.informatik.uni-mannheim.de>
 <1179953657.839272.160320@a26g2000pre.googlegroups.com>
 <f32d9o$fi9$1@jacob-sparre.dk>
 <1179991769.376381.252010@m36g2000hse.googlegroups.com>
 <12h6mi42jcha0.7f9vfsnihjwr$.dlg@40tude.net>
 <1180003336.1163.29.camel@kartoffel> <83abvs7sa9.fsf@hod.lan.m-e-leypold.de>
In-Reply-To: <83abvs7sa9.fsf@hod.lan.m-e-leypold.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <465aa5ba$0$23147$9b4e6d93@newsspool1.arcor-online.net>
NNTP-Posting-Date: 28 May 2007 11:49:46 CEST
NNTP-Posting-Host: ff30b5fd.newsspool1.arcor-online.net
X-Trace: 
 DXC=W@B:C\[PVMPPU8j_I0DN6_ic==]BZ:af^4Fo<]lROoRQFl8W>\BH3YRDS4AhY:H>IWA:ho7QcPOVSJhS=HSLFa=_I4?iVN_<b2P
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:15949
Date: 2007-05-28T11:49:46+02:00
List-Id: <comp.lang.ada>

Markus E Leypold wrote:
>  the Eiffel arguments versus Liskov/Wing
>> are that the principles guiding program design should come
>> from the solution to a problem, not from models when these
>> cannot capture the solution. In a sense, it is argued that
>> that L/W substitution (and also co/contra-variance) violate
>> programming principles!
> 
> Actually I'm a strong disbeliever in your approach. I doubt, that a
> solution that isn't mathematically beautiful and simple (i.e. fits a
> model) is viable in the long run. Intellectual friction will hampoer
> maintenance and optimization.

There is nothing wrong with a mathematically "beautiful"
and simple solution. But when

(1) there is a perfectly simple, straight forward, working
    solution,

(2) the solution matches the problem specification 1:1,

(3) the solution is partially incongruent with a mathematical
    model,

(4) because of (3), the solution (1)+(2) is discarded,

there is something wrong. First, because a belief in the model as
a conditio sine qua non is not justifiable, neither on
business terms, nor on technical terms (both because of (1)+(2)).
Second, while the existing solution suggests that there might be
a better model still the other model is preferred, and the existing
solution runs the risk of being discarded.

I bet that as soon as someone popularizes a mathematical model
that does away with variance issues for example, then people will
stop fighting over contravariance versus covariance.
Until then, only this or that kind of variance is allowed to exist,
for either mathematical or problem domain reasons, because the
other solution cannot but create an unmaintainable mess...

If I had the money, I'd put up a challange that triggers some
programming oriented model research (as opposed to research that
will move the focus of modelling to formal properties of models
only.)