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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,75a8a3664688f227 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-13 09:40:57 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!news.iac.net!news-out.cwix.com!newsfeed.cwix.com!cpk-news-hub1.bbnplanet.com!news.gtei.net!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: dmitry6243@my-deja.com Newsgroups: comp.lang.ada Subject: Re: Parameter Modes, In In Out and Out Date: Sat, 13 Jan 2001 17:29:35 GMT Organization: Deja.com Message-ID: <93q39q$oq0$1@nnrp1.deja.com> References: <7Cx56.90736$A06.3322588@news1.frmt1.sfba.home.com> <937jab$s23$1@nnrp1.deja.com> <3A57CD7F.2228BFD5@brighton.ac.uk> <938p3u$omv$1@nnrp1.deja.com> <93cagm$c1j$1@nnrp1.deja.com> <93e4e6$ucg$1@nnrp1.deja.com> <93encq$brm$1@nnrp1.deja.com> <93f6ar$m44$1@nnrp1.deja.com> <93flab$2mh$1@nnrp1.deja.com> <93fqau$6m2$1@nnrp1.deja.com> <93h9mo$bbm$1@nnrp1.deja.com> <93il87$iqo$1@nnrp1.deja.com> <93k6dv$qt6$1@nnrp1.deja.com> <93ko49$auq$1@nnrp1.deja.com> <93modu$36k$1@nnrp1.deja.com> <93n2co$alq$1@nnrp1.deja.com> NNTP-Posting-Host: 212.197.152.24 X-Article-Creation-Date: Sat Jan 13 17:29:35 2001 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt) X-Http-Proxy: 1.1 x64.deja.com:80 (Squid/1.1.22) for client 212.197.152.24 X-MyDeja-Info: XMYDJUIDdmitry6243 Xref: supernews.google.com comp.lang.ada:3989 Date: 2001-01-13T17:29:35+00:00 List-Id: In article <93n2co$alq$1@nnrp1.deja.com>, Robert Dewar wrote: > In article <93modu$36k$1@nnrp1.deja.com>, > dmitry6243@my-deja.com wrote: > In the days of the PDP-11, the remarkable thing was that people > could write small programs that had impressive functionality. Yes, EDT (and later LSE) is the best text editor of all times. > For example, Unix was a very small fraction of the size of > mainframe OS's. That time Unix was considered as a large, ugly, slow and unstable OS compared to RSX-11M. > In any case, if you want to talk about typical sizes of large > programs, you look at mainframes THEN, and NOW you can look > at ordinary PC's, since PC's have plenty of memory these days. Let's be scientific (:-)) and build a histogram: number of computers over the model price. The mediane of such histogram in 1985 will correspond to the computers comparable with PDP-11. Today it is a PC. Now take a "simple" program: a text processor. In 1985 for PDP-11 it was EDT + ROFF (only a fanatic would use a Unix on PDP-11 (:-)). Size ~50K. Now turn to PC and, well, what about MS-Word? (:-)) > > This is not a scientific issue. It is about > > feeling and belief. > > If science to you is strictly restricted to things that can > be objectively measured (not all scientists would accept this > limitation (*)) then that's absolutely right. But it is > probably more accurate to replace "feeling and belief" with > expert judgment (going back to my earlier analogy, the > excellence of certain paintings is a little more than just > some individuals feeling and belief, it is the result of a > consensus of expert judgment). Yes, a consensus of expert's feelings (:-)). [ Actually this is a good criterion to decide whether something is a science. Scientific issues are not subject of voting. ] > If I find that my opinion is not shared > by anyone else then I conclude that either > > a) I am arguing my case incompetently > b) I am wrong > > I never end up being the 1 in an N-1 vote on language design > issues, since neither a) nor b) justifies such a position. Robert, you are too merciless to yourself. Even in such pure sciences as mathematcs there is no consensus. Especially if it is about fundamental issues like set theory. I think you would argree that the issues of acceptance of MD and MI are fundamental for programing. > > But it is not enough for me to change my feeling > > that MD will be universally adopted in the near future > > But an individual "feeling" is not very convincing if it is > not backed up by good arguments, especially when you are in > a small technical minority. Absolutely. > So far, you really have not presented any arguments. First, we have not yet decided what is argued. Is is about MD in general? Is it about Ada extension, or an intrusive Ada redesign? Second, MD is extremely obscure. Alone the question whether this obscurity an inherent property of MD, or we simply do not understand something, is a good theme for a plethora of PhD works. You surely do not think that I am able to produce a complete proposal, how to incorporate MD in Ada (:-)). > I do NOT accept the "PL/1 style" argument that says "never mind, if > you don't want to use this feature, you don't have to, so it can't > harm you". I am with you here (I did my MS work in PL/1). Though it was PL/1 that opened exceptions and overloading to me. Interesting is that from the height of our current knowledge they were purely implemented. > To make your case, why not do the following > > a) propose, in rough form, no need to tie up the details > an MD addition to Ada > > b) show one example where this MD addition really adds > to expressive power. > > I think that's a reasonable request, the burden of proof is > definitely on your side for adding new features. What is > interesting then is to contrast the best possible solution > without MD to the example you show. I agree with you. But this is a good way for relatively small, well defined and "indestructive" proposals. Like "should we have fixed numeric types of e-radix?" (:-)) In contrary to this, the MD issue can potentially affect all parts of the language, which is not the smallest one. It is more like, someone says 'It would be nice to fly to stars', another answers 'well, give us the blueprints of the starship'. Technically the later one is correct. But he should be prepared to reconsider the idea time to time (:-)). > Also, a casual approach to considering the semantics often > covers up complex details. For example, in the case of > multiple inheritance, the mess we get into when we have > common base classes. "Mess" is not an argument, if I dare quote you (:-)). Common bases could be made distinguishable by an explicit inheritance path specification and enforcing naming of the immediate bases (like names of subroutine parameters). Converting to a class-wide should be parametrized by the path. For overriding there are many options to consider. It seems that all could be statically checked. C++ makes MI unsatisfactory, but still reasonable. [ no, this is not a proposal (:-)) ] -- Regards, Dmitry Kazakov Sent via Deja.com http://www.deja.com/