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:
Tue, 24 Nov 1998 08:58:41 -0800
In-Reply-To:
Content-Type:
text/plain; charset="us-ascii"
Reply-To:
Keith Shillington <[log in to unmask]>
Parts/Attachments:
text/plain (99 lines)
>Sam said
>>Keith said
*Keith adds

>> Syntax is mostly irrelevant.
>Perhaps you are using a more restrictive definition of "syntax" than
>I would.
* Probably so.  I view syntax as the tight (in Ada) structuring sequence of symbols,
* critically important to the process of compilation to ensure a minimal level of
* correctness of expression.  At the level of expression in English for a single
* sentence, syntax is extremely important.  At the level of expression in Ada for
* a single subprogram, syntax is extremely important.  It is the guarantee that
* we are exchanging information in the same language.

>> Well-built Object paradigm software cannot be intelligently viewed at the
>> source level.  A graphical representation of the design is required.
>
>It's trivially true that a higher-level representation makes the
>design clearer.  I assume you're comparing a graphical representation
>to an equal-level textual representation.
>
>But I would call that a change at the level of syntax, not semantics.
* Given your stated assumption that would indeed be correct.  I was actually
* attempting to press the envelope a little harder though.  I have a sense that
* we're limited in expression by the language(s) we are using, and the language(s)
* that we are using to represent OO concepts are largely textual.  Of course, our
* spoken languages are also largely textual; and as such, we have enormous
* difficulty thinking outside that confining box.
*
* I'm agreeing with you, and disagreeing with you in the same breath here.  Indeed
* if all we do is transform a textual OO program into a graphical representation,
* all we've done is a syntactic transform.  Interesting, useful, and somehow
* underlines my point that a specific syntax for expression is mostly irrelevant.
*
* Please note that I'm not saying syntax is meaningless or not useful; far from
* that; I AM saying that a specific textual syntax probably carries more or less
* the same amount of information as any other textual syntax.  So, I'm agreeing
* with you that the graphical syntax is probably only minimally more efficient
* at transmitting information.

>The change from text to graphics is a syntactic change, however
>radical it may be.  Both represent the same meaning, just in different
>formats.  (As a counter-example, using "enumeration" to represent
>mutually exclusive values, instead of integer codes, is a change at
>the semantic level, however small.)
>
>Your own example shows where a syntactic difference can present the
>semantics of the program in a more clear and useful way.
>
>If the developer is working only with diagrams, it doesn't matter if
>the tool generates Ada or C or assembler or Forth.
>
>If the developer is going to work in the source code at some point, I
>think it is useful to represent more of the semantics in the code.

* OK, here's where I'm trying to dig down to.  Using a graphical notation,
* we can reduce the quantity of syntax required to represent a given semantic
* notion.  By reducing the notional to notational ratio, we increase the amount
* of signal and reduce the amount of noise; improving the overall experience.

>> It is high time that we, the community of software movers and shakers, bring
>> forth the reality of a new higher level of abstraction.
>
>Conceived in liberty, and dedicated to the proposition...
>
>Well, maybe so.  My own mind and experience are more suited to
>"tuning" the current level of abstraction.  While, perhaps, less
>important in the overall scheme of things, I think such issues are
>still worth considering.

* I would be silly to contest you on this.  But, as most of this community is
* aware, I have a tendency to occasionally engage in something silly merely to
* find out if it's a worthwhile avenue to explore.  Just think, if SofTech had
* backed down a bit on pricing, IBM would have taken the P-System rather than
* DOS.  We wouldn't be having this conversation.  We'd be discussing different
* sets of iconographic expression.  **sigh**
*
* I see us (the Ada community) beginning to explore a spectrum of improvements
* to programmatic expression.  We've had a true OO language to work with for a
* bit over three years now, and are just coming to terms with the expressivity
* available.  I plan on blazing some new trails with the toolsets available
* within Aonix, but am going to need a groundswell of backing to engage in these
* conversations.  I deeply respect the work that Grady Booch and James Rumbaugh
* et. al. have done in the region of graphical expression for analysis, modelling
* and design.  What's missing is a sufficiently robust toolset to manage software
* modification throughout it's entire lifecycle.  We have the particles, and the
* notion to join them together.  The result is going to take some serious work
* and time.
*
* Thanks for a stimulating conversation
* --keith

>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