Communications of ACM: Sir, Please Step Away from the ASR-33!

Communications of ACM: Sir, Please Step Away from the ASR-33!

[Michael R]

Hi Folks,

There's a note in November's Communications of the ACM titled "Sir, Please Step Away from the ASR-33!" with the sub-title "To move forward with programming languages we must first break free from the tyranny of ASCII".

It's interesting that Ada has already stepped away from ASCII. Many of the test cases for my ZanyBlue.Text localization support library contain non-ASCII source, e.g., a test enumeration with identifiers containing Greek characters:

type Greek is (αβγ, βγα);

Take care,
Michael.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Florian Weimer]

* Michael R.:

> It's interesting that Ada has already stepped away from ASCII. Many
> of the test cases for my ZanyBlue.Text localization support library
> contain non-ASCII source, e.g., a test enumeration with identifiers
> containing Greek characters:

Has the ARG sourted out the mess caused by the combination of
non-ASCII identifiers, case insensitivity, and mandatory conversion of
enumeration literals to upper case for output purposes?

As far as I can tell, this is a classic choose-any-two situation.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Randy Brukardt]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message 
news:8739pyk6j9.fsf@mid.deneb.enyo.de...
>* Michael R.:
>
>> It's interesting that Ada has already stepped away from ASCII. Many
>> of the test cases for my ZanyBlue.Text localization support library
>> contain non-ASCII source, e.g., a test enumeration with identifiers
>> containing Greek characters:
>
> Has the ARG sourted out the mess caused by the combination of
> non-ASCII identifiers, case insensitivity, and mandatory conversion of
> enumeration literals to upper case for output purposes?
>
> As far as I can tell, this is a classic choose-any-two situation.

Yes, and I can show you the many answers that we have. :-)

Seriously, the Ada 2005 standard really messed that up, and so far as I 
know, no one ever actually implemented the rules as intended (GNAT surely 
doesn't). I don't think any one would want to have, if the standard was 
followed to the letter, they would have to change the results of 'Image to 
*lower case* (because "convert to upper case" is defined as an mapping that 
maps to lower case characters -- oops) -- which of course would be seriously 
inconsistent with Ada 95 (that is a run-time change of results, the worst 
kind of incompatibility).

We've discussed how to fix this, but a final decision hasn't been made yet. 
See AI05-0227-1 and especially the discussion on it from the latest ARG 
meeting (whose minutes I posted Tuesday) -- find both on www.ada-auth.org.

                                         Randy.


                                           Randy.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Jacob Sparre Andersen]

Michael R wrote:

> There's a note in November's Communications of the ACM titled "Sir,
> Please Step Away from the ASR-33!" with the sub-title "To move forward
> with programming languages we must first break free from the tyranny
> of ASCII".
>
> It's interesting that Ada has already stepped away from ASCII. Many of
> the test cases for my ZanyBlue.Text localization support library
> contain non-ASCII source, e.g., a test enumeration with identifiers
> containing Greek characters:

This is definitely a small step in the right direction.  But I don't
think it is anywhere as far at Poul-Henning Kamp would like it to go.  I
have the impression that as long as our source files are only defined as
a sequence of characters, we aren't there yet.  I'm a bit scared by the
thought of a source code being defined both at the file level (for
compatibility) and as a 2D (3D?) visual structure (for editing and
inspection).

Greetings,

Jacob
-- 
"Then, after a second or so, nothing continued to happen."

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 27.12.10 15:41, Jacob Sparre Andersen wrote:
> Michael R wrote:
> 
>> There's a note in November's Communications of the ACM titled "Sir,
>> Please Step Away from the ASR-33!" with the sub-title "To move forward
>> with programming languages we must first break free from the tyranny
>> of ASCII".
>>
>> It's interesting that Ada has already stepped away from ASCII. Many of
>> the test cases for my ZanyBlue.Text localization support library
>> contain non-ASCII source, e.g., a test enumeration with identifiers
>> containing Greek characters:
> 
> This is definitely a small step in the right direction.  But I don't
> think it is anywhere as far at Poul-Henning Kamp would like it to go.  I
> have the impression that as long as our source files are only defined as
> a sequence of characters, we aren't there yet.  I'm a bit scared by the
> thought of a source code being defined both at the file level (for
> compatibility) and as a 2D (3D?) visual structure (for editing and
> inspection).


Two reasons (to which, I think, Kamp briefly hints as "conservative")
why there will never be progress towards a more expressive, traditional
(sic) syntax. "Traditional", I mean, is a way to (a) refer to how
people used to write when they were not yet incapacitated by modern
digital(*) input devices---to an extent that has made the
mistake these devices to be the standard and only means of writing.
"Traditional" can (b) refer to the way syntax was used in Algol,
which had an abstract syntax, a "printable" syntax, and then ways
to type Algol programs such that input corresponded to Algol's syntax
in some implementation defined way.

1) ASCII is a fetish.  Empirical evidence instructs us what the
(equivalents of the) high priests and their following will do
if you don't bow to the fetish.

2) If implementers' personal history includes having been praised
for their clever, simple ASCII based identifier scanning algorithm,
if their customers can be persuaded to think ASCII is good,
why should they admit that the only reason ASCII systems still
work most of the time is the post hoc fallacy?  (And defend
ASCII against any malfunctioning produce as being "caused" by
integration of improperly ASCIIfied software?)

___
(*) hole/no hole in a punched card is digital, too.
(**) the key part of ASCII is that it is a fixed size table.
Its theory is simple, you have learned it when you were
very young...

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Mon, 27 Dec 2010 15:41:10 +0100, Jacob Sparre Andersen wrote:

> Michael R wrote:
> 
>> There's a note in November's Communications of the ACM titled "Sir,
>> Please Step Away from the ASR-33!" with the sub-title "To move forward
>> with programming languages we must first break free from the tyranny
>> of ASCII".
>>
>> It's interesting that Ada has already stepped away from ASCII. Many of
>> the test cases for my ZanyBlue.Text localization support library
>> contain non-ASCII source, e.g., a test enumeration with identifiers
>> containing Greek characters:
> 
> This is definitely a small step in the right direction.  But I don't
> think it is anywhere as far at Poul-Henning Kamp would like it to go.  I
> have the impression that as long as our source files are only defined as
> a sequence of characters, we aren't there yet.  I'm a bit scared by the
> thought of a source code being defined both at the file level (for
> compatibility) and as a 2D (3D?) visual structure (for editing and
> inspection).

Historically syntax was understood as a spoken language concept.
Biologically the only way spoken language can exist is as a sequence of
elements, i.e. 1D.

A machine language theoretically need not to be spoken. But practically
nobody managed to come with anything universally usable at 2D level.

I think the way our brain processes images excludes 2D representations. 3D
is biologically excluded because our vision is basically 2D.

There is a simple criterion to determine which syntax has future and which
does not: the search engine test. Can you search for image content? You
cannot, you can only for words describing images. There are many reasons
why you cannot. I can name a mathematical one, 2D sets lack order.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Niklas Holsti]

Jacob Sparre Andersen wrote:
> Michael R wrote:
> 
>> There's a note in November's Communications of the ACM titled "Sir,
>> Please Step Away from the ASR-33!" with the sub-title "To move forward
>> with programming languages we must first break free from the tyranny
>> of ASCII".
>>
>> It's interesting that Ada has already stepped away from ASCII. Many of
>> the test cases for my ZanyBlue.Text localization support library
>> contain non-ASCII source, e.g., a test enumeration with identifiers
>> containing Greek characters:
> 
> This is definitely a small step in the right direction.  But I don't
> think it is anywhere as far at Poul-Henning Kamp would like it to go.  I
> have the impression that as long as our source files are only defined as
> a sequence of characters, we aren't there yet.  I'm a bit scared by the
> thought of a source code being defined both at the file level (for
> compatibility) and as a 2D (3D?) visual structure (for editing and
> inspection).

Such mixed 2D+text codes are already a reality for many programmers who 
use box-and-arrow diagrams with tools like LabView, Simulink, or any of 
the UML-based tools, combined with application-specific function-boxes 
written in some traditional textual language. These programmers may not 
even glance at the 1D-text source-code that the tools generate from the 
diagrams, much less attempt to understand the structure of this code. 
They are satisfied that the final program does what the diagrams show. 
And why not? Few programmers inspect the assembly-language form of their 
C or Ada programs.

For an amusing idea of 2D programming, see the "funge" languages in 
http://en.wikipedia.org/wiki/Esoteric_programming_language: "A funge is 
an esoteric programming language which models its programs as metric 
spaces with coordinate systems (often, but not necessarily, Cartesian) 
and which execute instructions located at points in their program space 
by moving an instruction pointer (a position vector which indicates the 
currently executing instruction) through that space. Different 
instructions determine the direction in which the instruction pointer 
moves, and consequently, the sequence of instructions that is executed."

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Mon, 27 Dec 2010 20:41:36 +0200, Niklas Holsti wrote:

> Such mixed 2D+text codes are already a reality for many programmers who 
> use box-and-arrow diagrams with tools like LabView, Simulink, or any of 
> the UML-based tools, combined with application-specific function-boxes 
> written in some traditional textual language. These programmers may not 
> even glance at the 1D-text source-code that the tools generate from the 
> diagrams, much less attempt to understand the structure of this code.

In one project the customer was adamant that all code must be written in
such a language (DiaDem, now owned NI. They also maintain LabView). He had
an idea that diagrams were easy to understand, so that he could modify them
by himself.

As expected this ended in a disaster. The project was a real-size one. I
have no idea how many square meters the diagram was, but in the end we had
no other choice than to write a program, which processed the textual
descriptions of diagram. They were text files. So instead of editing square
kilometers of arrows, imagine how would you browse for anything in such a
thing! we patched these text files and let the tool add missing connections
and necessary blocks. Nobody ever looked at the blocks and arrows. Just to
load the mess to look at it took minutes.

Fortunately at some point the customer dropped the requirement and we
gradually removed most of the mess. Now only 1% of code remains in DiaDem.

Ada has nothing to fear from this side.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Niklas Holsti]

Dmitry A. Kazakov wrote:
> On Mon, 27 Dec 2010 20:41:36 +0200, Niklas Holsti wrote:
> 
>> Such mixed 2D+text codes are already a reality for many programmers who 
>> use box-and-arrow diagrams with tools like LabView, Simulink, or any of 
>> the UML-based tools, combined with application-specific function-boxes 
>> written in some traditional textual language. These programmers may not 
>> even glance at the 1D-text source-code that the tools generate from the 
>> diagrams, much less attempt to understand the structure of this code.
> 
> In one project the customer was adamant that all code must be written in
> such a language (DiaDem, now owned NI. They also maintain LabView). He had
> an idea that diagrams were easy to understand, so that he could modify them
> by himself.
> 
> As expected this ended in a disaster. The project was a real-size one. I
> have no idea how many square meters the diagram was, but in the end we had
> no other choice than to write a program, which processed the textual
> descriptions of diagram. They were text files. So instead of editing square
> kilometers of arrows, imagine how would you browse for anything in such a
> thing! we patched these text files and let the tool add missing connections
> and necessary blocks. Nobody ever looked at the blocks and arrows. Just to
> load the mess to look at it took minutes.
> 
> Fortunately at some point the customer dropped the requirement and we
> gradually removed most of the mess. Now only 1% of code remains in DiaDem.

This is a good description of a failure of diagram-based programming, 
thanks Dmitry.

Nevertheless, there are also many examples of successful projects that 
use diagrams. Perhaps the DIAdem tool was not a good match for the 
application where it failed. The NI webpage http://www.ni.com/diadem/ 
describes DIAdem as a data-analysis tool, not a general programming tool.

