TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Date:
Tue, 18 Jul 2000 16:58:45 -0500
Reply-To:
Randy Brukardt <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
<01BFF0D7.A852D960@IGNITOR>
Content-Type:
text/plain; charset="iso-8859-1"
From:
Randy Brukardt <[log in to unmask]>
Parts/Attachments:
text/plain (43 lines)
> Have you run into the thing where controls defined in the RC
> file don't work right and you have to define them in the C code?

I've never seen a case where I was convinced that I was doing everything
right. (But it has happened; perhaps it wasn't just me...)

But of course I use Ada code to define controls. There is no C in Claw.
(Something about that statement looks funny! :-) Claw interfaces directly to
the Win32 interfaces.

The main reason that I and the other Claw developers go through so much pain
with Windows is so that the Ada programmer using Claw doesn't have to. As
much as possible, we "cover up" differences between Windows versions and
unusual behavior in Claw. (Which is why Claw doesn't support some of the
Windows-defined styles: experments suggest that they don't work, so we don't
include them in Claw.)

> ...
>
> However, Microsoft, to its credit, is scrupulously clear about what
> versions a given option is good for.

Although sometimes the options don't work anyway. And it is often the case
that some important details are missing in the description...

> I've had a chance to study quite a few standards in recent years,
> and even contribute in a small way to a couple, and I can't think
> of one that even comes close to the rigor of the Ada standards.
> There's way too much "then you wave your hands and the magic
> happens" and neglect of initial and final conditions.  About the
> only truly outstanding thing I've seen in a spec recently is the
> ECMA-262 math function definitions.
>
> So I think your operational definitions of "standard" and "clearly
> defined" are set too high for real-world standards.

Could be. But that seems to prove the point: the world doesn't take
standards seriously. If they did, unclear and ambiguous standards wouldn't
last long. Another area for us Ada people to do some education. (See, I can
somehow relate this to Team-Ada. :-)

                        Randy.

ATOM RSS1 RSS2