Re: Ada vs. C++ (Readability)

Re: Ada vs. C++ (Readability)

[Hyman Rosen]

In article <341566c7.0@news.uni-ulm.de>,
Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
>However, looking at some examples I was suddenly struck by frustration:
>There was some code, that obviously could not work!!! At least that's what
>it looked like. Or how would you interpret the lines:
>  ray x, n;
>
>  x = 1.00,  0.40,  -1.00;
>  n = 0.31,  0.20,   0.93;
>
>Surely at first glance whatever type x and n will be, x will be assigned
>the value 1.00, n will be assigned 0.31. The remaining expression is not
>relevant at all from the definition of the colon operator!!!

Well, I would interpret the lines the way they look - assigning a three
element vector to each of the variables. Do you somehow find this to be
unreadable? It looks straightforward to me!

The implementation is cute, of course. You forgot that assignment has
lower precedence than comma. In function syntax, those lines become

	x.operator=(1.00).operator,(0.40).operator,(-1.00);
	n.operator=(0.31).operator,(0.20).operator,(0.93);

The comma operator has been prettily redefined to cause concatenation.

Ada vs. C++ (Readability)

[Joerg Rodemann]

Mr. Trey White brought our attention to expression templates in C++ as they
are used in blitz++. Well, I had a short glance at it and the performance
gains he mentionened are quite impressive to me. Although I do not under-
stand this concept completely by now, probably I took the main principles.
This really seems to be a powerful method for numerics.

However, looking at some examples I was suddenly struck by frustration:
There was some code, that obviously could not work!!! At least that's what
it looked like. Or how would you interpret the lines:
  ray x, n;

  x = 1.00,  0.40,  -1.00;
  n = 0.31,  0.20,   0.93;

Surely at first glance whatever type x and n will be, x will be assigned
the value 1.00, n will be assigned 0.31. The remaining expression is not
relevant at all from the definition of the colon operator!!!

This is truly the worst case I ever saw with respect of using side effects
and I am very convinced that this will cause a lot of confusion when those
members who developped the library have changed the employer. Look how
much confusion are already cause by normal C macros because the look like
functions with a specific calling convention but are merely text replacements.
I think: such extensions may be reasonable if noticeable. But here you wont
even recognize the "," comes from blitz++.

For me it comes to this: it maybe a good tool if high computing performance
is needed for a short-living, small project. If you want reusability and
maintainability, use something more explicit (and accept the loss of
performance). Maybe I am no god wrt programming skills but the C or C++
syntax already holds enough pitfalls for a programmer new to a existing
project to guess "what the fuck is it doing here?" (Sorry for the speech.)

Sorry, if this comment is somewhat harsh, but maybe you try to read some
code written by someone else using the mentioned library. Certainly you
will notice my excitement soon. If now I'll bow deeply at your feet for
you must be a real god... ;->

My personal opinion only

Yours

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Ada vs. C++ (Readability)

[Simon Wright]

hymie@panix.com (Hyman Rosen) writes:

> In article <341566c7.0@news.uni-ulm.de>,
> Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
> >However, looking at some examples I was suddenly struck by frustration:
> >There was some code, that obviously could not work!!! At least that's what
> >it looked like. Or how would you interpret the lines:
> >  ray x, n;
> >
> >  x = 1.00,  0.40,  -1.00;
> >  n = 0.31,  0.20,   0.93;
> >
> >Surely at first glance whatever type x and n will be, x will be assigned
> >the value 1.00, n will be assigned 0.31. The remaining expression is not
> >relevant at all from the definition of the colon operator!!!
> 
> Well, I would interpret the lines the way they look - assigning a three
> element vector to each of the variables. Do you somehow find this to be
> unreadable? It looks straightforward to me!
> 
> The implementation is cute, of course. You forgot that assignment has
> lower precedence than comma. In function syntax, those lines become
> 
> 	x.operator=(1.00).operator,(0.40).operator,(-1.00);
> 	n.operator=(0.31).operator,(0.20).operator,(0.93);
> 
> The comma operator has been prettily redefined to cause concatenation.

