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 Newsgroups: comp.lang.ada Subject: Re: Ada Interfaces and the Liskov Substitution Principle References: <1179953657.839272.160320@a26g2000pre.googlegroups.com> <1179991769.376381.252010@m36g2000hse.googlegroups.com> <12h6mi42jcha0.7f9vfsnihjwr$.dlg@40tude.net> <1180003336.1163.29.camel@kartoffel> <83abvs7sa9.fsf@hod.lan.m-e-leypold.de> <465aa5ba$0$23147$9b4e6d93@newsspool1.arcor-online.net> From: Markus E Leypold Organization: N/A Date: Mon, 28 May 2007 15:47:08 +0200 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:wARe4PzMKUKrQkc6YMGw4atzi9Q= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.74.52.169 X-Trace: news.arcor-ip.de 1180359481 88.74.52.169 (28 May 2007 15:38:01 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news4.google.com!proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:15953 Date: 2007-05-28T15:47:08+02:00 List-Id: > 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. But now you're arguing quite another case. You said >>> that the principles guiding program design should come from the >>> solution to a problem, not from models (But perhaps I'm reading even that quote wrongly). You've been basically advocating to invent new program architectures for every problem/solution pair, i.e. have a solution first than fit the "model" (language architecture, whatever) on your solution. If you can afford to design a domain language for every problem you have -- fine. If not, I suggest that the language designers hae Basically the language design is a contract: If you can fit your programming in a certain conceptual pattern (be it typing, OO or functional programming) the compiler builder promises that the compiler will produce a correct and (often) fast or efficient program with the advertised semantics. If you don't want that contract, I don't know what you get. Probably C, but even that has a "model" of sorts. Or SAP ... Bashing theory and inisiting on "fudged" ad hoc solutions ("it just works, so why not" has brought programming to the place where it is today: A mess. "If you do this you will get that, but we don't know why that is so and how that fits in with the rest which follows a different perhaps not even contradicting rule". I repeat, that I'm a strong believer in complete, consistent and "closed" solutions in programming language or system design without "undefined" borderline cases. Only such a design guarantees that you know where you stand, are prepared for the next step in evolution and can take it without breaking everything from the past. Regards -- Markus