> Ada has nothing to fear from this side.

I am not so sure. I remember attending an Ada conference (possibly 
Ada-Europe 2003) in which a speaker from Airbus appeared. I think he was 
expected to speak about how Ada was used at Airbus, and how good it was; 
instead, he told us that Airbus were moving to model-based development, 
using a synchronous modelling language, and that the hand-written Ada 
code was being replaced by automatically generated C code. I felt that 
this depressed the audience a good bit...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 11:32:04 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Mon, 27 Dec 2010 20:41:36 +0200, Niklas Holsti wrote:
>> 
>>> Such mixed 2D+text codes are already a reality for many programmers who 
>>> use box-and-arrow diagrams with tools like LabView, Simulink, or any of 
>>> the UML-based tools, combined with application-specific function-boxes 
>>> written in some traditional textual language. These programmers may not 
>>> even glance at the 1D-text source-code that the tools generate from the 
>>> diagrams, much less attempt to understand the structure of this code.
>> 
>> In one project the customer was adamant that all code must be written in
>> such a language (DiaDem, now owned NI. They also maintain LabView). He had
>> an idea that diagrams were easy to understand, so that he could modify them
>> by himself.
>> 
>> As expected this ended in a disaster. The project was a real-size one. I
>> have no idea how many square meters the diagram was, but in the end we had
>> no other choice than to write a program, which processed the textual
>> descriptions of diagram. They were text files. So instead of editing square
>> kilometers of arrows, imagine how would you browse for anything in such a
>> thing! we patched these text files and let the tool add missing connections
>> and necessary blocks. Nobody ever looked at the blocks and arrows. Just to
>> load the mess to look at it took minutes.
>> 
>> Fortunately at some point the customer dropped the requirement and we
>> gradually removed most of the mess. Now only 1% of code remains in DiaDem.
> 
> This is a good description of a failure of diagram-based programming, 
> thanks Dmitry.
> 
> Nevertheless, there are also many examples of successful projects that 
> use diagrams. Perhaps the DIAdem tool was not a good match for the 
> application where it failed. The NI webpage http://www.ni.com/diadem/ 
> describes DIAdem as a data-analysis tool, not a general programming tool.

DiaDem consists of several loosely coupled parts one of them is off-line
analysis tool. Others are equivalents of LabView, e.g. one part has various
computation blocks, another has instruments to indicate the results (gauges
etc). The UI is designed using the third part, the control and logic is
using the second, and the "off-line" analysis tool is used on line for
archiving and reporting.

Once DiaDem (originally developed by GfS) was a competitor of LabView. They
bought it and seem not very keen to promote. But DiaDem has a huge customer
base here in Germany, so they cannot kill it altogether.

>> Ada has nothing to fear from this side.
> 
> I am not so sure. I remember attending an Ada conference (possibly 
> Ada-Europe 2003) in which a speaker from Airbus appeared. I think he was 
> expected to speak about how Ada was used at Airbus, and how good it was; 
> instead, he told us that Airbus were moving to model-based development, 
> using a synchronous modelling language, and that the hand-written Ada 
> code was being replaced by automatically generated C code. I felt that 
> this depressed the audience a good bit...

Managers always have IDEAS... I didn't work much with Airbus, but in
automotive, where Ada never was in use, they indeed are using lots of
graphical and/or modeling languages/tools: Simulink, DiaDem, LabView,
ASCET, Modelica/Dymola.

I really don't know, but I have an impression that apart from natural
ignorance of software developing engineers have, another reason is that you
can circumvent certification procedures when you "generate" code. If the
code is written in C or Ada, that is a "code" to undergo more or less
strict quality control. If the "code" is a bunch of arrows and blocks, it
is no more considered "code," and you are free to do with that what pleases
you. Maybe I am wrong.

In my view tools is cancer of software developing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 28.12.10 11:13, Dmitry A. Kazakov wrote:

> In my view tools is cancer of software developing.

Sounds overly general.  Some programs are written over
and over again.  Typically, a fraction of programmers
repeats the mistakes of earlier programs of the same kind.
Forms, for example, have been in use for decades.  Yet,
forms continue to show the same flaws and mistakes.

If there is a theory of forms and a corresponding tool to direct
the programmer, then a forms tool is not different from a
programming language: a programming language, too, directs
the programmer to arrange program code and data in proper
order.  The difference between a "tool" and a language is,
then, that the tool (and generator) may reflect knowledge of
these repeatedly written programs, or patterns.

(I have once written a tool that would generate a
set of abstract classes modeling the possible interactions
of a user and a web application.  That seemed better than
to rely on manually connecting unrelated classes in
some ad hoc fashion.  It also helped in communication
ideas of how the system would work from the perspective
of users.)

A tool can focus on concepts applicable in certain situations.
It can, e.g., check a state machine diagram (or other formal
expression of a state machine) for completeness, concentrating
on just the state machine aspect.  An implementation has
details that will be distracting.
A traditional programming language is much more flexible *because*
it has no such concepts.  With flexibility comes confusion,
insofar as you, the programmer, will have to find the concepts
know how to properly match concepts and language, and separate
model and implementation in your head without this separation
being visible and documented in a formal way.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 12:01:19 +0100, Georg Bauhaus wrote:

> On 28.12.10 11:13, Dmitry A. Kazakov wrote:
> 
>> In my view tools is cancer of software developing.
> 
> Sounds overly general.  Some programs are written over
> and over again.  Typically, a fraction of programmers
> repeats the mistakes of earlier programs of the same kind.
> Forms, for example, have been in use for decades.  Yet,
> forms continue to show the same flaws and mistakes.
> 
> If there is a theory of forms and a corresponding tool to direct
> the programmer, then a forms tool is not different from a
> programming language: a programming language, too, directs
> the programmer to arrange program code and data in proper
> order.  The difference between a "tool" and a language is,
> then, that the tool (and generator) may reflect knowledge of
> these repeatedly written programs, or patterns.

This describes a situation when programmers failed to use the language for
providing higher level abstractions and reusing solutions in the language
terms. Instead of that they design another half-baked language called tool.
Just in order to be realistic. What is simpler:

1. To design a new language or to properly encapsulate domain specific
abstraction?

2. To hire a competent language/compiler developer or a competent software
developer?

3. To integrate generated code or designed code?

Tools distract language community efforts from improving the language.
Tools eat resources which otherwise would be invested in software quality.
Tool chains require maintenance is order of magnitude compared to
maintenance of a compiler. Programmers are busy writing tools to maintain
tools maintaining other tools. Tools give the manager a false impression
that the project is under control, and that instead of hiring competent
developers he could buy their knowledge in the form of a new fancy tool.
Tools make certification a joke. Tools make the code base virtually
non-existent. Tools generate worst possible code which need to be glued
with other code in a proportion that the amount of glue become bigger than
the functional parts. Tools prevent software reuse and serve insulation of
developers' communities.

Tools today is a combination the worst disasters software engineering
suffered since the invention of C, x86, Windows and Unix.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 28.12.10 13:07, Dmitry A. Kazakov wrote:
> On Tue, 28 Dec 2010 12:01:19 +0100, Georg Bauhaus wrote:
> 
>> On 28.12.10 11:13, Dmitry A. Kazakov wrote:
>>
>>> In my view tools is cancer of software developing.
>>
>> Sounds overly general.  Some programs are written over
>> and over again.  Typically, a fraction of programmers
>> repeats the mistakes of earlier programs of the same kind.
>> Forms, for example, have been in use for decades.  Yet,
>> forms continue to show the same flaws and mistakes.
>>
>> If there is a theory of forms and a corresponding tool to direct
>> the programmer, then a forms tool is not different from a
>> programming language: a programming language, too, directs
>> the programmer to arrange program code and data in proper
>> order.  The difference between a "tool" and a language is,
>> then, that the tool (and generator) may reflect knowledge of
>> these repeatedly written programs, or patterns.
> 
> This describes a situation when programmers failed to use the language for
> providing higher level abstractions and reusing solutions in the language
> terms. Instead of that they design another half-baked language called tool.
> Just in order to be realistic. What is simpler:
> 
> 1. To design a new language or to properly encapsulate domain specific
> abstraction?
> 
> 2. To hire a competent language/compiler developer or a competent software
> developer?

Is having written compilers a qualification if you are supposed
to write efficient accounting software?  Vice versa?

> 3. To integrate generated code or designed code?

Source text integration surely depends on a good theory behind
the tool, I'd think?  (There was no trouble caused by inheriting
from generated abstract classes and filling in the blanks.)


> Tools distract language community efforts from improving the language.
> Tools eat resources which otherwise would be invested in software quality.

Looking at source code only, what is the best way to answer a
question like this: "Which parts of the software do currently
depend on message box X's state?"

(Please, no reference to poor original design, here.  Start from
- a situation that needs fixing, or
- from a quite reasonable change of requirements that makes
the question pop up in the designers' minds for the first time.)

> Tool chains require maintenance is order of magnitude compared to
> maintenance of a compiler.

Is language maintenance more expensive than to tool maintenance?

> Programmers are busy writing tools to maintain
> tools maintaining other tools. Tools give the manager a false impression
> that the project is under control, and that instead of hiring competent
> developers he could buy their knowledge in the form of a new fancy tool.

Different tools will yield different results.  Do we have
comparative results?

> Tools make certification a joke. Tools make the code base virtually
> non-existent.

Tools can rely on a standard notation, then there is a code
base.  You'd need reliable translation from tool notation
to traditional programming language notation.

> Tools generate worst possible code which need to be glued
> with other code in a proportion that the amount of glue become bigger than
> the functional parts.

What if the code generated is fully controlled by the
tool user?  For example, you may use code templates to
be filled in. In this case, what you do is in many ways
traditional editing, with an enhanced editor.

In addition, relations not easily spotted in source text
become visible with the help of tools: call graphs,
collaborations, logical dependence (and circular dependence?),
indirect containment, etc.

At least in theory, such a tool seems worth having.
Not sure if this is just a dream:  has anyone used a tool
capable of reverse engineering sequence diagrams at
a satisfactory level?


> Tools prevent software reuse and serve insulation of
> developers' communities.

If UML notation captures much of your model with guaranteed
1:1 correspondence of UML notation and Ada notation (e.g.
template based correspondence, or Eiffel IDE style correspondence
with BON notation, ...), it will be possible to use _any_
UML tool, thus leaving a choice, and reducing insulation.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 14:03:27 +0100, Georg Bauhaus wrote:

> On 28.12.10 13:07, Dmitry A. Kazakov wrote:
>> On Tue, 28 Dec 2010 12:01:19 +0100, Georg Bauhaus wrote:
>> 
>>> On 28.12.10 11:13, Dmitry A. Kazakov wrote:
>>>
>>>> In my view tools is cancer of software developing.
>>>
>>> Sounds overly general.  Some programs are written over
>>> and over again.  Typically, a fraction of programmers
>>> repeats the mistakes of earlier programs of the same kind.
>>> Forms, for example, have been in use for decades.  Yet,
>>> forms continue to show the same flaws and mistakes.
>>>
>>> If there is a theory of forms and a corresponding tool to direct
>>> the programmer, then a forms tool is not different from a
>>> programming language: a programming language, too, directs
>>> the programmer to arrange program code and data in proper
>>> order.  The difference between a "tool" and a language is,
>>> then, that the tool (and generator) may reflect knowledge of
>>> these repeatedly written programs, or patterns.
>> 
>> This describes a situation when programmers failed to use the language for
>> providing higher level abstractions and reusing solutions in the language
>> terms. Instead of that they design another half-baked language called tool.
>> Just in order to be realistic. What is simpler:
>> 
>> 1. To design a new language or to properly encapsulate domain specific
>> abstraction?
>> 
>> 2. To hire a competent language/compiler developer or a competent software
>> developer?
> 
> Is having written compilers a qualification if you are supposed
> to write efficient accounting software?

No. But you need to be both a language/compiler/GUI design expert and an
accounting expert in order to design a graphical accounting programming
language. The probability of this to happen is less than breaking jackpot.
That is the reason why all these so-called domain-specific languages are so
bad.

>> 3. To integrate generated code or designed code?
> 
> Source text integration surely depends on a good theory behind
> the tool, I'd think?  (There was no trouble caused by inheriting
> from generated abstract classes and filling in the blanks.)

