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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!teaser.fr!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexander E. Kopilovich" Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: Wed, 15 Sep 2004 06:15:23 +0400 (MSD) Organization: Cuivre, Argent, Or Message-ID: References: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1095214528 16345 212.85.156.195 (15 Sep 2004 02:15:28 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Wed, 15 Sep 2004 02:15:28 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: ; from jayessay at 12 Sep 2004 12:20:24 -0400 X-Mailer: Mail/@ [v2.44 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Gateway to the comp.lang.ada Usenet newsgroup" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: g2news1.google.com comp.lang.ada:3740 Date: 2004-09-15T06:15:23+04:00 jayessay wrote: > ... I don't use much static typing anymore. It just > doesn't offer much because it is largely dependent on having all >requirements set in concrete (which they almost never are). > >Have a look at this: > >http://martinfowler.com/articles/newMethodology.html Well, personally I have no need to look at any article for acknowledging that in very many (probably majority of) software works the requirements are neither comprehensive nor stable - I know that too well. But your claim - that this is almost always so - is severe exaggeration; there are enough software works where where all requirements are (or at least presumed to be) indeed set in concrete. And Ada language was and is targetted primarily at the domains where the latter is generally true. > Personally, I think the sort of "agile" method I've been mentioning > here is in many ways analogous to developing a theory in mathematics > than what happens in "engineering". There is a lot of creative > "noodling" that goes into this buttressed by very high levels of > rigor, with a very bottom up approach where each definition, > proposition, lemma and theorem are incrementally determined and > tightly integrated. There are of course many differences, but it at > least indicates the very different mind set. I'm just wondering why do you think that this mind set can be successful in long run, when it is adopted without understanding and adoption of rigid requirements and limitations, which are associated with it in mathematics. Apart from that rather subjective notion of mind set, please note that there are two highly important aspects of the difference - *scheduled* reliability and associated immediate risks. All that widely acknowledged reliability of mathematical theories can't be achieved quickly - it is a long way for a theorem to be accepted as proved - that involves many checks by many persons and enough years to wait for a possible discovery of a hidden gap in the proof. Real-world projects these times are usually constrained by economy and competition and therefore can neither wait so much nor allow extensive public reviews. (Note, that besides of really firmly established theories, mathematics - and especially applied mathematics - has also so-called "methods", which quite often aren't reliable - sometimes they lead to a success, but in other cases they fail - and there may be no known way to predict what will happen in a particular case without trying the method... or going into specifics of the case to significant depth, and then using explicit or implicit references to previous experience. No wonder that those generally unreliable, but sometimes effective methods often can be developed much faster that solid theories.) Then, creative imagination do not face immediate real-word risks; therefore one can try to rely upon too fresh proof of some theorem (or upon too bold interpretation) and see what can be built atop of it. If your risks are low - just waste of some time, waste of some (not too much) money - then you may run as a creative programmer; but if your risks are high - immediate loss of lives, severe breach of security, strong and massive negative impact on environment, etc. - then your must run as responsible engineer, strictly limiting immediate impact of your creative imagination. And as usual, there are grey zones - where either both risks and possible gains are substantial or where taking risk in one aspect of the whole matter may significantly decrease risk associated with other aspects. Some would call this a gambling, others would call this a balancing. > Not type usefulness, most everyone agrees types are useful, even > necessary. It is _static_ typing that is of questionable usefulness > in any domain that doesn't have clear, well defined requirements > (which is to say the vast majority of cases). I think that after that rather prolonged arguing about usefulness of dynamic vs. static typing using "field performance" kind of arguments, it is time to try to describe the difference between them in some more general terms. First, for static typing, let's repeat that "Ada is for problem space". That means, that description of problem space is considered as primary strategic goal for Ada language. Static typing is natural thing for such a description - a typed variable is a natural instance of a coordinate in that space. So, the discussion is actually about whether it is generally good to strive for (precise) description of problem space. But what is an alternative? If static typing provides us means for description of problem state, then what does dynamic typing provide? I guess that dynamic typing provides description of "event space", that is, a particular stage of the whole process, on whatever level of the latter. In this sense, with dynamic typing, the variables represent a kind of local coordinates along the process's trajectory (at the process's current state). It also seems to me that there must be some duality between these two kinds of typing; perhaps the pair of universal objects from category theory - product and coproduct (which are dual to each other) - somehow relates to that comparison (where product stands for static typing, and coproduct stands for dynamic typing). Then, static typing, with its capabilities for descrpiption of whole problem state, promotes analytical approach, while dynamic typing, with its concentration on local events (on various levels), promotes synthetic approach. So, if a challenge is the most significant aspect of the job then dynamic typing may bring noticeable advantages; but from the crash investigator's viewpoint, dynamic typing is a horrible thing, and the stricter is static typing - the better: strict static typing will not eliminate crashes, but it will make investigation task much easier (note, that an investigator often must not only discover what causes the crash, but also make someone responsible). Alexander Kopilovich aek@vib.usr.pu.ru Saint-Petersburg Russia