This view of life is _exactly_ why I deprecate the use of C++ at our
shop (there are of course all too many reasons relating to the
availability of libraries/programmers/tools why it's a hard struggle).

Compare

  for (int i = 1, int j = 2; ..

with

  for (ray x = 1, 2, 3, int j = 2; ..

If you could do it using braces it would be much better:

  x = {1.00,  0.40,  -1.00};

To redefine "," like this is "clever"/"cute" but not "pretty";
certainly not from the view of the maintainer, and we spend a _lot_ of
our customers' money maintaining code.

I was about to suggest that maybe "<<" would be a less confusing
operator to redefine, but I suppose that that's only because all C++
programmers already _know_ that "<<" bas been botched about ..

-- 
Simon Wright                        Work Email: simon.j.wright@gecm.com
GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
Command & Information Systems Divsion            FAX: +44(0)1705-701800

Re: Ada vs. C++ (Readability)

[Joerg Rodemann]

Hyman Rosen (hymie@panix.com) wrote:

> In article <341566c7.0@news.uni-ulm.de>,
> Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
> >  x = 1.00,  0.40,  -1.00;
> >

> Well, I would interpret the lines the way they look - assigning a three
> element vector to each of the variables. Do you somehow find this to be
> unreadable? It looks straightforward to me!

> The implementation is cute, of course. You forgot that assignment has
> lower precedence than comma. In function syntax, those lines become

> 	x.operator=(1.00).operator,(0.40).operator,(-1.00);
> 	n.operator=(0.31).operator,(0.20).operator,(0.93);

Whoops...seems I messed up the precedence rules. Guess how often I use the
comma operator...?!! Well, many apologies for that here. I should have thought
twice about it.

> The comma operator has been prettily redefined to cause concatenation.

Nevertheless, I can't help to think overloading here is not a good idea if
you want someone else to read this. The only hint that the first two 
numbers are not omitted is that x is of type ray. Sure, once you know what
is meant here it is a neat way for assigning vectors, at least if their
dimension is not very high. I believe overloading is nice when the meaning
of the operator/function is clearly to be guessed from its name or standard
meaning. That is: you provide an abstract operation that has different 
implementations for each type. In this case the actual type is just relevant
to get that function signature right (and the compiler can check that) but
the general meaning should be obvious. IMHO this is not the case for the
example above. 

Another comment, or question, about the expression templates: what about
type safety? I understand that C++ templates are not in any way type safe
wrt the instantion parameters. (E.g. try a list template with a print 
method that calls the type's print method...and instantiate that with an
int or float.) I have not looked at the source of blitz++ nor have I any
deep insights into expression templates at all so this is probably a 
question to the authors? Could you please clarify that?

Sorry for the confusion again,

yours

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Ada vs. C++ (Readability)

[Robert Dewar]

Jeorg says

<<> The comma operator has been prettily redefined to cause concatenation>>

UGH! what a perfect illustration of the dangers of such capabilities. Whenever
someone thinks they have done something clever, as in this case, they have
often created an unreadable, unmaintainable nasty!

Re: Ada vs. C++ (Readability)

[Hyman Rosen]

In article <dewar.873999270@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
><<> The comma operator has been prettily redefined to cause concatenation>>
>
>UGH! what a perfect illustration of the dangers of such capabilities. Whenever
>someone thinks they have done something clever, as in this case, they have
>often created an unreadable, unmaintainable nasty!

What exactly is it about 'ray x = 1, 2, 3;' that you find unreadable?
The overloading lets you write vector and matrix initializations in a
completely transparent fashion. The reason for the existence of
operator overloading is exactly so that natural-looking notation does
what it appears to do.

In any case, this is part of the interface of a library for high-speed
computation, and is described clearly in that library's documentation
and examples. I would expect that someone maintaining this code would
first acquaint themselves with this, if they are to have any chance of
success at all.

Re: Ada vs. C++ (Readability)

[Hyman Rosen]

In article <3416458e.0@news.uni-ulm.de>,
Joerg Rodemann <rodemann@mathematik.uni-ulm.de> wrote:
>Nevertheless, I can't help to think overloading here is not a good idea if
>you want someone else to read this. The only hint that the first two 
>numbers are not omitted is that x is of type ray.

I would expect that anyone maintaining this code is going to first acquire
some knowledge of the libraries involved, or else they are not going to
succeed very well. The documentation for Blitz++ and the exmaples provided
describe and explain this usage for creating Arrays.

>Another comment, or question, about the expression templates: what about
>type safety? I understand that C++ templates are not in any way type safe
>wrt the instantion parameters.

Expression templates are completely typesafe, as are C++ templates in
general. It's easiest if you think of templates as a fancy macro facility.
The code which results from instantiating a template with specific types
and values is typesafe in the same way that writing the equivalent code
by hand would be.

It's true that C++ templates give you no way of formally stating the
operations that the generic parameters must support. Instead, C++ relies
on "legality by usage". If the result of an instantiation is legal code
given the specific types, then everything is fine. If the type does not
support some operation that the template requires, and that part of the
template is actually used, then the compiler will give you an appropriate
error message.

Re: Ada vs. C++ (Readability)

[Joerg Rodemann]

Hyman Rosen (hymie@panix.com) wrote:
> In article <dewar.873999270@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
>  wrote:
> >UGH! what a perfect illustration of the dangers of such capabilities.
> > Whenever
> >someone thinks they have done something clever, as in this case, they have
> >often created an unreadable, unmaintainable nasty!

> What exactly is it about 'ray x = 1, 2, 3;' that you find unreadable?
> The overloading lets you write vector and matrix initializations in a
> completely transparent fashion. The reason for the existence of
> operator overloading is exactly so that natural-looking notation does
> what it appears to do.

The problem we (or at least I) have with this is, that it is not a typical
statement in C++. It is not what a developper comfortable with C++ would
expect about this. If you want to design a new language then do so (as 
the Fortran people think about a simpler language called F(?) ). But think
about it: the training of new team member does contribute to the project's
costs as well. And sure, no one would expect e.g. Lisp code in Ada source.
It is one of the troubling things about macros and overloading: they may
lead to unexpected surprises. Say, there is an new library and you want to
keep your code as much as possible. Of course you have to change the type
names and...oops...suddely the comma has its usual meaning again. How
much time are you willing to search for such a bug? You see our concerns
are about the future of your programs: reusing, maintaining, extending.
Certainly this is something the numerics folks often do not care much about.
At least from my experiences.

> In any case, this is part of the interface of a library for high-speed
> computation, and is described clearly in that library's documentation
> and examples. I would expect that someone maintaining this code would
> first acquaint themselves with this, if they are to have any chance of
> success at all.

Hope the documentation is complete and up to date. :-) Especially if none
of the former experts is reachable any more.

Regards

Joerg

--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Ada vs. C++ (Readability)

[Richard A. O'Keefe]

hymie@panix.com (Hyman Rosen) writes:
>What exactly is it about 'ray x = 1, 2, 3;' that you find unreadable?

The fact that the comma operator has a standard reading which is completely
at variance with this one.  Overloading one sequencing operator (comma)
makes precisely as much sense as overloading the other sequencing symbol
(semicolon).  Especially in a declaration, I invite you to consider

	int y;
	ray x = 1, 2, y = 3, 4;

Is this a _legal_ declaration for a ray x where one component is the
value of the assignment y = 3, or is it an _illegal_ attempt to declare
two rays, one of the called x and initialised to 1, 2 and the other
called y and initialised to 3, 4.  Does the answer change if the first
declaration of y is deleted?

I note that the C9X standard introduces in-line aggregates, so that e.g.

	ray x(3, (int[]){0, 1, 2});

would be possible.  The sooner C++ gets this, the better.


>The overloading lets you write vector and matrix initializations in a
>completely transparent fashion.

It is not _completely_ transparent, because these comma operations can
occur in syntactic contexts where the _other_ readings of comma are
available, as shown above.

>In any case, this is part of the interface of a library for high-speed
>computation, and is described clearly in that library's documentation
>and examples. I would expect that someone maintaining this code would
>first acquaint themselves with this, if they are to have any chance of
>success at all.

That's not the problem.  The problem is that _even when you know what it
means_, it still appears ambiguous.


-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.