This is nothing comparing to tool integration. How about communication over
SMS or text files in a moderately dynamic system. Thanks to the tools such
solutions are common, almost standard, at least nobody wonders anymore.

>> Tools distract language community efforts from improving the language.
>> Tools eat resources which otherwise would be invested in software quality.
> 
> Looking at source code only, what is the best way to answer a
> question like this: "Which parts of the software do currently
> depend on message box X's state?"

The call stack? Show me an equivalent in Simulink.

If you meant that source navigation requires a tool, yes it does. Then:

1. This tool is not used for programming, it generates no code. I have
nothing against IDEs, ASIS, AdaControl etc.

2. Such tools for "tools proper" are non-existent. Try to search for
anything in Simulink blocks. Can you have anything like AdaControl for it?
The answer is no. Code generating tools are mess in all aspects, including
this one.

>> Tool chains require maintenance is order of magnitude compared to
>> maintenance of a compiler.
> 
> Is language maintenance more expensive than to tool maintenance?

Maintenance of GNAT + GPS is zero compared to, say ASCET.

>> Programmers are busy writing tools to maintain
>> tools maintaining other tools. Tools give the manager a false impression
>> that the project is under control, and that instead of hiring competent
>> developers he could buy their knowledge in the form of a new fancy tool.
> 
> Different tools will yield different results.  Do we have
> comparative results?

Yes I do. Some people from our staff are full-time busy writing tools to
maintain our customer's tools. Nobody of us writes anything to maintain
GNAT, VC#/++, Delphi, Borland C, and of course no customer would pay for
that.

That is the idea. When you buy a compiler from the worst vendor on Earth it
will require zero maintenance compared to the bunch of garbage called
"tools." It is OK to pay 100K+ for this garbage and have life-time
investments of money and staff in it. But try to convince your manager to
buy GNAT Pro. This is what ruins software development.

>> Tools make certification a joke. Tools make the code base virtually
>> non-existent.
> 
> Tools can rely on a standard notation, then there is a code
> base.

They can anything, my point was about what they actually do.

> You'd need reliable translation from tool notation
> to traditional programming language notation.

What for?

>> Tools generate worst possible code which need to be glued
>> with other code in a proportion that the amount of glue become bigger than
>> the functional parts.
> 
> What if the code generated is fully controlled by the
> tool user?

How can the user control generated code? Do you control the assembler code?
And your point was that the user is *incompetent* to write the code. That
was your idea of a tool as a substitute for competence. How can an
incompetent user be in control of the code? Why should he control the code
generated by a tool designed by the experts in this field? [So the
mythology goes]

>> Tools prevent software reuse and serve insulation of
>> developers' communities.
> 
> If UML notation captures much of your model

The model of what, and what role plays the word "if" in this sentence.

> with guaranteed
> 1:1 correspondence of UML notation and Ada notation (e.g.
> template based correspondence, or Eiffel IDE style correspondence
> with BON notation, ...), it will be possible to use _any_
> UML tool, thus leaving a choice, and reducing insulation.

Any example of UML code used for porting from Eiffel to Ada? The economic
reality tells the opposite. There is a huge industry feeding on porting DBs
from one RDBMS to another, from one modeling tool to another. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Simon Wright]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> If UML notation captures much of your model with guaranteed 1:1
> correspondence of UML notation and Ada notation (e.g.  template based
> correspondence, or Eiffel IDE style correspondence with BON notation,
> ...), it will be possible to use _any_ UML tool, thus leaving a
> choice, and reducing insulation.

If you do this, why bother with the UML tool at all? (unless all you
want is lots and lots of pretty diagrams to show the boss).

I strongly believe that the UML model should say what's appropriate at
its level, and that the code whould be generated from the model using
rules appropriate to the target environment.

That makes for two sorts of engineer on the project: the ones who look
after the application, and the ones who look after the mechanisms (what
Shlaer-Mellor call the Software Architecture).

It also means that the application team has to tell the architecure team
what the architecture must do (is the system dynamic? what performance
and timeliness requirements are there? ...) and, in the other direction,
the architecture team has to tell the application team what model
constructs to use to get the translator to behave as needed.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 28.12.10 14:56, Dmitry A. Kazakov wrote:

>> Is having written compilers a qualification if you are supposed
>> to write efficient accounting software?
> 
> No. But you need to be both a language/compiler/GUI design expert and an
> accounting expert in order to design a graphical accounting programming
> language. The probability of this to happen is less than breaking jackpot.
> That is the reason why all these so-called domain-specific languages are so
> bad.

OK, and since industry wants modes of expression beyond
(and in addition to) traditional programming languages,
this desire creates a substantial need beyond rhetoric.


>>> Tools distract language community efforts from improving the language.
>>> Tools eat resources which otherwise would be invested in software quality.
>>
>> Looking at source code only, what is the best way to answer a
>> question like this: "Which parts of the software do currently
>> depend on message box X's state?"
> 
> The call stack? Show me an equivalent in Simulink.

The call stack as a source of dependence information will
not work if the program sends pieces of text to communicate.
(Examples would be the recently posted memcached binding
or anything sending---at some point---specific information
along wires or file store or similar.)

OTOH, using a notation that provides for any kind of
message sent will ipso facto express message sending
regardless of implementation (of message sending).
Using source templates controlled by a programmer,
the model can be mapped to a specific implementation
(of message sending).


> If you meant that source navigation requires a tool, yes it does. Then:
> 
> 1. This tool is not used for programming, it generates no code. I have
> nothing against IDEs, ASIS, AdaControl etc.

No, I meant that there is human readable information beyond
data and subprograms in source, things that we normally can
only infer:
aspects, relations, logical dependence. A good tool would
represent these better than the hidden implications of source
text.


>>> Tool chains require maintenance is order of magnitude compared to
>>> maintenance of a compiler.
>>
>> Is language maintenance more expensive than to tool maintenance?
> 
> Maintenance of GNAT + GPS is zero compared to, say ASCET.

This is maintenance of a compiler/editor/... for a given language.
I meant maintenance of Ada, the language.  We would have to
compare a formal notation like UML to a formal notation like
Ada, both by cost and by benefits.



>>> Tools make certification a joke. Tools make the code base virtually
>>> non-existent.
>>
>> Tools can rely on a standard notation, then there is a code
>> base.
> 
> They can anything, my point was about what they actually do.

OK.

>> You'd need reliable translation from tool notation
>> to traditional programming language notation.
> 
> What for?

Translating from a tool notation to a traditional programming
language bridges the gap between a fairly general mode of expression
(the tool's) and a mode of expression closer to the
hardware specifics (using Ada, say).  Using a traditional
programming language, you have a basis for integration
that is flexible: integration can use different conventions,
programming language specifics, project specifics, or
or personal preferences.  All the more when you can control
what source text is produced from the tool notation.

Translation directly from tool to op codes might miss
opportunities to exploit the programming language
and to benefit from the experience distilled into the
language. (And reliance on what is available because of ISO
standardization  can be a big plus.)
  Also, suppose you'd translate directly from tool
notation to op codes.  If the translated code needs
supporting libraries, then developing the libraries will
likely mean a repetition of the development that had led to the
traditional programming language and its supporting libraries...

> And your point was that the user is *incompetent* to write the code.

Programmers can be competent and still not know everything
all the time.  Competent programmers make mistakes, too,
even when the job at hand is nothing new.


> That
> was your idea of a tool as a substitute for competence.

I meant tools not as a substitute, but rather as a guide.


>  Why should he control the code
> generated by a tool designed by the experts in this field? [So the
> mythology goes]

Some tools suggest that you create (or change) a mapping between
tool notation and programming language notation.  This offering
is useful because there are project standards, different ways
to map, and in particular you yourself may be the experts.
And you might have reusable code that sets the standard for
the mapping, etc.


>>> Tools prevent software reuse and serve insulation of
>>> developers' communities.
>>
>> If UML notation captures much of your model
> 
> The model of what, and what role plays the word "if" in this sentence.

As outlined above, a model might capture which objects collaborate
to achieve a certain effect (and no other objects are involved).


>> with guaranteed
>> 1:1 correspondence of UML notation and Ada notation (e.g.
>> template based correspondence, or Eiffel IDE style correspondence
>> with BON notation, ...), it will be possible to use _any_
                       ...then it...
>> UML tool, thus leaving a choice, and reducing insulation.
> 
> Any example of UML code used for porting from Eiffel to Ada? The economic
> reality tells the opposite. There is a huge industry feeding on porting DBs
> from one RDBMS to another, from one modeling tool to another. 

.NET!  All # languages share a common core.  I'd think that
persistent objects can be loaded using any # language?

Some years ago, a large military had been using over 400
programming languages.  Many of the programs could have
been written using a common programming language.  That was
an argument of Col. Whitaker: cost effective, technically
sound.  I think this is still correct, today, and can also
be applied to most of the tools we will be able to name.
 There were exceptions, and there are exceptions,
and there will be exceptions to the rule that a common
notation can express most aspects of software systems.

Thus, transporting Eiffel code to Ada (via XMI, say) does
not seem impossible.  If porting between languages
is not done this way today, I think the reasons are beyond
technical.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Tue, 28 Dec 2010 16:41:37 +0100, Georg Bauhaus wrote:

> On 28.12.10 14:56, Dmitry A. Kazakov wrote:
> 
>>> Is having written compilers a qualification if you are supposed
>>> to write efficient accounting software?
>> 
>> No. But you need to be both a language/compiler/GUI design expert and an
>> accounting expert in order to design a graphical accounting programming
>> language. The probability of this to happen is less than breaking jackpot.
>> That is the reason why all these so-called domain-specific languages are so
>> bad.
> 
> OK, and since industry wants modes of expression beyond
> (and in addition to) traditional programming languages,
> this desire creates a substantial need beyond rhetoric.

Industry wants money. Tools is a new market niche. Due to A) specialization
(=> lack of expertise) B) market fragmentation (=> lack of choice), tool
vendors maintain monopoly and earn money. The core idea - corner the
customer. This is the economical substance of tools.

> OTOH, using a notation that provides for any kind of
> message sent will ipso facto express message sending
> regardless of implementation (of message sending).
> Using source templates controlled by a programmer,
> the model can be mapped to a specific implementation
> (of message sending).

So simple? No multicast, unicast, acknowledges, QoS, synchronization,
routing, balanced load, naming and browsing services,
connection/disconnection, marshaling, peers, retries, frames and windows,
state transitions.

Send a message - done! Do you really believe in THIS?

>> If you meant that source navigation requires a tool, yes it does. Then:
>> 
>> 1. This tool is not used for programming, it generates no code. I have
>> nothing against IDEs, ASIS, AdaControl etc.
> 
> No, I meant that there is human readable information beyond
> data and subprograms in source, things that we normally can
> only infer:
> aspects, relations, logical dependence. A good tool would
> represent these better than the hidden implications of source
> text.

