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
Mime-Version:
1.0
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
Keith Shillington <[log in to unmask]>
Date:
Mon, 23 Nov 1998 12:49:33 -0800
In-Reply-To:
Content-Type:
text/plain; charset="us-ascii"
Reply-To:
Keith Shillington <[log in to unmask]>
Parts/Attachments:
text/plain (124 lines)
To accede to your request, I'll answer the broader discussion with a stronger
statement.  (And I'll add lot's of <cr>s for brain-dead-mailers)

Syntax is mostly irrelevant.

Well-built Object paradigm software cannot be intelligently viewed at the
source level.  A graphical representation of the design is required.

Just as I would no longer attempt to debug a Unix kernel with a voltmeter
and a red LED; we must take the step to understand that the human readable
textual source of computer software is too deep in the minutia to understand
an object model of more than exemplary complexity.  This is merely another
step in a long process of abstraction.

We began to program computers by specifying multiple steps for calculating
logarithms (Lovelace in 1835 onward).  Hollerith and Jacquard devised methods
for recording these steps in binary format.  We took a step backward and programmed
machines by punching holes in cards, or flipping chrome-plated switches (Eniac).
Autocoder and assembly brought forward a mnemonic representation of the binary
coding.  ForTran, CoBOL, RPG, Basic, Algol and hundreds of other "languages"
raised the bits to mnemonic ratio.  As the languages have evolved, the bits
to representation ratio continues to increase.  When computer software fit
comfortably within the 56K/64K limitations imposed by various architectures;
we were mostly happy to express the software in mixed combinations of wire-strapped
binary, assembly and various simple languages such as Pascal, or K&R C.  Memory
got bigger and cheaper.  Processors gained dramatically in address space.  User
interfaces transformed from a 1x80 punched card, through 24x80 CRT screen, to a
bitmap of ever increasing proportion.  Whereas a test program in 1965 consisted of
sending 7 characters to the teletype:

  mov 48, @r2
  mov 65, @r2
  mov 6c, @r2
  mov 6c, @r2
  mov 6f, @r2
  mov 0c, @r2
  mov 0a, @r2

Now this same program requires we set up and open a windowing environment, create
a window in that environment, specify it's geometry and default character set,
which may mean loading the bit patterns for the character glyphs.  Once the
environment has been created, we send a message to the window we've created:

  Test_Window.Display_Text("Hello");

And spend two hours figuring out that we displayed white text on a white background...

The point of all this rambling?  Syntax is irrelevant.  Semantics are crucial to
the ability to express what is present in a given model.  Without the appropriate
semantics, the software becomes increasingly difficult to create.  Note that it
is possible to implement even the wildest of designs using the ultimate RISC
architecture: Turing.  Sure, there will be some difficulties in modelling a
multiprocessor concurrent architecture; but they would merely be difficulties.

It is high time that we, the community of software movers and shakers, bring
forth the reality of a new higher level of abstraction.  To misquote Rilke:

  The spirit only wants that there be graphical programming,
    as for who accomplishes it, in this it only has a passing interest.

At 11:52 AM 11/23/98 -0600, Samuel Mize wrote:
>Keith Shillington wrote:
>> If we're arguing about syntax, it is tantamount to a religious
>> discussion.  One can write good or bad software in any language.
>> The semantics of the language will have the greatest impact on
>> how easy or hard this is to accomplish.  The syntax mostly impacts
>> how pretty the program looks in the long run.
>
>I agree generally, but wish to raise two point (infidel :-)
>
>- - - - -
>1. A "class" package is not just a package with a tagged type in it.
>There ARE semantic differences.
>
>Even object.method notation carries a semantic connotation -- that a
>specific object is the recipient of a message -- that cannot be
>expressed in Ada.
>
>An object receiving a message will be a controlling tagged parameter.
>But a controlling parameter is not necessarily an object receiving
>a message.  First, there may be several controlling parameters, only
>one of which is the "recipient", the rest are helpers.  For that
>matter, I've used tagged types when I wasn't even doing
>object-oriented work, as they support programming by extension in a
>general way.
>
>So there is a semantic content that people would like to express,
>and which must be hand-built in Ada (the way enumeration semantics
>must be hand-built in C).
>
>- - - - -
>2. Syntax does have an impact on how clear and unambiguous the
>semantics are to the reader.  Granted, the most-often argued aspects
>are more a matter of taste, e.g. whether "{ }" is better than "BEGIN
>END".  However, note that, for example, C's if-then-else syntax can
>cause semantic confusion (migrating else clauses), and that Ada's
>syntax helps prevent that semantic problem.
>
>- - - - -
>By the way, I note that you're responding to an earlier message
>that says:
>
>> >In message <[log in to unmask]>, [log in to unmask]
>> >writes
>> >>on a side point about no class construct in Ada: I feel it was a mistake
>> >>not to add it in. I understand that the semantics of a class in there, but
>> >>not the construct itself.
>
>So perhaps you aren't yet responding to the broader discussion that
>followed.  I look forward to your input.
>
>In my opinion, much of the semantics of "class" are in Ada 95 -- as
>much as are in C++, if we want to set the bar that low -- but some of
>them don't get as much automated support as I would like to see.  And
>the combination of pragmas and ASIS give us an opportunity to change
>that, and to start advertising "more OO than C++!"
>
>Best,
>Sam Mize
>
>--
>Samuel Mize -- [log in to unmask] (home email) -- Team Ada
>Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

ATOM RSS1 RSS2