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=unavailable autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!217.188.199.168.MISMATCH!takemy.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sat, 06 Apr 2013 20:43:32 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Usefulness of OOP (was Is this expected behavior or not)
References: <c988e09f-8532-4840-9749-b61aa39551b4@googlegroups.com>
 <kiqkqk$9u7$1@munin.nbi.dk> <1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net>
 <kit43q$mj1$1@munin.nbi.dk> <wdlyfbnwcnp7.10c9btwjmpm7j.dlg@40tude.net>
 <kivi42$hmu$1@munin.nbi.dk> <cqf0yy6q930$.1sdzw45bc0c1w.dlg@40tude.net>
 <kj2e90$9iu$1@munin.nbi.dk> <byacn0wck9qt$.norrlukaw80l$.dlg@40tude.net>
 <kj5cqn$8q7$1@munin.nbi.dk> <1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net>
 <kjd9ec$6lr$1@munin.nbi.dk> <3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net>
 <kjfk1t$38n$1@munin.nbi.dk> <1gkxiwepaxvtt$.u3ly33rbwthf.dlg@40tude.net>
 <kjig2j$nof$1@munin.nbi.dk> <1fmcdkj58brky.bjedt0pr39cd$.dlg@40tude.net>
 <kjknuu$gc8$1@munin.nbi.dk> <1bj564vat3q1j$.1s4d00rlzx4ux$.dlg@40tude.net>
 <kjnt9t$ia$1@munin.nbi.dk> <kjob6i$ctp$1@dont-email.me>
 <1qp6hk0v8ztvb$.1c0usjaywidmx.dlg@40tude.net>
In-Reply-To: <1qp6hk0v8ztvb$.1c0usjaywidmx.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <51606cd5$0$6574$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 06 Apr 2013 20:43:33 CEST
NNTP-Posting-Host: c4d7331d.newsspool3.arcor-online.net
X-Trace: DXC=Z_61Y[`H_EMAa;
 :RKVJ>LEMcF=Q^Z^V3H4Fo<]lROoRA8kF<OcfhCOK=1C`OE2TQ9EPCY\c7>ejVH0Wm; _G;
 AYBJoiZb5DTiAmC
X-Complaints-To: usenet-abuse@arcor.de
X-Original-Bytes: 3129
Xref: number.nntp.dca.giganews.com comp.lang.ada:180962
Date: 2013-04-06T20:43:33+02:00
List-Id: <comp.lang.ada>

On 06.04.13 12:31, Dmitry A. Kazakov wrote:
> Both [procedural decomposition and OO] greatly hinder re-use and
>  fail to adapt to the reality of ever changing requirements.


Requirements do change. Change is always managed in some way. What if
we knew well how methods and languages influence the cost and outcome
of change management? I mean formally, more scientifically. We do know
about time spent on adapting software to changing requirements. This
means we know the cost. But do we know why this or that change has
cost more or less? I mean, formally, so that some theory could lead
the way to better methods, and to better languages.

A science of successful reactions to change, in terms of methods of
programming, would seem to be a bigger project for academics
co-operating with industry. Is it on anyone's radar? I speculate that
proprietary building blocks for software are moving ahead, without
feedback arriving in language design.  (I hope I am wrong.)

A possible idea that I admit is foggy: Is there something in GoF
patterns worth of making them new primitives of formal expression?