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,131f06967722ab4b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!newsread.com!newsprint.newsread.com!in.100proofnews.com!in.100proofnews.com!border2.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.rcn.net!news.rcn.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 23 Dec 2004 11:42:39 -0600 Sender: jsa@rigel.goldenthreadtech.com Newsgroups: comp.lang.ada Subject: Re: Ada 2005? References: <1103344064.372396.51420@c13g2000cwb.googlegroups.com> <1n1v6175zrtcc.2g6ewdvu7ei5$.dlg@40tude.net> <1103568585.285484.237450@c13g2000cwb.googlegroups.com> <20xbhf8rjd33.t7dojmf0ky12.dlg@40tude.net> <1nl7gq6tozeyw.146x7at50m0lr.dlg@40tude.net> <1vj2pp9437gal.1b1lyqe3o973k$.dlg@40tude.net> <1ttqv5msigzua$.12l6jurw2zmd6$.dlg@40tude.net> From: jayessay Organization: Tangible Date: 23 Dec 2004 13:09:34 -0500 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 209.6.25.79 X-Trace: sv3-A88WKh9z39FMU/6q78jYRodjK9Uk/GbzERKx0z4q7wraeutL8pjp8sbfIAX1UrwaPlGrUEzybJyfNjS!j65BzAJn8mSQAnjIqtf26ctzjbRSP0RvZTpMgfzit7lQfdUt4F5Fg7CujVyMXqDJ6VJsxD0QWVec X-Complaints-To: abuse@rcn.net X-DMCA-Complaints-To: abuse@rcn.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.22 Xref: g2news1.google.com comp.lang.ada:7195 Date: 2004-12-23T13:09:34-05:00 List-Id: "Dmitry A. Kazakov" writes: > On 22 Dec 2004 13:02:26 -0500, jayessay wrote: > > > "Dmitry A. Kazakov" writes: > > > >>>> I doubt that CLOS seriously approaches the problem. > >>> > >>> That's an odd statement, and it is just uninformed opinion which > >>> happens to be factually incorrect. > >> > >> Maybe > > > > There is no "maybe" about it. You clearly have not studied this and > > therefore any comment you make on it is indeed uninformed opinion. > > > >> , but the very first page introduces "no-applicable-method". It is a > >> non-starter for me. In my view the goal of safe MD design is to make > >> dispatch failures impossible (checked at compile time). > > > > For true MD, that requires solving the halting problem in any Turing > > complete setting. > > What about any proof? One Hint: I/O. There are many others. > [ Hint: Ada is statically typed, freezing rules do > not allow dynamic declaration of primitive operations. ] Irrelevant to the above point. However, these rules really have nothing to do with restricting "dynamic declarations" (Ada is static and so of course there are no dynamic declarations at all). The rules are about where the representation of the entity is frozen and can no longer be added to even statically. One consequence of these rules is that they remove a lot of the potential good from the separation of name space and class constructs. > > Good luck on your hopeless quest. OTOH, if you > > restrict things enough, what you are talking about is simply > > overloading. Ada already has that. > > There is no way to restrict dynamic dispatch to make overloading of it. > Care to elaborate? "things" /= DD > >> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time > >> exceptions. It is tolerable because there was no better way, and > >> only as an intermediate state to be replaced by a "right" MD in the > >> future. > > > > First, raising runtime exceptions is not only reasonable, it is the > > only thing possible in non trivial situations. > > Again, the goal of proper design is to have no such situations. Then you should not have dynamic dispatch at all. Actually, that is a defensible position - at least for some class of problems. > Dispatch tables are finite in presence of finite number of types and > finite number of actual parameters. It is quite trivial to check > that all cells in each table are defined. That's completely irrelevant to the problem. The issue is whether any given actual call will find a match in the table. The tables are trivial, it is the flow analysis that is (in the general case) impossible. > > Second, Ada has no MD. That is a fact. > > MD = "more to have than one dispatching parameter". > > So clearly, Ada has MD. Ah, so you define it away. MD = "Multiple Dispatch" in the orignal context of this thread which is /= more than one dispatching parameter. This should be obvious. Ada does not have MD, to argue otherwise just makes you look silly. > To have any meta language is a wrong idea anyway. MOP is not a meta language, it is a meta _protocol_ for object models. The only extent example (that I am aware of) is CLOS, but there could be others. OTOH, I'm not sure why a "meta language" is somehow an intrinsically "wrong idea". There are several very important areas where such things are not only the right idea, but provide the _only_ way to do something. If you were more open minded and less dogmatic in outlook, you would have a much better chance of learning and understanding the value of many things not matching your preconceived notions. > Either generics or parameter pattern matching, anything like that > just indicates language infancy. What has this to do with a "meta language"? And what in the world is "language infancy"? > Non-trivial problem is one for which a particular person knows no solution. > Once solved it becomes trivial. This is clearly (even trivially) incorrect. First, whether a particular person knows a solution or not is totally irrelevant to whether a problem is difficult, easy, trivial, non trivial, etc. This should be obvious (as such qualifiers are pretty much defined by how many people can work the problem and how much effort it takes to work it.) Second, there are plenty of solved problems that are highly non trivial in nature. And, of course, there are (literally) countless problems that are trivial to solve. > > I've seen situations where this claim is completely at odds with > > reality. Hence, your position would remove expressivity and force > > programmers into pounding square pegs into round holes. > > Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate are > made of hard steel. So the programmer will spend a lot of time pounding on. > This has an important educational effect. Maybe next time [s]he will think > first. I don't think this is "Ada's way". I sure hope it isn't because it is the dumbest thing anyone could advocate. The "education" any intelligent person would get from this would be, "this language is an extremely poor means for expressing elegant correct solutions." That's pretty damning. > > What you call "playing with fire", is simply another tool, with a well > > defined and specified protocol. Can it be abused? Yes. Does it > > require someone above average to use it properly? Most likely. Can > > it be exactly the right thing for an elegant solution to a thorny > > problem? Yes. > > Bottom line: > *rejected* Bottom line: You will not be able to solve a large class of (non trivial) problems as they will require far too much work to find a means to express their solution. In theory (of course) they could be worked, but in practice they won't. Which is fine. There are plenty of mundane problems that need simple perfunctory solutions. > > Being a denizen of cla I realize you are probably a B&D software > > development proponent, and I suppose in certain contexts (mediocre > > programmers, large beauracracies) your sentiment here makes sense. > > But in general it is a bad idea which at best tends to produce what I > > like to term "superior mediocrity" (which, to be fair, often wins big > > in the "marketplace"). > > You have to understand a very simple thing. You cannot get excellent > programmers for each project. They are precious goods. They make errors > too. specially if the language requires permanent attention and high > concentration to each typed character. So you cannot rely on excellence in > mass production. You should do on technology. And technology is the > language. Superior mediocrity? Yes, sure. What a sad attitude. And not even correct, if given a more enlightened position. Hints: 1. The number and severity of errors and bad solutions are in direct relation to how far the language used in expressing the "solutions" is from the language of the problem domain. 2. libraries/class systems are not languages. 3. domain specific languages are very close to the problem space. 4. Use your "precious goods" to work on the "right" level of the problem. 5. Enjoy how much happier you (and your customers) are with your mediocre people. /Jon -- 'j' - a n t h o n y at romeo/charley/november com