If the tool can, why syntax does not? Xref was great to represent gotos and
labels. Remember the last time you used it in Ada?

I trust in the concept of manifested imperative programming. I don't want
to infer anything either by tool or by man. That suggests that the result
may depend on the inference process.

>> Maintenance of GNAT + GPS is zero compared to, say ASCET.
> 
> This is maintenance of a compiler/editor/... for a given language.
> I meant maintenance of Ada, the language.

That is up to the compiler vendors, why should a programmer care?

> We would have to
> compare a formal notation like UML to a formal notation like
> Ada, both by cost and by benefits.

Yes, when you use UML you have to maintain both GNAT and, say, Rational
Rose and plug-ins of one in another.

>>> You'd need reliable translation from tool notation
>>> to traditional programming language notation.
>> 
>> What for?
> 
> Translating from a tool notation to a traditional programming
> language bridges the gap between a fairly general mode of expression
> (the tool's) and a mode of expression closer to the
> hardware specifics (using Ada, say).

I don't buy this. Ada is higher level than UML. UML as a language is
untyped, lacks abstraction, encapsulation and whatever properties decent
languages have since Pascal times. That UML can generate Ada code does not
make it high level. You can generate Ada code from Assembler.

>> And your point was that the user is *incompetent* to write the code.
> 
> Programmers can be competent and still not know everything
> all the time.  Competent programmers make mistakes, too,
> even when the job at hand is nothing new.

They supposedly make no mistakes when connect arrows in UML? In order to
make this point, you should tell more about readability, redundancy,
typing, early error detection, about the stuff UML obviously lacks.

>> That
>> was your idea of a tool as a substitute for competence.
> 
> I meant tools not as a substitute, but rather as a guide.

Why the compiler cannot be a guide?

>>>> Tools prevent software reuse and serve insulation of
>>>> developers' communities.
>>>
>>> If UML notation captures much of your model
>> 
>> The model of what, and what role plays the word "if" in this sentence.
> 
> As outlined above, a model might capture which objects collaborate
> to achieve a certain effect (and no other objects are involved).

Why an Ada program cannot capture this?

> Some years ago, a large military had been using over 400
> programming languages.  Many of the programs could have
> been written using a common programming language.  That was
> an argument of Col. Whitaker: cost effective, technically
> sound.  I think this is still correct, today, and can also
> be applied to most of the tools we will be able to name.

Yes, now we have 800 languages and 2,000 tools.

>  There were exceptions, and there are exceptions,
> and there will be exceptions to the rule that a common
> notation can express most aspects of software systems.

You can express everything by just one integer number. If that played any
role we would program in binary code, which is just that number.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 12/28/10 3:39 PM, Simon Wright wrote:
> Georg Bauhaus<rm.dash-bauhaus@futureapps.de>  writes:
>
>> If UML notation captures much of your model with guaranteed 1:1
>> correspondence of UML notation and Ada notation (e.g.  template based
>> correspondence, or Eiffel IDE style correspondence with BON notation,
>> ...), it will be possible to use _any_ UML tool, thus leaving a
>> choice, and reducing insulation.
>
> If you do this, why bother with the UML tool at all? (unless all you
> want is lots and lots of pretty diagrams to show the boss).

I think I meant what you explain, that the correspondence
of UML (at its level) to source (at its level) should
be established by co-operation between model makers and
program authors.  The thing is, we can do this, and there
is benefit.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 12/28/10 5:26 PM, Dmitry A. Kazakov wrote:

>> This is maintenance of a compiler/editor/... for a given language.
>> I meant maintenance of Ada, the language.
>
> That is up to the compiler vendors, why should a programmer care?


Doomed! We're doomed!  I sincerely hope that language
development is not just in the hand of compiler makers.
That happened when C was created.
  


> I don't buy this. Ada is higher level than UML. UML as a language is
> untyped,

Huh?

> lacks abstraction,

Pardon?

> encapsulation

L(N) packages, self-description, ...

Or are you thinking about modeling tools that can transform one entire
program to become a different program and the transformation is
steered by some transformation processor?


>> Programmers can be competent and still not know everything
>> all the time.  Competent programmers make mistakes, too,
>> even when the job at hand is nothing new.
>
> They supposedly make no mistakes when connect arrows in UML?

No, using tools, they will be guided in the direction the
tool knows best.  Just like an Ada compiler will instruct
us to not leave out values in a case distinction.

> In order to
> make this point, you should tell more about readability, redundancy,
> typing, early error detection, about the stuff UML obviously lacks.

I'm not sure I should say this but you might want to bring
your knowledge of UML up to date. Even StP went far to make
sure your model was checked in all sorts of directions.

>>> That
>>> was your idea of a tool as a substitute for competence.
>>
>> I meant tools not as a substitute, but rather as a guide.
>
> Why the compiler cannot be a guide?

The compiler is a guide where it "knows the area".
But there are things that have no specific representation
in a source program. Rather, you as a programmer have to infer them
and the compiler cannot help.  Such as collaboration schemes
between objects, their order, etc.  These associations,
relations, etc.  are not easily spotted, not in one
place, in a source program.  The compiler won't tell you.

>>>> If UML notation captures much of your model
>>>
>>> The model of what, and what role plays the word "if" in this sentence.
>>
>> As outlined above, a model might capture which objects collaborate
>> to achieve a certain effect (and no other objects are involved).
>
> Why an Ada program cannot capture this?


A typical item that, I think, will be easier to express as a
model element than to program in source text is a thing external
to the program that influences the program's control structure:
Being external, it has no direct counterpart in the programming
language.  If such a thing can be represented in model language
(has a direct counterpart there), then the model seem easier to
understand, the expression is still formal, and the mapping to
some programming language construct can be chosen flexibly.


Suppose there is a setup like the following: some external entity
acts as a mutex controlling concurrent activities of
co-operating "jobs". The jobs, in some heterogeneous system,
run as separate processes. They signal states via a
data store or file system or other means.  State values are used
to establishing order, the states signaling if and when
some job may continue, for example, and how.

Facade style entity descriptions should then suffice to express
the idea. If I wanted to express the idea in Ada, I'd have to
produce all kinds of types and interfaces with no purpose other
than to satisfy the level of abstraction necessary for a suitably
abstract model. (Of external control.)  Isn't it easier to
sketch the idea and later choose some mapping to Ada than to extract
the idea from some specific, concrete, and elaborate rendition in
source text?  All the more when writing source text must
not only lead to a program that runs as expected but must
also meet the needs of abstract model construction (for documentation,
maintenance views, ...)

Also, when I start from the model, then I can change
the Ada source without changing the model. (Since the
model captures the general ideal in a formal way).
This is what mappings should be good for.
When I always start from Ada, from this or that choice
of concrete representation, I will be re-iterating the thought
process that drops implementation detail in order to arrive at
the unchanged model idea.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 28.12.10 17:26, Dmitry A. Kazakov wrote:

>> OTOH, using a notation that provides for any kind of
>> message sent will ipso facto express message sending
>> regardless of implementation (of message sending).
>> Using source templates controlled by a programmer,
>> the model can be mapped to a specific implementation
>> (of message sending).
> 
> So simple? No multicast, unicast, acknowledges, QoS, synchronization,
> routing, balanced load, naming and browsing services,
> connection/disconnection, marshaling, peers, retries, frames and windows,
> state transitions.
> 
> Send a message - done! Do you really believe in THIS?

Absolutely.  Understanding the model will not require
that the model itself provides the fundament of human
understanding.  Whenever the expression
    "Send a message - done!"
answers a question about the functioning of a system,
then indeed, done!

The two teams that Simon has mentioned should
be able to communicate meaningfully this way. For
example, sometimes it is "understood" (borrowing math
speak) what sending a message means, given some architecture.

If more detail is needed, it is up to the model makers
and programmers to agree on a useful rule regarding
specification en detail.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Wed, 29 Dec 2010 14:55:57 +0100, Georg Bauhaus wrote:

> On 28.12.10 17:26, Dmitry A. Kazakov wrote:
> 
>>> OTOH, using a notation that provides for any kind of
>>> message sent will ipso facto express message sending
>>> regardless of implementation (of message sending).
>>> Using source templates controlled by a programmer,
>>> the model can be mapped to a specific implementation
>>> (of message sending).
>> 
>> So simple? No multicast, unicast, acknowledges, QoS, synchronization,
>> routing, balanced load, naming and browsing services,
>> connection/disconnection, marshaling, peers, retries, frames and windows,
>> state transitions.
>> 
>> Send a message - done! Do you really believe in THIS?
> 
> Absolutely.  Understanding the model will not require
> that the model itself provides the fundament of human
> understanding.  Whenever the expression
>     "Send a message - done!"
> answers a question about the functioning of a system,
> then indeed, done!

Then we are living in two different Universes, yours is build of
antimatter. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Wed, 29 Dec 2010 13:56:00 +0100, Georg Bauhaus wrote:

> On 12/28/10 5:26 PM, Dmitry A. Kazakov wrote:
> 
>>> This is maintenance of a compiler/editor/... for a given language.
>>> I meant maintenance of Ada, the language.
>>
>> That is up to the compiler vendors, why should a programmer care?
> 
> 
> Doomed! We're doomed!  I sincerely hope that language
> development is not just in the hand of compiler makers.

The real problem is that it is in other's hands!

> That happened when C was created.

Nope, that happened when guys having too much spare time and computers
strove to busy themselves.

> Or are you thinking about modeling tools that can transform one entire
> program to become a different program and the transformation is
> steered by some transformation processor?

I am thinking of a language as a language. 

>> They supposedly make no mistakes when connect arrows in UML?
> 
> No, using tools, they will be guided in the direction the
> tool knows best.  Just like an Ada compiler will instruct
> us to not leave out values in a case distinction.

Ada is capable of this because it has types. It is not because Ada knows
anything about specific types, but because the programmer can use the type
system to express constraints the compiler will then check. There is no
magic knowledge Ada oracle sheds to guide programmers. All information is
exclusively from the programmer. Any tool is no different, it is a
dangerous delusion to believe otherwise.

>> In order to
>> make this point, you should tell more about readability, redundancy,
>> typing, early error detection, about the stuff UML obviously lacks.
> 
> I'm not sure I should say this but you might want to bring
> your knowledge of UML up to date. Even StP went far to make
> sure your model was checked in all sorts of directions.

Assembler checks the code in that sorts of direction too. It just lacks
that lobby to organize a promotion campaign...

>>>> That was your idea of a tool as a substitute for competence.
>>>
>>> I meant tools not as a substitute, but rather as a guide.
>>
>> Why the compiler cannot be a guide?
> 
> The compiler is a guide where it "knows the area".

Why this area must be different for an Ada compiler and a UML diagram
interpreter?

> But there are things that have no specific representation
> in a source program. Rather, you as a programmer have to infer them
> and the compiler cannot help.  Such as collaboration schemes
> between objects, their order, etc.  These associations,
> relations, etc.  are not easily spotted, not in one
> place, in a source program.  The compiler won't tell you.

and UML would?

>>>>> If UML notation captures much of your model
>>>>
>>>> The model of what, and what role plays the word "if" in this sentence.
>>>
>>> As outlined above, a model might capture which objects collaborate
>>> to achieve a certain effect (and no other objects are involved).
>>
>> Why an Ada program cannot capture this?
> 
> 
> A typical item that, I think, will be easier to express as a
> model element than to program in source text is a thing external
> to the program that influences the program's control structure:

Sorry, I don't understand this. Why a thing important to the program must
be external to it? Why this thing must be external in Ada, but internal in
UML?

> Suppose there is a setup like the following: some external entity
> acts as a mutex controlling concurrent activities of
> co-operating "jobs".

Don't use low-level concurrency primitives. Ada has better means for that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 29.12.10 15:52, Dmitry A. Kazakov wrote:

>> No, using tools, they will be guided in the direction the
>> tool knows best.  Just like an Ada compiler will instruct
>> us to not leave out values in a case distinction.
> 
> Ada is capable of this because it has types. It is not because Ada knows
> anything about specific types, but because the programmer can use the type
> system to express constraints the compiler will then check. There is no
> magic knowledge Ada oracle sheds to guide programmers. All information is
> exclusively from the programmer.

The information in models is man-made, too.

> Any tool is no different, it is a
> dangerous delusion to believe otherwise.

There are differences among tools' domains.
(In what they are about, in what they can express.)

Tools are different, and so are the benefits.
Even when two tools are in the same class of tools:
An Ada compiler will treat a case statement in a way
that is different from the way a C compiler treats a switch.
Both are, by intent, case distinctions.

So even among compilers guidance is different.

The crucial part is that an Ada compiler guides you by
answering the question "Which case distinctions do I
have to change?" (provided you don't use C style "others"
for subtypes typically appearing in case statements).
A C compiler typically cannot do this.

