>> Syntax is mostly irrelevant.
>Perhaps you are using a more restrictive definition of "syntax" than
* 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
>Samuel Mize -- [log in to unmask] (home email) -- Team Ada
>Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam