Re: Ada 2005?

[jayessay <nospam@foo.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 22 Dec 2004 13:02:26 -0500, jayessay wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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