Modeling tools will answer different questions.  But they will
answer them when answers are more difficult to find using only
Ada source text and human inference.  This is because, when
modeling, humans have expressed one set of notions. This
set is slightly different from the set expressed in Ada source.



>> Even StP went far to make
>> sure your model was checked in all sorts of directions.
> 
> Assembler checks the code in that sorts of direction too.

Assembly language cannot, for example, *express* IS-A
relations, Ada can (there is syntax for it), UML too,
and more than this.

You can have conventions in assembly language, like the first
parameter pushed for a call is a pointer to a memory location, and
the first word there is a pointer that either represents the
null pointer or is a pointer to another memory location of
similar structure. (...)  I think this isn't meant by *express*
IS-A.


>> The compiler is a guide where it "knows the area".
> 
> Why this area must be different for an Ada compiler and a UML diagram
> interpreter?

Ada and UML deal with a different set of objects and notions.
There is some correspondence, but the focus is different.

>> These associations,
>> relations, etc.  are not easily spotted, not in one
>> place, in a source program.  The compiler won't tell you.
> 
> and UML would?

Yes. BON, e.g., is a particularly simple way to express relations
and orders of communication.  UML has this, too. Formally,
unlike comments.


> Why a thing important to the program must
> be external to it?

The system architecture is such that concurrent processes
communicate via a data store. So the important thing happens
to be external to the program.  It is a requirement that I
cannot change. But a model can express the external control
as a system element nevertheless.

> Why this thing must be external in Ada, but internal in
> UML?

An external control can be an element of a UML diagram or
other modes of expression, but not in Ada (not directly).
The set of objects directly expressible in some modeling
language may be larger (or different).


>> Suppose there is a setup like the following: some external entity
>> acts as a mutex controlling concurrent activities of
>> co-operating "jobs".
> 
> Don't use low-level concurrency primitives. Ada has better means for that.

That's the non-argument I'd like to again ask to avoid:
the setup is given, as is.  When I can use Ada
to cope with the given setup, I'll have to act as if Ada
had no direct support for the CSP mechanisms permitted
in the given setup.  However, direct support is available
in other (modeling) formalisms. They can be mapped
to Ada (in several ways). I pick a mapping that matches
the setup.

The model is clear, the implementation in Ada is up
to the programmer.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Wed, 29 Dec 2010 17:32:31 +0100, Georg Bauhaus wrote:

> On 29.12.10 15:52, Dmitry A. Kazakov wrote:
> 
>>> No, using tools, they will be guided in the direction the
>>> tool knows best.  Just like an Ada compiler will instruct
>>> us to not leave out values in a case distinction.
>> 
>> Ada is capable of this because it has types. It is not because Ada knows
>> anything about specific types, but because the programmer can use the type
>> system to express constraints the compiler will then check. There is no
>> magic knowledge Ada oracle sheds to guide programmers. All information is
>> exclusively from the programmer.
> 
> The information in models is man-made, too.

Thus the argument of "guidance" is finally ditched?

>> Any tool is no different, it is a
>> dangerous delusion to believe otherwise.
> 
> There are differences among tools' domains.

Right. If the domain of UML is supposed to be "generating Ada code," then,
thanks, I prefer GPS.

If we are talking about a *real* domain, like designing an application X
that does Y, then convince me that UML does it better than Ada and what
does prevent Ada from providing same level of support.

> The crucial part is that an Ada compiler guides you by
> answering the question "Which case distinctions do I
> have to change?" (provided you don't use C style "others"
> for subtypes typically appearing in case statements).

What is "case distinctions"?
 
> Modeling tools will answer different questions.  But they will
> answer them when answers are more difficult to find using only
> Ada source text and human inference.

So it is about things like AdaBrowse? I have no question to the source
texts. Right mouse click in GPS, then select "references."

>This is because, when
> modeling, humans have expressed one set of notions. This
> set is slightly different from the set expressed in Ada source.

Certainly yes, if you compare UML input with its output. But I don't buy
this trick. You have to show that the guidance given while connecting
blocks is better than the guidance given by Ada compiler when compiling Ada
program. It is NOT.
 
>>> Even StP went far to make
>>> sure your model was checked in all sorts of directions.
>> 
>> Assembler checks the code in that sorts of direction too.
> 
> Assembly language cannot, for example, *express* IS-A
> relations, Ada can (there is syntax for it), UML too,
> and more than this.

No, UML cannot, it is untyped as Assember. You cannot define a type of
blocks and then derive a new type from it, for example, blocks with the
number of incoming arrows equal to the number of outgoing arrows multiplied
by two.

IS-A at the language level is a relationship between two types. UML does
not have this. If you are rather talking about the language code you are
generating using UML, then Assembler can perfectly express IS-A in that
language too, by appropriately initializing appropriate registers. It is
Turing complete. You are confusing the meta language with the object one.

>>> The compiler is a guide where it "knows the area".
>> 
>> Why this area must be different for an Ada compiler and a UML diagram
>> interpreter?
> 
> Ada and UML deal with a different set of objects and notions.
> There is some correspondence, but the focus is different.

Why Ada cannot focus on what you wanted?

>> Why a thing important to the program must
>> be external to it?
> 
> The system architecture is such that concurrent processes
> communicate via a data store. So the important thing happens
> to be external to the program.  It is a requirement that I
> cannot change. But a model can express the external control
> as a system element nevertheless.

Nope, it is likewise external to the model. You didn't answer the question:
what is the crucial difference between the code in UML (a bunch of blocks)
and the code in Ada (a bunch of texts). The semantics of the program (what
and if it models anything) is irrelevant, because we assume them doing the
*same* thing. Please, do not compare the output of UML with an Ada program.
Compare the man-made inputs.
 
>> Why this thing must be external in Ada, but internal in UML?
> 
> An external control can be an element of a UML diagram or
> other modes of expression, but not in Ada (not directly).

Why?

> The set of objects directly expressible in some modeling
> language may be larger (or different).

Why cannot they be "directly expressible" in Ada?

>>> Suppose there is a setup like the following: some external entity
>>> acts as a mutex controlling concurrent activities of
>>> co-operating "jobs".
>> 
>> Don't use low-level concurrency primitives. Ada has better means for that.
> 
> That's the non-argument I'd like to again ask to avoid:
> the setup is given, as is.

That's it! The setup seems to be: "have to use UML." I challenge this
setup.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 29.12.10 18:26, Dmitry A. Kazakov wrote:
> On Wed, 29 Dec 2010 17:32:31 +0100, Georg Bauhaus wrote:
> 
>> On 29.12.10 15:52, Dmitry A. Kazakov wrote:
>>
>>>> No, using tools, they will be guided in the direction the
>>>> tool knows best.  Just like an Ada compiler will instruct
>>>> us to not leave out values in a case distinction.
>>>
>>> Ada is capable of this because it has types. It is not because Ada knows
>>> anything about specific types, but because the programmer can use the type
>>> system to express constraints the compiler will then check. There is no
>>> magic knowledge Ada oracle sheds to guide programmers. All information is
>>> exclusively from the programmer.
>>
>> The information in models is man-made, too.
> 
> Thus the argument of "guidance" is finally ditched?

No. Man-made programming things are not arbitrary.  Ada source
text follows Ada language rules and Ada culture.  Similarly,
UML diagrams would not be drawn arbitrarily, either.

>>> Any tool is no different, it is a
>>> dangerous delusion to believe otherwise.
>>
>> There are differences among tools' domains.
> 
> Right. If the domain of UML is supposed to be "generating Ada code," then,
> thanks, I prefer GPS.

The domain of UML is modeling and possibly metamodeling.
Models can be made to correspond to source code.
"Generating Ada code" falls short of "making two modes of
human expression correspond" (model and source text).

> If we are talking about a *real* domain, like designing an application X
> that does Y, then convince me that UML does it better than Ada and what
> does prevent Ada from providing same level of support.

External control in a given setup is easily and formally
communicated in a modeling language.  As I said, I'd need
a load of Ada source text (thus fixing certain detail
early on) in order to come close to said simple
control element.

>> The crucial part is that an Ada compiler guides you by
>> answering the question "Which case distinctions do I
>> have to change?" (provided you don't use C style "others"
>> for subtypes typically appearing in case statements).
> 
> What is "case distinctions"?

case Few_Values'(X) is
  when One => ...
  when Two => ...
  when Three => ...
end case;

switch (x) {
  case One: ... break;
  case Two: ... break;
  case Three: ... break;
  // default:
}

Now change Few_Value:

  type Few_Values is (One, Two, Three, Four);

  enum Few_Values {One, Two, Three, Four);

And adapt your software.  Which compiler guides best?

