* Re: next "big" language?? (disagree)
[not found] <4p0fdd$4ml@news.atlantic.net>
@ 1996-06-04 0:00 ` Peter Hermann
1996-06-04 0:00 ` The Amorphous Mass
` (6 more replies)
1996-06-06 0:00 ` next "big" language?? (disagree) Dale Pontius
` (3 subsequent siblings)
4 siblings, 7 replies; 100+ messages in thread
From: Peter Hermann @ 1996-06-04 0:00 UTC (permalink / raw)
Kurt Johmann (johmann@moal.com) wrote:
: Programming languages are almost completely subjective, because the only
I strongly disagree
: minds apparently like that kind of enforced discipline (masochist types,
: perhaps :-), but to my mind it was a build-your-own-straightjacket-and-
: wear-it kind of approach to programming.
the opposite is true: a professional is always thankful for every
hint from the compiler or environment for potential errors.
Working with languages of the past like Fortran or C is true
masochism. I have worked on very large systems in Fortran
(one was a half million source lines of code, the other 300_000 sloc)
and we had to run the systems on every hardware brand.
I can see no advantage to allow e.g. a memory overwrite error,
by accident, or, e.g. an outside range value at run time or
a wrong subroutine call due to bad parameter profile.
When I decide, as a programmer, that a peculiar type or
variable may have a value in the range from 1 to 9, can you please
explain me why it should be useful to assign a value of 10 or
4711 or -1234?
I will justify the value of that freedom in your favour:
This has the big advantage that the typical Fortran, C, or C++
programmer being not immediately aware of an erroneous code
is happy to catch the error all-day-long and when the day is done,
he is proud to have found this bug and fully convinced to
have fulfilled his work of the day.
In contrast, a poor Ada programmer does not have this fun:
a potential error is revealed at the moment of the very first
compilation/execution. What a pity! No fun at all ;-(
The product life cycle is shortened. No bug chasing.
no extra lint steps, because its unfortunately in
the language design.
btw: Ada is the first useful (and even readable) Pascal
with free compilers running on any platform
--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
@ 1996-06-04 0:00 ` The Amorphous Mass
1996-06-04 0:00 ` Peter Hermann
` (2 more replies)
1996-06-05 0:00 ` ++ robin
` (5 subsequent siblings)
6 siblings, 3 replies; 100+ messages in thread
From: The Amorphous Mass @ 1996-06-04 0:00 UTC (permalink / raw)
On 4 Jun 1996, Peter Hermann wrote:
> Kurt Johmann (johmann@moal.com) wrote:
> : Programming languages are almost completely subjective, because the only
>
> I strongly disagree
Why? If they were not subjective then programming languages would all
be very similar.
> : minds apparently like that kind of enforced discipline (masochist types,
> : perhaps :-), but to my mind it was a build-your-own-straightjacket-and-
> : wear-it kind of approach to programming.
>
[snip]
> I can see no advantage to allow e.g. a memory overwrite error,
> by accident, or, e.g. an outside range value at run time or
> a wrong subroutine call due to bad parameter profile.
> When I decide, as a programmer, that a peculiar type or
> variable may have a value in the range from 1 to 9, can you please
> explain me why it should be useful to assign a value of 10 or
> 4711 or -1234?
>
> btw: Ada is the first useful (and even readable) Pascal
> with free compilers running on any platform
_Any_ platform? You mean I could fire it up on my little 68020-powered
Mac with its expansive 4MB of memory and galactic 80MB hard drive and
enjoy the full benefits of Ada's rich set of features? Or is there a
cost to having a language that does everything, an environment that does
everything, and a compiler that does everything?
My C compiler takes up 5.1MB on my hard drive and runs in just under 1MB
of RAM. That's with full support for the Mac Toolbox and an
object-oriented extention to the language, plus a class library for the
Mac GUI and a nice debugger. Are there any Ada compilers that can say that?
I think you're assuming that everyone is deveoping a huge, complex
project with 100 teams of 100 programmers each working on mainframes with
350MHz Alphas and 256MB of RAM (OK, I'm exaggerating a little :-). Those
of us lone programmers who put speed and space at a premium are willing
to go hunting for stray pointers as a necessary cost of using a small,
fast language.
Besides, Ada is not the only big, safe, feature-laden, industrial-strength
language out there. So obviously there are people who would agree
wholeheartedly with your argument, but who would then disagree that Ada
would be the best language to use for "professional" programming. The
nature of that disagreement is, of course, subjective.
- James "Good candidates for exceptions are situations
james-robinson@uiowa.edu that do not occur under normal circumstances."
-- Kevin J. Hopps
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` The Amorphous Mass
@ 1996-06-04 0:00 ` Peter Hermann
1996-06-04 0:00 ` The Amorphous Mass
1996-06-04 0:00 ` Robert Dewar
1996-06-05 0:00 ` next "big" language?? (disagree) Ian Ward
2 siblings, 1 reply; 100+ messages in thread
From: Peter Hermann @ 1996-06-04 0:00 UTC (permalink / raw)
The Amorphous Mass (robinson@blue.weeg.uiowa.edu) wrote:
[snip]
: I think you're assuming that everyone is deveoping a huge, complex
: project with 100 teams of 100 programmers each working on mainframes with
: 350MHz Alphas and 256MB of RAM (OK, I'm exaggerating a little :-). Those
not at all.
My home PC is a 486 which I recently upgraded from 8 to 24MB RAM.
The reason was an application which steadily grew complex.
(btw, a simple DOS application, but very useful ;-) ).
The 8MB were fine for GNAT (the GNU Ada95 translator) as long as
I did not use excessive generic abstraction. However, with the
need of dynamically requested space during compilation of
a demanding logical architecture, the 8MB did not satisfy
the compilation process. The size is NOT in terms of lines of code.
A few keystrokes for a coding-abstraction generates temp space
for the compilation process.
The result is an executable of a few KILObytes,
where the compiler has done all optimization before. ;-)
: of us lone programmers who put speed and space at a premium are willing
: to go hunting for stray pointers as a necessary cost of using a small,
: fast language.
I better leave this hunting to a compiler.
(btw: the pointer concept in Ada does not allow dangling pointers)
:Besides, Ada is not the only big, safe, feature-laden, industrial-strength
Ada is not big, safe, feature-laden, but industrial-strength and
shaped with that minimum of features to compete as a general purpose
object-oriented language (with concurrency and real-time capability).
: language out there. So obviously there are people who would agree
: wholeheartedly with your argument, but who would then disagree that Ada
: would be the best language to use for "professional" programming. The
: nature of that disagreement is, of course, subjective.
James, you will certainly agree that a state-of-the-art PC
sold today will have a minimum of 16MB/800MB/80MHz, don't you?
This is much larger than needed for the free GNAT3.04 which
simply requires 12MB(ram)/20MB(disk) space.
The idea is: Developing on a commonly used PC or workstation
and cross-compiling to a target e.g. an embedded system,
small computer, or even an 8051 field processor.
The developer has the flavor of object-orientedness,
genericity, etc. and the executable will easily fit into a
heart pacer, if needed.
To come to an end:
One of the great potentials of the future are reusable software elements.
--
Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` Peter Hermann
@ 1996-06-04 0:00 ` The Amorphous Mass
1996-06-05 0:00 ` Michael David WINIKOFF
0 siblings, 1 reply; 100+ messages in thread
From: The Amorphous Mass @ 1996-06-04 0:00 UTC (permalink / raw)
On 4 Jun 1996, Peter Hermann wrote:
> The Amorphous Mass (robinson@blue.weeg.uiowa.edu) wrote:
> [snip]
> : I think you're assuming that everyone is deveoping a huge, complex
> : project with 100 teams of 100 programmers each working on mainframes with
> : 350MHz Alphas and 256MB of RAM (OK, I'm exaggerating a little :-). Those
>
> not at all.
> My home PC is a 486 which I recently upgraded from 8 to 24MB RAM.
> The reason was an application which steadily grew complex.
> (btw, a simple DOS application, but very useful ;-) ).
> The 8MB were fine for GNAT (the GNU Ada95 translator) as long as
> I did not use excessive generic abstraction. However, with the
> need of dynamically requested space during compilation of
> a demanding logical architecture, the 8MB did not satisfy
> the compilation process. The size is NOT in terms of lines of code.
> A few keystrokes for a coding-abstraction generates temp space
> for the compilation process.
> The result is an executable of a few KILObytes,
> where the compiler has done all optimization before. ;-)
Right. And my concern is not final executable size, because I'm sure
Ada is just as subject to optimization as many other languages
(especially if it has some way to guarantee against aliasing). It's
development bloat. On of the reasons I refuse to give up my "obsolete"
machine is that I see the new ones are much less stable (this box only
crashes if I run Microsoft Word for too long, but that's Microsoft...)
and the compilers are bloated, slow and bug-ridden.
> Ada is not big, safe, feature-laden, but industrial-strength and
> shaped with that minimum of features to compete as a general purpose
> object-oriented language (with concurrency and real-time capability).
Really? Then where did I hear the complaint about every Ada programmer
using a different language? I will admit that as I have not been exposed
to the language in depth, my statements are less accusations and more
questions. I'm quite happy to be corrected. FWIW I'm very taken by
Miranda, although I do wish they'd port it to something besides Unix.
> : language out there. So obviously there are people who would agree
> : wholeheartedly with your argument, but who would then disagree that Ada
> : would be the best language to use for "professional" programming. The
> : nature of that disagreement is, of course, subjective.
>
> James, you will certainly agree that a state-of-the-art PC
> sold today will have a minimum of 16MB/800MB/80MHz, don't you?
State of the art is 24MB/2GB/166MHz for PCs, with slightly lower numbers
for Macs. Alphas are up to 350MHz(!). Of greater concern is what a run of
the mill PC/Mac/whatever is equipped with. 8MB RAM is not uncommon,
although 16MB is becoming more prevalent. Of course, OSes and
applications which hog all that space are also becoming more prevalent...
> One of the great potentials of the future are reusable software elements.
They're also one of the great dangers of the future. I keep a fairly
substantial library of useful little functions that I've written over the
3 or so years I've been programming in C, and their reusability is greatly
enhanced by the fact that I can tweak the code a little for particular
applications. By contrast, at work we're trying to get this souped-up OO
development platform to talk to an edits package written in C (the
development platform is written in C++) and we keep getting errors
concerning classes that we didn't know existed, whose purpose is completely
unknown to us and undocumented, apropos problems that no amount of
debugging has revealed sofar, because the code and the interface is at
such a high level that the programmer only has the most notional control
over what's actually happening. The classes will doubtless get used
over and over again, but too much of our development time consists of
waiting for support to call back.
I'm thus wary of the idea of "code reuse." Not dismissive, just wary.
/**James Robinson***********************
"If a fatal error occurs, the program should not be allowed to continue."
-- Oracle Pro*C User's Guide *************james-robinson@uiowa.edu**/
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` The Amorphous Mass
@ 1996-06-05 0:00 ` Michael David WINIKOFF
1996-06-07 0:00 ` Robert Dewar
0 siblings, 1 reply; 100+ messages in thread
From: Michael David WINIKOFF @ 1996-06-05 0:00 UTC (permalink / raw)
The Amorphous Mass <robinson@blue.weeg.uiowa.edu> writes:
>On 4 Jun 1996, Peter Hermann wrote:
> Really? Then where did I hear the complaint about every Ada programmer
>using a different language? I will admit that as I have not been exposed
>to the language in depth, my statements are less accusations and more
>questions. I'm quite happy to be corrected. FWIW I'm very taken by
>Miranda, although I do wish they'd port it to something besides Unix.
Try Gofer.
Gofer is quite similiar to Miranda, is free and has been ported to
many machines (Unix, DOS, Windows, Mac, Amiga, Acorn etc.)
It's a byte code interpreter / interactive environment.
(Similar to Miranda).
From the comp.lang.functional FAQ:
Gofer
The Gofer system provides an interpreter for a small language based closely
on the current version of the Haskell report. In particular, Gofer supports l
azy
evaluation, higher-order functions, polymorphic typing, pattern-matching,
support for overloading, etc.
The most recent version of Gofer, 2.30a, is available by ftp:
ftp.cs.nott.ac.uk/nott-fp/languages/gofer.
Gofer runs on a wide range of machines including PCs, Ataris, Amigas, etc.
as well as larger Unix-based systems. A version for the Apple Macintosh has
been produced and is available by anonymous ftp from ftp.dcs.glasgow.ac.uk
in the directory pub/haskell/gofer/macgofer.
Please note the spelling, derived from the notion that functional languages a
re
GO(od) F(or) E(quational) R(easoning). This is not to be confused with
`Gopher', the widely used Internet distributed information delivery system!
--
Michael Winikoff winikoff@cs.mu.oz.au http://www.cs.mu.oz.au/~winikoff
Computer science postgrad. University of Melbourne, Australia.
CC/C/B iv++ u c 3/2/4 r(-) f++(+) h p+ o+ s+(++) d y? SYC-(P)FF CWF BDB MUF AIA
How many Prolog programmers does it take to change a lightbulb?
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` Michael David WINIKOFF
@ 1996-06-07 0:00 ` Robert Dewar
0 siblings, 0 replies; 100+ messages in thread
From: Robert Dewar @ 1996-06-07 0:00 UTC (permalink / raw)
"> Really? Then where did I hear the complaint about every Ada programmer
>using a different language? I will admit that as I have not been exposed
>to the language in depth, my statements are less accusations and more
>questions. I'm quite happy to be corrected. FWIW I'm very taken by
>Miranda, although I do wish they'd port it to something besides Unix."
If Miranda seems interesting, take a closer look at Haskel, which is widely
available, and I think represents a much more comperhensive approach to
the issue of applicative lazy semantics.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` The Amorphous Mass
1996-06-04 0:00 ` Peter Hermann
@ 1996-06-04 0:00 ` Robert Dewar
1996-06-06 0:00 ` Ken Garlington
1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group
1996-06-05 0:00 ` next "big" language?? (disagree) Ian Ward
2 siblings, 2 replies; 100+ messages in thread
From: Robert Dewar @ 1996-06-04 0:00 UTC (permalink / raw)
" _Any_ platform? You mean I could fire it up on my little 68020-powered
Mac with its expansive 4MB of memory and galactic 80MB hard drive and
enjoy the full benefits of Ada's rich set of features? Or is there a
cost to having a language that does everything, an environment that does
everything, and a compiler that does everything?"
No, you cannot run Ada on arbitrary obsolete machines, but you certainly
can run Ada on typical current Mac's and PC's. You actually aren't too
far away from being able to run Ada on your machine. Buy a bit more
memory and an external drive, and there is a 68K version of Mac/Ada
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` Robert Dewar
@ 1996-06-06 0:00 ` Ken Garlington
1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group
1 sibling, 0 replies; 100+ messages in thread
From: Ken Garlington @ 1996-06-06 0:00 UTC (permalink / raw)
Robert Dewar wrote:
>
> " _Any_ platform? You mean I could fire it up on my little 68020-powered
> Mac with its expansive 4MB of memory and galactic 80MB hard drive and
> enjoy the full benefits of Ada's rich set of features? Or is there a
> cost to having a language that does everything, an environment that does
> everything, and a compiler that does everything?"
>
> No, you cannot run Ada on arbitrary obsolete machines, but you certainly
> can run Ada on typical current Mac's and PC's. You actually aren't too
> far away from being able to run Ada on your machine. Buy a bit more
> memory and an external drive, and there is a 68K version of Mac/Ada
Actually, given the original spec (Mac 68020 with 4MB of memory,
80MB hard drive) you _can_ run Ada _83_. I know; I did for years on my MacII,
which is a 68020-class machine with 4MB of memory and 40MB of memory (using
Meridian). For obsolete machines, you should obviously use obsolete Ada. :)
Then, once you come to your senses and buy a new Mac, you can have a new Ada
to go with it, which should allow you to reuse a lot of your 83 code.
The _real_ question is: When I upgrade, do I want to spend more time building
native applications with GNAT, or applets with AppletMagic?
--
LMTAS - "Our Brand Means Quality"
^ permalink raw reply [flat|nested] 100+ messages in thread
* Help making ada pretty
1996-06-04 0:00 ` Robert Dewar
1996-06-06 0:00 ` Ken Garlington
@ 1996-06-12 0:00 ` CSC Trusted Systems Group
1996-06-14 0:00 ` Sandy McPherson
1996-06-19 0:00 ` Ruediger Berlich
1 sibling, 2 replies; 100+ messages in thread
From: CSC Trusted Systems Group @ 1996-06-12 0:00 UTC (permalink / raw)
Hi,
I am looking for any tools around to print ada-code in a more presentable
form, ie keywords bolded etc. apparently they sometimes go by the name
"pretty printers", however I do not want to rejustify the code in any
way, I only require the bolding type features.
Also am looking for any latex tools for typesetting ada.
as I rarely have time to read mews replies to csctsg@adam.com.au would
greatly be appreciated
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Help making ada pretty
1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group
@ 1996-06-14 0:00 ` Sandy McPherson
1996-06-19 0:00 ` Ruediger Berlich
1 sibling, 0 replies; 100+ messages in thread
From: Sandy McPherson @ 1996-06-14 0:00 UTC (permalink / raw)
IcnoC
Therefore discontinue this thread now!!!!!!
--
Sandy McPherson MBCS CEng. tel: +31 71 565 4288 (w)
ESTEC/WAS +31 527 68 1314 (h)
P.O. Box 299
NL-2200AG Noordwijk
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Help making ada pretty
1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group
1996-06-14 0:00 ` Sandy McPherson
@ 1996-06-19 0:00 ` Ruediger Berlich
1 sibling, 0 replies; 100+ messages in thread
From: Ruediger Berlich @ 1996-06-19 0:00 UTC (permalink / raw)
CSC Trusted Systems Group (csctsg@adam.com.au) wrote:
: Hi,
: I am looking for any tools around to print ada-code in a more presentable
: form, ie keywords bolded etc. apparently they sometimes go by the name
: "pretty printers", however I do not want to rejustify the code in any
: way, I only require the bolding type features.
: Also am looking for any latex tools for typesetting ada.
: as I rarely have time to read mews replies to csctsg@adam.com.au would
: greatly be appreciated
Hi,
if you have xemacs (ver. 19.13) around , you could try to use
the syntax-hilighting-function.
Highlighting via different fonts (bold,italic, also possible via
colours) is available from the menus by a simple mouse-click.
Since xemacs is able to print postscript, you can print out
the highlighted program.
This is the way I usually print C/C++ and Fortran-programs.
Since I only just started programming in Ada (yesterday :-)
I haven't tried to print Ada-code from xemacs. I only know that there is an
Ada-mode for xemacs and that it can highlight keywords, comments, ...
Printing should be easy then.
Use the command
<ESC>-<x> ps-print-buffer-with-faces <RETURN>
to print the higlighted buffer.
Please be aware, that I'm not talking about the X-version of GNU-emacs
but about the emacs-version formerly known as Lucid-emacs, which is
now for some unknown reason called xemacs.
This has a pretty nice X/Motif-Interface. It is available for free
from the same places where you get GNU-emacs.
Otherwise check out
http://xemacs.cs.uiuc.edu/
It also does automatic indentation of the program, if you want that.
Bye and have a nice day,
Ruediger Berlich
[berlich@pc66.mppmu.mpg.de]
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` The Amorphous Mass
1996-06-04 0:00 ` Peter Hermann
1996-06-04 0:00 ` Robert Dewar
@ 1996-06-05 0:00 ` Ian Ward
1996-06-05 0:00 ` The Amorphous Mass
2 siblings, 1 reply; 100+ messages in thread
From: Ian Ward @ 1996-06-05 0:00 UTC (permalink / raw)
On June the Fourth, 1996, James Robinson (The Amorphous Mass) wrote
---
> Those of us lone programmers who put speed and space at a premimum
> are willing to go hunting for stray pointers as a necessary cost
> of using a small, fast language.
If I hear the implication that Ada is not fast just one more time
I think I will scream. The whole perpetuation of this myth is carried
by Chinese whispers from feature obsessive people who used complicated
Ada constructs, TEN years ago, (before compiler writes had devised
efficient implementations.) These people left the Ada scene and have
not looked at it since.
Nine times out of ten it is just as fast as 'C' or assembler or anything
else.
> Besides, Ada is not the only big, safe, feature-laden, industrial-strength
> language out there. So obviously there are people who would agree
> wholeheartedly with your argument, but who would then disagree that Ada
> would be the best language to use for "professional" programming. The
> nature of that disagreement is, of course, subjective.
And then later that day, he said -
> They're also one of the great dangers of the future. I keep a fairly
> substantial library of useful little functions that I've written over the
> 3 or so years I've been programming in C, and their reusability is greatly
> enhanced by the fact that I can tweak the code a little for particular
> applications. By contrast, at work we're trying to get this souped-up OO
> development platform to talk to an edits package written in C (the
> development platform is written in C++) and we keep getting errors
> concerning classes that we didn't know existed, whose purpose is completely
> unknown to us and undocumented, apropos problems that no amount of
> debugging has revealed sofar, because the code and the interface is at
> such a high level that the programmer only has the most notional control
> over what's actually happening. The classes will doubtless get used
> over and over again, but too much of our development time consists of
> waiting for support to call back.
> I'm thus wary of the idea of "code reuse." Not dismissive, just wary.
The first question, James, I must ask is, is C++ your idea of an alternative?
You say that Ada is not the only big, safe, feature laden, industrial-
strength language, (mischien) but then go on to give actual real
evidence as why C++ isn't. All your arguments against Ada are based on
inaccurate hearsay, and all of your arguments against C++ are based on your
own actual experience. Why are you arguing against Ada, if I was in your
shoes, I should be saying that C++ is crap, and trying to use something
that prevents the errors that everybody there seems to be experiencing.
C++ is not crap at all of course, I am still learning it, but it simply
is trying to evolve into a language which is fundamentally different
in concept to its parent. A lot more than one generation of evolution
will be need for such a radical change in language aim.
Software reuse is not the problem, and neither is Object oriented
design. In this case of yours, it appears that it is a bad implementation
of C++ that seems to be behind it. Of course, at this point we can go
into how it came to be a bad implementation.
I am not going to though, I will simply say that if I were to end up
using software, where in the background, side effects of it were
detrimentally affecting mine, that I could not even find, then I WOULD
use something else. Bruce Lee said, "If it works, use it." It clearly
is not working. Anything else must be better? Why are you not trying
to convince your boss to use something else? Anything else?
Best regards, hope it is as hot there as it is here,
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
It's "burgled" Mr. President, not burglarised.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` next "big" language?? (disagree) Ian Ward
@ 1996-06-05 0:00 ` The Amorphous Mass
1996-06-08 0:00 ` Robert Dewar
1996-06-08 0:00 ` Robert Dewar
0 siblings, 2 replies; 100+ messages in thread
From: The Amorphous Mass @ 1996-06-05 0:00 UTC (permalink / raw)
On 5 Jun 1996, Ian Ward wrote:
> On June the Fourth, 1996, James Robinson (The Amorphous Mass) wrote
> ---
>
> > Those of us lone programmers who put speed and space at a premimum
> > are willing to go hunting for stray pointers as a necessary cost
> > of using a small, fast language.
>
> If I hear the implication that Ada is not fast just one more time
> I think I will scream.
I was not implying that Ada executables are slow (although your
complaint is understandable -- I should have said "a language that
allows for a small, fast environment"). I was trying to say that the
environment and compile times for Ada would be big and/or slow, for the
simple reason that the language offers a great deal more support than C
does. As I have said in this thread I'm sure Ada is just as subject to
efficient compiling and optimizing techniques as other languages are, and
almost as fast as C. :-)
[re: "reusable code modules"]
> > They're also one of the great dangers of the future. I keep a fairly
> > substantial library of useful little functions that I've written over the
> > 3 or so years I've been programming in C, and their reusability is greatly
> > enhanced by the fact that I can tweak the code a little for particular
> > applications. By contrast, at work we're trying to get this souped-up OO
> > development platform to talk to an edits package written in C (the
> > development platform is written in C++) and we keep getting errors
> > concerning classes that we didn't know existed, whose purpose is completely
> > unknown to us and undocumented, apropos problems that no amount of
> > debugging has revealed sofar, because the code and the interface is at
> > such a high level that the programmer only has the most notional control
> > over what's actually happening. The classes will doubtless get used
> > over and over again, but too much of our development time consists of
> > waiting for support to call back.
> > I'm thus wary of the idea of "code reuse." Not dismissive, just wary.
>
> The first question, James, I must ask is, is C++ your idea of an alternative?
No. C++ is great fun to play with but I don't consider it an
attractive alternative because it's far too easy to shoot yourself in
the foot, and because it's a write-your-own-language language that can
make reading or modifying someone else's code a nontrivial exercize. I was
thinking more along the lines of Mercury or Miranda or even Delphi, or
(arguably) the resurgent PL/I. This is not to say that C++ is not useful
for development, but the programmer has to be very thorough and very careful.
> You say that Ada is not the only big, safe, feature laden, industrial-
> strength language, (mischien) but then go on to give actual real
> evidence as why C++ isn't.
You assume that I am comparing Ada to C++. I am not. Given the
choice as a dev. platform, I would probably pick Ada. I was comparing Ada
to C, which is an apples and oranges comparison, with the explicit intent of
demonstrating that sometimes you want an apple and sometimes you want an
orange. :-)
> Software reuse is not the problem, and neither is Object oriented
> design. In this case of yours, it appears that it is a bad implementation
> of C++ that seems to be behind it. Of course, at this point we can go
> into how it came to be a bad implementation.
It's a perfectly fine, even ingenious implementation.If anything, it's
a sterling example of a well-written C++ application. When you
work within its parameters it runs beautifully, even distributed across
platforms running 4 different OSs. When you try to stretch its
capabilities (which is what we're doing) then you start to see all the
stuff that's supposed to be 'transparent.' That was my point, and that
_is_ a problem with software reuse, and a risk with OO design.
> I am not going to though, I will simply say that if I were to end up
> using software, where in the background, side effects of it were
> detrimentally affecting mine, that I could not even find, then I WOULD
> use something else. Bruce Lee said, "If it works, use it." It clearly
> is not working. Anything else must be better? Why are you not trying
> to convince your boss to use something else? Anything else?
Frankly, I can't think of anything better. We looked all over, and
this is the best there was. Remember, the problem is not that it fails
to work as advertized, and it is not that it is unstable or buggy or
unpredictable. The problem is that if you try to do something a little
bit different from what it's designed for it stops being friendly and
starts being obscure. By contrast, if I want one of my C libraries
to do something a bit different, I just go in and modify them.
Does my argument make more sense to you now?
--James Robinson (robinson@cs.uiowa.edu -or- james-robinson@uiowa.edu)
/* Indeed, C++ is a bit of an oddball of a language ... given the way that *
* it requires private parts to be visible. This increases the strength of *
* coupling dramatically... -- Dr. Rich Artym */
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` The Amorphous Mass
@ 1996-06-08 0:00 ` Robert Dewar
1996-06-08 0:00 ` The Amorphous Mass
1996-06-08 0:00 ` Robert Dewar
1 sibling, 1 reply; 100+ messages in thread
From: Robert Dewar @ 1996-06-08 0:00 UTC (permalink / raw)
James Robinson said
" Frankly, I can't think of anything better. We looked all over, and
this is the best there was. Remember, the problem is not that it fails
to work as advertized, and it is not that it is unstable or buggy or
unpredictable. The problem is that if you try to do something a little
bit different from what it's designed for it stops being friendly and
starts being obscure. By contrast, if I want one of my C libraries
to do something a bit different, I just go in and modify them."
This is as wrong as it could be, and basically could only be written by
someone who has not understood the whole point of data abstraction,
using the term widely to encompass object oriented programming as well.
The whole point of abstraction is to make it easier to reuse code.
C has advantages, particularly in the simplicity of its computing model,
and simple syntax, but there is a price to be paid for this simplicity,
and the price is precisely almost complete lack of data abstraction.
And it is this lack of data abstraction that makes "just go in and modify"
type programming MUCH harder in C than in any higher level language with
proper abstraction facilities (Ada, C++, ...)
James, if you disagree, then I suspect you just don't have much experience
with higher level languages, or, if you do, that, as is common with programmers
whose primary experience is with C, you have not yet fully understood what
data abstraction and the design of abstract interfaces is about (let alone
object oriented programming). It is certainly true that much of (the worst of)
C++ code that is around today was clearly written by C programmers who have
not yet started to understand what C++ is about.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-08 0:00 ` Robert Dewar
@ 1996-06-08 0:00 ` The Amorphous Mass
1996-06-09 0:00 ` Robert Dewar
0 siblings, 1 reply; 100+ messages in thread
From: The Amorphous Mass @ 1996-06-08 0:00 UTC (permalink / raw)
On 8 Jun 1996, Robert Dewar wrote:
> James Robinson said
>
> " Frankly, I can't think of anything better. We looked all over, and
> this is the best there was. Remember, the problem is not that it fails
> to work as advertized, and it is not that it is unstable or buggy or
> unpredictable. The problem is that if you try to do something a little
> bit different from what it's designed for it stops being friendly and
> starts being obscure. By contrast, if I want one of my C libraries
> to do something a bit different, I just go in and modify them."
>
> This is as wrong as it could be, and basically could only be written by
> someone who has not understood the whole point of data abstraction,
> using the term widely to encompass object oriented programming as well.
> The whole point of abstraction is to make it easier to reuse code.
> C has advantages, particularly in the simplicity of its computing model,
> and simple syntax, but there is a price to be paid for this simplicity,
> and the price is precisely almost complete lack of data abstraction.
> And it is this lack of data abstraction that makes "just go in and modify"
> type programming MUCH harder in C than in any higher level language with
> proper abstraction facilities (Ada, C++, ...)
Unfortunately, you read in to my statement something that I wasn't
saying. I indentified the libraries as "C libraries" because that's what
they are. The point was that libraries that I have the source code and
docs for are much more reusable then libraries (or class hierarchies, or
whatever buzzword you want to use :-) that are engineered to "to
everything" but are transparent to me.
If I were to pick an ideal language, instead of C (which I use because
it is highly and easily portable, and the language I am most famiilar
with) I would have said something like "Smalltalk libraries." In fact
Smalltalk is a good example of an organizational system that IMO
intelligently handles code reuse: The whole shebang runs smoothly and
transparently, and not only are the individual parts are available for
modification as necessary, they are also broken up into small, clearly
written routines. And its much harder to blow up your machine by making
a small change in Smalltalk code than in C code. In fact, our second
choice for a dev platform was VisualAge, but Smalltalk scared away the
principle programmer (a FORTRAN guy).
> James, if you disagree, then I suspect you just don't have much experience
> with higher level languages, or, if you do, that, as is common with
> programmers whose primary experience is with C, you have not yet fully
> understood what data abstraction and the design of abstract interfaces
> is about (let alone object oriented programming).
Well since I didn't disagree you will not be surprised to hear that
although my primary experience _is_ with C, I have been exposed to a
large number of programming paradigms (including OOP), and I apply as
many of the lessons of those paradigms to my C code as I can. Now
that I'm no longer in school I might actually have time to _learn_ the
languages I was exposed to (Smalltalk, Prolog, Miranda) and some
others that have been suggested to me.
> It is certainly true that much of (the worst of)
> C++ code that is around today was clearly written by C programmers who have
> not yet started to understand what C++ is about.
And the rest was written by C++ programmers who have not yet started to
understand what C++ is about. After all, "what C++ is about" is an open
question. I certainly wouldn't use it in a course about object-oriented
programming!
- James "Good candidates for exceptions are situations
james-robinson@uiowa.edu that do not occur under normal circumstances."
-- Kevin J. Hopps
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-08 0:00 ` The Amorphous Mass
@ 1996-06-09 0:00 ` Robert Dewar
0 siblings, 0 replies; 100+ messages in thread
From: Robert Dewar @ 1996-06-09 0:00 UTC (permalink / raw)
" Unfortunately, you read in to my statement something that I wasn't
saying. I indentified the libraries as "C libraries" because that's what
they are. The point was that libraries that I have the source code and
docs for are much more reusable then libraries (or class hierarchies, or
whatever buzzword you want to use :-) that are engineered to "to
everything" but are transparent to me.
"
No, I read into your statement exactly what you repeated above, and I
repeat my view that it is plain wrong. It is a common attitude of C
programmers, but it simply means that you don't really know the
alternatives well. Report back when you have extensive experience with
a language that supports data abstraction properly!
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` The Amorphous Mass
1996-06-08 0:00 ` Robert Dewar
@ 1996-06-08 0:00 ` Robert Dewar
1 sibling, 0 replies; 100+ messages in thread
From: Robert Dewar @ 1996-06-08 0:00 UTC (permalink / raw)
James Robinson said:
" I was not implying that Ada executables are slow (although your
complaint is understandable -- I should have said "a language that
allows for a small, fast environment"). I was trying to say that the
environment and compile times for Ada would be big and/or slow, for the
simple reason that the language offers a great deal more support than C
does. As I have said in this thread I'm sure Ada is just as subject to
efficient compiling and optimizing techniques as other languages are, and
almost as fast as C. :-)
"
That's not a valid conclusion. Fast compilers can be written for any language,
it is simply a matter of whether this is a primary goal or not of the
compiler effort (compared to portability, etc). The fastest compiler for
any language on the PC is the Computer Associates Realia COBOL compiler,
and it is certainly not the case that COBOL is the simplest language.
But compile speeds are of absolute, not relative interest, so as machines
get faster, more and more compilers are fast enough, and speed becomes much
less of an issue. Indeed at Realia, early on, when Realia could compile
10,000 lines/minute on an 8088 PC-1, it was a real competitive advantage
to the competitions 500 lines minute, but later on, when both compilers
got 50 times faster mainly because of faster hardware, the difference
was not nearly so significant competitively.
These days, GNAT on a top of the line SGI machine, using multiple processors,
can compile at a rate of a few hundred thousand lines a minute, which is in
the fast enough category. Now of course not everyone has a 16 processor
power challenge on their desktop, but todays very expensive machine becomes
next years affordable machine, and the year after that's cheap machine.
Technically, it is certainly feasible to write a very fast compiler and
environment for Ada 95. There is no reason why Ada 95 cannot be compiled
just as fast as COBOL [incidentally I should mention that the speed of
Realia COBOL was not achieved at the expense of poor generated code, indeed
it was written in its own language and self-compiled, and at the time I was
involved, generated the fastest code of any compiler for any language for
the (in)famous seive benchmark -- that comparison was carried out by
Phillipe Kahn of Borland, independently of us].
There was a time when concentrating on a really fast Ada compiler would have
made sense, but with modern hardware that becomes much less interesting. In
the case of the GNAT project, it made much better sense to take advantage
of the GCC backend, which is not particularly fast, because the primary
goals are highly efficient code, and ease of porting -- obviously specialized
code generators for spcific machines can be faster than the approach in GCC
using machine description files, but the ease of porting GNAT is one of its
very attractive features -- I think everyone would agree that it is better
to have GNAT on many different systems than a faster compiler that ran on
only one machine [Realia COBOL is *very* {C s[pecific, in fact it has taken ten
years to finally port from a 286 to a 386).
In the case of GNAT, the front end is quite fast (no one has really seen this
yet because we have never issued other than the debugging version of the front
end so far -- that wlil be something that waits for version 4 of GNAT later
this year). The backend however wlil never be Realia-style fast.
But back to the original point, the idea that a C compiler should obviously
be much faster than an Ada compiler because C is simpler is just wrong. Sure,
if everything else were equal, this might be the case, but it is never the
case that everything else is equal -- the difference in speed between
compilers results from the approach and design of the compiler, not from
the language being compiled.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
1996-06-04 0:00 ` The Amorphous Mass
@ 1996-06-05 0:00 ` ++ robin
1996-06-05 0:00 ` Ian Ward
[not found] ` <4p60nk$imd@euas20.eua.ericsson.se>
` (4 subsequent siblings)
6 siblings, 1 reply; 100+ messages in thread
From: ++ robin @ 1996-06-05 0:00 UTC (permalink / raw)
ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes:
>Kurt Johmann (johmann@moal.com) wrote:
>: Programming languages are almost completely subjective, because the only
>I strongly disagree
>: minds apparently like that kind of enforced discipline (masochist types,
>: perhaps :-), but to my mind it was a build-your-own-straightjacket-and-
>: wear-it kind of approach to programming.
>the opposite is true: a professional is always thankful for every
>hint from the compiler or environment for potential errors.
>Working with languages of the past like Fortran or C is true
>masochism. I have worked on very large systems in Fortran
>(one was a half million source lines of code, the other 300_000 sloc)
>and we had to run the systems on every hardware brand.
>I can see no advantage to allow e.g. a memory overwrite error,
>by accident, or, e.g. an outside range value at run time or
>a wrong subroutine call due to bad parameter profile.
>When I decide, as a programmer, that a peculiar type or
>variable may have a value in the range from 1 to 9, can you please
>explain me why it should be useful to assign a value of 10 or
>4711 or -1234?
---Why, someone inevitably decides that the range is going
to be something different! Users are apt to change their minds.
Then someone has to go in and modify the program. Or, someone
overlooked a limit, and put in a limit one smaller than that
actually required. Again, someone has to go in and find where
that limit is, and change it.
>I will justify the value of that freedom in your favour:
>This has the big advantage that the typical Fortran, C, or C++
>programmer being not immediately aware of an erroneous code
>is happy to catch the error all-day-long and when the day is done,
>he is proud to have found this bug and fully convinced to
>have fulfilled his work of the day.
>In contrast, a poor Ada programmer does not have this fun:
>a potential error is revealed at the moment of the very first
>compilation/execution. What a pity! No fun at all ;-(
---Oh how wonderful if this were so! If it were true,
all our programming difficulties would be over.
Alas, it's just another pipe dream.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` ++ robin
@ 1996-06-05 0:00 ` Ian Ward
1996-06-05 0:00 ` Ian Ward
1996-06-11 0:00 ` Jon S Anthony
0 siblings, 2 replies; 100+ messages in thread
From: Ian Ward @ 1996-06-05 0:00 UTC (permalink / raw)
On 5/6/95, in reply to Peter Hermann, who said
">When I decide, as a programmer, that a peculiar type or
>variable may have a value in the range from 1 to 9, can you please
>explain me why it should be useful to assign a value of 10 or
>4711 or -1234?"
Robin, from Australia raplied.
"---Why, someone inevitably decides that the range is going
to be something different! Users are apt to change their minds.
Then someone has to go in and modify the program. Or, someone
overlooked a limit, and put in a limit one smaller than that
actually required. Again, someone has to go in and find where
that limit is, and change it."
I was just thinking that the other day. All the world software
engineering problems solved. No more boundaries to any variable,
and as I had 31 pounds and 312,032.231234 pence in my bank
account I could celebrate this solution to the software
crisis with a ride on a brand new -234 cc. Kawasaki Zx6R.
---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
It's "burgled" Mr. President, not burglarised.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` Ian Ward
@ 1996-06-05 0:00 ` Ian Ward
1996-06-06 0:00 ` Richard Riehle
1996-06-11 0:00 ` ++ robin
1996-06-11 0:00 ` Jon S Anthony
1 sibling, 2 replies; 100+ messages in thread
From: Ian Ward @ 1996-06-05 0:00 UTC (permalink / raw)
On 5/6/95, in reply to Peter Hermann, who said
">When I decide, as a programmer, that a peculiar type or
>variable may have a value in the range from 1 to 9, can you please
>explain me why it should be useful to assign a value of 10 or
>4711 or -1234?"
Robin, from Australia raplied.
"---Why, someone inevitably decides that the range is going
to be something different! Users are apt to change their minds.
Then someone has to go in and modify the program. Or, someone
overlooked a limit, and put in a limit one smaller than that
actually required. Again, someone has to go in and find where
that limit is, and change it."
I was just thinking that the other day. All the world software
engineering problems solved. No more boundaries to any variable,
and as I had 31 pounds and 312,032.231234 pence in my bank
account I could celebrate this solution to the software
crisis with a ride on a brand new -234 cc. Kawasaki Zx6R.
---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
It's "burgled" Mr. President, not burglarised.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` Ian Ward
@ 1996-06-06 0:00 ` Richard Riehle
1996-06-07 0:00 ` Richard Riehle
` (2 more replies)
1996-06-11 0:00 ` ++ robin
1 sibling, 3 replies; 100+ messages in thread
From: Richard Riehle @ 1996-06-06 0:00 UTC (permalink / raw)
To: Ian Ward
On 5 Jun 1996, Ian Ward wrote:
> On 5/6/95, in reply to Peter Hermann, who said
> ">When I decide, as a programmer, that a peculiar type or
> >variable may have a value in the range from 1 to 9, can you please
> >explain me why it should be useful to assign a value of 10 or
> >4711 or -1234?"
>
> Robin, from Australia raplied.
>
> "---Why, someone inevitably decides that the range is going
> to be something different! Users are apt to change their minds.
> Then someone has to go in and modify the program. Or, someone
> overlooked a limit, and put in a limit one smaller than that
> actually required. Again, someone has to go in and find where
> that limit is, and change it."
Good point. This is one of the very reasons why Ada works so well
for this kind of thing, when programs are written correctly. In
particular, when one takes advantage of the availability of
attributes. Let's say that we establish a range of 1 through 10 for some
type T1. Then we write a program using variables of that type.
For example, we define the type T1, and an unconstrained array as follows:
type T1 is range 1..10;
type Vector is array(Positive range <>) of Float;
Then we declare a variable of type Vector:
Float_Set : Vector(T1'First..T1'Last);
Some algorithm, elsewhere in the code can be written as:
for I in Float_Set'Range loop ... end loop;
As we separate the concerns of implementation, generalizing our
algorithms with attributes and other useful Ada mechanisms, we discover
that we can write those algorithms independently of explicit range
information. This is only on example of the power of Ada. One could
illustrate many more if necessary.
Granted, if we abide by the rules of static binding, it is necessary to
recompile the entire dependent set of compilation units when we change
the ranges, but this is more of a mechanical excercise and has no
impact on the underlying logic of our implementation. Software
practitioners unfamiliar with Ada often make the mistake of believing
that the restrictive nature of their favorite language carries over to
Ada. That is why it is so much fun to see those practitioners become
excited when they learn just how powerful this language really is.
Richard Riehle
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-06 0:00 ` Richard Riehle
@ 1996-06-07 0:00 ` Richard Riehle
1996-06-08 0:00 ` O'Connor
1996-06-07 0:00 ` Robert Dewar
1996-06-11 0:00 ` ++ robin
2 siblings, 1 reply; 100+ messages in thread
From: Richard Riehle @ 1996-06-07 0:00 UTC (permalink / raw)
To: Ian Ward
On Thu, 6 Jun 1996, Richard Riehle wrote:
To Anyone who might have noticed:
I guess I should desk-check my code more carefully. The example shown
below would generate a compile-time error due to a type mismatch. Better
to have defined the index type as a subtype of Positive, or even Integer
than a a distinct type. This points out one of the benefits of Ada:
when sloppy coders, such as I seem to be, make this kind of error, it
is easily detected and rejected by the compiler.
Sorry for the coding error. Mea culpa. The offending code follows:
Richard Riehle
> type T1 is range 1..10;
-- change the preceding to
subtype T1 is Positive range 1..10;
> type Vector is array(Positive range <>) of Float;
>
> Then we declare a variable of type Vector:
>
> Float_Set : Vector(T1'First..T1'Last);
>
> Some algorithm, elsewhere in the code can be written as:
>
> for I in Float_Set'Range loop ... end loop;
>
[snip, snip ] the rest of the message deleted
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-07 0:00 ` Richard Riehle
@ 1996-06-08 0:00 ` O'Connor
0 siblings, 0 replies; 100+ messages in thread
From: O'Connor @ 1996-06-08 0:00 UTC (permalink / raw)
Richard Riehle wrote:
>
> On Thu, 6 Jun 1996, Richard Riehle wrote:
>
> To Anyone who might have noticed:
>
> I guess I should desk-check my code more carefully. The example shown
> below would generate a compile-time error due to a type mismatch. Better
> to have defined the index type as a subtype of Positive, or even Integer
> than a a distinct type. This points out one of the benefits of Ada:
> when sloppy coders, such as I seem to be, make this kind of error, it
> is easily detected and rejected by the compiler.
>
> Sorry for the coding error. Mea culpa. The offending code follows:
>
> Richard Riehle
But is this truly an 'error' in that your code does not express your
requirements? The problem isn't with what your are trying to accomplish.
The problem is that you have violated the language's rules for how to
express a particular idea. As such, the compiler has merely enforced the
language rules. Any decent compiler for any language will enforce the
rules for that language.
As a personal opinion, I think the Ada typing rules caused you to make
the error in the first place that you compliment the compiler for
catching.
>
> > type T1 is range 1..10;
>
> -- change the preceding to
> subtype T1 is Positive range 1..10;
>
If I was doing this in Smalltalk I could do it a number of ways;
depending on why I was trying to constrain it.
For example, if I just needed a generic concept of an contrained
range Integer, I would probably subclass Integer and added supporting
instance variables and methods. The limits on the new class would be
either instance variables to allow each object to have individual limits,
or class variables to enforce common limits across all objects of the
class. The attraction of the class limit approach would be that I could
use Class methods to accomplish the various range looping mechanisms.
If instead I had some Domain Object (a Bank Account) whose
attributes had domain contraints against their values; I would probably
write range checking code into the various get and set methods. If I
wanted a more dynamic solution, I would probably use some sort of
Validator class. One interesting idea is that fact that the contraints
agianst the values of an attribute are contingent on the values in other
attributes in the object, or other objects. "X must be between 1 and 5
if Y is less then 7, otherwise X must be between 4 and 12." Expressing
such rules is not as straightforward using a simple subtyping approach.
Another twist is the idea of using a database table to express the
Metadata (including constraints) associated with a particular attribute.
The database could hold the limits in values; A Validator object could
load these limits when the program started. Changing these limits based
on new business conditions could be accomplished with a database update
and no code changes at all.
Anyway, just some meandering food for thought....
James O'Connor
oconnor@apci.net
--
##
##
######## "He that loveth not
######## knoweth not God."
## --1 John 4:8
##
##
##
##
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-06 0:00 ` Richard Riehle
1996-06-07 0:00 ` Richard Riehle
@ 1996-06-07 0:00 ` Robert Dewar
1996-06-10 0:00 ` Richard Riehle
1996-06-11 0:00 ` ++ robin
2 siblings, 1 reply; 100+ messages in thread
From: Robert Dewar @ 1996-06-07 0:00 UTC (permalink / raw)
Richard used in an example:
Float_Set : Vector(T1'First..T1'Last);
I assume this was just done for pedagogical reasons, the preferable
syntax is of course simply:
Float_Set : Vector (T1);
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-07 0:00 ` Robert Dewar
@ 1996-06-10 0:00 ` Richard Riehle
0 siblings, 0 replies; 100+ messages in thread
From: Richard Riehle @ 1996-06-10 0:00 UTC (permalink / raw)
On 7 Jun 1996, Robert Dewar wrote:
> Richard used in an example:
>
> Float_Set : Vector(T1'First..T1'Last);
>
> I assume this was just done for pedagogical reasons, the preferable
> syntax is of course simply:
>
> Float_Set : Vector (T1);
Thanks, Robert. Yes, I considered several approaches and decided
that, because this thread goes to readers from other newsgroups,
the 'First and 'Last attribute version would be easier to read.
For an experienced Ada practitioner, other variations were possible.
Richard Riehle
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-06 0:00 ` Richard Riehle
1996-06-07 0:00 ` Richard Riehle
1996-06-07 0:00 ` Robert Dewar
@ 1996-06-11 0:00 ` ++ robin
1996-06-11 0:00 ` James_Rogers
` (2 more replies)
2 siblings, 3 replies; 100+ messages in thread
From: ++ robin @ 1996-06-11 0:00 UTC (permalink / raw)
Richard Riehle <rriehle@nunic.nu.edu> from San Diego writes:
>On 5 Jun 1996, Ian Ward wrote:
>> On 5/6/95, in reply to Peter Hermann, who said
>> ">When I decide, as a programmer, that a peculiar type or
>> >variable may have a value in the range from 1 to 9, can you please
>> >explain me why it should be useful to assign a value of 10 or
>> >4711 or -1234?"
>>
>> Robin, from Australia raplied.
>>
>> "---Why, someone inevitably decides that the range is going
>> to be something different! Users are apt to change their minds.
>> Then someone has to go in and modify the program. Or, someone
>> overlooked a limit, and put in a limit one smaller than that
>> actually required. Again, someone has to go in and find where
>> that limit is, and change it."
> Good point. This is one of the very reasons why Ada works so well
> for this kind of thing, when programs are written correctly. In
> particular, when one takes advantage of the availability of
> attributes. Let's say that we establish a range of 1 through 10 for some
> type T1. Then we write a program using variables of that type.
> For example, we define the type T1, and an unconstrained array as follows:
> type T1 is range 1..10;
> type Vector is array(Positive range <>) of Float;
> Then we declare a variable of type Vector:
> Float_Set : Vector(T1'First..T1'Last);
> Some algorithm, elsewhere in the code can be written as:
> for I in Float_Set'Range loop ... end loop;
> As we separate the concerns of implementation, generalizing our
> algorithms with attributes and other useful Ada mechanisms, we discover
> that we can write those algorithms independently of explicit range
> information. This is only on example of the power of Ada. One could
> illustrate many more if necessary.
> Granted, if we abide by the rules of static binding, it is necessary to
> recompile the entire dependent set of compilation units when we change
> the ranges, but this is more of a mechanical excercise and has no
> impact on the underlying logic of our implementation. Software
> practitioners unfamiliar with Ada often make the mistake of believing
> that the restrictive nature of their favorite language carries over to
> Ada. That is why it is so much fun to see those practitioners become
> excited when they learn just how powerful this language really is.
> Richard Riehle
---One of the problems of using rigid facilities -- amply
illustrates my point. Arrays don't often have fixed sizes.
The size depends on the problem. One day, it might be 10,
next day, 300, day after, 90.
Are you seriusly suggesting that EACH time the program
is run that it be edited and recompiled? And what
happens -- as is often the case -- the size of the array
changes DURING the run?
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-11 0:00 ` ++ robin
@ 1996-06-11 0:00 ` James_Rogers
1996-06-11 0:00 ` Kevin J. Weise
1996-06-11 0:00 ` David Weller
1996-06-11 0:00 ` Chris Warack <sys mgr>
2 siblings, 1 reply; 100+ messages in thread
From: James_Rogers @ 1996-06-11 0:00 UTC (permalink / raw)
rav@goanna.cs.rmit.EDU.AU (++ robin) wrote:
> Are you seriusly suggesting that EACH time the program
>is run that it be edited and recompiled? And what
>happens -- as is often the case -- the size of the array
>changes DURING the run?
Now you are approaching the real problem. Arrays are must
always have a specific size. That size may be defined at
compile time or it may be det4rmined at run time using
dynamic allocation. Either way a given instance of an array
does not change its size. If this is not enough reason to
use some other more dynamic data structure such as a list or
a tree, then the common methods used with arrays include the
concept of declaring a size which is the largest expected for
current needs. A subset of that array is typically used for
the problem at hand, wasting the remainder for future growth.
The point is that every array must be accompanied by some method
of indicating the specific subset of elements to be processed.
In C this means one typically either passes an array pointer and
a size parameter, or a special character is expected to be
embedded in the array to mark the end of useful data ( the NULL
character, for instance).
Ada allows a parameter to be expressed as an unconstrained array.
This means any size (within system limits) of array may be passed
as a parameter. The array attributes 'First, 'Last, 'Range can then
be used to traverse the array passed to the subprogram. Now, you
ask, how does a calling subprogram pass a specific array to the
subprogram expecting an unconstrained array. Ada allows you to
pass a slice of an array. For instance, if your predefined array
is defined as:
example : array (1..10000) of integer;
and you want to pass elements 23 through 413 to a function producing
a total which uses an unconstrained array parameter, the following
syntax is used:
Total := sum(example(23..413));
In this case elements 23 through 413 are passed to function "sum".
Funciton "sum" sees an array of integer with 'First mapping to element
23 of array example.
No recompilation is necessary to change the slice sent to the function.
All that is necessary is to use variables in the slice syntax, instead
of constants as shown in the above example.
--
Jim Rogers
*********************************************
I would not say that my mind is filled with useless information.
The information is, however, amazingly inappropriate in most
circumstances.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-11 0:00 ` James_Rogers
@ 1996-06-11 0:00 ` Kevin J. Weise
0 siblings, 0 replies; 100+ messages in thread
From: Kevin J. Weise @ 1996-06-11 0:00 UTC (permalink / raw)
James_Rogers <jrogers> wrote (with deletions):
>rav@goanna.cs.rmit.EDU.AU (++ robin) wrote:
>
>> Are you seriusly suggesting that EACH time the program
>>is run that it be edited and recompiled? And what
>>happens -- as is often the case -- the size of the array
>>changes DURING the run?
>
>Now you are approaching the real problem. Arrays are must
>always have a specific size. That size may be defined at
>compile time or it may be det4rmined at run time using
>dynamic allocation. Either way a given instance of an array
>does not change its size. If this is not enough reason to
>use some other more dynamic data structure such as a list or
>a tree, then the common methods used with arrays include the
>concept of declaring a size which is the largest expected for
>current needs. A subset of that array is typically used for
>the problem at hand, wasting the remainder for future growth.
>
>The point is that every array must be accompanied by some method
>of indicating the specific subset of elements to be processed.
>In C this means one typically either passes an array pointer and
>a size parameter, or a special character is expected to be
>embedded in the array to mark the end of useful data ( the NULL
>character, for instance).
Methinks you missed one other alternative, Mr. Rogers. It is
also possible to elaborate, at runtime, an array of appropriate
size without having to use dynamic (i.e., heap) memory. E.g.:
procedure Made_Up_Example (MAX_SIZE : Natural) is
THIS_STRING : String (1..MAX_SIZE);
begin
-- whatever
end Made_Up_Example;
Obviously, the parameter value cannot be expected to be static,
so you (and the compiler) can safely assume the amount of memory
needed for THIS_STRING will probably vary from one invocation to
another. (In fact, the memory gets allocated for it on the stack
when its declaration is elaborated.) Then you only need to figure
out how big an array you need *before* invoking your subprogram.
This works great with blocks,too. On nice machines that let your
stack space float to however much virtual memory your program
needs, you can have great flexibility without having to use the
heap or the old FORTRAN-style "declare it as big as your biggest
possible need" method. And you don't have to edit/recompile/relink
everytime the size changes! The only problem I recall having with
this is when the subprogram (or block) is executed within the
context of a task whose default stack size is insufficient to
handle the block creation. But that is relatively easy to solve
with a 'Size pragma.
-------------------------------------------------------------
Kevin J. Weise kweise@c3i-ccmail.sed.redstone.army.mil
COLSA Corporation voice: (205) 842-9680
Huntsville, AL
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-11 0:00 ` ++ robin
1996-06-11 0:00 ` James_Rogers
@ 1996-06-11 0:00 ` David Weller
1996-06-11 0:00 ` Chris Warack <sys mgr>
2 siblings, 0 replies; 100+ messages in thread
From: David Weller @ 1996-06-11 0:00 UTC (permalink / raw)
In article <4pj7e0$fat@goanna.cs.rmit.EDU.AU>,
++ robin <rav@goanna.cs.rmit.EDU.AU> wrote:
>---One of the problems of using rigid facilities -- amply
>illustrates my point. Arrays don't often have fixed sizes.
>The size depends on the problem. One day, it might be 10,
>next day, 300, day after, 90.
>
> Are you seriusly suggesting that EACH time the program
>is run that it be edited and recompiled? And what
>happens -- as is often the case -- the size of the array
>changes DURING the run?
If this is your belief, then you are SERIOUSLY missing the point.
If you have software where the array size MIGHT change, then you write
your software to support that. You MIGHT decide to make the array
size a constant and recompile when needed (it's a valid choice,
although not one I'd make), you also MIGHT allow your array to grow as
more things are added to it. These things are easy to handle.
The point of the discussion, however, was situations where you indexed
outside an array, which is so damn easy in C that EVERY book I've seen
in C says, "be careful not to do this!"
There is a VERY considerable difference between adding something to an
array in a manner such that the array size grows with the addition,
and indexing outside an array, such that you're now lost in the middle
of memory-land and can't figure out why your program gives (most
likely) unrepeatable errors.
--
Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
This is not your father's Ada -- lglwww.epfl.ch/Ada
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-11 0:00 ` ++ robin
1996-06-11 0:00 ` James_Rogers
1996-06-11 0:00 ` David Weller
@ 1996-06-11 0:00 ` Chris Warack <sys mgr>
2 siblings, 0 replies; 100+ messages in thread
From: Chris Warack <sys mgr> @ 1996-06-11 0:00 UTC (permalink / raw)
In article <4pj7e0$fat@goanna.cs.rmit.EDU.AU>, rav@goanna.cs.rmit.EDU.AU (++ robin) writes:
|> Richard Riehle <rriehle@nunic.nu.edu> from San Diego writes:
|>
|> >> Robin, from Australia raplied.
|> >>
|> >> "---Why, someone inevitably decides that the range is going
|> >> to be something different! Users are apt to change their minds.
|> >> Then someone has to go in and modify the program. Or, someone
|> >> overlooked a limit, and put in a limit one smaller than that
|> >> actually required. Again, someone has to go in and find where
|> >> that limit is, and change it."
|>
|> > Good point. This is one of the very reasons why Ada works so well
|> > for this kind of thing, when programs are written correctly. In
|> > particular, when one takes advantage of the availability of
|> > attributes. Let's say that we establish a range of 1 through 10 for some
|> > type T1. Then we write a program using variables of that type.
|>
|> > For example, we define the type T1, and an unconstrained array as follows:
|>
|> > type T1 is range 1..10;
|> > type Vector is array(Positive range <>) of Float;
|>
|> > Then we declare a variable of type Vector:
|>
|> > Float_Set : Vector(T1'First..T1'Last);
|>
|> > Some algorithm, elsewhere in the code can be written as:
|>
|> > for I in Float_Set'Range loop ... end loop;
|>
...
|>
|> ---One of the problems of using rigid facilities -- amply
|> illustrates my point. Arrays don't often have fixed sizes.
|> The size depends on the problem. One day, it might be 10,
|> next day, 300, day after, 90.
|>
|> Are you seriusly suggesting that EACH time the program
|> is run that it be edited and recompiled? And what
|> happens -- as is often the case -- the size of the array
|> changes DURING the run?
No. If that's the case change the declaration of T1 to:
subtype T1 is positive range 1 .. What_ever_the_value_is_today; *
or
subtype T1 is positive range 1 .. This_runs_size;
or
type Vector is private;
if you really want to make it behave in some special manner.
or ...
* Recognizing that T1 really needed to be a subtype in the example
above
In those first two examples, it doesn't matter how the upper values
are set (e.g., hardware, sensor, data file, user input ...) and this
works fine. It's not too hard to change from the rigid approach to
this more flexible approach either. It does preclude some possibilities
for static optimizations perhaps.
The last alternative is a serious change to the given example. When
you don't want to use an array, however, you shouldn't use an array then.
Define the dynamic data structure of your dreams in whatever way you see fit.
--
Christopher A. Warack, Capt, USAF cwarack@cs.usafa.af.mil (719) 472-2401
Computer Science Department, US Air Force Academy
This content in no way reflects the opinions, standards, or policy
of the USAF Academy, or the US government.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` Ian Ward
1996-06-06 0:00 ` Richard Riehle
@ 1996-06-11 0:00 ` ++ robin
1996-06-11 0:00 ` Ian Ward
1 sibling, 1 reply; 100+ messages in thread
From: ++ robin @ 1996-06-11 0:00 UTC (permalink / raw)
ian@rsd.bel.alcatel.be (Ian Ward) writes:
>On 5/6/95, in reply to Peter Hermann, who said
> ">When I decide, as a programmer, that a peculiar type or
> >variable may have a value in the range from 1 to 9, can you please
> >explain me why it should be useful to assign a value of 10 or
> >4711 or -1234?"
>Robin, from Australia raplied.
>"---Why, someone inevitably decides that the range is going
>to be something different! Users are apt to change their minds.
>Then someone has to go in and modify the program. Or, someone
>overlooked a limit, and put in a limit one smaller than that
>actually required. Again, someone has to go in and find where
>that limit is, and change it."
> Ian, from the UK "raplied" [sic]:
>I was just thinking that the other day. All the world software
>engineering problems solved. No more boundaries to any variable,
>and as I had 31 pounds and 312,032.231234 pence in my bank
>account I could celebrate this solution to the software
>crisis with a ride on a brand new -234 cc. Kawasaki Zx6R.
>Ian Ward's opinions only : ian@rsd.bel.alcatel.be
Reminds me of a joke I once heard:
A man went into a certain pub, hoping to pull a swiftie on
the barman. He asked: "Oi, have you change of an 18 pound note?"
The barman replied: "Aye. What would you like? 2 nines or
3 sixes?"
Seems to me that Ian has missed the point.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-11 0:00 ` ++ robin
@ 1996-06-11 0:00 ` Ian Ward
1996-06-12 0:00 ` ++ robin
0 siblings, 1 reply; 100+ messages in thread
From: Ian Ward @ 1996-06-11 0:00 UTC (permalink / raw)
rav@goanna.cs.rmit.EDU.AU writes :
> ian@rsd.bel.alcatel.be (Ian Ward) writes:
>>On 5/6/95, in reply to Peter Hermann, who said
>> ">When I decide, as a programmer, that a pecu
>> >variable may have a value in the range from 1 to 9,
>> >explain me why it should be useful to assign a value of 9
>> >4711 or -1234?"
>>Robin, from Australia raplied.
>>"---Why, someone inevitably decides that the range is going
>>to be something different! Users are apt to change their minds.
>>Then someone has to go in and modify the program. Or, someone
>>overlooked a limit, and put in a limit one smaller than that
>>actually required. Again, someone has to go in and find where
>>that limit is, and change it."
>> Ian, from the UK "raplied" [sic]:
>>I was just thinking that the other day. All the world software
>>engineering problems solved. No more boundaries to any variable,
>>and as I had 31 pounds and 312,032.231234 pence in my bank
>>account I could celebrate this solution to the software
>>crisis with a ride on a brand new -234 cc. Kawasaki Zx6R.
>>Ian Ward's opinions only : ian@rsd.bel.alcatel.be
>>Reminds me of a joke I once heard:
>>A man went into a certain pub, hoping to pull a swiftie on
>>the barman. He asked: "Oi, have you change of an 18 pound note?"
>>The barman replied: "Aye. What would you like? 2 nines or
>>3 sixes?"
> Seems to me that Ian has missed the point.
I am so sorry; there were two conclusions I could deduce
from a reply to a question about putting the value of ten
in a variable designed to hold only one to nine.
Firstly, there was mine, which was that the original
programmer had decided, quite wrongly, that nought to
nine was a valid range for this variable. As he
was working from what some user was eventually going
to enter once he had produced the system, and not some
pre-defined spec which defined the system in the first
place (which the users got their chance to shout at.)
He should be sacked for failing to accurately predict
the future. Perhaps they should employ astrologers.
Secondly, there was the conclusion, that Peter Herman
was not talking about some variable at all when he
said the programmer wished to define a variable within
the range of 0 to 9. He was, in fact, talking about a
varying size of some array, say, or record component.
Had I known that that was his intent, and that, 'that'
was the point Robin brought up, or even if a project
required a varying length array, String etc. Then I
would have simply, as many other people who know what
they are talking about, have said :
Why did the programmer not simply define a varying
length array, string etc. and use it, such as.
procedure FRED ( HARRY : in STRING );
function JOHN (NUMBER : in INTEGER) return STRING;
both of these operations, return or take varying
length strings, with the added advantage that
the length, start and end points are defined within
the procedure, and if the user tries to examine
HARRY (4231) when HARRY is only defined from 0 to 9
then the user will know about it straight away,
unless the programmer decides not to tell him.
Furthermore,
....
type MATRIX (A,B : integer := 5) is
record
CONTENTS : array (1 .. A, 1 .. B) of INTEGER;
end record;
function INVERT (MAT : in MATRIX) return MATRIX;
....
takes a varying defined setup, and can be fixed
at compile time if one wishes, or not, can be
generated dynamically, statically or anyway one
pleases, but the end result is the same; which
is: why would anyone want to access component
number X if X is not in the range of valid
components. Nine times out of ten, or more,
it is going to be a fault.
Here is, of course, a case where myself and
Robin have failed to notice vital information
in text with which we were presented, I made
the wrong conclusion on what Peter, and hence
Robin was talking about, (and mispelt, in the
heat of typing "replied".) Robin presumably also
in the heat of typing, mispelt "Belgium".
Faults like this happen every day when reading
requirements, and inevitably, now and again,
element 51, the 'last' element, of a 15 number
array is indexed, because someone was not
correctly assimilating the text in front of
their eyes.
I feel safe at night knowing that the language's
run time checking caught this error during
the unit test phase, or earlier, during first
compilation, leaving the programmer time to
work on all the other problems he has; such as
predicting what the user will do tomorrow.
Groetjes,
Ian.
---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-11 0:00 ` Ian Ward
@ 1996-06-12 0:00 ` ++ robin
1996-06-12 0:00 ` Ian Ward
0 siblings, 1 reply; 100+ messages in thread
From: ++ robin @ 1996-06-12 0:00 UTC (permalink / raw)
ian@rsd.bel.alcatel.be (Ian Ward) writes:
>Here is, of course, a case where myself and
>Robin have failed to notice vital information
>in text with which we were presented, I made
>the wrong conclusion on what Peter, and hence
>Robin was talking about, (and mispelt, in the
>heat of typing "replied".) Robin presumably also
>in the heat of typing, mispelt "Belgium".
---What? You made another mistake. You're attributing
to me what another writer wrote, or you imagined it.
Perhaps you should now read what you wrote: "Faults
like this happen every day . . ."
">Faults like this happen every day when reading
>requirements, and inevitably, now and again,
>element 51, the 'last' element, of a 15 number
>array is indexed, because someone was not
>correctly assimilating the text in front of
>their eyes."
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-12 0:00 ` ++ robin
@ 1996-06-12 0:00 ` Ian Ward
0 siblings, 0 replies; 100+ messages in thread
From: Ian Ward @ 1996-06-12 0:00 UTC (permalink / raw)
> ian@rsd.bel.alcatel.be (Ian Ward) writes:
> >Here is, of course, a case where myself and
> >Robin have failed to notice vital information
> >in text with which we were presented, I made
> >the wrong conclusion on what Peter, and hence
> >Robin was talking about, (and mispelt, in the
> >heat of typing "replied".) Robin presumably also
> >in the heat of typing, mispelt "Belgium".
> ---What? You made another mistake. You're attributing
> to me what another writer wrote, or you imagined it.
I am so sorry, I thought you said somthing like,
"Ian from the UK "raplied" (sic)"
when a look at the last two letters of
my URL clearly says "be", not "uk".
If it was not you, then I apologise.
> Perhaps you should now read what you wrote: "Faults
> like this happen every day . . ."
> ">Faults like this happen every day when reading
> >requirements, and inevitably, now and again,
> >element 51, the 'last' element, of a 15 number
> >array is indexed, because someone was not
> >correctly assimilating the text in front of
> >their eyes."
It seems another mistake has been made, if it was me then
I am sorry. In fact, this only reinforces my earlier
statements on compilers and language design progressing
to help cope with common human errors.
Best regards,
Ian
---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
It's "burgled" Mr. President, not burglarised.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-05 0:00 ` Ian Ward
1996-06-05 0:00 ` Ian Ward
@ 1996-06-11 0:00 ` Jon S Anthony
1 sibling, 0 replies; 100+ messages in thread
From: Jon S Anthony @ 1996-06-11 0:00 UTC (permalink / raw)
In article <4pj7e0$fat@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes:
>
> > Granted, if we abide by the rules of static binding, it is necessary to
> > recompile the entire dependent set of compilation units when we change
> > the ranges, but this is more of a mechanical excercise and has no
> > impact on the underlying logic of our implementation. Software
> > practitioners unfamiliar with Ada often make the mistake of believing
> > that the restrictive nature of their favorite language carries over to
> > Ada. That is why it is so much fun to see those practitioners become
> > excited when they learn just how powerful this language really is.
> > Richard Riehle
>
> ---One of the problems of using rigid facilities -- amply
> illustrates my point. Arrays don't often have fixed sizes.
> The size depends on the problem. One day, it might be 10,
> next day, 300, day after, 90.
What has this to do with anything? Dynamically sized arrays are
trivial, flexible, easy and _safe_ to use in Ada and are in fact used
all the time. The point being made is simply that if you decide on
the _definition_ of a type as a subrange, then only the clueless would
think it "good" to _not_ conform to the definition! Get a clue.
> Are you seriusly suggesting that EACH time the program
> is run that it be edited and recompiled? And what
> happens -- as is often the case -- the size of the array
> changes DURING the run?
No he isn't. I hope you aren't serious about this ridiculous comment.
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 100+ messages in thread
[parent not found: <4p60nk$imd@euas20.eua.ericsson.se>]
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
` (2 preceding siblings ...)
[not found] ` <4p60nk$imd@euas20.eua.ericsson.se>
@ 1996-06-12 0:00 ` Jon S Anthony
1996-06-14 0:00 ` Jon S Anthony
` (2 subsequent siblings)
6 siblings, 0 replies; 100+ messages in thread
From: Jon S Anthony @ 1996-06-12 0:00 UTC (permalink / raw)
In article <4pljv3$oqp@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes:
[In response to Richard A. O'Keefe]
Gobs and gobs of rubish about why assertions are not "as good as"
silly print statements in bodies of code.
You should just give this up. Do you have any idea how stupid
this makes you look???
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
` (3 preceding siblings ...)
1996-06-12 0:00 ` Jon S Anthony
@ 1996-06-14 0:00 ` Jon S Anthony
1996-06-15 0:00 ` Jon S Anthony
1996-06-18 0:00 ` Jon S Anthony
6 siblings, 0 replies; 100+ messages in thread
From: Jon S Anthony @ 1996-06-14 0:00 UTC (permalink / raw)
In article <4prafa$o6p@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:
> http://www.cs.rmit.edu.au/~rav/
> takes to you rav's home page, which will tell you that he is
> a Senior Lecturer. (Me, I'm only a Lecturer.) He has recently
> published two books. He is our local PL/I expert.
GREAT MAKER!! This guy has access to _students_??!?! One can only
hope they see his bunk for what it is and emerge relatively unscathed...
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
` (4 preceding siblings ...)
1996-06-14 0:00 ` Jon S Anthony
@ 1996-06-15 0:00 ` Jon S Anthony
1996-06-18 0:00 ` Adam Beneschan
1996-06-18 0:00 ` Jon S Anthony
6 siblings, 1 reply; 100+ messages in thread
From: Jon S Anthony @ 1996-06-15 0:00 UTC (permalink / raw)
In article <dewar.834584250@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
> A. Grant said
>
> "The point of assertions is not to print messages for the
> programmer. You can use them to allow the compiler to
> optimise safely, provide a contractual interface between
> modules, and for preconditions, postconditions, loop invariants
> etc. when proving the correctness of programs."
>
> Actually that is a very controversial statement. What most people want is
> non-intrusive assertions that do NOT affect the generated code. That's
> not 100% possible, but it is something you can aim at.
>
> It is certainly true that assertions can be used for compiler optimization,
> but that's not what people want.
That may be what _some_ people don't want. For reasons that would
seem to be beyond the ken of mere mortals. But I would certainly hope
that an Eiffel compiler, for example, would use the assertions
specified by a programmer to (among other things) get rid of
extraneous and useless code whenever it could deduce such cases from
the assertions. What's the point of generating code for something
that you _know_ won't be needed? that you _know_ will do _nothing_
but a) slow down execution speed and b) increase size of code? If
these people like that sort of thing, how about just telling them to
use the nooptimize pragma or switch? Then they can get all the
useless code they want.
> When we discussed putting pragma Assert into the language (i.e. into the
> standard), it was this point that tripped us up, and resulted in it being
> left out. We could not figure out how to formally define the notion that
> the compiler should NOT be allowed to use the assertion for optimization
> purpoes.
This is _almost_ as wog-boggling as the goof-up of not directly
supporting specification of mutually recursive types across packages.
Really. It is incomprehensible. I suppose these people don't want
_any_ optimizations? No? Well, how do they justify all that
"intrusive" code movement and elmination that happens with
"standard/traditional" optimization? What about ranges? They can be
seen in various contexts as just being a limited form of assertion.
And those are taken advantage of all the time for "intrusive"
optimizations. I suppose they positively have paroxysms over this.
Or, how about telling these people to _NOT_ use pragma assert if they
are so wigged out about possibly useful optimizations? It's not like
they are in any better shape now given the way things turned out. And
the rest of us could be taking advantage of this without resorting to
_NON_standard pragma Assert in GNAT. Or will this actually just
become the defacto standard because it so obviously makes sense?
Does the Intermetrics frontend implement Assert as defined in GNAT?
Actually, the more I think about it, I believe this may be _more_
incomprehensible than the recursive type bungle after all.
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-15 0:00 ` Jon S Anthony
@ 1996-06-18 0:00 ` Adam Beneschan
0 siblings, 0 replies; 100+ messages in thread
From: Adam Beneschan @ 1996-06-18 0:00 UTC (permalink / raw)
jsa@organon.com (Jon S Anthony) writes:
>In article <dewar.834584250@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>
>> A. Grant said
>>
>> "The point of assertions is not to print messages for the
>> programmer. You can use them to allow the compiler to
>> optimise safely, provide a contractual interface between
>> modules, and for preconditions, postconditions, loop invariants
>> etc. when proving the correctness of programs."
>>
>> Actually that is a very controversial statement. What most people want is
>> non-intrusive assertions that do NOT affect the generated code. That's
>> not 100% possible, but it is something you can aim at.
>>
>> It is certainly true that assertions can be used for compiler optimization,
>> but that's not what people want.
>
>That may be what _some_ people don't want. For reasons that would
>seem to be beyond the ken of mere mortals. But I would certainly hope
>that an Eiffel compiler, for example, would use the assertions
>specified by a programmer to (among other things) get rid of
>extraneous and useless code whenever it could deduce such cases from
>the assertions. What's the point of generating code for something
>that you _know_ won't be needed? that you _know_ will do _nothing_
>but a) slow down execution speed and b) increase size of code? If
>these people like that sort of thing, how about just telling them to
>use the nooptimize pragma or switch? Then they can get all the
>useless code they want.
>
>
>> When we discussed putting pragma Assert into the language (i.e. into the
>> standard), it was this point that tripped us up, and resulted in it being
>> left out. We could not figure out how to formally define the notion that
>> the compiler should NOT be allowed to use the assertion for optimization
>> purpoes.
>
>This is _almost_ as wog-boggling as the goof-up of not directly
>supporting specification of mutually recursive types across packages.
>
>Really. It is incomprehensible. I suppose these people don't want
>_any_ optimizations? No? Well, how do they justify all that
>"intrusive" code movement and elmination that happens with
>"standard/traditional" optimization? What about ranges? They can be
>seen in various contexts as just being a limited form of assertion.
>And those are taken advantage of all the time for "intrusive"
>optimizations. I suppose they positively have paroxysms over this.
I have to agree with Jon's point here. I don't see any reason why the
definition of the language would have to prevent the compiler from
using the information for optimization. If the customer didn't want
that to happen, the vendor could add a command-line option or pragma
to tell the compiler not to. Don't Ada compilers already have
command-line options and/or pragmas to control how much optimization
takes place, anyway?
-- Adam
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
` (5 preceding siblings ...)
1996-06-15 0:00 ` Jon S Anthony
@ 1996-06-18 0:00 ` Jon S Anthony
1996-06-28 0:00 ` Assertions (an heretic view) Michel Gauthier
6 siblings, 1 reply; 100+ messages in thread
From: Jon S Anthony @ 1996-06-18 0:00 UTC (permalink / raw)
In article <ag129.532.0011DA32@ucs.cam.ac.uk> ag129@ucs.cam.ac.uk (A. Grant) writes:
> In article <dewar.834584250@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
> >A. Grant said
> >"The point of assertions is not to print messages for the
> >programmer. You can use them to allow the compiler to
> >optimise safely..."
>
> >It is certainly true that assertions can be used for compiler optimization,
> >but that's not what people want.
>
> What people want is for the compiler to do all the work, i.e. prove
> that all array subscripts are valid, that all dereferenced pointers
I basically agree with you here. Well, more or less. Well, you know,
they probably would like it to do everything, like:
program A:
Setting: The Factory
Task : Construct complete CIM and TQM system
end A
:-)
> Why don't you like assertions enabling optimisation where
> the compiler can prove the correctness of the assertion, i.e.
> optimise it away? Then all you are doing is giving a hint to
> the compiler about an optimisation strategy, without altering
> the meaning of the program at all.
I don't believe that Robert said the _he_ wouldn't like assertions
allowed to do this, but that certain "other people" didn't. I find this
incomprehensible also. And since GNAT (GNU Ada, which Robert had a
significant hand in) has pragma Assert it would appear he agrees - at
least at some level! :-)
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Assertions (an heretic view)
1996-06-18 0:00 ` Jon S Anthony
@ 1996-06-28 0:00 ` Michel Gauthier
1996-06-28 0:00 ` Robert A Duff
1996-06-28 0:00 ` Robert Dewar
0 siblings, 2 replies; 100+ messages in thread
From: Michel Gauthier @ 1996-06-28 0:00 UTC (permalink / raw)
Many people recently wrote about assertions. I am not really convinced
by the general spirit of the debate. I guess there is a harmful confusion
somewhere. Do not read any more if you think the contrary.
IMHO, it is _essential_ to distinguish :
- _failures_ : some piece of program does not do what it has been designed
to do, in an intrinsicly impossible case,
- _programming errors_ : the programmer did not do what the specification
required, including failure cases.
Underflowing a stack is (almost always) an error, whereas overflowing a
stack depends on the data and on the environment of each execution, hence
is a failure.
Failures can _always_ be foreseen, and suitable programming can handle
them if appropriate, with exceptions or with any other means.
Errors can _never_ be foreseen.
Coming back to assertions, I guess that they essentially relate to errors,
which they can help detecting. It seems to be a good style not to combine
assertions with failures.
Moreover, I can't agree with the idea that failing an assertion check would
always result in raising Assert_Error. Failing an assertion check is an effect
of some -possibly incompletely identified- programming error. Different
possible continuations can be envisaged : raising a well-specified
exception associated with the case, doing some appropriate thing
(tracing,...), raising some user-defined exception, invoking the debugger,
and possibly others, among which continuing until other failing checks.
This choice depends on the current status of the project, on the
nature of the checked assertion, on reuse or not, etc. In some cases,
it may depend also on execution options.
From another point of view, assertion-handling components should
be replaceable by others without any other on the program effect than
early abortion (whether compared with normal end or with abortion).
Do-nothing must be one of the possible assertion-handling components,
to be used for the final program.
This is the spirit of the assertion mechanism that I have coded for
my students (I had some remaining problems with initialisation
of package instances, which seem to be fixed with gnat 3.05).
---------- ---------- ---------- ----------
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 () 55457315 [or ~7201]
---------- ---------- ---------- ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
---------- ---------- ---------- ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
---------- ---------- ---------- ----------
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Assertions (an heretic view)
1996-06-28 0:00 ` Assertions (an heretic view) Michel Gauthier
@ 1996-06-28 0:00 ` Robert A Duff
1996-06-28 0:00 ` Robert Dewar
1 sibling, 0 replies; 100+ messages in thread
From: Robert A Duff @ 1996-06-28 0:00 UTC (permalink / raw)
In article <gauthier-2806961227410001@164.81.60.62>,
Michel Gauthier <gauthier@unilim.fr> wrote:
>IMHO, it is _essential_ to distinguish :
> - _failures_ : some piece of program does not do what it has been designed
> to do, in an intrinsicly impossible case,
> - _programming errors_ : the programmer did not do what the specification
> required, including failure cases.
A perfectly reasonable distinction. However, you cannot, in general,
tell whether it's a "failure" or a "programming error" at the point
where the problem is detected. This is the whole point of exceptions:
one piece of code can detect the problem, and another piece of code,
possibly far away, can decide whether it is a "failure" or not, and if
so, what to do about it. (And, of course, the *usual* thing to do with
an exception is to treat it as a programming error, and simply let it
kill the program or go into the debugger or whatever.)
>Underflowing a stack is (almost always) an error, whereas overflowing a
>stack depends on the data and on the environment of each execution, hence
>is a failure.
>
>Failures can _always_ be foreseen, and suitable programming can handle
>them if appropriate, with exceptions or with any other means.
>
>Errors can _never_ be foreseen.
>
>Coming back to assertions, I guess that they essentially relate to errors,
>which they can help detecting. It seems to be a good style not to combine
>assertions with failures.
I disagree, for the above reasons. If you have a stack overflow, it
might be a "failure", and it might make sense to recover from it. On
the other hand, I might calculate the maximum stack size, so that my
algorithm is guaranteed not to overflow the stack -- in this case, the
only way the stack can overflow is if I have a programming error. And
the code for Stacks.Push can't tell which is which. Only the *caller*
of Stacks.Push can know.
>Moreover, I can't agree with the idea that failing an assertion check would
>always result in raising Assert_Error. Failing an assertion check is an effect
>of some -possibly incompletely identified- programming error. Different
>possible continuations can be envisaged : raising a well-specified
>exception associated with the case, doing some appropriate thing
>(tracing,...), raising some user-defined exception, invoking the debugger,
>and possibly others, among which continuing until other failing checks.
> This choice depends on the current status of the project, on the
>nature of the checked assertion, on reuse or not, etc. In some cases,
>it may depend also on execution options.
Right. But "raising an exception" covers all these cases. Any decent
implementation will let you go into the debugger in case of an unhandled
exception, for example. Anyway, you have no choice -- the language
Standard doesn't define an Enter_Debugger primitive.
- Bob
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Assertions (an heretic view)
1996-06-28 0:00 ` Assertions (an heretic view) Michel Gauthier
1996-06-28 0:00 ` Robert A Duff
@ 1996-06-28 0:00 ` Robert Dewar
1 sibling, 0 replies; 100+ messages in thread
From: Robert Dewar @ 1996-06-28 0:00 UTC (permalink / raw)
One thing for sure, this discussion on assertions certainly nicely
indicates the problem. People have very different ideas of what
assertions should be, and this kind of divergence does not make
it easy to agree on a single language feature. Some people argue
for multiple language features to respond to the confusion, but
that of course is also a controversial position.
Anyway, readers of this thread should now have a better appreciation of
why the apparently simple and obvious feature did not make it into the
official language.
My own taste would have been to define a simple feature similar to that
implemented in GNAT, but as you see from the discussion, there is no
consensus that this is the "right" approach, and the discussion in
WG9 was quite similar to that in this thread.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
[not found] <4p0fdd$4ml@news.atlantic.net>
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
@ 1996-06-06 0:00 ` Dale Pontius
1996-06-11 0:00 ` Jon S Anthony
` (2 subsequent siblings)
4 siblings, 0 replies; 100+ messages in thread
From: Dale Pontius @ 1996-06-06 0:00 UTC (permalink / raw)
In article <4p37cs$efi@goanna.cs.rmit.edu.au>,
rav@goanna.cs.rmit.EDU.AU (++ robin) writes:
>
> >When I decide, as a programmer, that a peculiar type or
> >variable may have a value in the range from 1 to 9, can you please
> >explain me why it should be useful to assign a value of 10 or
> >4711 or -1234?
>
>---Why, someone inevitably decides that the range is going
>to be something different! Users are apt to change their minds.
>Then someone has to go in and modify the program. Or, someone
>overlooked a limit, and put in a limit one smaller than that
>actually required. Again, someone has to go in and find where
>that limit is, and change it.
>
You've made the assumption that the limit was arbitrary. I would
expect that the limit would be put there based on the capabilities
of the code. In that case, exceeding the limit of that variable
is the same as exceeding the capabilities of the code, and may
have unpredicted results.
In that case, if the user wants to change the limits the code had
better be scrubbed to make sure it can handle the new limits.
Obviously the limit must have been intelligently selected in the
first place. But in any case, new expectations call for reexamination
of the program, not "try it and see if it breaks," because there's
always the "this time" clause in there.
Dale Pontius
(NOT speaking for IBM)
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
[not found] <4p0fdd$4ml@news.atlantic.net>
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
1996-06-06 0:00 ` next "big" language?? (disagree) Dale Pontius
@ 1996-06-11 0:00 ` Jon S Anthony
1996-06-12 0:00 ` Help making ada pretty Pedro de las Heras
1996-06-18 0:00 ` next "big" language?? (disagree) ++ robin
4 siblings, 0 replies; 100+ messages in thread
From: Jon S Anthony @ 1996-06-11 0:00 UTC (permalink / raw)
In article <4pj7v8$g3c@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes:
> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
> >johmann@moal.com (Kurt Johmann) writes:
>
> >>Range checking, IMO, is something that should be
> >>checked by the programmer's code as needed. For example:
> >>
> >> assert(x > 0 && x < 10); // int x must be between 1 and 9 inclusive
> >>
> >>One disadvantage of doing it the Ada way (in which the allowed range is
> >>declared as part of the type) is that it is inflexible and global, and
> >>the range information is separated from where the variable's value is
> >>actually used in the program.
>
> >I disagree that the Ada way is inflexible. Usually associating a range
> >with a type is what you want.
>
> ---Is it?
Typically, yes it is.
> Rarely do programs stay the same. Users change
> their minds, during program design and after it is complete.
What does this have to do with the point??? The kind of situation
being described is one most likely dealing with the internal structure
of the _implementation_, not the user level requirements! Criminey!
> ---Why, someone inevitably decides that the range is going
> to be something different!
I would hope that your "designs" of the internals of an application
are not that sloppy and slipshod. Then again, looking at typical
examples of programs certainly doesn't help my faith here...
> Users are apt to change their minds.
> Then someone has to go in and modify the program. Or, someone
> overlooked a limit, and put in a limit one smaller than that
> actually required. Again, someone has to go in and find where
> that limit is, and change it.
Again, get a clue. No one is talking about hard coding restrictions
at the user level - unless, of course, those restrictions make sense
from the standpoint of the user level model. Trivial example: the
user level model imposes the requirement that a current ranges between
3 and 15 units (amperes, milliamps, whatever). That's the designed in
range. Anything outside this range is an indication that a fault
has/is occuring. Only the feckless would think it is somehow a great
idea to just let any value outside this range occur in such a context.
Furthermore, you can let this range be specifiable by the user for any
given "run" (maybe it's a simulation):
subtype Current_Range is range Get_Current_Min .. Get_Current_Max;
...
Where the Get_Current* obtain values at runtime. Quick hack:
with Ada.Command_Line; use Ada.Command_Line;
with Text_Io; use Text_Io;
procedure Junk is
subtype Current_Range is Integer
range Integer'Value(Argument(1))..Integer'Value(Argument(2));
begin
Put_Line(
"Current_Range = " &
Integer'Image(Current_Range'First) & " .." &
Integer'Image(Current_Range'Last) );
end;
$ gnatmake junk.adb
$ junk 1 4
Current_Range = 1 .. 4
$ junk 4 8
Current_Range = 4 .. 8
$
Looks to me like both the flexibility _and_ the safety. Really, if
you are going to comment, at least have some idea of what you're
talking about.
> > But Ada also provides ways of suppressing
> >range checks or of adding arbitrary assertions in a manner equivalent
> >to C's assert.
>
> ---and I suppose it never has happened that someone forgot to
> suppress a range check . . .
Irrelevant. If you don't want a range then DON'T specify one. You
can let it be whatever you want. The difference is that in Ada you
_can_ specify a range as a definition if you know that this is correct
and the language will ensure that this is enforced.
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: Help making ada pretty
[not found] <4p0fdd$4ml@news.atlantic.net>
` (2 preceding siblings ...)
1996-06-11 0:00 ` Jon S Anthony
@ 1996-06-12 0:00 ` Pedro de las Heras
1996-06-18 0:00 ` next "big" language?? (disagree) ++ robin
4 siblings, 0 replies; 100+ messages in thread
From: Pedro de las Heras @ 1996-06-12 0:00 UTC (permalink / raw)
In article <31BE430F.52F8@adam.com.au> CSC Trusted Systems Group <csctsg@adam.com.au> writes:
Hi,
I am looking for any tools around to print ada-code in a more presentable
form, ie keywords bolded etc. apparently they sometimes go by the name
"pretty printers", however I do not want to rejustify the code in any
way, I only require the bolding type features.
Also am looking for any latex tools for typesetting ada.
as I rarely have time to read mews replies to csctsg@adam.com.au would
greatly be appreciated
Hello.
Check ftp://ordago.gsyc.inf.uc3m.es/pub/literate/ape4noweb.tgz
It is a modification of APE (A pretty printer for Ada) made by
Paco Ballesteros (nemo), a colleague of mine.
It does not rejustify and it produces LaTeX marks.
Regards,
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
[not found] <4p0fdd$4ml@news.atlantic.net>
` (3 preceding siblings ...)
1996-06-12 0:00 ` Help making ada pretty Pedro de las Heras
@ 1996-06-18 0:00 ` ++ robin
4 siblings, 0 replies; 100+ messages in thread
From: ++ robin @ 1996-06-18 0:00 UTC (permalink / raw)
jsa@organon.com (Jon S Anthony) writes:
>In article <4pqsed$a4v@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes:
>> >No you are wrong. Ranges and assertions will let the compiler
>> >eliminate these checks. That is exactly what you wanted. You don't
>> >have a clue. Why are you posting on this topic when you clearly don't
>> >understand any of the principals??
>>
>> ---Having a range allows the compiler to produce code
>> to check that the value of the variable concerned
>> lies within that range. Whenever that variable
>> is assigned a value (including via an input), the
>> check is performed.
>>
>> Sorry you embarrassed yourself again with this and other
>> wrong assertions (no pun intended).
>No, you did. Again. But you appear not to care. The compiler can
>use ranges at COMPILE TIME to check that bounds are not violated AT
>COMPILE TIME so that it does not need to produce code to check the
>variable AT RUNTIME. It can't do this in every case, but in very many
>cases it can.
---That's what I already said a couple of posts ago:
>> "You can write
>> a = b - c; or the equivalent do/end. In either case,
>> the checks are done by the compiler and/or the object code."
But Jon, you are contradicting yourself, because you then replied
that the checks are not needed:
"No. Try reading what was said. The _elimination_ of the checks comes
from the assertions or ranges which are in the language and from which
the compiler can deduce that the checks are not needed. Subscripting
is basically always eliminated."
>Jon Anthony
>Organon Motives, Inc.
>1 Williston Road, Suite 4
>Belmont, MA 02178
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
@ 1996-06-07 0:00 Ian Ward
1996-06-08 0:00 ` O'Connor
1996-06-09 0:00 ` Robert Dewar
0 siblings, 2 replies; 100+ messages in thread
From: Ian Ward @ 1996-06-07 0:00 UTC (permalink / raw)
On June the ?sixth?, James Robinson wrote :
> On 5 Jun 1996, Ian Ward wrote:
> > On June the Fourth, 1996, James Robinson (The Amorphous Mass) wrote
snip....
> > I think I will scream.
> I was not implying that Ada executables are slow (although your
> complaint is understandable -- I should have said "a language that
> allows for a small, fast environment"). I was trying to say that the
> environment and compile times for Ada would be big and/or slow, for the
> simple reason that the language offers a great deal more support than C
> does. As I have said in this thread I'm sure Ada is just as subject to
> efficient compiling and optimizing techniques as other languages are, and
> almost as fast as C. :-)
Of course, the time taken for the compiler to spot syntactic errors
is much less than that which a person takes. In fact, if the langauge
syntax is cunningly enough design such that different constructs look
sufficiently different, it will also wipe out a large proportion of
unwitting semantic (&functional) errors as well. This feature more
than makes up for compile times, which is one of the reasons languages
such as the Pascal family is twice as quick in terms of man hours to
get down to any arbitrary level of bugs. (It stands to reason, if one
does not have to worry about the syntax, one has more time to work
on the semantics.)
> [re: "reusable code modules"]
> > > They're also one of the great dangers of the future. I keep a fairly
snip...
> > I'm thus wary of the idea of "code reuse." Not dismissive, just wary.
snip...
> No. C++ is great fun to play with but I don't consider it an
> attractive alternative because it's far too easy to shoot yourself in
> the foot, and because it's a write-your-own-language language that can
> make reading or modifying someone else's code a nontrivial exercize.
Concur. Like Mother, like Daughter.
> > Software reuse is not the problem, and neither is Object oriented
> > design. In this case of yours, it appears that it is a bad implementation
> > of C++ that seems to be behind it. Of course, at this point we can go
> > into how it came to be a bad implementation.
> It's a perfectly fine, even ingenious implementation.If anything, it's
> a sterling example of a well-written C++ application. When you
> work within its parameters it runs beautifully, even distributed across
> platforms running 4 different OSs. When you try to stretch its
> capabilities (which is what we're doing) then you start to see all the
> stuff that's supposed to be 'transparent.' That was my point, and that
> _is_ a problem with software reuse, and a risk with OO design.
> > I am not going to though, I will simply say that if I were to end up
> > using software, where in the background, side effects of it were
> > detrimentally affecting mine, that I could not even find, then I WOULD
> > use something else. Bruce Lee said, "If it works, use it." It clearly
> > is not working. Anything else must be better? Why are you not trying
> > to convince your boss to use something else? Anything else?
> Frankly, I can't think of anything better. We looked all over, and
> this is the best there was. Remember, the problem is not that it fails
> to work as advertized, and it is not that it is unstable or buggy or
> unpredictable. The problem is that if you try to do something a little
> bit different from what it's designed for it stops being friendly and
> starts being obscure. By contrast, if I want one of my C libraries
> to do something a bit different, I just go in and modify them.
> Does my argument make more sense to you now?
Yes, I was miles off track with what I thought you were talking about. It
is at this point that I have to concur with what you are saying, there are
two different types of software reuse.
1. Reusing software, to do the same job for which it was designed.
- Such as I/O utilities, this usually works well,
provided the interfaces are well defined.
2. Trying to reuse software for different purpose than it was originally
defined.
- This can be tragic, if one has no ability to examine the works,
then one has no idea what side effects may present themselves;
in the worst cases of this it may be better to write one's own.
- If, of course, one has the sources, it may better to modify
them to suit one's own needs, after all, they were not designed
to do the job for which they will be used, disk space is cheap,
and one will have at the end two pieces of software which gives
a better chance in the future that when a component is needed,
then there will be a closer match, in a library, somewhere.
It is at this point, modification, where code readability
comes into its own, trying to modify write only languages can be
an exercise in frustration to say the least. Of course, programmer
time is the least expensive component of software engineering....
or did I dream it?
> --James Robinson (robinson@cs.uiowa.edu -or- james-robinson@uiowa.edu)
> /* Indeed, C++ is a bit of an oddball of a language ... given the way that *
> * it requires private parts to be visible. This increases the strength of *
> * coupling dramatically... -- Dr. Rich Artym */
Best regards,
Ian.
---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
It's "burgled" Mr. President, not burglarised.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-07 0:00 Ian Ward
@ 1996-06-08 0:00 ` O'Connor
1996-06-10 0:00 ` Matt Kennel
1996-06-09 0:00 ` Robert Dewar
1 sibling, 1 reply; 100+ messages in thread
From: O'Connor @ 1996-06-08 0:00 UTC (permalink / raw)
Ian Ward wrote:
>
> Of course, the time taken for the compiler to spot syntactic errors
> is much less than that which a person takes. In fact, if the langauge
> syntax is cunningly enough design such that different constructs look
> sufficiently different, it will also wipe out a large proportion of
> unwitting semantic (&functional) errors as well. This feature more
> than makes up for compile times, which is one of the reasons languages
> such as the Pascal family is twice as quick in terms of man hours to
> get down to any arbitrary level of bugs. (It stands to reason, if one
> does not have to worry about the syntax, one has more time to work
> on the semantics.)
>
> Best regards,
> Ian.
This is precisely why I enjoy Smalltalk so much. With very few
syntactical rules to worry about, whether I'm writing code or reading
someone elses, I can concentrate more on the intent of the code. "What
needs to be accomplished" rather than "What language rules do I have to
remember for this situation".
James O'Connor
oconnor@apci.net
##
##
######## "He that loveth not
######## knoweth not God."
## --1 John 4:8
##
##
##
##
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-08 0:00 ` O'Connor
@ 1996-06-10 0:00 ` Matt Kennel
1996-06-11 0:00 ` Ian Ward
1996-06-11 0:00 ` Robb Nebbe
0 siblings, 2 replies; 100+ messages in thread
From: Matt Kennel @ 1996-06-10 0:00 UTC (permalink / raw)
O'Connor (oconnor@apci.net) wrote:
: Ian Ward wrote:
: >
: > Of course, the time taken for the compiler to spot syntactic errors
: > is much less than that which a person takes. In fact, if the langauge
: > syntax is cunningly enough design such that different constructs look
: > sufficiently different, it will also wipe out a large proportion of
: > unwitting semantic (&functional) errors as well. This feature more
: > than makes up for compile times, which is one of the reasons languages
: > such as the Pascal family is twice as quick in terms of man hours to
: > get down to any arbitrary level of bugs. (It stands to reason, if one
: > does not have to worry about the syntax, one has more time to work
: > on the semantics.)
: >
: > Best regards,
: > Ian.
: This is precisely why I enjoy Smalltalk so much. With very few
: syntactical rules to worry about, whether I'm writing code or reading
: someone elses, I can concentrate more on the intent of the code. "What
: needs to be accomplished" rather than "What language rules do I have to
: remember for this situation".
And by doing so turns what would otherwise be superficial syntactic or
linguistic errors into programs with run-time bugs.
``Youse pays yer money and youse takes yer choice.''
That is a complaint have re C++: nightmare programs from hell are dense
in the space of dream programs.
: James O'Connor
: oconnor@apci.net
: ##
: ##
: ######## "He that loveth not
: ######## knoweth not God."
: ## --1 John 4:8
: ##
: ##
: ##
: ##
--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-10 0:00 ` Matt Kennel
@ 1996-06-11 0:00 ` Ian Ward
1996-06-12 0:00 ` Norman H. Cohen
1996-06-11 0:00 ` Robb Nebbe
1 sibling, 1 reply; 100+ messages in thread
From: Ian Ward @ 1996-06-11 0:00 UTC (permalink / raw)
In reply to my earlier statements along the lines of having the
compiler hammer out the syntax checking ...
James O'Connor wrote :
: This is precisely why I enjoy Smalltalk so much. With very few
: syntactical rules to worry about, whether I'm writing code or reading
: someone elses, I can concentrate more on the intent of the code. "What
: needs to be accomplished" rather than "What language rules do I have to
: remember for this situation".
Firstly, I didn't say there were no syntax rules to Ada, there
are, and they are there for the reason that they help eradicate
errors in program production, (note that James O'Connor hasn't
specifically stated this about Smalltalk either but as I only
have a finite time to learn languages I am not qualified to
make a guess what he meant by it.)
Which then brings me to Mathew B. Kennel's retort
> And by doing so turns what would otherwise be superficial syntactic or
> linguistic errors into programs with run-time bugs.
If he is talking about Ada here, then I think his argument is flawed
because it, in my opinion, assumes that the rate of errors per SLOC
a programmer makes is independent of language.
I don't think that for every syntax error a programmer spots in
his code as a result of a compiler listing, another semantic error
is created instead, (or is even present.)
It is more likely that a given programmer generally has N syntax
errors/1000SLOC and M semantic errors/1000SLOC (where M and N
vary on the ability of the programmer, his interest in his work,
and the difficulty of it.)
In this situation, a good compiler, will point out his N syntax errors,
which he will correct. In the process of correcting these, it is
also likely that he will spot a few of the semantic errors.
This would then leave < M semantic errors for the programmer to
track down at run-time.
All the language would then need is some kind of run time checking
to help him out.
---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-11 0:00 ` Ian Ward
@ 1996-06-12 0:00 ` Norman H. Cohen
0 siblings, 0 replies; 100+ messages in thread
From: Norman H. Cohen @ 1996-06-12 0:00 UTC (permalink / raw)
In article <4pjl57$cn0@btmpjg.god.bel.alcatel.be>, ian@rsd.bel.alcatel.be
(Ian Ward) writes:
|> Which then brings me to Mathew B. Kennel's retort
|>
|> > And by doing so turns what would otherwise be superficial syntactic or
|> > linguistic errors into programs with run-time bugs.
|>
|> If he is talking about Ada here, then I think his argument is flawed
|> because it, in my opinion, assumes that the rate of errors per SLOC
|> a programmer makes is independent of language.
|>
|> I don't think that for every syntax error a programmer spots in
|> his code as a result of a compiler listing, another semantic error
|> is created instead, (or is even present.)
|>
|> It is more likely that a given programmer generally has N syntax
|> errors/1000SLOC and M semantic errors/1000SLOC (where M and N
|> vary on the ability of the programmer, his interest in his work,
|> and the difficulty of it.)
|>
|> In this situation, a good compiler, will point out his N syntax errors,
|> which he will correct. In the process of correcting these, it is
|> also likely that he will spot a few of the semantic errors.
|> This would then leave < M semantic errors for the programmer to
|> track down at run-time.
|>
|> All the language would then need is some kind of run time checking
|> to help him out.
The distinction between "syntax" errors "semantic" errors is misleading.
What is relevant here is the distinction between errors caught at compile
time and those caught at run time (or, worse, not caught at all). For
example, a missing semicolon is a syntax error and a type mismatch is a
semantic error, but both are caught by an Ada compiler at compile time.
The point that Matthew was making was that Ada's strong compile-time
checks allow certain errors that might not be detected until run time, or
might not be detected until a program is in the hands of customers, to be
detected during compilation instead. The greater number of compile-time
error messages means that more work is required to get a program to
compile, but once it compiles it is likely to have fewer run-time errors.
Thus it will take less work to get the compiled program to pass its tests
and the end product will be more reliable.
--
Norman H. Cohen ncohen@watson.ibm.com
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-10 0:00 ` Matt Kennel
1996-06-11 0:00 ` Ian Ward
@ 1996-06-11 0:00 ` Robb Nebbe
1 sibling, 0 replies; 100+ messages in thread
From: Robb Nebbe @ 1996-06-11 0:00 UTC (permalink / raw)
I believe it was Von Neuman who said: "If you don't know what you are
talking about then there is no reason for precision."
I suppose you could apply this to programming and say that if you don't
know why your code works then there is no reason for precision. Things
like types as well as pre- and postconditions are just extra work; aren't
they? ;-|
Matt Kennel wrote:
>
> O'Connor (oconnor@apci.net) wrote:
>
> : This is precisely why I enjoy Smalltalk so much. With very few
> : syntactical rules to worry about, whether I'm writing code or reading
> : someone elses, I can concentrate more on the intent of the code. "What
> : needs to be accomplished" rather than "What language rules do I have to
> : remember for this situation".
>
> And by doing so turns what would otherwise be superficial syntactic or
> linguistic errors into programs with run-time bugs.
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: next "big" language?? (disagree)
1996-06-07 0:00 Ian Ward
1996-06-08 0:00 ` O'Connor
@ 1996-06-09 0:00 ` Robert Dewar
1 sibling, 0 replies; 100+ messages in thread
From: Robert Dewar @ 1996-06-09 0:00 UTC (permalink / raw)
Ian Ward said
"2. Trying to reuse software for different purpose than it was originally
defined."
Sure, but abstraction is all about making sure that software you use
is maximally reusable, i.e. that the set of purposes for which the
software you write is as large as possible. If you have no method
for easily enforcing and taking advantage of data abstraction, you
cannot easily avoid over-specification and thus narrowing down the
scope of possible reuse purposes.
Code modification is the worst possible form of reuse (only slight
ly better, and sometimes worse than, rewriting stuff from scratch).
The whole idea is to reuse code as much as possible WITHOUT ever
having to touch it. Sure, in the C world, the normal paradigm for
code reuse is precisely to grab source and much with it, and that
is not surprising given the language, but it is far from ideal,
and from one point ofview you can see a major design goal in modern
language design is to eliminate the need for (and therefore the
practice of) this kind of source code mucking.
^ permalink raw reply [flat|nested] 100+ messages in thread
end of thread, other threads:[~1996-07-01 0:00 UTC | newest]
Thread overview: 100+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <4p0fdd$4ml@news.atlantic.net>
1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann
1996-06-04 0:00 ` The Amorphous Mass
1996-06-04 0:00 ` Peter Hermann
1996-06-04 0:00 ` The Amorphous Mass
1996-06-05 0:00 ` Michael David WINIKOFF
1996-06-07 0:00 ` Robert Dewar
1996-06-04 0:00 ` Robert Dewar
1996-06-06 0:00 ` Ken Garlington
1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group
1996-06-14 0:00 ` Sandy McPherson
1996-06-19 0:00 ` Ruediger Berlich
1996-06-05 0:00 ` next "big" language?? (disagree) Ian Ward
1996-06-05 0:00 ` The Amorphous Mass
1996-06-08 0:00 ` Robert Dewar
1996-06-08 0:00 ` The Amorphous Mass
1996-06-09 0:00 ` Robert Dewar
1996-06-08 0:00 ` Robert Dewar
1996-06-05 0:00 ` ++ robin
1996-06-05 0:00 ` Ian Ward
1996-06-05 0:00 ` Ian Ward
1996-06-06 0:00 ` Richard Riehle
1996-06-07 0:00 ` Richard Riehle
1996-06-08 0:00 ` O'Connor
1996-06-07 0:00 ` Robert Dewar
1996-06-10 0:00 ` Richard Riehle
1996-06-11 0:00 ` ++ robin
1996-06-11 0:00 ` James_Rogers
1996-06-11 0:00 ` Kevin J. Weise
1996-06-11 0:00 ` David Weller
1996-06-11 0:00 ` Chris Warack <sys mgr>
1996-06-11 0:00 ` ++ robin
1996-06-11 0:00 ` Ian Ward
1996-06-12 0:00 ` ++ robin
1996-06-12 0:00 ` Ian Ward
1996-06-11 0:00 ` Jon S Anthony
[not found] ` <4p60nk$imd@euas20.eua.ericsson.se>
[not found] ` <4p8lmq$oq7@goanna.cs.rmit.edu.au>
1996-06-11 0:00 ` ++ robin
1996-06-11 0:00 ` A. Grant
1996-06-12 0:00 ` Robert Dewar
1996-06-17 0:00 ` A. Grant
1996-06-18 0:00 ` Robert Dewar
1996-06-24 0:00 ` Robert I. Eachus
1996-06-26 0:00 ` Norman H. Cohen
1996-06-19 0:00 ` Jon S Anthony
1996-06-20 0:00 ` Robert Dewar
1996-06-24 0:00 ` Dale Stanbrough
1996-06-24 0:00 ` Assertions (was: Re: next "big" language?? (disagree)) Robert A Duff
1996-06-24 0:00 ` Assertions (a different intent?) Gary McKee
1996-06-24 0:00 ` Assertions (was: Re: next "big" language?? (disagree)) Robert Dewar
1996-06-25 0:00 ` Robert A Duff
1996-06-28 0:00 ` Robert Dewar
[not found] ` <4qrljg$15l8@watnews1.watson.ibm.com>
1996-06-28 0:00 ` Robert Dewar
1996-06-24 0:00 ` next "big" language?? (disagree) Robert Dewar
1996-06-24 0:00 ` hopkinc
1996-06-24 0:00 ` Lars Duening
1996-06-24 0:00 ` Adam Beneschan
1996-06-26 0:00 ` Marc C. Brooks
1996-06-26 0:00 ` Marc C. Brooks
[not found] ` <4qsbm7$r1s@Starbase.NeoSoft.COM>
1996-06-28 0:00 ` "Assert"? "Assume"? (was: next "big" language?? (disagree)) Alexander Bunkenburg
1996-06-28 0:00 ` Ian Collier
1996-07-01 0:00 ` Cameron Laird
1996-06-24 0:00 ` next "big" language?? (disagree) Keith Thompson
1996-06-25 0:00 ` Robert A Duff
1996-06-25 0:00 ` Simon Read
1996-06-24 0:00 ` Adam Beneschan
1996-06-25 0:00 ` Darin Johnson
1996-06-26 0:00 ` Dale Stanbrough
1996-06-26 0:00 ` A. Grant
1996-06-25 0:00 ` Brian Nettleton @pulsar
1996-06-26 0:00 ` Robert Dewar
1996-06-28 0:00 ` Fergus Henderson
1996-06-28 0:00 ` Robert Dewar
1996-06-30 0:00 ` Fergus Henderson
1996-06-30 0:00 ` Robert Dewar
1996-06-12 0:00 ` ++ robin
1996-06-12 0:00 ` A. Grant
1996-06-14 0:00 ` Richard A. O'Keefe
1996-06-12 0:00 ` Richard A. O'Keefe
1996-06-12 0:00 ` ++ robin
1996-06-12 0:00 ` Richard A. O'Keefe
1996-06-13 0:00 ` ++ robin
1996-06-13 0:00 ` ++ robin
1996-06-12 0:00 ` Jon S Anthony
1996-06-14 0:00 ` Jon S Anthony
1996-06-15 0:00 ` Jon S Anthony
1996-06-18 0:00 ` Adam Beneschan
1996-06-18 0:00 ` Jon S Anthony
1996-06-28 0:00 ` Assertions (an heretic view) Michel Gauthier
1996-06-28 0:00 ` Robert A Duff
1996-06-28 0:00 ` Robert Dewar
1996-06-06 0:00 ` next "big" language?? (disagree) Dale Pontius
1996-06-11 0:00 ` Jon S Anthony
1996-06-12 0:00 ` Help making ada pretty Pedro de las Heras
1996-06-18 0:00 ` next "big" language?? (disagree) ++ robin
1996-06-07 0:00 Ian Ward
1996-06-08 0:00 ` O'Connor
1996-06-10 0:00 ` Matt Kennel
1996-06-11 0:00 ` Ian Ward
1996-06-12 0:00 ` Norman H. Cohen
1996-06-11 0:00 ` Robb Nebbe
1996-06-09 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox