>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