(GCC's C compiler can be instructed to issue a warning:
sw.c:7: warning: enumeration value �Four� not handled in switch
GCC's Ada compiler rejects the program.)

>> Modeling tools will answer different questions.  But they will
>> answer them when answers are more difficult to find using only
>> Ada source text and human inference.
> 
> So it is about things like AdaBrowse? I have no question to the source
> texts. Right mouse click in GPS, then select "references."

As mentioned before, communication might send message strings.
It need not mean to call the recipient. UML has a type of arrow
for messages.  GPS looses. (It cannot know some arbitrary
subprogram, that somehow, indirectly, informs us that
what seems a string parameter is a message sent to some
designated object (and not a call).
  Or, you may have a Message_Tube type, its names being all
you have to convey "message". This is by far not as immediate
as the typed message sending arrow of UML and others.)


>> This is because, when
>> modeling, humans have expressed one set of notions. This
>> set is slightly different from the set expressed in Ada source.
> 
> Certainly yes, if you compare UML input with its output. But I don't buy
> this trick. You have to show that the guidance given while connecting
> blocks is better than the guidance given by Ada compiler when compiling Ada
> program. It is NOT.

Use cases.
Permissible call orders of a type's operations.
Answering questions about program structure at large.

>>>> Even StP went far to make
>>>> sure your model was checked in all sorts of directions.
>>>
>>> Assembler checks the code in that sorts of direction too.
>>
>> Assembly language cannot, for example, *express* IS-A
>> relations, Ada can (there is syntax for it), UML too,
>> and more than this.
> 
> No, UML cannot, it is untyped as Assember. You cannot define a type of
> blocks and then derive a new type from it,

(You cannot define "if" in Ada, either.)
OTOH, UML is defined, AFAICT, in terms of itself.
For more, see below.

> for example, blocks with the
> number of incoming arrows equal to the number of outgoing arrows multiplied
> by two.

This is silly, and not what UML is about or needs to
be about.  UML is typed, its universe of things
is full of categorized modeling elements and associated
"operations" (things you can do with them in diagrams).
Tools typically allow definition of modeling elements whose
"UML behavior" would go by the rules of UML.

> IS-A at the language level is a relationship between two types. UML does
> not have this.

UML does not relate its modeling elements? I'd be
surprised to learn that a class is not related to parameterized
class, that a uni-directional association it totally unrelated
to a bi-directional association, or to association, type-wise.
Or that a realization arrow is, by your analogy with assembly
language, like an untyped register word to be arbitrarily
re-interpreted to be a state in a state chart.
I have not seen a tool, or rule, that allows this.

And even so, I couldn't care less about (meta)programming
in UML.  About as much as I'd care about metaprogramming
in Ada (which does not have programming the programming
language at all).
I am a UML user, not a UML language maker.
I am an Ada user, not an Ada language maker.

> If you are rather talking about the language code you are
> generating using UML, then Assembler can perfectly express IS-A in that
> language too, by appropriately initializing appropriate registers. It is
> Turing complete. You are confusing the meta language with the object one.

This starts to sound like Humpty Dumpty.
An expression is man made.  It is not an operation.
The expectation it triggers is that,

- in Ada, there will be an effect having something
  to do with the expression.

- in UML, there is a relation, first and foremost.

The Ada declaration ("to declare"...)

  type T is new ...

*expresses* T IS-A ... by employing the word "new" in
this context.

There is absolutely nothing in assembly language that
has such connotation.  *Has*.  Not "code that produces
the operational effect of BEING-A".


> Why Ada cannot focus on what you wanted?

Because only the model entities can express
directly what cannot be directly expressed in Ada.
A focus is small by definition, it excludes some
things from sight and typically draws attention to
hot spots.  This is why Ada cannot easily focus on
things that need to be programmed first.


>>> Why a thing important to the program must
>>> be external to it?
>>
>> The system architecture is such that concurrent processes
>> communicate via a data store. So the important thing happens
>> to be external to the program.  It is a requirement that I
>> cannot change. But a model can express the external control
>> as a system element nevertheless.
> 
> Nope, it is likewise external to the model.

A model element isn't external to the model.
Model notation includes model elements representing control.
The meaning of "control" need not include a reference
to either "external to the program" or "internal to the
program".  Hence, there is no model element that is
either internal or external to the model.

> You didn't answer the question:
> what is the crucial difference between the code in UML (a bunch of blocks)
> and the code in Ada (a bunch of texts). The semantics of the program (what
> and if it models anything) is irrelevant, because we assume them doing the
> *same* thing.

Absolutely not.

I don't assume (non-executable) UML diagrams to do anything.
They inform.  They guide.  They can be made to correspond
to some Ada program.  Models do something to their readers,
you might say.

> Please, do not compare the output of UML with an Ada program.

UML has no output.  A choice of rules of correspondence
produces output.  Output is up to the teams deciding on
how source code should correspond to model elements.

> Compare the man-made inputs.

External control must be programmed in Ada.  It is not an
immediate part of the language.  It is part of UML and others,
because of the absence of prerequisite "external" or "internal".

>>> Why this thing must be external in Ada, but internal in UML?
>>
>> An external control can be an element of a UML diagram or
>> other modes of expression, but not in Ada (not directly).
> 
> Why?

Because "external" means beyond reach of the Ada language,
by definition.  (I'd rather not go on speaking about this
external example, but well. Anything expressed in terms
of complexity of requirements of understanding might do just
as well. After all, this is all about reducing complexity!)
"External" things are only within reach through
the effects of certain library calls, calls to external software,
or by reacting to interrupts.  These things need to be programmed
using Ada, they are not part of Ada.

I'd have to program an emulation of external control.
That, then, is implementation detail.
Implementation detail is certainly beside point when modeling
(as opposed to planning).


>>>> Suppose there is a setup like the following: some external entity
>>>> acts as a mutex controlling concurrent activities of
>>>> co-operating "jobs".
>>>
>>> Don't use low-level concurrency primitives. Ada has better means for that.
>>
>> That's the non-argument I'd like to again ask to avoid:
>> the setup is given, as is.
> 
> That's it! The setup seems to be: "have to use UML." I challenge this
> setup.

That's not it.  Modeling (and understanding) a system
is a lot easier, and in some cases possible,  when you don't
have to refer to tons of Ada declarations for expressing
simple things (simple as in the modeling language).

--
IF you don't know what a Gryphon is,
look at the picture.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Wed, 29 Dec 2010 20:31:18 +0100, Georg Bauhaus wrote:

> On 29.12.10 18:26, Dmitry A. Kazakov wrote:
>> On Wed, 29 Dec 2010 17:32:31 +0100, Georg Bauhaus wrote:
>> 
>>> The information in models is man-made, too.
>> 
>> Thus the argument of "guidance" is finally ditched?
> 
> No. Man-made programming things are not arbitrary.  Ada source
> text follows Ada language rules and Ada culture.  Similarly,
> UML diagrams would not be drawn arbitrarily, either.

It is the superior UML culture, which makes Ada usage impossible? And where
is the guidance?

>>>> Any tool is no different, it is a
>>>> dangerous delusion to believe otherwise.
>>>
>>> There are differences among tools' domains.
>> 
>> Right. If the domain of UML is supposed to be "generating Ada code," then,
>> thanks, I prefer GPS.
> 
> The domain of UML is modeling and possibly metamodeling.

I am interested in software design. Why UML is better for designing
software than Ada and what does Ada lack to become as good as UML allegedly
is.

>> If we are talking about a *real* domain, like designing an application X
>> that does Y, then convince me that UML does it better than Ada and what
>> does prevent Ada from providing same level of support.
> 
> External control in a given setup is easily and formally
> communicated in a modeling language.

I don't know what external control is, but let me a shot:

"External control in a given setup is easily and formally
communicated in Ada."

Is it wrong? How much of X doing Y is "external control"? Let's take matrix
inversion program as an example.

>>> The crucial part is that an Ada compiler guides you by
>>> answering the question "Which case distinctions do I
>>> have to change?" (provided you don't use C style "others"
>>> for subtypes typically appearing in case statements).
>> 
>> What is "case distinctions"?
> 
> case Few_Values'(X) is
>   when One => ...
>   when Two => ...
>   when Three => ...
> end case;
> 
> switch (x) {
>   case One: ... break;
>   case Two: ... break;
>   case Three: ... break;
>   // default:
> }
> 
> Now change Few_Value:
> 
>   type Few_Values is (One, Two, Three, Four);
> 
>   enum Few_Values {One, Two, Three, Four);
> 
> And adapt your software.  Which compiler guides best?
> 
> (GCC's C compiler can be instructed to issue a warning:
> sw.c:7: warning: enumeration value οΏ½FourοΏ½ not handled in switch
> GCC's Ada compiler rejects the program.)

How is this related to UML?
 
>>> Modeling tools will answer different questions.  But they will
>>> answer them when answers are more difficult to find using only
>>> Ada source text and human inference.
>> 
>> So it is about things like AdaBrowse? I have no question to the source
>> texts. Right mouse click in GPS, then select "references."
> 
> As mentioned before, communication might send message strings.
> It need not mean to call the recipient. UML has a type of arrow
> for messages. GPS looses.

In GPS I see a call Send_Message. I can even refactor Send_Message and
rename it to Send_An_Excellent_Message. Can UML refactor arrows?

> (It cannot know some arbitrary
> subprogram, that somehow, indirectly, informs us that
> what seems a string parameter is a message sent to some
> designated object (and not a call).

Surely not, because it is untyped. I don't send strings, I send messages.
Message is an object.

> Or, you may have a Message_Tube type, its names being all
> you have to convey "message". This is by far not as immediate
> as the typed message sending arrow of UML and others.)

Since when strings became typed messages?

>>> This is because, when
>>> modeling, humans have expressed one set of notions. This
>>> set is slightly different from the set expressed in Ada source.
>> 
>> Certainly yes, if you compare UML input with its output. But I don't buy
>> this trick. You have to show that the guidance given while connecting
>> blocks is better than the guidance given by Ada compiler when compiling Ada
>> program. It is NOT.
> 
> Use cases.
> Permissible call orders of a type's operations.
> Answering questions about program structure at large.

GPS has this sort of stuff (see "tools" in the menu), but I don't count it
for guidance or even valuable comparing to typing, reuse, information
hiding, encapsulation and modularity, which Ada offers and UML does not.

>> for example, blocks with the
>> number of incoming arrows equal to the number of outgoing arrows multiplied
>> by two.
> 
> This is silly, and not what UML is about or needs to be about.

Yes, UML is not about it.

> UML is typed, its universe of things
> is full of categorized modeling elements and associated
> "operations" (things you can do with them in diagrams).

This equally apply to Assembler. It is a universe of things (registers,
commands, labels) and associated operations. It is perfectly typed in the
"sense" that MOV R1,R0 is OK, but R0 MOV,R1 is not OK.

>> IS-A at the language level is a relationship between two types. UML does
>> not have this.
> 
> UML does not relate its modeling elements?

Yes, what you operate is not what you are.

> And even so, I couldn't care less about (meta)programming
> in UML.

That is another issue. My point merely was that UML as a language is not as
advanced as Ada. Therefore I wonder why do you insist that UML can do more
than Ada ever could. That looks illogical.

>> If you are rather talking about the language code you are
>> generating using UML, then Assembler can perfectly express IS-A in that
>> language too, by appropriately initializing appropriate registers. It is
>> Turing complete. You are confusing the meta language with the object one.
> 
> This starts to sound like Humpty Dumpty.
> An expression is man made.  It is not an operation.
> The expectation it triggers is that,
> 
> - in Ada, there will be an effect having something
>   to do with the expression.
> 
> - in UML, there is a relation, first and foremost.
> 
> The Ada declaration ("to declare"...)
> 
>   type T is new ...
> 
> *expresses* T IS-A ... by employing the word "new" in
> this context.

It does not expresses is-a, it constructs a new type. Relation is a Boolean
operation of two arguments. There is nothing problematic to construct such
operation in Assembler.

Talking about certain properties of types, you should first show me

1. an equivalent of a type in UML. E.g. arrow might be a value of some type
of arrows.

2. construct a new type, e.g. new type of arrows.

3. show how the language treats values of new type substitutable in
operations of the old one, e.g. operation "connect two blocks."

It is not construction of new language, it is a property of a language to
abstract a set of language things sharing some properties. Note that Ada
not only has this, it goes further it can abstract sets of sets (generics
and classes).

>> Why Ada cannot focus on what you wanted?
> 
> Because only the model entities can express
> directly what cannot be directly expressed in Ada.

By this you mean that these entities cannot be modeled by values, types,
operations, packages?

>>>> Why a thing important to the program must
>>>> be external to it?
>>>
>>> The system architecture is such that concurrent processes
>>> communicate via a data store. So the important thing happens
>>> to be external to the program.  It is a requirement that I
>>> cannot change. But a model can express the external control
>>> as a system element nevertheless.
>> 
>> Nope, it is likewise external to the model.
> 
> A model element isn't external to the model.

So it has some interface internal to my program, otherwise the program
cannot become aware of its existence.

>> You didn't answer the question:
>> what is the crucial difference between the code in UML (a bunch of blocks)
>> and the code in Ada (a bunch of texts). The semantics of the program (what
>> and if it models anything) is irrelevant, because we assume them doing the
>> *same* thing.
> 
> Absolutely not.
> 
> I don't assume (non-executable) UML diagrams to do anything.
> They inform.  They guide. They can be made to correspond
> to some Ada program.  Models do something to their readers,
> you might say.

Ada declarations inform, guide and mean something. I see no difference.

>>> An external control can be an element of a UML diagram or
>>> other modes of expression, but not in Ada (not directly).
>> 
>> Why?
> 
> Because "external" means beyond reach of the Ada language,
> by definition.

Maybe there is something wrong with that definition?

> (I'd rather not go on speaking about this
> external example, but well. Anything expressed in terms
> of complexity of requirements of understanding might do just
> as well. After all, this is all about reducing complexity!)
> "External" things are only within reach through
> the effects of certain library calls, calls to external software,
> or by reacting to interrupts.  These things need to be programmed
> using Ada, they are not part of Ada.

This equally apply to UML. You have to describe these thing in order to be
able to talk to and about them. In Ada it is called interface. The
interface can be as detailed as you wish. You can invent non-existent in
reality objects as you would do in UML. In fact many Ada binding do just
this. They create proxy objects, hierarchies of such objects etc.
Admittedly Ada has problems with that, but I bet it is much more advanced
than UML in that respect. Last time I looked at UML it was all about
relationships between concrete instances.

> Modeling (and understanding) a system
> is a lot easier, and in some cases possible,  when you don't
> have to refer to tons of Ada declarations for expressing
> simple things (simple as in the modeling language).

I doubt it much because of completeness of such descriptions. They cannot
capture the system architecture and behavior at the level of details
necessary for designing and maintaining the system. The key advantage of
Ada is that it satisfactory works throughout most of the levels. Diagrams
do not, you lose either vital details or understanding. And when not
directly executable or else reverse engineered from actual code, they do
more harm than help.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Marco]

find it here:
http://queue.acm.org/detail.cfm?id=1871406

How far away from ASCII do you want to go - for example:
http://www.clarity-support.co.uk/index.html

(for myself text has always been better for any details)

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Georg Bauhaus]

On 30.12.10 00:35, Dmitry A. Kazakov wrote:

I'll put this up front:

> Ada declarations inform, guide and mean something. I see no difference.

UML elements inform, guide and mean something.
Something slightly different.

>> No. Man-made programming things are not arbitrary.  Ada source
>> text follows Ada language rules and Ada culture.  Similarly,
>> UML diagrams would not be drawn arbitrarily, either.
> 
> It is the superior UML culture, which makes Ada usage impossible? And where
> is the guidance?

The UML repertoire for expressing ideas makes you model
in terms of UML.  That's useful in many modeling cases.
It is not useful if modeling is misunderstood: it is not
the same as programming.


> I am interested in software design. Why UML is better for designing
> software than Ada and what does Ada lack to become as good as UML allegedly
> is.

The question is *when* is UML better for what kind of
design.

UML, for example, has simple elements for simply expressing
control as part of the system that would be external to the
program you will be writing, as mentioned many times.


>>> If we are talking about a *real* domain, like designing an application X
>>> that does Y, then convince me that UML does it better than Ada and what
>>> does prevent Ada from providing same level of support.
>>
>> External control in a given setup is easily and formally
>> communicated in a modeling language.
> 
> I don't know what external control is, but let me a shot:
> 
> "External control in a given setup is easily and formally
> communicated in Ada."
> 
> Is it wrong? How much of X doing Y is "external control"? Let's take matrix
> inversion program as an example.

Suppose the matrix inversion program can be split into
a number of jobs (huge matrices).  The operating system requires
that each job do not exceed a given quota.  Each job may
just fail because the OS decides it should fail for some
reason (including economic/commercial reasons).
 It may be re-allocating processors and therefore
some jobs would have to be terminated.  In some systems,
there is no way for your job to be told about its
imminent death.  In any case, in order to deal with this, you
need some means of communication: each job must

(1) register itself
(2) communicate success

via some non-failing "message box" external to almost
everything.  Other jobs must try to look into the message
box and see if there are pending jobs. If not, they see whether
all jobs have reported success.  These manager jobs may need
 to run some of the same jobs again. This, again, requires that
the jobs themselves be made such that they can be run once
more, ideally in arbitrary order.

The important part here is the external data store and
control mechanisms.  They are easily expressed if you
abstract away the specifics of the heterogeneous system.
A data store is very much part of modeling tools.
A data store abstractions can be programmed in Ada.
There is no direct support for a data store in Ada, the
language.  There is, with some tools.


>>>> The crucial part is that an Ada compiler guides you by
>>>> answering the question "Which case distinctions do I
>>>> have to change?" (provided you don't use C style "others"
>>>> for subtypes typically appearing in case statements).

>> (GCC's C compiler can be instructed to issue a warning:
>> sw.c:7: warning: enumeration value οΏ½FourοΏ½ not handled in switch
>> GCC's Ada compiler rejects the program.)
> 
> How is this related to UML?

It is related to how one tool (compiler for some language) provides
more guidance than another when performing necessary changes
of case distinctions in source code.


> In GPS I see a call Send_Message. I can even refactor Send_Message and
> rename it to Send_An_Excellent_Message. Can UML refactor arrows?

In Ada, then, you need to embed another language into Ada
in order to be able to say "this is a message".
(pick some convention for choosing identifiers)

Wheras "Message" is a built-in in some modeling tools.


> Surely not, because it is untyped. I don't send strings, I send messages.
> Message is an object.

The external software expects a \0-terminated string,
sent in message style.


>>>> This is because, when
>>>> modeling, humans have expressed one set of notions. This
>>>> set is slightly different from the set expressed in Ada source.
>>>
>>> Certainly yes, if you compare UML input with its output. But I don't buy
>>> this trick. You have to show that the guidance given while connecting
>>> blocks is better than the guidance given by Ada compiler when compiling Ada
>>> program. It is NOT.
>>
>> Use cases.
>> Permissible call orders of a type's operations.
>> Answering questions about program structure at large.
> 
> GPS has this sort of stuff (see "tools" in the menu),

GPS lets me draw actors and actions of use cases?

> but I don't count it
> for guidance or even valuable comparing to typing, reuse, information
> hiding, encapsulation and modularity, which Ada offers and UML does not.

UML and others make all of these readily available.
They are ready.  You don't need to construct anything.
Even second level information hiding (excluding
parts of the model from sight) in not unusual with
those tools.

>> UML is typed, its universe of things
>> is full of categorized modeling elements and associated
>> "operations" (things you can do with them in diagrams).
> 
> This equally apply to Assembler. It is a universe of things (registers,
> commands, labels) and associated operations. It is perfectly typed in the
> "sense" that MOV R1,R0 is OK, but R0 MOV,R1 is not OK.

The assembly language universe of things is
much smaller than Ada's and UML's, obviously, and does not
include anything like a package or an actor.

>>> IS-A at the language level is a relationship between two types. UML does
>>> not have this.
>>
>> UML does not relate its modeling elements?
> 
> Yes, what you operate is not what you are.

The interpretation of typed associations in UML is not
subject to other operations that the informed brain's
understanding the relations.

At the level of modeled things, things *are* related.
At the level of UML language, items *are* related as
described by (Meta-)UML, AFAIK (a class model is a ...).

>> And even so, I couldn't care less about (meta)programming
>> in UML.
> 
> That is another issue. My point merely was that UML as a language is not as
> advanced as Ada. Therefore I wonder why do you insist that UML can do more
> than Ada ever could. That looks illogical.

It becomes logical when you concentrate on structure:
static structure, dynamic structure.  I don't want to be
forced into messy detail, choice of implementation,
choice of language, just to see the big picture (typed
picture!).



>>   type T is new ...
>>
>> *expresses* T IS-A ... by employing the word "new" in
>> this context.
> 
> It does not expresses is-a, it constructs a new type.

Text does not construct anything.  It denotes, with
the help of an reader interpreting the text.

The text "type T is new T0" expresses a relationship
between T and T0 (T being derived from T0).  This mode
of expression corresponds to another where you would
say "class T IS-A class T0".


> Relation is a Boolean
> operation of two arguments. 

I thought that a relation is a thing between two things.
And "operation" in a programming context is not usually
an abstracted static function table?  A text does not
operate.  Neither does an arrow.

When a write "T is new T0", I am expressing a relationship.
When I place a specific arrow between a boxed "T" (denoting
a named model item of type class) and a boxed "T0" (denoting
another named model item of type class), I am expressing a
relationship.  The same, in the modeling sense. The second
mode of expression does not depend on the choice of a
programming language.

> There is nothing problematic to construct such
> operation in Assembler.

To construct is not the same as to express. To me, that is
an important difference.
Assembly language permits the construction of anything
but no expression of assembly language comes close
"type T is new T0".  "New" is simply not part of assembly
language.


> Talking about certain properties of types, you should first show me
> 
> 1. an equivalent of a type in UML. E.g. arrow might be a value of some type
> of arrows.

It is.  This is also irrelevant, because you use "UML elements"
not to construct the language UML, or to construct "UML
programs", but you use UML elements to express static
and dynamic structure of your model.

> 2. construct a new type, e.g. new type of arrows.

That's available with some UML tools, and some other tools
do not have anything but elements constructed in this way.
I don't find this universally helpful, though, because you
loose one important property of a language like UML: that
everyone understands it.

> 3. show how the language treats values of new type substitutable in
> operations of the old one, e.g. operation "connect two blocks."

One example would be adorned associations.  The fact of
association is not lost when the ornaments are dropped.
Therefore, one arrow can be used in place of the other.
Since it is up to the team to decide on a correspondence of
UML elements and Ada source text, they can construct rules
of correspondence that take ornaments into account.

> you mean that these entities cannot be modeled by values, types,
> operations, packages?

You'd need a larger set of Ada constructs, you'd need to choose,
and you won't have standard elements. You do all this in order
to arrive at the modeling equivalent of some simple model
element.
In many modeling cases, such specifics will be distracting.



>> A model element isn't external to the model.
> 
> So it has some interface internal to my program,

First, your "program" is a notion that does not have a counterpart
in  "model", unless there is a model element for "program".

> otherwise the program
> cannot become aware of its existence.

Second, the interface is not one that is an element of Ada's
immediate repertoire.  You'd have to choose, construct,
etc., in some project-specific way.  Which is what should
be done when deciding how the message sending/receiving
source text should correspond to the model element.

>>>> An external control can be an element of a UML diagram or
>>>> other modes of expression, but not in Ada (not directly).
>>>
>>> Why?
>>
>> Because "external" means beyond reach of the Ada language,
>> by definition.
> 
> Maybe there is something wrong with that definition?

The definition of Ada includes the word "external".
I think there are hints near it as to why some things
external are not covered by Ada.

> You have to describe these thing in order to be
> able to talk to and about them. In Ada it is called interface.

You'd be creating interfaces in Ada that match the
repertoire of UML.  Well... Wouldn't you be creating
a UML tool, then?

> Last time I looked at UML it was all about
> relationships between concrete instances.

(Some of UML is about relationships between concrete instances.
But not all.)

> They cannot
> capture the system architecture and behavior at the level of details
> necessary for designing and maintaining the system.

Precisely! At least if you exclude the tools that turn technical
drawings full of all necessary detail into an executable program.

But you don't necessarily loose detail when modeling (as opposed
to programming).
You can, however, get lost in detail when not modeling.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Thu, 30 Dec 2010 19:28:16 +0100, Georg Bauhaus wrote:

> The UML repertoire for expressing ideas makes you model
> in terms of UML.  That's useful in many modeling cases.
> It is not useful if modeling is misunderstood: it is not
> the same as programming.

If only you could sell diagrams instead of programs. Alas at some moment
the customer becomes anxious to see something alive...

>> I am interested in software design. Why UML is better for designing
>> software than Ada and what does Ada lack to become as good as UML allegedly
>> is.
 
> UML, for example, has simple elements for simply expressing
> control as part of the system that would be external to the
> program you will be writing, as mentioned many times.

OK, it is no help.
 
>> Is it wrong? How much of X doing Y is "external control"? Let's take matrix
>> inversion program as an example.
> 
> Suppose the matrix inversion program can be split into
> a number of jobs (huge matrices).  The operating system requires
> that each job do not exceed a given quota.  Each job may
> just fail because the OS decides it should fail for some
> reason (including economic/commercial reasons).
>  It may be re-allocating processors and therefore
> some jobs would have to be terminated.  In some systems,
> there is no way for your job to be told about its
> imminent death.  In any case, in order to deal with this, you
> need some means of communication: each job must
> 
> (1) register itself
> (2) communicate success
> 
> via some non-failing "message box" external to almost
> everything.  Other jobs must try to look into the message
> box and see if there are pending jobs. If not, they see whether
> all jobs have reported success.  These manager jobs may need
>  to run some of the same jobs again. This, again, requires that
> the jobs themselves be made such that they can be run once
> more, ideally in arbitrary order.
> 
> The important part here is the external data store and
> control mechanisms.  They are easily expressed if you
> abstract away the specifics of the heterogeneous system.
> A data store is very much part of modeling tools.
> A data store abstractions can be programmed in Ada.
> There is no direct support for a data store in Ada, the
> language.  There is, with some tools.

UML is absolutely unusable for distributed systems, but I don't want to get
into it. Suppose I need to invert a 10x10 matrix, and, please, no message
boxes, customers get fancy when see that mess.

>>>>> The crucial part is that an Ada compiler guides you by
>>>>> answering the question "Which case distinctions do I
>>>>> have to change?" (provided you don't use C style "others"
>>>>> for subtypes typically appearing in case statements).
> 
>>> (GCC's C compiler can be instructed to issue a warning:
>>> sw.c:7: warning: enumeration value οΏ½FourοΏ½ not handled in switch
>>> GCC's Ada compiler rejects the program.)
>> 
>> How is this related to UML?
> 
> It is related to how one tool (compiler for some language) provides
> more guidance than another when performing necessary changes
> of case distinctions in source code.

Why should I perform these changes?
 
> Wheras "Message" is a built-in in some modeling tools.

Really? Send me an EtherCAT SDO over the corresponding PDUs packed into the
corresponding frames.

>> Surely not, because it is untyped. I don't send strings, I send messages.
>> Message is an object.
> 
> The external software expects a \0-terminated string,
> sent in message style.

No problem, the message object is serialized when marshaled.

>>>>> This is because, when
>>>>> modeling, humans have expressed one set of notions. This
>>>>> set is slightly different from the set expressed in Ada source.
>>>>
>>>> Certainly yes, if you compare UML input with its output. But I don't buy
>>>> this trick. You have to show that the guidance given while connecting
>>>> blocks is better than the guidance given by Ada compiler when compiling Ada
>>>> program. It is NOT.
>>>
>>> Use cases.
>>> Permissible call orders of a type's operations.
>>> Answering questions about program structure at large.
>> 
>> GPS has this sort of stuff (see "tools" in the menu),
> 
> GPS lets me draw actors and actions of use cases?

Use cases are supported through AdaUnit.
 
>>> UML is typed, its universe of things
>>> is full of categorized modeling elements and associated
>>> "operations" (things you can do with them in diagrams).
>> 
>> This equally apply to Assembler. It is a universe of things (registers,
>> commands, labels) and associated operations. It is perfectly typed in the
>> "sense" that MOV R1,R0 is OK, but R0 MOV,R1 is not OK.
> 
> The assembly language universe of things is
> much smaller than Ada's and UML's, obviously, and does not
> include anything like a package or an actor.

It includes the program counter register and other wonderful things.

There is not much difference between Assembler and UML except for their
application domains.

>>>> IS-A at the language level is a relationship between two types. UML does
>>>> not have this.
>>>
>>> UML does not relate its modeling elements?
>> 
>> Yes, what you operate is not what you are.

[...]
> At the level of UML language, items *are* related as
> described by (Meta-)UML, AFAIK (a class model is a ...).

Yes, that is my point. E.g. in Assembler registers and commands are related
as described in the processor handbook.

>>> And even so, I couldn't care less about (meta)programming
>>> in UML.
>> 
>> That is another issue. My point merely was that UML as a language is not as
>> advanced as Ada. Therefore I wonder why do you insist that UML can do more
>> than Ada ever could. That looks illogical.
> 
> It becomes logical when you concentrate on structure:
> static structure, dynamic structure.  I don't want to be
> forced into messy detail, choice of implementation,
> choice of language, just to see the big picture (typed
> picture!).

It replaces one mess with a bigger one:

Messy details: blocks and arrows
Implementation: connecting block with arrows
Language: UML

>>>   type T is new ...
>>>
>>> *expresses* T IS-A ... by employing the word "new" in
>>> this context.
>> 
>> It does not expresses is-a, it constructs a new type.
> 
> Text does not construct anything.  It denotes, with
> the help of an reader interpreting the text.

Denotation is an act of construction in the corresponding computing
context, e.g. in the reader's brain.

> The text "type T is new T0" expresses a relationship
> between T and T0 (T being derived from T0).

No, that would be:

   Assert (T in T0'Class)

>> Relation is a Boolean
>> operation of two arguments. 
> 
> I thought that a relation is a thing between two things.

http://en.wikipedia.org/wiki/Binary_relation

> Assembly language permits the construction of anything
> but no expression of assembly language comes close
> "type T is new T0".  "New" is simply not part of assembly
> language.

Yes, that is because Assembly lacks level necessary to create new reusable
abstractions, just as UML is. All your arguments in favor of UML can be
reduced to just one. UML has some built-in abstractions. It is out of
question whether anybody needs them (I don't). The problem is that UML is
incapable to augment and extend this limited set.

>> you mean that these entities cannot be modeled by values, types,
>> operations, packages?
> 
> You'd need a larger set of Ada constructs, you'd need to choose,
> and you won't have standard elements.

Ada's has a standard. If you are talking about some off the shelf solution,
why a library cannot provide it?

>>> A model element isn't external to the model.
>> 
>> So it has some interface internal to my program,
> 
> First, your "program" is a notion that does not have a counterpart
> in  "model", unless there is a model element for "program".

We are talking about programs, I am not interested in developing something
that does not compute.

>> You have to describe these thing in order to be
>> able to talk to and about them. In Ada it is called interface.
> 
> You'd be creating interfaces in Ada that match the
> repertoire of UML.  Well... Wouldn't you be creating
> a UML tool, then?

Nope, I would create interfaces corresponding to the real thing at hand. I
don't need to mimic poor UML's abstractions.

> But you don't necessarily loose detail when modeling (as opposed
> to programming).

This is a thought opposition, modeling *is* programming using a modeling
language, or Ada. The activity of describing desired behavior by means of
some language is programming independently on the application field.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> UML is absolutely unusable for distributed systems, but I don't want
> to get into it. Suppose I need to invert a 10x10 matrix, and, please,
> no message boxes, customers get fancy when see that mess.

It would be very unproductive to model matrix inversion in UML. You'd
use a library function in your language of choice.

Unless, of course, the problem you have to solve is to invert a
1000000x1000000 matrix over a distributed system, in which case you must
deal with how to distribute the solution; and designing the necessary
software modules and communications between them would be of the
essence. At which point, why would UML be inappropriate? It [can be used
as] a language for discussing problems at an abstract level, so you can
see the wood for the trees.


>>> Relation is a Boolean
>>> operation of two arguments. 
>> 
>> I thought that a relation is a thing between two things.
>
> http://en.wikipedia.org/wiki/Binary_relation

No, no! it's relationship or association, _quite_ a different concept.


There's an excellent article at
http://knol.google.com/k/how-to-build-articulate-uml-class-models by my
hero Leon Starr.

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Dmitry A. Kazakov]

On Thu, 30 Dec 2010 22:05:07 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> UML is absolutely unusable for distributed systems, but I don't want
>> to get into it. Suppose I need to invert a 10x10 matrix, and, please,
>> no message boxes, customers get fancy when see that mess.
> 
> It would be very unproductive to model matrix inversion in UML. You'd
> use a library function in your language of choice.
> 
> Unless, of course, the problem you have to solve is to invert a
> 1000000x1000000 matrix over a distributed system, in which case you must
> deal with how to distribute the solution; and designing the necessary
> software modules and communications between them would be of the
> essence. At which point, why would UML be inappropriate?

For the same reason it would be unproductive to model the matrix inversion
process. Presently I have enough trouble with other modeling tools there.
The recent plaque is all sorts of pseudo-languages describing communication
protocol layers. This is a disaster, far worse than any UML. Nobody can
decipher this mess in order to determine what should actually be put on the
wire.

> It [can be used
> as] a language for discussing problems at an abstract level, so you can
> see the wood for the trees.

Yes, however people forget the meaning of the bubbles at the arrows' ends.
Code snippets are more dense and better convey the idea of the pattern
being discussed.

> There's an excellent article at
> http://knol.google.com/k/how-to-build-articulate-uml-class-models by my
> hero Leon Starr.

"Object oriented methods" by James Martin and James Odell is not bad. I
periodically blow the dust off it, when yet another customer comes with an
idea of requiring UML. Fortunately, this happens less frequently, as years
go by...

Happy New Year,

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Communications of ACM: Sir, Please Step Away from the ASR-33!

[Florian Weimer]

* Randy Brukardt:

> "Florian Weimer" <fw@deneb.enyo.de> wrote in message 
> news:8739pyk6j9.fsf@mid.deneb.enyo.de...
>>* Michael R.:
>>
>>> It's interesting that Ada has already stepped away from ASCII. Many
>>> of the test cases for my ZanyBlue.Text localization support library
>>> contain non-ASCII source, e.g., a test enumeration with identifiers
>>> containing Greek characters:
>>
>> Has the ARG sourted out the mess caused by the combination of
>> non-ASCII identifiers, case insensitivity, and mandatory conversion of
>> enumeration literals to upper case for output purposes?
>>
>> As far as I can tell, this is a classic choose-any-two situation.
>
> Yes, and I can show you the many answers that we have. :-)
>
> Seriously, the Ada 2005 standard really messed that up, and so far as I 
> know, no one ever actually implemented the rules as intended (GNAT surely 
> doesn't).

This matches my testing, but it was recently claimed on this newsgroup
that GNAT implements the standard accurately. 8-/

> I don't think any one would want to have, if the standard was
> followed to the letter, they would have to change the results of
> 'Image to *lower case* (because "convert to upper case" is defined
> as an mapping that maps to lower case characters -- oops) -- which
> of course would be seriously inconsistent with Ada 95 (that is a
> run-time change of results, the worst kind of incompatibility).

Oops indeed.

> We've discussed how to fix this, but a final decision hasn't been made yet. 
> See AI05-0227-1 and especially the discussion on it from the latest ARG 
> meeting (whose minutes I posted Tuesday) -- find both on www.ada-auth.org.

Are there any commercial users of this feature?  I'm sure that some
teaching material needs updating because the extended source character
set is regular used to hype Ada.  But it's very likely that students
will have trouble compiling such source code files, so this capability
will not be used in any central manner.

Myself, I would make the feature obsolescent, and give broad
permissions to implementations when they encounter non-ASCII source
code.  Spending any additional effort on this looks like a complete
waste to me.

By the way, every other HTTP request to www.ada-auth.org results in an
empty result for me.