Re: Programming language vote - results

Re: Programming language vote - results

[Gary L. Scott]

Oh the horror stories about Ada just about anyone in the defense
industry could tell you...(inefficiency, bloat, development delays,
budget overruns)...I dare you to fit a Jovial application that already
max's out a computer's capabilities in the same box using OO techniques
in Ada...In fact, multiply memory and CPU throughput by 10 and try it.
You will likely be forced to back off OO quite a bit, making an even
bigger mess of maintainability/reusability...

Vincent Lambercy wrote:

> After two weeks, Ada and Smalltalk seems to be the best languages. If
> you
> don't thik so (or if you think so), vote on
> homepages.iprolink.ch/~lambercy



--
Gary L. Scott
scottg@flash.net

Re: Programming language vote - results

[Jack Rudd]

Gary L. Scott wrote:
> 
> Oh the horror stories about Ada just about anyone in the defense
> industry could tell you...(inefficiency, bloat, development delays,
> budget overruns)...I dare you to fit a Jovial application that already
> max's out a computer's capabilities in the same box using OO techniques
> in Ada...In fact, multiply memory and CPU throughput by 10 and try it.
> You will likely be forced to back off OO quite a bit, making an even
> bigger mess of maintainability/reusability...
> 
> Vincent Lambercy wrote:
> 
> > After two weeks, Ada and Smalltalk seems to be the best languages. 
...
Problems along the above lines helped get a very large defense
project cancelled that was near and dear to me.   I may never
forgive the folks who pushed OO in Ada on that project.

Incidentally, the Air Force has now backed off from its previous
position of requiring Ada on all new software projects.  

Jack Rudd
Lockheed Martin Federal Systems	
Boulder, CO

Re: Programming language vote - results

[Gary L. Scott]

Jack Rudd wrote:

> Gary L. Scott wrote:
> >
> > Oh the horror stories about Ada just about anyone in the defense
> > industry could tell you...(inefficiency, bloat, development delays,
> > budget overruns)...I dare you to fit a Jovial application that
> already
> > max's out a computer's capabilities in the same box using OO
> techniques
> > in Ada...In fact, multiply memory and CPU throughput by 10 and try
> it.
> > You will likely be forced to back off OO quite a bit, making an even
>
> > bigger mess of maintainability/reusability...
> >
> > Vincent Lambercy wrote:
> >
> > > After two weeks, Ada and Smalltalk seems to be the best languages.
>
> ...
> Problems along the above lines helped get a very large defense
> project cancelled that was near and dear to me.   I may never
> forgive the folks who pushed OO in Ada on that project.
>
> Incidentally, the Air Force has now backed off from its previous
> position of requiring Ada on all new software projects.

I am aware of 3 projects that fairly recently were required to use Ada
by the Air Force.  I don't think that they speak with one voice on this
subject.

>
>
> Jack Rudd
> Lockheed Martin Federal Systems
> Boulder, CO

> --

Gary L. Scott
Lockheed Martin Tactical Aircraft Systems
scottg@flash.net

Re: Programming language vote - results

[safetran]

Jack Rudd wrote:
> 
> Gary L. Scott wrote:
> >
> > Oh the horror stories about Ada just about anyone in the defense
> > industry could tell you...(inefficiency, bloat, development delays,
>>  (Deleted text)...
> >
> > Vincent Lambercy wrote:
> >
> > > After two weeks, Ada and Smalltalk seems to be the best languages.
> ...
> Problems along the above lines helped get a very large defense
> project cancelled that was near and dear to me.   I may never
> forgive the folks who pushed OO in Ada on that project.
> 
> Incidentally, the Air Force has now backed off from its previous
> position of requiring Ada on all new software projects.
> 
> Jack Rudd
> Lockheed Martin Federal Systems
> Boulder, CO

Can you provide more info about why the project got cancelled ?   

I have been using Ada quite successfully since about 1991 - non
defense/non aerospace companies.  The projects are _hard_ real-time,
embedded (we design our own embedded hardware) and safety critical.  In
fact being safety critical, the software _has_ to meet its deadlines
otherwise there could be some serious problems :)

The compilers (2 different manufacturers) I have used have generated
assembly  that was very efficient and there was not much code bloat.
Admittedly the projects were based on 68332's or 68030 (not exactly
8051's) and we had about 512KB of ROM space with 256KB RAM.

1 project we used Yourdon/Ward-Mellor Real-time extensions as the
methodology.  The other 2 projects were done using Shlaer-Mellor OOA.
--
Rakesh

Re: Programming language vote - results

[Jack Rudd]

safetran wrote:
> 
> Can you provide more info about why the project got cancelled ?

The short answer is, inability to meet cost and schedule constraints.
One large contributing factor to this was the use of OO in Ada by
a team that had no previous experience with OO in Ada.   The other
contributing factors are irrelevant to this thread. 

> I have been using Ada quite successfully since about 1991 - non
> defense/non aerospace companies.  The projects are _hard_ real-time,
> embedded (we design our own embedded hardware) and safety critical.  In
> fact being safety critical, the software _has_ to meet its deadlines
> otherwise there could be some serious problems :)
> 
Fine.  I have no quarrel with success.  How did your team perform the
first time using OO in Ada?   Was it on a small project?

Jack Rudd

Re: Programming language vote - results

[Philip Brashear]

In article <34428215.41C6@lmco.com>, Jack Rudd  <jack.rudd@lmco.com> wrote:
>safetran wrote:
>> 
>> Can you provide more info about why the project got cancelled ?
>
>The short answer is, inability to meet cost and schedule constraints.
>One large contributing factor to this was the use of OO in Ada by
>a team that had no previous experience with OO in Ada.   The other
>contributing factors are irrelevant to this thread. 
>
>> I have been using Ada quite successfully since about 1991 - non
>> defense/non aerospace companies.  The projects are _hard_ real-time,
>> embedded (we design our own embedded hardware) and safety critical.  In
>> fact being safety critical, the software _has_ to meet its deadlines
>> otherwise there could be some serious problems :)
>> 
>Fine.  I have no quarrel with success.  How did your team perform the
>first time using OO in Ada?   Was it on a small project?
>
>Jack Rudd



And there you have it.  Projects that use Ada (or C or COBOL or ...) 
appropriately succeed.  Projects that use Ada as if it were C or Ada as if 
it were COBOL or C as if it were COBOL or ... don't.

Blame the management, blame the designers, blame the programmers ...
But why blame the language?

If the shoe doesn't fit (or if you don't know how to lace it), don't wear it!

Phil

Re: Programming language vote - results

[Gary L. Scott]

Philip Brashear wrote:

> In article <34428215.41C6@lmco.com>, Jack Rudd  <jack.rudd@lmco.com>
> wrote:
> >safetran wrote:
> >>
> >> Can you provide more info about why the project got cancelled ?
> >
> >The short answer is, inability to meet cost and schedule constraints.
>
> >One large contributing factor to this was the use of OO in Ada by
> >a team that had no previous experience with OO in Ada.   The other
> >contributing factors are irrelevant to this thread.
> >
> >> I have been using Ada quite successfully since about 1991 - non
> >> defense/non aerospace companies.  The projects are _hard_
> real-time,
> >> embedded (we design our own embedded hardware) and safety
> critical.  In
> >> fact being safety critical, the software _has_ to meet its
> deadlines
> >> otherwise there could be some serious problems :)
> >>
> >Fine.  I have no quarrel with success.  How did your team perform the
>
> >first time using OO in Ada?   Was it on a small project?
> >
> >Jack Rudd
>
> And there you have it.  Projects that use Ada (or C or COBOL or ...)
> appropriately succeed.  Projects that use Ada as if it were C or Ada
> as if
> it were COBOL or C as if it were COBOL or ... don't.
>
> Blame the management, blame the designers, blame the programmers ...
> But why blame the language?
>
> If the shoe doesn't fit (or if you don't know how to lace it), don't
> wear it!
>
> Phil

In my original post, it was my intent to blame the inappropriate use of
OO at the insistence of management caught up in the OO fad.  We were
writing an entire operating system and all of its "applications",
attempting to be OO "pure".  Ada is a fine language, used
appropriately...

--
Gary L. Scott
scottg@flash.net

Re: Programming language vote - results

[FRS DES]

In article <34424524.B8C67C@kaiwan.com>, safetran <safetran@kaiwan.com> writes:

>Can you provide more info about why the project got cancelled ?   
>
>I have been using Ada quite successfully since about 1991 - non
>defense/non aerospace companies.  The projects are _hard_ real-time,
>embedded (we design our own embedded hardware) and safety critical.  In
>fact being safety critical, the software _has_ to meet its deadlines
>otherwise there could be some serious problems :)
>
>

This thread has really ceased to have any relation to APL or J. Could you
please take it to some other group? Thank you.



              -David E. Siegel
               Software Developer, Financial Reporting Software (FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Robert Munck]

On Sun, 12 Oct 1997 23:41:42 -0600, Jack Rudd <jack.rudd@lmco.com>
wrote:

>Gary L. Scott wrote:
>> 
>> Oh the horror stories about Ada just about anyone in the defense
>> industry could tell you...(inefficiency, bloat, development delays,
>> budget overruns)... 
>...
>Problems along the above lines helped get a very large defense
>project cancelled that was near and dear to me.   I may never
>forgive the folks who pushed OO in Ada on that project.

Ada turned out to be an excellent scapegoat for the many
management failures that are found in software projects in
general and large projects done by large contractors for the
DoD in particular.  It will be interesting to see what gets
the blame now that "you don't have Ada to kick around anymore."
I'll bet that it's Microsoft and/or Sun.

Bob Munck
Mill Creek Systems LC

Re: Programming language vote - results

[Gary L. Scott]

Robert Munck wrote:

> On Sun, 12 Oct 1997 23:41:42 -0600, Jack Rudd <jack.rudd@lmco.com>
> wrote:
>
> >Gary L. Scott wrote:
> >>
> >> Oh the horror stories about Ada just about anyone in the defense
> >> industry could tell you...(inefficiency, bloat, development delays,
>
> >> budget overruns)...
> >...
> >Problems along the above lines helped get a very large defense
> >project cancelled that was near and dear to me.   I may never
> >forgive the folks who pushed OO in Ada on that project.
>
> Ada turned out to be an excellent scapegoat for the many
> management failures that are found in software projects in
> general and large projects done by large contractors for the
> DoD in particular.  It will be interesting to see what gets
> the blame now that "you don't have Ada to kick around anymore."
> I'll bet that it's Microsoft and/or Sun.
>
> Bob Munck
> Mill Creek Systems LC

I agree completely that there were many short-sighted decisions being
made by both management and our customers.  However, I don't understand
the "don't have Ada..." comment.  We are still using and still being
directed to use Ada by our customers on "new" projects.

Very few of us are against Ada or "OO" or the attempts to solve the
"language proliferation, maintenance/reusability" issues.  I am against
not being allowed to make the decision as to which language best solves
the problem that I have to solve and being dictated to meet cost and
schedules based upon historical data that involved using a different
programming language, especially when I have little or no experience in
the new language.  Let me decide where I can implement an "OO" design
and where I can't rather than making arbitrary/blanket requirements for
"pure OO" development.  Let me develop the skills on a small project
first.  Doesn't that make more sense?


--
Gary L. Scott
scottg@flash.net

Re: Programming language vote - results

[Jack Rudd]

Robert Munck wrote:
> 
> Ada turned out to be an excellent scapegoat for the many
> management failures that are found in software projects in
> general and large projects done by large contractors for the
> DoD in particular.  

Now remember, I didn't blame "Ada" per se.   If the team hadn't 
tried to do OO in Ada, the situation would have been more manageable. 
Not to say that there weren't other problems too; but these newsgroups
are focused on language-related issues.   And the team had significant
problems with OO in Ada.   That's simply a fact.
  	
>It will be interesting to see what gets
> the blame now that "you don't have Ada to kick around anymore."
> I'll bet that it's Microsoft and/or Sun.
> 
Where did you get the idea that we don't have Ada to kick around
any more?   Ada is still required on some projects.

Jack Rudd

Re: Programming language vote - results

[Gary L. Scott]

William Dale Jr wrote:

> Jack Rudd wrote:
> >
> > Gary L. Scott wrote:
> > >
> > > Oh the horror stories about Ada just about anyone in the defense
> > > industry could tell you...(inefficiency, bloat, development
> delays,
> > > budget overruns)...I dare you to fit a Jovial application that
> already
> > > max's out a computer's capabilities in the same box using OO
> techniques
> > > in Ada...In fact, multiply memory and CPU throughput by 10 and try
> it.
> > > You will likely be forced to back off OO quite a bit, making an
> even
> > > bigger mess of maintainability/reusability...
> > >
>
> If you consider that most programmers on defense programs get no
> training on Ada, much less OO and real-time issues, it is surprizing
> that so many projects ARE SUCCESSFUL.   The advantages of Ada are not
> FREE.  Additional memory, and processor horsepower may/will be needed.
>
> If these cannot be tolorated and management ignores the risk - well,
> the
> above is what you get.

I was intending to comment on the miss-application of OO techniques
rather than the use of Ada specifically.  There was considerable
training provided in Ada, OOA, OOD, etc.  The problem was one of using
the wrong tool for the specific task at the direction of management
(largely).

>
>
> Ignorance of the domain and the forced use of obscure (MIL-STD-1750A)
> processors have also given Ada a bad name.  It is a poor workman who
> blames his tools.  ( Then again, the boss didn't give you any tools,
> did
> he? )

MIL-STD-1750A processors may be obscure, but they are widely used on
military aircraft.  If a Pentium or a Power-PC could survive the
environmental conditions that 1750 processors are required to survive
in, we'd love to use them.  As for tools, cost for tools was no object;
workstations, configuration management tools, significant training in
OOA, OOD, OOP, you name it.  But we were still producing operating
system code and applications for an underpowered processor with too
little memory.

>
>
> > > Vincent Lambercy wrote:
> > >
> > > > After two weeks, Ada and Smalltalk seems to be the best
> languages.
> > ...
> > Problems along the above lines helped get a very large defense
> > project cancelled that was near and dear to me.   I may never
> > forgive the folks who pushed OO in Ada on that project.
> >
> Again, I bet you had no training in OO with Ada nor got any OO design
> tools and expected all the great Ada "'illities" to be for FREE.
>
> > Incidentally, the Air Force has now backed off from its previous
> > position of requiring Ada on all new software projects.
> >
>
> This, I believe, is a good thing.

Backed off, but not eliminated.  We still seem to be required to use Ada
on all "new" development (usually a costly waste of time due to the
age/near obsolescence of some of these devices).  If we replace an
obsolete CPU and nothing else, the code gets redesigned in Ada.  It
seems to be written in to some "long-term" contracts.

>
>
> > Jack Rudd
> > Lockheed Martin Federal Systems
> > Boulder, CO
>
> --
> =================================================
> William L. Dale  mailto:william.dale.jr@lmco.com
>    ~~~~  Round up the usual disclaimers ~~~~
> =================================================
> "You can have one of two beliefs about miracles :
>  1.  There are no such thing as miracles.
>  2.  Everything is a miracle.
>                . . .  I prefer the later."  A.E.
> -------------------------------------------------



--
Gary L. Scott
scottg@flash.net

Re: Programming language vote - results

[James Giles]

William Dale Jr <William.Dale.Jr@lmco.com> wrote in article
<3442B745.5352@lmco.com>...
[...]
> Ignorance of the domain and the forced use of obscure (MIL-STD-1750A)
> processors have also given Ada a bad name.  It is a poor workman who
> blames his tools.  ( Then again, the boss didn't give you any tools, did
> he? )

The line "It's a poor workman that blames his tools" is one of my
favorites on the net.  It is usually used to defend particularly badly
designed tools (though, I do not accuse you in this instance).  The
correct response is: "A good workman acquires the best tools and
discards those which don't suit his purposes."

-- 
J. Giles
Ricercar Software

Re: Programming language vote - results

[Andrew Haley]

William Dale Jr <William.Dale.Jr@lmco.com> wrote in article
<3442B745.5352@lmco.com>...
[...]
> Ignorance of the domain and the forced use of obscure (MIL-STD-1750A)
> processors have also given Ada a bad name.

I did a Forth for MIL-STD-1750A: it's a nice architecture, and was a
pleasure to program.  I don't see how it's possible to blame that
processor for any problems with Ada.

Andrew.

Re: Programming language vote - results

[David Ness]

How about dropping comp.lang.apl from this thread? It doesn't seem
to have much to do with APL/J...

Gary L. Scott wrote:
>
><SNIP of lots of stuff about ADA> 
> 
> --
> Gary L. Scott
> scottg@flash.net

Re: Programming language vote - results

[Jan Karman]

David Ness <dness@ibm.net> wrote in article <34428914.2D71D0F@ibm.net>...
> How about dropping comp.lang.apl from this thread? It doesn't seem
> to have much to do with APL/J...
> 
> Gary L. Scott wrote:
> >
> ><SNIP of lots of stuff about ADA> 
> > 

In general I find it interesting reading other people's opinion on related
subjects.
If somebody likes to compare computer languages by way of a poll then APL
is involved and related comments fit quite well in the news group. If it
wouldn't then we would have APL and the rest of the world. 
I repeatingly see people try to preserve other people from doing things
which are really harmless and not disturbing. Is this the "religious
thread" some people talk about? 

I have in my news-setup 10 days for keeping messages. 
In cla the headers always fit on one page. And I feel no in the least
obliged to read them all. 
In fact I have set "Mark as read after leaving a newsgroup" in my setup.

BTW, the previous poster may learn in this specific case (ADA vs APL) a
closer relation from Jack Rudd's contribution to APL93 (Toronto)

 

Re: Programming language vote - results

[Alan E & Carmel J Brain]

Jan Karman wrote:
> 
> David Ness <dness@ibm.net> wrote in article <34428914.2D71D0F@ibm.net>...
> > How about dropping comp.lang.apl from this thread? It doesn't seem
> > to have much to do with APL/J...
> >
> > Gary L. Scott wrote:
> > >
> > ><SNIP of lots of stuff about ADA>
> > >
> 
> In general I find it interesting reading other people's opinion on related
> subjects.
> If somebody likes to compare computer languages by way of a poll then APL
> is involved and related comments fit quite well in the news group. If it
> wouldn't then we would have APL and the rest of the world.
> I repeatingly see people try to preserve other people from doing things
> which are really harmless and not disturbing. Is this the "religious
> thread" some people talk about?

I guess I'm probably the only contributor here whose preferred language
is Ada-95, and who has used a lot of APL in the commercial environment.
Would you believe an integrated accounting, invoicing and GUI-aided Cost
estimation system with multiple workstations and a file server in 1982?
Yes 1982. MCM-824 workstations. 

Every time someone says how terse and powerful C is, I think of APL.

But for programs that have to be maintained, and have to be reliable,
give me Ada, -83 or -95. For reasons why, see http://www.adahome.com

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[D'Arcy J.M. Cain]

Alan E & Carmel J Brain wrote:
> Every time someone says how terse and powerful C is, I think of APL.

My favourite quote about APL - "I refuse to use any computer language
in which the proponents shove snippets of code under each other's
nose saying 'I bet you can't guess what this does!'"

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: Programming language vote - results

[FRS DES]

In article <3444BFC6.794BDF32@druid.net>, "D'Arcy J.M. Cain"
<darcy@druid.net> writes:

>Subject:	Re: Programming language vote - results
>From:	"D'Arcy J.M. Cain" <darcy@druid.net>
>Date:Wed, 15 Oct 1997 09:06:14 -0400
>
>Alan E & Carmel J Brain wrote:
>> Every time someone says how terse and powerful C is, I think of APL.
>
>My favourite quote about APL - "I refuse to use any computer language
>in which the proponents shove snippets of code under each other's
>nose saying 'I bet you can't guess what this does!'"
>
>

I have been a full-time professional APL programmer for more than 7 years.
 I am active in the local and national User groups.  I have NEVER seen
someone doing this.  I will g\rant that it has occasionally happened
between college students recently exposed to APL, but one expects
sophomoric behaviour from sophomores.  In any case, there is a nationaly
publicized "obfuscated C contest" where the contestants spend great time
and effort constructing deliberately obsucre and mangled but functional
programs. By the above reasoning, you should never use C either.



              -David E. Siegel
               Software Developer, Financial Reporting Software (FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Mark Stephen]

In article <3444BFC6.794BDF32@druid.net>,
"D'Arcy J.M. Cain" <darcy@druid.net> wrote:
>Alan E & Carmel J Brain wrote:
>> Every time someone says how terse and powerful C is, I think of APL.
>
>My favourite quote about APL - "I refuse to use any computer language
>in which the proponents shove snippets of code under each other's
>nose saying 'I bet you can't guess what this does!'"
>
Damn! Where's my copy of "Devil's DP Dictionary"?

From memory

	There are three things a man must do
	before his life is done.
	Write two lines of APL
	and make the buggers run.

best wishes, mark s.

Re: Programming language vote - results

[Randy MacDonald]

In article <dWVR08LNqpWb092yn@enter.net>, mstephen@enter.net (Mark Stephen) wrote:

>        There are three things a man must do
>        before his life is done.
>        Write two lines of APL
>        and make the buggers run.

With apologies to Crocodile Dundee... That's not a life...

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[Alan E & Carmel J Brain]

D'Arcy J.M. Cain wrote:
> 
> Alan E & Carmel J Brain wrote:
> > Every time someone says how terse and powerful C is, I think of APL.
> 
> My favourite quote about APL - "I refuse to use any computer language
> in which the proponents shove snippets of code under each other's
> nose saying 'I bet you can't guess what this does!'"

Trouble is, this is true. I wrote a security system that took a user
input, used it to write a program which when executed wrote another
program that modified the first program, exited, and the first program
then gave access to certain data. In 2 lines. Due to hardware
limitations, this 2-liner was impossible to make "hidden" so I made it
Cryptic, and self-modifying. 2 months later, even I couldn't figure out
exactly what it did.
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[FRS DES]

In article <34466EB4.3381@dynamite.com.au>, Alan E & Carmel J Brain
<aebrain@dynamite.com.au> writes:

>D'Arcy J.M. Cain wrote:
>> 
>> Alan E & Carmel J Brain wrote:
>> > Every time someone says how terse and powerful C is, I think of APL.
>> 
>> My favourite quote about APL - "I refuse to use any computer language
>> in which the proponents shove snippets of code under each other's
>> nose saying 'I bet you can't guess what this does!'"
>
>Trouble is, this is true. I wrote a security system that took a user
>input, used it to write a program which when executed wrote another
>program that modified the first program, exited, and the first program
>then gave access to certain data. In 2 lines. Due to hardware
>limitations, this 2-liner was impossible to make "hidden" so I made it
>Cryptic, and self-modifying. 2 months later, even I couldn't figure out
>exactly what it did.
> 
Of course, you were deliberately *trying* to be cryptic, as a security
measure (not the best way to do security, IMO, but that is another matter).
 I would say that your code fulfilled its designed function pretty well. 
It might have been a good idea to document what it did, how and why, and
sve this in a secure (off-line) place, since the code was intentionally obscure.




              -David E. Siegel
               Software Developer, Financial Reporting Software (FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Jerry van Dijk]

In article <19971016134401.JAA11348@ladder01.news.aol.com> frsdes@aol.com writes:

>Of course, you were deliberately *trying* to be cryptic, as a security
>measure (not the best way to do security, IMO, but that is another matter).

In our company this is known as the SBO method.

SBO = Security By Obscurity

:-)

--

-- Jerry van Dijk | Leiden, Holland
-- Consultant     | Team Ada
-- Ordina Finance | jdijk@acm.org

Re: Programming language vote - results

[John Sullivan]

In article <34466EB4.3381@dynamite.com.au>, Alan E & Carmel J Brain
<aebrain@dynamite.com.au> writes
>D'Arcy J.M. Cain wrote:
>> 
>> Alan E & Carmel J Brain wrote:
>> > Every time someone says how terse and powerful C is, I think of APL.
>> 
>> My favourite quote about APL - "I refuse to use any computer language
>> in which the proponents shove snippets of code under each other's
>> nose saying 'I bet you can't guess what this does!'"
>
>Trouble is, this is true. I wrote a security system that took a user
>input, used it to write a program which when executed wrote another
>program that modified the first program, exited, and the first program
>then gave access to certain data. In 2 lines. Due to hardware
>limitations, this 2-liner was impossible to make "hidden" so I made it
>Cryptic, and self-modifying. 2 months later, even I couldn't figure out
>exactly what it did.
> 
You can do exactly the same thing in most other languages. I could write
a book about the Fortran I've had to debug that was impenetrable. Stuff
from reputable suppliers that came undebugged, with so many computed
goto's that the diagrams I drew to try to see what was going on
resembled spaghetti.

So, why didn't you document your code when you wrote it? Don't blame APL
for your own inadequacies.


John Sullivan
-------------
remove the dots from the first three (Welsh) words for my real address

Re: Programming language vote - results

[Randy MacDonald]

In article <3gIvKGAfUmR0EwEl@yddraiggoch.demon.co.uk>, John Sullivan <john@y.ddraig.goch.demon.co.uk> wrote:
 
>You can do exactly the same thing in most other languages.

but it takes sooo much longer....

>So, why didn't you document your code when you wrote it? Don't blame APL
>for your own inadequacies.

I'm not sure if the impenetrability of the "security" code was a problem
or a solution, are you?

The lovely thing about incomprehensible APL is, when you find it, how little
of it there is, compared to reams of C.

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[Alan E & Carmel J Brain]

John Sullivan wrote:
> In 2 lines. Due to hardware
> >limitations, this 2-liner was impossible to make "hidden" so I made it
> >Cryptic, and self-modifying. 2 months later, even I couldn't figure out
> >exactly what it did.
> >
> You can do exactly the same thing in most other languages.

Disagree. Truly impenetrable FORTRAN can't be written in only 2 lines. I
repeat 2 lines. Not 2 pages. 2 lines.
For a real rat's nest of FORTRAN, you need more than 2 pages. 

> So, why didn't you document your code when you wrote it? Don't blame APL
> for your own inadequacies.

*SIGH* Obviously I didn't make myself clear.

1. I had to write a security system.
2. I couldn't stop any hacker from being able to read the source code.
(It was interpreted). 
3. So I deliberately tried to made it obscure, so no casual hacker could
break in in a few minutes.
4. I succeeded in my attempt.

If the above isn't clear to you, I'll explain in more detail via e-mail.

Yes, the code was documented, giving the exact algorithms used, and said
documentation (about 12 pages) was kept in a safe. The point was that
even I, the author of the code, could not look at a mere 2 lines and
figure out what the thing did, just from looking at the source.

Regarding inadequacies, I can't exactly blame APL for mine, there are
too many! An inability to suffer fools gladly being one of them. 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[John Sullivan]

In article <34481248.4F0A@dynamite.com.au>, Alan E & Carmel J Brain
<aebrain@dynamite.com.au> writes
>John Sullivan wrote:
>> In 2 lines. Due to hardware
>> >limitations, this 2-liner was impossible to make "hidden" so I made it
>> >Cryptic, and self-modifying. 2 months later, even I couldn't figure out
>> >exactly what it did.
>> >
>> You can do exactly the same thing in most other languages.
>
>Disagree. Truly impenetrable FORTRAN can't be written in only 2 lines. I
>repeat 2 lines. Not 2 pages. 2 lines.
>For a real rat's nest of FORTRAN, you need more than 2 pages. 

What's all this crap about only two lines? Are you trying to claim somne
sort of prize -- "Look over here guys, I got this program down to just 2
lines. Bet you can't figure out what it does"!


>
>> So, why didn't you document your code when you wrote it? Don't blame APL
>> for your own inadequacies.
>
>*SIGH* Obviously I didn't make myself clear.
No, you made yourself only too clear.
>
>1. I had to write a security system.
>2. I couldn't stop any hacker from being able to read the source code.
>(It was interpreted). 
>3. So I deliberately tried to made it obscure, so no casual hacker could
>break in in a few minutes.
>4. I succeeded in my attempt.
That's obvious. You succeeded in preventing yourself knowing what your
own "program" was doing. Very secure system, that. 
>
>If the above isn't clear to you, I'll explain in more detail via e-mail.
Don't bother. I really couldn't care one way or the other.

I am fed up with hearing about people using unsuitable languages for the
jobs they have to do. This is just another boring example. Why you want
to boast about it beats me.

Lesson 1: Do not use an interpreted language to write a security system.
>
>Yes, the code was documented, giving the exact algorithms used, and said
>documentation (about 12 pages) was kept in a safe. The point was that
>even I, the author of the code, could not look at a mere 2 lines and
>figure out what the thing did, just from looking at the source.
Maybe you should read some textbooks on program design, the sort of
things I, and no doubt many other APLers also, was encouraged to read,
in order to learn how to program so you cannot get into the situation
you describe.

And I repeat, using different words this time, your attempted solution
to your problem was totally inadequate. Do not blame APL for this
inadequacy.

>
>Regarding inadequacies, I can't exactly blame APL for mine, there are
>too many! An inability to suffer fools gladly being one of them. 
You muat be very insufferable then. And try not to look in the mirror.

John Sullivan
-------------
remove the dots from the first three (Welsh) words for my real address

Re: Programming language vote - results

[Randy MacDonald]

In article <34466EB4.3381@dynamite.com.au>, aebrain@dynamite.com.au wrote:
>..ines. Due to hardware
>limitations, this 2-liner was impossible to make "hidden" so I made it
>Cryptic, and self-modifying. 2 months later, even I couldn't figure out
>exactly what it did.

So, where's the code? Sounds like a challenge.  If it's MCM code, you
might be interested in knowing we are still using code derived from that
system ([]XR []XW ring a bell?) 

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[Alan E & Carmel J Brain]

Randy MacDonald wrote:
> 
> In article <34466EB4.3381@dynamite.com.au>, aebrain@dynamite.com.au wrote:
> >..ines. Due to hardware
> >limitations, this 2-liner was impossible to make "hidden" so I made it
> >Cryptic, and self-modifying. 2 months later, even I couldn't figure out
> >exactly what it did.
> 
> So, where's the code? Sounds like a challenge.

No. Please. I'm begging. I've spent the better part of my professional
life trying to get rid of the "fastest gun in the west" mentality of
programming.

"There are two ways to write a program: Either make it so complex,
there's nothing obviously wrong, or so simple that there's obviously
nothing wrong."

Hence my preference for Ada. When listening to C weenies - er -
enthusiasts talking about how their code is so tight, so efficient, and
above all so impenetrable that it's obviously superior to another
solution (in Ada so clear that "Any Fool could have written that"), I
have to take a dried-frog pill and count to 10. In my younger and more
foolish days, I was of a like mind. Now I think that APL has a place,
but only in small, one-use throw-aways, and where terseness if vital (as
in downloading complex programs over low-bandwidth data links). Probably
other, similar areas as well. I'm glad it exists, as I'd hate to have to
invent it!

I once made the mistake of lending one of these C Hackers my old copy of
"Structured Programming in APL" (a title that still leaves me gasping at
the Oxymoron), and he's now a confirmed APL enthusiast.

>  If it's MCM code, you
> might be interested in knowing we are still using code derived from that
> system ([]XR []XW ring a bell?)

Yes. All too well. ACKH. (Imagine Bill the Cat, that's my reaction) Oh,
and of course Quad ZZ.
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[FRS DES]

In article <344BCED0.2D51@dynamite.com.au>, Alan E & Carmel J Brain
<aebrain@dynamite.com.au> writes:

> Now I think that APL has a place,
>but only in small, one-use throw-aways, and where terseness if vital (as
>in downloading complex programs over low-bandwidth data links). Probably
>other, similar areas as well. I'm glad it exists, as I'd hate to have to
>invent it!

Those of us who spend our full time working on multi-megabyte APL
programs, sold to Fortune 500 companies, written entirely in APL, disagree
with your notion of its "Place".  I woulf be the first toi agree that not
every task is best accomplished in APL (or any other single language), but
it is an excellant tool in a *wide* range of situations. Properly written
and commented, it need be no more obscure than any other programming
language.  I grant that it is possible to write particularly obscure APL,
but have you looked at the output of the "obfuscated C contest" lately. 
Idiocy canb be committed in any language.

>
>I once made the mistake of lending one of these C Hackers my old copy of
>"Structured Programming in APL" (a title that still leaves me gasping at
>the Oxymoron), and he's now a confirmed APL enthusiast.
>
APL does not *enforce* structured programming (neither does C), but
structured programming is perfectly possible (and not uncommen) in APL. 
Modern APL supports such control structures as IF/ElseIF/Else/Endif;
For/EndFor/ Select/Case/Case/EndSelect; Repeat/Until; and Do While/EndDo
which can aid the programmer in creating clear code, and can often improve
run-time speed as well.





              -David E. Siegel
               Software Developer, Financial Reporting Software (FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Alan E & Carmel J Brain]

FRS DES wrote:
> 
> In article <344BCED0.2D51@dynamite.com.au>, Alan E & Carmel J Brain
> <aebrain@dynamite.com.au> writes:
> 
> > Now I think that APL has a place,
> >but only in small, one-use throw-aways, and where terseness if vital (as
> >in downloading complex programs over low-bandwidth data links). Probably
> >other, similar areas as well. I'm glad it exists, as I'd hate to have to
> >invent it!
> 
> Those of us who spend our full time working on multi-megabyte APL
> programs, sold to Fortune 500 companies, written entirely in APL, disagree
> with your notion of its "Place".

Why is it in APL? Because at the time the first version was written,
that was the most appropriate choice of language available, and because
no single upgrade was worth a re-write from the ground up? If the code
was to be written from the start  NOW with the tools now available,
would APL be the best choice?
I will willingly admit that in some cases at least, the answer to that
last may well be YES. But I'd be interested in knowing why. I'm not
being facetious or sarcastic, I genuinely want to exploit another
professional's expertise (for free)

I admit the idea of multi-megabyte APL rather boggles my mind. The
configuration management alone must be an interesting challenge on such
a large project.

>  I woulf be the first toi agree that not
> every task is best accomplished in APL (or any other single language), but
> it is an excellant tool in a *wide* range of situations. Properly written
> and commented, it need be no more obscure than any other programming
> language.  I grant that it is possible to write particularly obscure APL,
> but have you looked at the output of the "obfuscated C contest" lately.
> Idiocy canb be committed in any language.

Concur. It can be done in Ada too, it just requires a higher order of
idiocy. I guess that's the nub: that good APL requires a really good (ie
gifted) programmer, whereas a mediocre (not bad, just not gifted) one
can write good Ada that's at least as efficient, readable and more
maintainable.
 
> Modern APL supports such control structures as IF/ElseIF/Else/Endif;
> For/EndFor/ Select/Case/Case/EndSelect; Repeat/Until; and Do While/EndDo
> which can aid the programmer in creating clear code, and can often improve
> run-time speed as well.

Thanks, I didn't know this. (ie that modern dielects of APL had this
capability, not the worth of same). What's the situation vis-a-vis
Standards, ie compatability between brand-X APL and brand-Y?
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[Lawrence Kirby]

In article <344BCED0.2D51@dynamite.com.au>
           aebrain@dynamite.com.au "Alan E & Carmel J Brain" writes:

...

>Hence my preference for Ada. When listening to C weenies - er -
>enthusiasts talking about how their code is so tight, so efficient, and
>above all so impenetrable that it's obviously superior to another
>solution (in Ada so clear that "Any Fool could have written that"), I
>have to take a dried-frog pill and count to 10.

I don't know what sort of C programmers you talk to but that is *not*
the sort of approach advocated on comp.lang.c. Here we're interested
in code that is portable and clear. Optimisation is only a secondary
issue, the most important aspect of that is choosing the right
algorithm.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Programming language vote - results

[Kaz]

In article <877355167snz@genesis.demon.co.uk>,
Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>In article <344BCED0.2D51@dynamite.com.au>
>           aebrain@dynamite.com.au "Alan E & Carmel J Brain" writes:
>
>...
>
>>Hence my preference for Ada. When listening to C weenies - er -
>>enthusiasts talking about how their code is so tight, so efficient, and
>>above all so impenetrable that it's obviously superior to another
>>solution (in Ada so clear that "Any Fool could have written that"), I
>>have to take a dried-frog pill and count to 10.
>
>I don't know what sort of C programmers you talk to but that is *not*
>the sort of approach advocated on comp.lang.c. Here we're interested
>in code that is portable and clear. Optimisation is only a secondary
>issue, the most important aspect of that is choosing the right
>algorithm.

In any case, Ada's clarity of expression is extremely overemphasized
by Ada ween^H^H^H^Hadvocates.

Ada source has very little to guide the eye, due to its lack of the use of
concise graphical symbols. Blocks delimited by BEGIN and END simply do not
nest visually.  The comments introduced by -- simply don't stand out very
well. The input character set is excessively restricted, and simple ()
parentheses are too overloaded in meaning because {} and [] aren't available
(is x(y) a function call or an array ref?). Can you say dull? 
As a result, your brain has to do a lot more analysis when reading code,
since you have to subconsciously check the syntax and even some semantics
to glean information that could be lexically determined.

Ada programs tend to be verbose and amorphous looking, qualities which occlude
the meaning. (I'm talking about conventionally formatted programs, too e.g.
GNAT sources. It wouldn't be fair to pick a purposely obfuscated example,
just like it wouldn't be fair to choose an obfuscated C example.)

Although Ada is great, I wouldn't advocate it on grounds of lexical or
syntactic convenience or readability. You'd have to be crazy!
-- 

Re: Programming language vote - results

[Alan E & Carmel J Brain]

Kaz wrote:

> >>Hence my preference for Ada. When listening to C weenies - er -
> >>enthusiasts talking about how their code is so tight, so efficient, and
> >>above all so impenetrable that it's obviously superior to another
> >>solution (in Ada so clear that "Any Fool could have written that"), I
> >>have to take a dried-frog pill and count to 10.

> In any case, Ada's clarity of expression is extremely overemphasized
> by Ada ween^H^H^H^Hadvocates.

The word you're looking for is "Fanatics". As in people who are so busy
fighting, they've forgotten what they're fighting for. I have been known
to suffer from this myself, as you may have guessed, but I try to keep
it in check. Sometimes it's difficult.

> Ada source has very little to guide the eye, due to its lack of the use of
> concise graphical symbols. Blocks delimited by BEGIN and END simply do not
> nest visually.

Concur. Chroma keying helps, as it does in any similar language. But
even {} is not really good, unless used in the style
xxxxxxx
{
  xxxx
  xxxxx
}

rather than

xxxxxxx {
  xxxx
  xxxxx
}

> The comments introduced by -- simply don't stand out very well.

As opposed to // ? Have to think about this one, I can't see there's
much to choose. */ and /* on the other hand, seem significantly worse.
But what about other languages/methods? How can this be done better?
Over 2 U for suggestions.
 
> The input character set is excessively restricted, and simple ()
> parentheses are too overloaded in meaning because {} and [] aren't available
> (is x(y) a function call or an array ref?).

Does it matter? Sometimes, yes, it does, and the overload is then a
right pain. Other times, the degree of abstraction that is optimal is
such that you don't need to know, and this is more often the case in the
domains I've been working in.
For example, TheGuestList(x) could be:
a function that examines a database on system 345 then assembles the
name into a record, then makes a call to a server outside the system to
find the dietary restrictions, then after completion asks for operator
input from another terminal so we can allocate a seat , or it could be a
simple reference to an array. In either case though, what you end up
with is a guest and the data. How that's done, especially on a
distributed system where the data is all over the place, is irrelevant
to the issue. More to the point, you can make a system where everything
is hard-coded in a table and get your segment working correctly, while
the team(s) doing the server and HCI get their act together 2 months
late.
  
The fact that other languages have this problem, and worse, is
immaterial.

> As a result, your brain has to do a lot more analysis when reading code,
> since you have to subconsciously check the syntax and even some semantics
> to glean information that could be lexically determined.

Excellent point, Sir! Agree that all languages I've seen have this
problem. Some worse than others, eg fred*bill; - declaration or
multiplication?
  
> Ada programs tend to be verbose and amorphous looking, qualities which occlude
> the meaning. (I'm talking about conventionally formatted programs, too e.g.
> GNAT sources. It wouldn't be fair to pick a purposely obfuscated example,
> just like it wouldn't be fair to choose an obfuscated C example.)

Partial agreement. Example: A loop through an enumerated type (this is
fairly common to a lot of problems, right?)

C++ (with Hungarian-like Notation)
//----------------------------------------------------------

enum TrafficLight_E [ Red_KE = 1, Amber_KE, Green_KE ];
const MaxTrafficLight_K = Green_KE + 1;

for (int index = 1; index < MaxTrafficLight_K ; index++)
{
   // some statements
}

//----------------------------------------------------------

compared with:

Ada (with TypeRecord notation)
--///////////////////////////////////////////////////////////

type TrafficLightType is (Red, Amber, Green);

for index in TrafficLightType
loop
  -- some statements 
end loop;

--///////////////////////////////////////////////////////////

In some ways, the C++ is more verbose, is it not?
 
> Although Ada is great, I wouldn't advocate it on grounds of lexical or
> syntactic convenience or readability. You'd have to be crazy!

To me, in the above example, the Ada is more readable. And a heck of a
lot easier to type. Examples are always suspect, however, and I agree
completely that you can always find a pathological case. Yet to me, this
one is not atypical: The Hungarian Notation for C++ seems neccessary to
me, since in C++ you're vitally interested in the representation. Sure,
it's a maintenance nightmare when an int changes to a long, but the
benefits far outway the disadvantages. At least IMHO.
In Ada, you've got better things to worry about than the representation,
as a general rule. And when you do need it, you use a representation
clause, such as one that makes Red equal to (binary) 100, Amber to 010
and Green to 001, as they may well do if you're controlling/reading via
a parallel port.

Your thoughts? I'm especially interested since you obviously know
something about Ada-83 or -95 as well as C/C++. Unlike most critics, I
hasten to add. Are you familiar with APL too? The comment symbol there
is not exactly obvious!
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Ada Readability (Re: Programming language vote - results)

[Ray Blaak]

kaz@latte.cafe.net (Kaz) writes:

>Ada source has very little to guide the eye, due to its lack of the use of
>concise graphical symbols. Blocks delimited by BEGIN and END simply do not
>nest visually.  The comments introduced by -- simply don't stand out very
>well. The input character set is excessively restricted, and simple ()
>parentheses are too overloaded in meaning because {} and [] aren't available
>(is x(y) a function call or an array ref?). Can you say dull? 
>As a result, your brain has to do a lot more analysis when reading code,
>since you have to subconsciously check the syntax and even some semantics
>to glean information that could be lexically determined.

I would suggest that this is a subjective matter. For me Ada's verbose
constructs stand out much better than C/C++'s, simply because there is an
english-like way to read them. It is really a matter of what you are used to;
once your brain is wired for a language, it can see it easily.

As for needing to know the semantics, I would say that the situation is much
worse in C++, where a function call might in fact be a constructor, implicit
construction and type coversions are happening, and almost all operators can
be user defined.

Note that not knowing if x(y) is a function call or an array can be an
advantage in that it need not matter how the mapping is implemented. Consider
a look up table that starts off being implemented as a succinctly coded
function, but is later changed to be a straight array for efficiency reasons.
Client usage will not have to change.

>Although Ada is great, I wouldn't advocate it on grounds of lexical or
>syntactic convenience or readability. You'd have to be crazy!

Call me crazy then.

Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Programming language vote - results

[Alan E & Carmel J Brain]

Lawrence Kirby wrote:

> >Hence my preference for Ada. When listening to C weenies - er -
> >enthusiasts talking about how their code is so tight, so efficient, and
> >above all so impenetrable that it's obviously superior to another
> >solution (in Ada so clear that "Any Fool could have written that"), I
> >have to take a dried-frog pill and count to 10.
> 
> I don't know what sort of C programmers you talk to but that is *not*
> the sort of approach advocated on comp.lang.c. Here we're interested
> in code that is portable and clear. Optimisation is only a secondary
> issue, the most important aspect of that is choosing the right
> algorithm.

I've noticed that often the type of views espoused on comp.lang.c are,
if I may say so, both highly professional and alas, atypical. At least
in my experience (in 3 continents and 4 companies).

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[Randy MacDonald]

In article <344BCED0.2D51@dynamite.com.au>, aebrain@dynamite.com.au wrote:
>Randy MacDonald wrote:
 
>> So, where's the code? Sounds like a challenge.

>No. Please. I'm begging.

Thus you consider your security code a failure?

>I've spent the better part of my professional
>life trying to get rid of the "fastest gun in the west" mentality of
>programming.

Given that most languages have built in viscosity, this is probably
a wise course.

>"There are two ways to write a program: Either make it so complex,
>there's nothing obviously wrong, or so simple that there's obviously
>nothing wrong."

The mathematical nature ("everything is either trivial or impossible") of
software is, regrettably, still in the future.  A middle ground still exists.

>Hence my preference for Ada. When listening to C weenies - er -
>enthusiasts talking about how their code is so tight, so efficient, and
>above all so impenetrable that it's obviously superior to another
>solution (in Ada so clear that "Any Fool could have written that"),

This is the claim COBOL made also.  I don't believe that one either.
My impression is that if an Ada program is clear, it probably isn't being
used for its intended purpose, i.e. an embedded program.

> I have to take a dried-frog pill and count to 10. In my younger and more
>foolish days, I was of a like mind. 

>Now I think that APL has a place,
>but only in small, one-use throw-aways, 

We, and those of our clients who have used our "one-use throw-away"
software for time now measureable in decades would probably differ on
this.  As one who has built these systems, the 

>and where terseness if vital (as
>in downloading complex programs over low-bandwidth data links).

If that were true, Java wouldn't exist.

>Probably other, similar areas as well. I'm glad it exists, as I'd hate to
> have to invent it!

>I once made the mistake of lending one of these C Hackers my old copy of
>"Structured Programming in APL" (a title that still leaves me gasping at
>the Oxymoron), and he's now a confirmed APL enthusiast.

The structure is in the data, and more recently in the code.  A nice property
of APL/J programs is that, where a structured look appears, for example, where
a series of lines have parallel structure, the similarity can be factored out,
leaving a series of individually unique lines.

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[Don Guinn]

Why is it OK to spend a whole morning understanding a couple pages of
FORTRAN code, yet it is unreasonable to spend the same amount of time
with a 2-liner in APL or J which does the same thing?

Don Guinn
donguinn@hal-pc.org

Re: Programming language vote - results

[Randy MacDonald]

In article <344DEAA9.5115@hal-pc.org>, donguinn@hal-pc.org wrote:
>Why is it OK to spend a whole morning understanding a couple pages of
>FORTRAN code, yet it is unreasonable to spend the same amount of time
>with a 2-liner in APL or J which does the same thing?

A couple of reasons come to mind:

1. APL hides a lot of the detail within primitives.  Usually the result
   is the focus as opposed to the algorithm.

2. APL combines a lot of what would be separate cases in FORTRAN into 
   a single case.  Essentially there is one set of numbers in APL, where
   in FORTRAN, code varies for each separate data type, and the semantics
   of expressions like:


    C = A / B
    K = I / J

    can produce quite different results.  Note that I am assuming the
    I..N as INTEGER rule for FORTRAN.

3.  APL can remove the need for temporary variables, or control variables
    or index variables.


In terms of what one would call a reasonable period for understanding, it
is also true that APL tends to match the subject matter, while FORTRAN
also adds the artifacts of the language as things to be understood.

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[Don Guinn]

D.H. Kelly wrote:
> 
> Don Guinn wrote:
> Why is it OK to spend a whole morning understanding a couple pages of
> FORTRAN code, yet it is unreasonable to spend the same amount of time
> with a 2-liner in APL or J which does the same thing?
> _______________________________
> I prefer to use APL but I have long ago realized that it is beneficial to
> spread it out a bit rather than use very complex 1 or 2 liners. It might
> make it possible to figure the program out in a couple of minutes rather
> than hours - especially if properly commented. APL is great for getting
> things done concisely and effectively but that is no excuse for obscurity.
> The delight many take in writing one line recursive programs, etc, actually
> turns others off so that they miss the real usefullness of the language.
> --
> Don Kelly
> dkelly@nanaimo.ark.combull
> remove the "bull " to reply
_________________________________

You are right.  It does make it easier to read if things are spread out.

Lately I have had to spend a fair amount of time studying Visual Basic
and was impressed on how Microsoft and other writers could fill a thick
book with so little information.  I was able to read the books faster
than I read paperbacks because after I saw the same information the
third time I could simply scan it looking for possible differences.

Not so with APL and J.  Redundancy is minimal and it takes a long time
to read the manuals.

The same thing happens in code.  Visual Basic, C etc. are voluminous in
the size of the source.  The source for a small application go on and on
and can be read rapidly because the information content is so low.  A
manager looks at the size of the source and is impressed!  Don't tell
him that most of it is boilerplate built by a wizard.  That out of the
20 to 100 pages of source there resides two or three pages of original
code.

Now that same manager comes in and sees that you're spending days
working on a program in APL which, if printed, would fill only a few
pages.  He is not impressed!  You are obviously not producing. 
Nevermind that both produce the same result.

As far as documenting code.  Documentation is wonderful when it adds
information and insight on what the program does.  I have seen too many
programs full of documentation which does nothing but repeat what is
already stated in the code itself.  It's as if the person who wrote it
can't read his own code.

Which brings up how programming is being taught.  We go to classes to
learn how to write computer programs.  Where does one go to learn how to
read programs?  Ever see a course in reading computer programs. 
Actually there are, but they're never called that.  They are called
analysis and debugging courses and no applications programmer would ever
want to go to.

I'll never forget the little red book for a linear algebra course I
took.  It was no bigger than the J dictionary.  We would spend an entire
evening on one page.  Does that mean that it was not well written?

Documentation needs to explain the concepts used in an application.  It
should provide definitions of terms (variables) and possible things to
watch out for.  But it should not have to translate the source code into
English.  It should not be measured by the pound.


Don Guinn
donguinn@hal-pc.org

Re: Programming language vote - results

[Shmuel (Seymour J.) Metz]

Don Guinn wrote:
> 
> As far as documenting code.  Documentation is wonderful when it adds
> information and insight on what the program does.  I have seen too many
> programs full of documentation which does nothing but repeat what is
> already stated in the code itself.  It's as if the person who wrote it
> can't read his own code.

When I was drafted into teaching a programming course I told my students
that I would take points off for any comments that didn't clarify the
program and for any code that I couldn't understand. I'm older and wiser
now; if I have to teach another course I will also insist that a
randomly selected student be able to understand the code.
 
> Documentation needs to explain the concepts used in an application.  It
> should provide definitions of terms (variables) and possible things to
> watch out for.  But it should not have to translate the source code into
> English.  It should not be measured by the pound.

Amen!

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Documenting Code (was:Programming language vote - results)

[Alan E & Carmel J Brain]

Don Guinn wrote:

> > Don Guinn wrote:
> > Why is it OK to spend a whole morning understanding a couple pages of
> > FORTRAN code, yet it is unreasonable to spend the same amount of time
> > with a 2-liner in APL or J which does the same thing?

> > I prefer to use APL but I have long ago realized that it is beneficial to
> > spread it out a bit rather than use very complex 1 or 2 liners.

> You are right.  It does make it easier to read if things are spread out.

> As far as documenting code.  Documentation is wonderful when it adds
> information and insight on what the program does.  I have seen too many
> programs full of documentation which does nothing but repeat what is
> already stated in the code itself.  It's as if the person who wrote it
> can't read his own code.

> Documentation needs to explain the concepts used in an application.  It
> should provide definitions of terms (variables) and possible things to
> watch out for.  But it should not have to translate the source code into
> English.  It should not be measured by the pound.

My viewpoint:

If one is using a language that is "terse", such as APL, where WHAT the
thing does is not immediately obvious, then a quickly-read line which
explains what the code is _supposed_ to be doing is very helpful. At
first glance, it can tell a reader what the code does, more quickly than
ploughing through cryptic things like

GHTransmit(const char* const X);

which is basically a read-only string input to a function.

Secondly, comments often tell what the program is _supposed_ to do, not
always what it does. This means that a quick-scan of the comments only
will not reveal a bug. OTOH a more careful reading, which would reveal
the difference between actual and intended, automatically finds the bug
and suggests a solution.

OK, that's it for documenting WHAT the code does. In many, less terse
languages, comments are more useful for describing _why_ something is
done. For example (in Ada-83);

with Tracker;			-- package for Radar Trackers only!
with TacticalPicture;           -- what's the environment we're in

procedure AllocateRadarTrackers
(TheTrackerStates         in Tracker.StateTableType,
 TheTacticalPicture       in TacticalPicture.BasicRecordType,
 ResultantTrackerCommands out Tracker.CommandListType)
is
-- Procedure that, given a table of the current radar tracker
-- states, and the tactical picture, decides on what commands
-- to give to the radar trackers.
-- These commands are then expected to be transmitted to the
-- trackers by another procedure.
-- Exceptions that can be raised here are:
--   AllTrackersKaputException ( The Trackers are all KO )
--   UnexpectedErrorException  ( Bug or hardware fault)

begin
  -- and so on and so on
end;

Note that in this (deliberately) verbose and non-terse example, the
variables, procedure, exception and type names are self-explanatory.
To some degree, the code _is_ the comment, at least on "what it does".
Most of the comments "as such" are either explanations of the intention,
or give implications of events.

A terser piece of code that is exactly hemeomorphic is:

with Trk;
with TacPic;
procedure TCmds ( T in Trk.Lst, TP in TacPic.TP, Cmds out Trk.Cmds )
is
-- Procedure that, given a table of the current radar tracker
-- states (Trk.Lst), and the tactical picture (TacPic.TP), decides on
-- what commands to give to the radar trackers (Trk.Cmds).
-- These commands are then expected to be transmitted to the
-- trackers by another procedure.
-- Exceptions that can be raised here are:
--   ATK ( _A_ll _T_rackers _K_O )
--   FUBAR  ( Bug or hardware fault)
begin
-- etc etc
end;

Note that despite some bad names, the comments explain what's happening.
Without the comments, this would be so cryptic as to be baroque. A
translation into C++ would be something like

#include TP.h;  // Tactical Picture Class
#include Trk.h; // Tracker Class

Trk::CmdList* TCmds( const Trk::Lst* const TL, const TP::Data* const TP)

// Procedure that, given a table of the current radar tracker
// states (Trk::Lst), and the tactical picture (TP::TP), decides on
// what commands to give to the radar trackers (Trk::Cmds).
// These commands are then expected to be transmitted to the
// trackers by another procedure.
// It's assumed that TL and TP are both going to be used later, so
// the pointers have been made const, as well as the data pointed to.
// Exceptions that can be thrown here are:
//   ATK ( _A_ll _T_rackers _K_O )
//   FUBAR  ( Bug or hardware fault)

{
 // etc etc
}  

When using Hungarian Notation, a lot more verbosity sneaks in, as in the
first Ada example, which has an equivalent of Hungarian Notation in it ( 
Tracker.StateTableType rather than Tracker.State for example)

How NOT to do it (in any language):

procedure P_12_356( X99 in integer )
is
  NumberOfBananas : integer; -- The number of Bananas
  NumberOfBaskets : integer; -- The number of Baskets
  F : float;
begin
 -- and so on in this deliberately BAD example
 -- which shows that it's possible to write really bad Ada,
 -- and make comments that are both verbose and useless,
--  but you have to really, really work at it!
end;

I still for the life of me can't understand why C++ is so popular, yet
Ada is described as obsolete, etc etc when for a lot of purposes, Ada is
C++ with (usually more) clarity, power and safety belts. Certainly in my
experience C++ programmers who've had some exposure to Ada have an
advantage over the rest. But never mind.
--     
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Documenting Code (was:Programming language vote - results)

[Charles Lin]

    One problem with documenting code is that it is often at too fine
a level.   That is, you document individual functions or classes, when
what the user really wants is the overall structure of the code, as
well as how this solution solves the problem.   Sometimes, one practically
wants an overview manual of the code, including the approach to the
solution, the data structures used, and their interactions.

    So, you might have a, say, CAD tool.   You might have objects
that stand for shapes (rectangles, circles), objects that stand
for treating sevearal base objects as a whole.   Objects to keep
track of the state of what is being done (draw, insert, delete,
copy, etc).    Most people would simply comment each of the classes,
but this still gives only a vague idea of how it all fits together.

    I think that producing such a general document might also be
useful for implementors, forcing them to put into words, ideas they
have in their head.   This is esp. important for people who write
code for themselves (or in classes).   By placing idea to paper,
they may clarify muddy thoughts which lead to muddy designs.

--
Charles Lin
clin@cs.umd.edu

Re: Documenting Code (was:Programming language vote - results)

[James L. Ryan]

About a year ago I started using (admittedly with reluctance!) the then
new control structures which appeared in Dyalog APL. (Dyadic had copied
the definitions implemented earlier in APL/2000.) After having used them,
I find that they themselves provide somewhat of a self-commenting
structure. That is, I can find my way around in a routine with such
structures with greater ease than in a similar routine written with
"conventional" means of flow control.

-- 
James L. Ryan   --  bosworth@waterw.com

Re: Documenting Code (was:Programming language vote - results)

[Robert Bernecky]

James L. Ryan wrote:

> About a year ago I started using (admittedly with reluctance!) the then
> new control structures which appeared in Dyalog APL. (Dyadic had copied
> the definitions implemented earlier in APL/2000.) After having used them,
> I find that they themselves provide somewhat of a self-commenting
> structure. That is, I can find my way around in a routine with such
> structures with greater ease than in a similar routine written with
> "conventional" means of flow control.

I agree. I implemented most of APEX using them and found code MUCH
easier to read and maintain. Two other points:

a. Control structures make it easier to generate efficient compiled code
    than I can with GOTO. APEX generates code for these that
    matches or beats good hand-coded FORTRAN on many applications.

b. Control structures make your INTERPRETED code run faster than
    GOTOd code. See my APL95 paper on dynamic programming in
    APL for an example of a 25% speedup in interpreted execution time
    by use of control structures.
Bob

Re: Documenting Code (was:Programming language vote - results)

[Robert Bernecky]

Charles Lin wrote:

>     One problem with documenting code is that it is often at too fine
> a level.   That is, you document individual functions or classes, when
> what the user really wants is the overall structure of the code, as
> well as how this solution solves the problem.   Sometimes, one practically
> wants an overview manual of the code, including the approach to the
> solution, the data structures used, and their interactions.

Indeed.
Consider the usual situation: You get hired into a project with these
characteristics:
   - anyone who designed the original system has been laid off or
     has gone to greener pastures.
   - the system has been maintained for the last 3 years by apprentice
     programmers whose previous job was mechanic in a muffler shop.
   - part X of the system is chewing entire mainframes and growing
     at 15% per month.

The documentation you want to see (and rarely ever do) is:

- What is the INTENT of part X? E.g., in a matrix inversion
   routine, you want something of the form:
     "This function solves sparse linear systems.
       We don't use the built-in DOMINO primitive to do this,
        because the arrays have 250,000 rows and domino doesn't
        know from sparseness today."

- What is going to break if I change/replace/rewrite this?
   In APL, this is a pain to determine, because of APL's
   prehistoric dynamic scoping rules. You have to know
   everyone who calls you (if you use/set a variable that's
   global to you), and you have to know everyone you
   call (if you set or use any variable), because ALL of
   your variables are visible to everyone you call.

   My approach lately has been to feed the entire application
   into the APEX APL compiler, which determines this
   as part of the setup for a later data flow analysis phase.

   In a large system, it's hard because you end up with
       . Black-box subapplications that (for historical reasons
         of wee, tiny main memories) set global/semi-global
         variables. No, you do not have access to the source
         code for the black box.
       . huge function paging files that are either unavailable
         or undecypherable.
    The advent of code maintenance systems such as LOGOS
    help the latter, but not the former.

Bob

Re: Documenting Code (was:Programming language vote - results)

[Randy MacDonald]

In article <3459A84A.246@dynamite.com.au>, aebrain@dynamite.com.au wrote:

>I still for the life of me can't understand why C++ is so popular, yet
>Ada is described as obsolete, etc etc when for a lot of purposes, Ada is
>C++ with (usually more) clarity, power and safety belts. 

Perhaps because most serious implementations have a large price tag
attached, and are not subject to marketing/price wars like those that
have boosted the fortunes of BASIC, Pascal, C and C++.  If Microsoft
had actually succeeded with an APL implementation, this would
probably have led to a much more interesting present.

>Certainly in my experience C++ programmers who've had some exposure to Ada
>have an advantage over the rest. But never mind.

This I would tend to believe as an If-APL-did-not-exist-I-would-be-using-Ada
person.

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Documenting Code (was:Programming language vote - results)

[Robert Dewar]

Randy said of Ada implementations

<<Perhaps because most serious implementations have a large price tag
attached, and are not subject to marketing/price wars like those that
have boosted the fortunes of BASIC, Pascal, C and C++.  If Microsoft
had actually succeeded with an APL implementation, this would
probably have led to a much more interesting present.>>

While this may have been true at one point, at this stage it is serious
disinformation :-)

There is a freely available implementation of Ada 95 that is widely used
by major commercial customers. It is GNAT, the GNU Ada 95 compiler, part
of the GCC system. GNAT is fully validated on a wide range of systems,
and is in fact the *only* Ada 95 technology that implements the full
Ada 95 language and passes 100% of the ACVC tests).

GNAT is available freely on many mirror sites on the net (check out
www.gnat.com for a list of sites). 

You might think that this kind of free availability would eliminate
price competition, but nothing could be further from the truth! Aonix
has an Ada 95 compiler for Windows NT/Win 95 and competes energetically
with GNAT. Limited capability versions of the Aonix Object-Ada compiler
are available for free downloading, and fully capable versions are sold
at very low prices, fully comparable with the price scale established by
MS and Borland for Pascal and C.

Robert Dewar
Ada Core Technologies (which provides commercial support for GNAT)

I realize this is cross-posted rather widely, but when disinformation is
spread widely, it seems appropriate to follow it up to all
corresponding groups.

Re: Documenting Code (was:Programming language vote - results)

[Jon S Anthony]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Randy said of Ada implementations
> 
> <<Perhaps because most serious implementations have a large price tag
> attached, and are not subject to marketing/price wars like those that
> have boosted the fortunes of BASIC, Pascal, C and C++.  If Microsoft
> had actually succeeded with an APL implementation, this would
> probably have led to a much more interesting present.>>
> 
> While this may have been true at one point, at this stage it is serious
> disinformation :-)
> 
> There is a freely available implementation of Ada 95 that is widely used

Well, I'm a big Ada supporter and user, but I have to say that this is
not quite as true as it seems - at least on UNIX.  Certainly, if you
are developing a product you will want to have support for the
implementation vehicle.  For good or ill, that support _is_ more
expensive than for C/C++ stuff.  This is recent "voice of experience"
speaking here.


> price competition, but nothing could be further from the truth! Aonix
> has an Ada 95 compiler for Windows NT/Win 95 and competes energetically
> with GNAT.

I would say that the Aonix NT ObjectAda compiler _is_ definitely
competitive in price with any C/C++ kind of stuff and the capabilities
are way beyond anything in C/C++.  That's for the complete enterprise
level support package.  Hat's off to Aonix for this extremely useful
product line/pricing offering.


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Programming language vote - results

[FRS DES]

In article <01bce1bf$5c2baaa0$95b66bcf@dkelly.ark.com>, "D.H. Kelly"
<dkelly@nanaimo.ark.combull> writes:

>_______________________________
>I prefer to use APL but I have long ago realized that it is beneficial to
>spread it out a bit rather than use very complex 1 or 2 liners. It might
>make it possible to figure the program out in a couple of minutes rather
>than hours - especially if properly commented. APL is great for getting
>things done concisely and effectively but that is no excuse for obscurity.
>The delight many take in writing one line recursive programs, etc, actually
>turns others off so that they miss the real usefullness of the language.  
>-

I agree.  I never write one-line loops or recursive functions -- there is
no good reason to do so.  If there were, in a particular case, I would
probably add 4-5 lines of comments explainging what the fn did and why. 
APL is terse, compared to manyn other languages, but well written APL is
rarely as ters as the language theoritically permits.

              -David E. Siegel
               Software Developer, Financial Reporting Software (FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Alan E & Carmel J Brain]

Randy MacDonald wrote:
>
> >> So, where's the code? Sounds like a challenge. 
> >No. Please. I'm begging.
> Thus you consider your security code a failure?

Nope. I just don't feel any tearing need to a) look up the hard copy
from 1981, b) transcribe the APL into ASCII equivalents for posting and
c) Expose to public view a piece of work I'm not particularly proud of.
Don't think anyone could learn from it, and I'm not being paid, so why
devote the time? 

> >Hence my preference for Ada. When listening to C weenies - er -
> >enthusiasts talking about how their code is so tight, so efficient, and
> >above all so impenetrable that it's obviously superior to another
> >solution (in Ada so clear that "Any Fool could have written that"),
> 
> This is the claim COBOL made also.  I don't believe that one either.
> My impression is that if an Ada program is clear, it probably isn't being
> used for its intended purpose, i.e. an embedded program.

Based upon what evidence? (No, this is not sarcasm, it's a request for
info that might teach me something, if it can penetrate my thick skull).
My own experience on embedded systems these past 12 years or so directly
contradicts this. If you wish, I'll quote some code fragments. I'd be
interested in whether you think them clear, and if not, why not.  

> We, and those of our clients who have used our "one-use throw-away"
> software for time now measureable in decades would probably differ on
> this.

Fair enough. I'm sure you're correct (heck, there are even people who
think RPG is just dandy). Can you tell me why though?

> >and where terseness if vital (as
> >in downloading complex programs over low-bandwidth data links).
> 
> If that were true, Java wouldn't exist.

??? Something with the terseness of APL, if it had the functionality of
Java plus a fair bit more, would be ideal. As it is, Java is
flavour-of-the-month, but has not been shown to be appropriate for
anything larger than relatively small applications. But now we're
straying into territory more appropriate to comp.lang.java, and I'm
adducing vague generalities without giving evidence, so I'd rather not
continue here.
  
> The structure is in the data, and more recently in the code.  A nice property
> of APL/J programs is that, where a structured look appears, for example, where
> a series of lines have parallel structure, the similarity can be factored out,
> leaving a series of individually unique lines.

Please elucidate. A code fragment illustrating this would be greatly
appreciated. My thanks for your time and effort.

I think, considering the cross-post, an equivalent in C, C++ and Ada-95
would be useful too. I'll add those, if you wish (or maybe some reader
who's more enthusiastic about C, C++ might be willing to). 

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

functionality of Java (was Re: Programming language vote - results)

[Randy MacDonald]

In article <3451AE2C.7F7A@dynamite.com.au>, aebrain@dynamite.com.au wrote:
>Randy MacDonald wrote:
>
>> >and where terseness if vital (as
>> >in downloading complex programs over low-bandwidth data links).
>> 
>> If that were true, Java wouldn't exist.
>
>???

If a terse language was what was ideal for downloading complex
programs over these slow links, why did a verbose (relative to
APL) language become the darling of this platform.


> Something with the terseness of APL, if it had the functionality of
>Java plus a fair bit more, 

Given that most of the functionality of Java is in the "built in" objects,
or the default classes (since otherwise, Java is just another Algoloid
language, although it DOES allow objects as the results of functions...)
all APL needs is a sufficiently powerful "default workspace" containing
specific functionality. J, for example, contains in its default profile, an
impressive amount of functionality: program management tools, GUI
management tools,...

>would be ideal.


--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[Jack Rudd]

Alan E & Carmel J Brain wrote:
> 
> ... Now I think that APL has a place,
> but only in small, one-use throw-aways, and where terseness if vital (as
> in downloading complex programs over low-bandwidth data links). Probably
> other, similar areas as well. I'm glad it exists, as I'd hate to have to
> invent it!
> 
I'm an algorithm developer.  The greatest value of APL for me is 
in rapid prototyping.   Usually I can prototype a new application or
subsystem myself, quickly, without need of programmers.  Almost
never is there need for more than a few APLers.  Using a scalar
language, one would have to triple the number of project members,
thus quadrupling the amount of pairwise miscommunication among 
project members.   

I've tried Ada for prototyping.   There's nothing rapid about it.

Jack Rudd

Re: Programming language vote - results

[Alan E & Carmel J Brain]

Jack Rudd wrote:
> 
> Alan E & Carmel J Brain wrote:
> >
> > ... Now I think that APL has a place,
> > but only in small, one-use throw-aways, ---->8------

> I'm an algorithm developer.  The greatest value of APL for me is
> in rapid prototyping. 

Concur completely, an excellent example of 1-use throw-away is when
you're developing and testing an algorithm! APL is one heck of a good
rapid prototyping language. In fact, for algorithm design, I can't think
of one better.

> I've tried Ada for prototyping.   There's nothing rapid about it.

Concur again. It's strengths are in large systems, which are designed to
be maintainable over the long term, and "safe".

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[Kaz]

In article <3451AA9D.259C@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@dynamite.com.au> wrote:
>Concur completely, an excellent example of 1-use throw-away is when
>you're developing and testing an algorithm! APL is one heck of a good
>rapid prototyping language. In fact, for algorithm design, I can't think
>of one better.
>
>> I've tried Ada for prototyping.   There's nothing rapid about it.
>
>Concur again. It's strengths are in large systems, which are designed to
>be maintainable over the long term, and "safe".

Also, Ada does not require a ``space-cadet'' terminal. That is something to
consider.

Does APL still require a character set full of graphic symbols, or are there
``alternate spellings''? What is the latest status of APL as a standardized
language? Is it possible to decompose a system written in APL into separately
compiled modules?

You will have to pardon me, because all I know about APL comes from a book
dating back to 1972 or so. :)
-- 

Re: Programming language vote - results

[FRS DES]

In article <62te54$p4l$1@latte.cafe.net>, kaz@latte.cafe.net (Kaz) writes:

>
>Also, Ada does not require a ``space-cadet'' terminal. That is something to
>consider.
>
Most modern APLs run on standard equipment.  I write APL full-time on a
Dell PC, with no special keyboard.

>Does APL still require a character set full of graphic symbols, or are there
>``alternate spellings''? What is the latest status of APL as a standardized
>language? Is it possible to decompose a system written in APL into separately
>compiled modules?
>
APL still uses special symbols, but this simply means one more font file
on a windows (or mac) system.  It is no harder to install and use an APL
font than any other font.  Most APL programs install one or more APL fonts
for the user.  

I don't know what you mean by a "standardized language".  Most
implementations of APL adhere to the ISO standard for APL, just as most
implementations of C adhere to the C standard.

APL is not (normnally) compiled, so it can not be decomposed into compiled
modules, seperately or not.  An APL system can be decomposed into seperate
modules in any of several ways, depending on the purpose involved.  APL can
call and be called by code written in other languages, such as in a DLL (in
windows).

>You will have to pardon me, because all I know about APL comes from a book
>dating back to 1972 or so. :)

While the core of the language is the same, *MUCH* has changed in APL
since 1972.




              -David E. Siegel
               Software Developer, Financial Reporting Software (FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Robert Bernecky]

Kaz wrote:

> In article <3451AA9D.259C@dynamite.com.au>,
> Alan E & Carmel J Brain  <aebrain@dynamite.com.au> wrote:
> Does APL still require a character set full of graphic symbols, or are there
> ``alternate spellings''? What is the latest status of APL as a standardized
> language? Is it possible to decompose a system written in APL into separately
> compiled modules?

a. APL still requires an oddball character set. I am now on week 9 of
    my latest effort of trying to make a Type 1 PostScript APL font work
    for getting my thesis into .pdf format.
    Languages derived from APL, such as J (www.jsoftware.com) and
    QNial use ascii, and not thus hampered. I suspect that if we [the
    APL design community] had not been so blind to the realities of ergonomics,
    psychology, and display engineering, that we would have abandoned
    the APL character set long ago, and perhaps thereby made APL a far more
    popular language.

b. There is an extant ISO APL Standard, N8485, and a new extended language
     standard either pending acceptance or already accepted. Unfortunately,
     APL vendors are taking almost NO steps to make their products interoperable
     [The adoption of the APL2000 control structures by Dyadic represents a
      very desirable departure from the past in this area. I hope IBM and
      Soliton see the light and do likewise.]. In fact, they seem go to
      substantial lengths to ensure that their products are different enough that

      an application writer has almost zilch change of writing a highly portable
      application. Specific nasty areas include, but are not limited to:
        - Screen driver support
        - File handling
        - Error handling
        - Namespaces
      This NIH attitude is not a new thing. It's been going on since the dark
ages.
      To be fair to the designers, I think they honestly feel that their approach

      is somehow better than the competition. This, however, does the APL
      user community a great disservice.


c. It is possible to decompose an APL application into separately compilable
    modules, sort of. There are several ways this can be done, depending on
    your definitions of separately, compilable, and module. For example:

     - Dyadic Systems offers a namespace capability that lets you
       segregate subsystems (applications) into logically distinct spaces.
       This greatly simplifies merging subsystems into a single workspace,
       maintaining large systems, etc.

     - Iverson Software/Strand offer a similar capability within the J
        interpreter.
     - Snake Island Research's APEX APL compiler has the ability to
        compile APL into UNIX/Winnt executables or .DLL files.
        APEX is not yet a product, but an adjunct to our consulting services.

      - Products such as Soliton's logos provide many of the capabilities needed
        for large system development, such as checkout/checkin, hierarchical
        libraries, makfiles, etc.

Bob

Re: APL argument

[W. Wesley Groleau x4923]

> a. APL still requires an oddball character set. I am now on week 9 of
>     my latest effort of trying to make a Type 1 PostScript APL font work
>     for getting my thesis into .pdf format.

Even when it looks OK on screen, without an APL keyboard, 
it takes a while to train your mind and fingers what's what.

Time to start editing your newsgroups lines!!!

-- 
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be
                    wwgrol AT pseserv3.fw.hac.com

Don't send advertisements to this domain unless asked!  All disk space
on fw.hac.com hosts belongs to either Hughes Defense Communications or 
the United States government.  Using email to store YOUR advertising 
on them is trespassing!
----------------------------------------------------------------------

Re: APL argument

[Randy MacDonald]

In article <3454DCF7.4D05@pseserv3.fw.hac.com>, "W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com> wrote:
>> a. APL still requires an oddball character set. I am now on week 9 of
>>     my latest effort of trying to make a Type 1 PostScript APL font work
>>     for getting my thesis into .pdf format.

I'd be suprised if this hasn't been solved, over and over. If you could detail
the nature of your problems, perhaps a cla'er has some suggestions...

>Even when it looks OK on screen, without an APL keyboard, 
>it takes a while to train your mind and fingers what's what.

This "while" is vastly overemphasized in importance, and is not even
comparable to the effort of learning qwerty in the first place.  Most APL
implementations allow for a "union" keyboard, where ASCII gets top billing
and the APL characters are tucked away behind the Alt- state.  Once you
remember that quad is Alt-L, jot is Alt-J (like that would be tough),
rho is Alt+R, et cetera, you are pretty much back in business.  I haven't used
keycaps since the 80's.

>Time to start editing your newsgroups lines!!!

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[Jan Karman]

Bernecky's hypothesis

"APL still requires an oddball character set
"[..]
"I suspect that if we [the APL design community] had not been so blind to
the realities 
"of ergonomics, psychology, and display engineering, that we would have
abandoned 
"the APL character set long ago, and perhaps thereby made APL a far more
popular 
"language.

is easily be refuted.

Proof #1
It would have been as easy for APL vendors to deliver a free, suitable
keyboard together with the interpreter as it is for canneries to stick a
little key to the bottom of their cans in order to get access to the food
inside. 
I beleive IBM did in the old days, or was it only caps?, and DEC and Data
General had carefully designed decals, but you had to pay for it, presumed
you knew the secret numbers to order them by.
IBM abandoned this habit and even the decals disapeared from the boxes.
Why? 
Perhaps, it didn't add any value to the interpreter. This was a
"marketing-mix" solution. 
A trainee-salesman would have been able to sell the power and fun of APL
against the disadvantages of the oddball characters ("See that little key
sticked at the bottom? ... there's a deli inside!!").
Because knowledge of APL characters is only relevant to programmers, this
would have solved the oddball character problem.
If this had been really the problem it should have easily been solved 

Proof #2, by counter example, i.e. J
Could you say  e.g.: "Let's give APL common ASCII-characters and it would
become as popular as Yahoo?"  
At the same speed you could say : "If we should colour Campari corn-yellow
it would become as popular as beer." 

There's no need for 20,000,000 APL interpreters, but to solve some of the
mudding with computer languages in the 21st century (NB! not just the first
day) we'll badly need some powerful, symbolic language, as there are APL, J
or K. 
J is too complicated and too confusing (private opinion) 
K is privately owned (there seems no desire to make it popular).  
APL is available, cheep  ... and fun. "Stick more magic key to the can",
I'd say.

(Main gates :  http://www.acm.org/sigapl or http://www.vector.org.uk )

Re: Programming language vote - results

[Robert Bernecky]

Jan Karman wrote:

> Bernecky's hypothesis
>
> "APL still requires an oddball character set
> "[..]
> "I suspect that if we [the APL design community] had not been so blind to
> the realities
> "of ergonomics, psychology, and display engineering, that we would have
> abandoned
> "the APL character set long ago, and perhaps thereby made APL a far more
> popular
> "language.

> is easily be refuted.
>
> Proof #1
> It would have been as easy for APL vendors to deliver a free, suitable
> keyboard

I am talking about history and what DID happen. There was no serious
attempt by any vendor to make APL fit into the ascii terminal world.
There is NO doubt in my mind that this seriously hampered APL's acceptance
as a popular language in the 70's and 80's.

> I beleive IBM did in the old days, or was it only caps?, and DEC and Data

Decals (to tell you where the right parenthesis key is when it is not where
you expect it to be... Duuhh) did NOT solve the problems of:
   - Using ascii-only terminals
   - transmitting APL programs across ascii-based networks.

> Because knowledge of APL characters is only relevant to programmers, this

Not so. See above. It affects users and system administrators. Ever triedto
explain to someone back in the dark ages why your APL system couldn't print
a report with someone's name in Upper Case and Lower Case because APL
only had upper case and underbarred characters?

> Proof #2, by counter example, i.e. J
> Could you say  e.g.: "Let's give APL common ASCII-characters and it would
> become as popular as Yahoo?"

Read my message again. I was discussing history. What DID and DID NOT
happen. I am not attempting to peddle APL characters in the 90's. It's too late

for that. Marketing and trendiness have taken over from technical superiority.

Bob

Re: Programming language vote - results

[James L. Ryan]

In article <34565F22.5B66C13E@acm.org>, Robert Bernecky <bernecky@acm.org>
wrote:

[snip]
> 
> I am talking about history and what DID happen. There was no serious
> attempt by any vendor to make APL fit into the ascii terminal world.
> There is NO doubt in my mind that this seriously hampered APL's acceptance
> as a popular language in the 70's and 80's.

In the early seventies Burroughs APL had a "keyword" mode which was
intended to make APL somewhat accessible from an ASCII terminal. When
keywords were enabled APL letters mapped into ASCII lowercase and APL
underscored letters mapped into ASCII uppercase. APL's special characters
were represented by mnemonics embraced by less-than and greater-than
symbols. Admittedly this was not intended to be a substitute for an APL
terminal, but was intended to allow "emergency" access to APL from a
non-APL terminal. With keywords on, and from an ASCII terminal, a line of
APL might have looked as follows:    

     average<is>(+/data)<div><rho>data<is><quad>

Burroughs also contracted, in the early seventies, with Memorex to build a
small number of terminals with 188 printing glyphs, 94 for ASCII and 94
for APL. These terminals could be either hard switched or soft switched
between the character sets. The encodation of the characters was based
upon the so-called APL/ASCII Typewriter Pairing overlay standard which was
agreed upon at the Atlanta APL conference. The inclusion of the dual
character set slowed the performance by a factor of two, but these
terminals were still faster than the then only alternative, the 2741 and
friends "golf-ball" terminals. Even though Burroughs attempted to sell
these Memorex dual character set terminals, the market didn't seem
interested.

[snip]
> 
> Not so. See above. It affects users and system administrators. Ever triedto
> explain to someone back in the dark ages why your APL system couldn't print
> a report with someone's name in Upper Case and Lower Case because APL
> only had upper case and underbarred characters?

Actually the ability to have computer output with both upper and lower
case didn't come about until the early sixties. The computers I programmed
in the late fifties used six bits instead of eight bits to represent
characters. Rather amusingly, the first computer I programmed had 32 bit
words which hosted five six-bit characters per word. You had the uppercase
alphabet, the numerals, and a variety of punctuation characters.

[snip]
>

-- 
James L. Ryan   --  bosworth@waterw.com

Re: Programming language vote - results

[Robert Bernecky]

James L. Ryan wrote:

> In article <34565F22.5B66C13E@acm.org>, Robert Bernecky <bernecky@acm.org>
> wrote:



> In the early seventies Burroughs APL had a "keyword" mode which was



> intended to make APL somewhat accessible from an ASCII terminal. When

> keywords were enabled APL letters mapped into ASCII lowercase and APL

The word "somewhat" is indeed true. I may have invented the first
ascii/apltranslator when I wrote Teletype support into SHARP APL in 1971 or 1972.

I included a translation function that took two character matrices [glyphs and
their text representation] and used that to translate text one way to the other.
You reversed translation direction by switching the matrix arguments.
Similar in spirit to Weigang's APLASCII mapping arrays, but more primitive.

> underscored letters mapped into ASCII uppercase. APL's special characters
> were represented by mnemonics embraced by less-than and greater-than
> symbols. Admittedly this was not intended to be a substitute for an APL
> terminal, but was intended to allow "emergency" access to APL from a
> non-APL terminal. With keywords on, and from an ASCII terminal, a line of
> APL might have looked as follows:

ALL of the keyword schemes I saw (ALL of which differed from
vendor to vendor and even within a single vendor's products) had a
number of bad characteristics, such as:
   - incorrect caret placement on error display
   - difficulties with escape characters
   - little (no) attention paid to user-centered design, to
     make the thing inviting to use. As you point out, Jim,
     they were strictly "Emergency use only" interfaces.

> Burroughs also contracted, in the early seventies, with Memorex to build a
> small number of terminals with 188 printing glyphs, 94 for ASCII and 94
> for APL. These terminals could be either hard switched or soft switched

Yes, indeed. The mighty MRX1240, with an 18 inch long ribbon cartridge thatcost a
bundle, inability to see what you were typing or where the cursor was,
and a MTBF of a few hours.

> friends "golf-ball" terminals. Even though Burroughs attempted to sell
> these Memorex dual character set terminals, the market didn't seem
> interested.

Probably the market asked the suckers (like us) who actually bought oneor two of
them first.

> Actually the ability to have computer output with both upper and lower
> case didn't come about until the early sixties. The computers I programmed

Well before the inception of the APL\360 project.

Bob

Re: Programming language vote - results

[Robert Bernecky]

James L. Ryan wrote:

> In article <34576752.11BAACA1@acm.org>, Robert Bernecky <bernecky@acm.org>
> wrote:
>
> [snip]
>
> > ALL of the keyword schemes I saw (ALL of which differed from
> > vendor to vendor and even within a single vendor's products) had a
> > number of bad characteristics, such as:
> [snip]
>
> I can't comment on keyword schemes other than the one we implemented at
> Burroughs, but we did have correct caret placement on errors. (As an

I don't think I ever saw this in action. Sorry.

> I'm not sure what you mean by "difficulties with escape characters" or

Ability to read a text matrix containing one or more escape characters,
whencolumns were supposed to line up. Your scheme (adding blank columns)
could make a function display REALLY wide. The key here is that

> "user-centered design." I have no recollection of an escape character

Check http://www.ibm.com/ucd for a bit of stuff on user-centered
orhuman-centered design. Also, look at SIGCHI (Human-Computer Interaction)
Proceedings going back 10 years or so. UCD's fundamental precepts include
stuff like: you never design something right the first time, the designer is
NOT
the person who should make decisions about the usability of a design
[the designer is blind to its faults and will often blame the user instead of
the design. If you ever do usability testing (I mean formal  testing, not
shipping a beta off to a few people), you'll quickly find the major holes
in your design, when you see 4 out of 5 users making EXACTLY the same
errors.], use of ergonomic measures such as Fitt's Law [Failure to observe
this is why the Windows up/down scrollbutton placement is so frustrating.]
and so on. I'd like to see someone fund an APL usability study. I'll
bet the language design would dramatically improve within weeks.

> problem when using an ASCII terminal with Burroughs APL. Given that at the

You are not a normal user, being bright, totally familiar with the product,and
[bad bad bad] a designer of it.

> time APL was accessed solely through hard-copy terminals, I feel that the
> input and editing conventions implemented by Burroughs were a cut above
> those implemented with APL/360. And given that the use of a special

 Your crew did some very nice design work.  Generally, elegant and
  clean, well-thought-out ideas.

Of course, with regard to your comment on Burroughs APL vs APL\360:

      "One of the problems of being a pioneer is that you always make
        mistakes, and I never, never want to be a pioneeer. It's always best
        to come second when you can look at the mistakes the
        pioneers made."
              Seymour Cray, LLNL CRAY-1 Introduction Lecture (1976).

Bob

Re: Programming language vote - results

[James L. Ryan]

In article <3458D7A4.A64A0D8F@acm.org>, Robert Bernecky <bernecky@acm.org>
wrote:

[snip]

> Ability to read a text matrix containing one or more escape characters,
> whencolumns were supposed to line up. Your scheme (adding blank columns)
> could make a function display REALLY wide. The key here is that
> 

[snip]

Bob,

I'm a bit confused. The column widening used in Burroughs APL/700 to
accomodate keywords had nothing to do with function display unless the
matrix being displayed contained, say, the canonical representation of a
function. As for the direct display of functions, APL/700, as did all APLs
at the time, reformatted the functions into a canonical form in which
redundant blanks were removed. This removal held whether keywords were
enabled or not. As a now somewhat humorous aside, APL/700, when displaying
a function, removed all redundant parentheses. To some this was blasphemy
and to others this was a desirable feature. (This removal was a byproduct
of the line image being reconstructed from the prefix Polish
representation to which all source lines were converted to immediately
prior to initial execution--the redundant parentheses would appear in a
function image for those lines not yet executed.)

Jim

-- 
James L. Ryan   --  bosworth@waterw.com

Re: Programming language vote - results

[Robert Bernecky]

James L. Ryan wrote:

> In article <3458D7A4.A64A0D8F@acm.org>, Robert Bernecky <bernecky@acm.org>
> wrote:
>
> [snip]
>
> > Ability to read a text matrix containing one or more escape characters,
> > whencolumns were supposed to line up. Your scheme (adding blank columns)
> > could make a function display REALLY wide. The key here is that
>



> I'm a bit confused. The column widening used in Burroughs APL/700 to
> accomodate keywords had nothing to do with function display unless the
> matrix being displayed contained, say, the canonical representation of a

I'm thinking of how one might have made a user-friendly matrix editor.

> enabled or not. As a now somewhat humorous aside, APL/700, when displaying
> a function, removed all redundant parentheses. To some this was blasphemy
> and to others this was a desirable feature. (This removal was a byproduct

Redundancy is in the eyes of the redunder. I think that keeping the
text as entered is a much better idea, having suffered from the disappearing
white space school of design. Keeping parens and white space allows the
programmer to lay things out in a manner that may enhance clarity of
structure to a reader, without making any difference (aside from space and
cpu cycles, which don't appear to matter to people anymore...  8^})
to the computer.

Bob

Re: Programming language vote - results

[James L. Ryan]

In article <3459FAF1.CA68D6CB@acm.org>, Robert Bernecky <bernecky@acm.org>
wrote:

[snip]
> 
> Redundancy is in the eyes of the redunder. I think that keeping the
> text as entered is a much better idea, having suffered from the disappearing
> white space school of design. Keeping parens and white space allows the
> programmer to lay things out in a manner that may enhance clarity of
> structure to a reader, without making any difference (aside from space and
> cpu cycles, which don't appear to matter to people anymore...  8^})
> to the computer.

Dyalog APL does remove redundant white spaces within the APL code but does
preserve comment positioning, and, as a default, preserves leading
indentation. A user preference provides for "AutoFormatting" of functions.
With this facility enabled, the indentation preceding each line is
automatically determined. Such indentation facilitates the reading of
programs as the beginning and ending of the control structures are then
easily paired. I've found that, with autoformatting enabled, I tend to not
miss the ability to include arbitrary white space within my APL code.

As an aside, I have wished, on a number of occasions, for the capability
of breaking (with user selected break points) a long line of APL code into
multiple lines of display.

-- 
James L. Ryan   --  bosworth@waterw.com

Re: Programming language vote - results

[Jack Rudd]

Alan E & Carmel J Brain wrote:
> 
> Jack Rudd wrote:
> >
> > Alan E & Carmel J Brain wrote:
> > >
> > > ... Now I think that APL has a place,
> > > but only in small, one-use throw-aways, ---->8------
> 
> > I'm an algorithm developer.  The greatest value of APL for me is
> > in rapid prototyping.
> 
> Concur completely, an excellent example of 1-use throw-away is when
> you're developing and testing an algorithm! APL is one heck of a good
> rapid prototyping language. In fact, for algorithm design, I can't think
> of one better.
> 
I very seldom throw away a prototyped algorithm.  Write enough of
them (I'm coming up on 30 years of this activity), and one can 
prototype subsystems, then whole systems.  My APL96 paper describes 
one of these... an APL2 prototype of a "hard real-time" system.   

In general, I advocate translating a prototyped system from APL to
another language just prior to delivery to a customer...who, when he
screws it up, can't then blame his problems on APL!

Jack Rudd

Re: Programming language vote - results

[Peter Seebach]

In article <344BCED0.2D51@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@dynamite.com.au> wrote:
>Hence my preference for Ada. When listening to C weenies - er -
>enthusiasts talking about how their code is so tight, so efficient, and
>above all so impenetrable that it's obviously superior to another
>solution (in Ada so clear that "Any Fool could have written that"), I
>have to take a dried-frog pill and count to 10.

Can you honestly point to anyone claiming that "impenetrable" is a
sign of superiority out of the IOCCC?

Efficient is good.  Tight can be good.  Impenetrable is generally not
good.

I disagree with at least the implications of your conclusion.  Writing,
on purpose, impenetrable, bad, inefficient, and ugly code is one of the
best ways to comprehend good code better.  It's all well and good to say
"look, here's a good way to do this".  It's just as good to say "and look,
here's a bad way".

You can't understand fully what makes good code good without understanding
just as fully what makes bad code bad.

-s
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! --- http://www.plethora.net/~seebs
http://www.plethora.net/ - More Net, Less Spam!

Re: Programming language vote - results

[Ingemar Ragnemalm]

Peter Seebach wrote:
> 
> In article <344BCED0.2D51@dynamite.com.au>,
> Alan E & Carmel J Brain  <aebrain@dynamite.com.au> wrote:
> >Hence my preference for Ada. When listening to C weenies - er -
> >enthusiasts talking about how their code is so tight, so efficient, and
> >above all so impenetrable that it's obviously superior to another
> >solution (in Ada so clear that "Any Fool could have written that"), I
> >have to take a dried-frog pill and count to 10.
> 
> Can you honestly point to anyone claiming that "impenetrable" is a
> sign of superiority out of the IOCCC?

There are plenty of people who use C since it is "cool", but just can't
say what is so cool with it. It is cool because Mom can't understand it.
No, they won't say that. You can identify that kind of people by the
lack of comments in the code. They *want* it that way - and they are
many!

> Efficient is good.  Tight can be good.  Impenetrable is generally not
> good.

When "efficient" and "tight" means as few keystrokes as possible, it
isn't good. Efficient C code usually means that you take
responsabilities
that the optimizer should really do for you, and do that through
questionable backdoors in the language. Case switches jumping into
while loops is one example.

> I disagree with at least the implications of your conclusion.  Writing,
> on purpose, impenetrable, bad, inefficient, and ugly code is one of the
> best ways to comprehend good code better.  It's all well and good to say
> "look, here's a good way to do this".  It's just as good to say "and look,
> here's a bad way".

> You can't understand fully what makes good code good without understanding
> just as fully what makes bad code bad.

When you show the bad way to those kids, they think it is WAAAY cool!
They will use any stinking obscure construction just because "it is
valid C code".

Simple example from real life:

if (call_this() || call_that());

Valid, yes. Better than

if (!call_this()) call_that();

or more clear forms in other languages?
Some people actually think so.

/Ingemar

Re: Programming language vote - results

[firewind]

Ingemar Ragnemalm <ingemar@lysator.liu.se> wrote:
> Peter Seebach wrote:
> > Can you honestly point to anyone claiming that "impenetrable" is a
> > sign of superiority out of the IOCCC?

> There are plenty of people who use C since it is "cool", but just can't
> say what is so cool with it. It is cool because Mom can't understand it.
> No, they won't say that. 

So, you insult a great many professional C programmers, and hobbyists, et
cetra by comparing them to an adolescent who just follows the crowd? The
crowd is gaping at OOP at the moment. C is not OOP.

> You can identify that kind of people by the
> lack of comments in the code. They *want* it that way - and they are
> many!

I very seldom comment my code at the first writing. I prefer to just code
and get it done, then go back later and add comments, but -only- to
code which is not easily understood.

> > Efficient is good.  Tight can be good.  Impenetrable is generally not
> > good.

> When "efficient" and "tight" means as few keystrokes as possible, it
> isn't good. 

Why not? You are associating 'few keystrokes' with 'unintelligible' and
'brokenly using bad self-optimization techniques' which is not correct.

> Efficient C code usually means that you take
> responsabilities
> that the optimizer should really do for you, and do that through
> questionable backdoors in the language. Case switches jumping into
> while loops is one example.

'Questionable backdoors'? Some might disagree. BTW, last time I checked,
the C standard didn't garuntee there is an optimizer around to babysit you.

> > I disagree with at least the implications of your conclusion.  Writing,
> > on purpose, impenetrable, bad, inefficient, and ugly code is one of the
> > best ways to comprehend good code better.  It's all well and good to say
> > "look, here's a good way to do this".  It's just as good to say "and look,
> > here's a bad way".

> > You can't understand fully what makes good code good without understanding
> > just as fully what makes bad code bad.

> When you show the bad way to those kids, they think it is WAAAY cool!
> They will use any stinking obscure construction just because "it is
> valid C code".

Again this insulting analogy.

> Simple example from real life:

> if (call_this() || call_that());

> Valid, yes. Better than

> if (!call_this()) call_that();

> or more clear forms in other languages?
> Some people actually think so.

I find myself using a construct like this a lot recently (snipped directly
from code I'm working on right now):

if(!to && !(to = malloc(sizeof *to)))) return(NULL);

For 'verbose' code this would be written:

if(!to) {
	if(!to = malloc(sizeof *to)) {
		return(NULL);
	}
}

I find this unacceptable. The first form is understood well enough anyway:
If 'to' is not valid and an attempt to make 'to' valid fails, return an error.

The

if(foo() || bar())

construct may seem obfuscated and weird to you, it is the way the logic of
some people's minds work. To insult these people by comparing them to
fickle adolescents is simply out of line.

-- 
[-                               firewind                                   -]
[-   email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work)  -]
[-          "You're just jealous because the voices talk to -me-."          -]
[-                   Have a good day, and enjoy your C.                     -]
[-          (on a crusade of grumpiness where grumpiness is due)            -]

Re: Programming language vote - results

[Kevin Swan]

firewind (firewind@metroid.dyn.ml.org) wrote:

: I very seldom comment my code at the first writing. I prefer to just code
: and get it done, then go back later and add comments, but -only- to
: code which is not easily understood.

Heh, I take a somewhat opposite route.  I comment before I code.  :)  Quite
often, the first iteration of my programs look like this:

FILE *fp;
int count = 0;
/* Open the file, test for errors. */
while (1) {
  /* Read a line, look for keyword. */
      /* If found a keyword, print the line, otherwise increment count. */
      /* If EOF hit, break out of loop. */
}
/* Close file, print results to stdout. */

I then go back and fill in the code.  I find this approach works quite well,
and is very close to the top-down paradigm.

Kev.

--
Kevin Swan                                                           BCSH
My university broke my email.  If you want to email me, please send it to
013639s@dragon.acadiau.ca                               Acadia University
                   How's my posting?  Call 1-800-DEV-NULL
** Fatal Error [1]: 'Win95' virus detected on /dev/hda1; Formatting ...

Re: Programming language vote - results

[Alan E & Carmel J Brain]

Kevin Swan wrote:
> 
> firewind (firewind@metroid.dyn.ml.org) wrote:
> 
> : I very seldom comment my code at the first writing. I prefer to just code
> : and get it done, then go back later and add comments, but -only- to
> : code which is not easily understood.
> 
> Heh, I take a somewhat opposite route.  I comment before I code. 

I'd recommend this practice, regardless of the language you're doing it
in. Of course, with a high-level language,

Start the Ethernet Process Task

becomes

ETHERNET(START);

and even a not-so-high-level language can have

Ethernet->Start();

and you can just chop-and-change the comment. Well-written Ada, for
example, is almost character-for-character identical with a good PDL.
In fact, there's an IEEE standard on the use of Ada _AS_  a PDL.

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[Larry Elmore]

firewind wrote in message <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>...

>I very seldom comment my code at the first writing. I prefer to just code
>and get it done, then go back later and add comments, but -only- to
>code which is not easily understood.


Personally, I find it much easier to write the comments describing what each
procedure/function does _first_ (after doing as much design work as I can
force myself to do -- I don't _like_ doing it, but it sure beats
bug-hunting), with stubs, _then_ adding in the code and whatever few
comments are needed to describe what the code is doing at any point. Leaving
all the commenting to the end makes it seem a bigger, more burdensome job,
especially since the program is already done. I suspect this is one reason
why so many programs out there are so poorly commented...

>I find myself using a construct like this a lot recently (snipped directly
>from code I'm working on right now):
>
>if(!to && !(to = malloc(sizeof *to)))) return(NULL);

I _hope_ this isn't really snipped directly from your program, since the
compiler will choke on the parentheses... ;)

Larry

Re: Programming language vote - results

[firewind]

Larry Elmore <ljelmore@montana.campus.mci.net> wrote:
> firewind wrote in message <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>...

> >I very seldom comment my code at the first writing. I prefer to just code
> >and get it done, then go back later and add comments, but -only- to
> >code which is not easily understood.

> Personally, I find it much easier to write the comments describing what each
> procedure/function does _first_ (after doing as much design work as I can
> force myself to do -- I don't _like_ doing it, but it sure beats
> bug-hunting), with stubs, _then_ adding in the code and whatever few
> comments are needed to describe what the code is doing at any point. Leaving
> all the commenting to the end makes it seem a bigger, more burdensome job,
> especially since the program is already done. I suspect this is one reason
> why so many programs out there are so poorly commented...

Well, I document my interface first, on paper, (actually, with 'vi' :) then I
code the interface, then I comment anything hard to understand -within- the
individual functions. (If I know at the time that what I'm coding is
confusing, even to myself, I'll comment as I code... this is comparitively
rare, however.)

> >I find myself using a construct like this a lot recently (snipped directly
> >from code I'm working on right now):
> >
> >if(!to && !(to = malloc(sizeof *to)))) return(NULL);
                                        ^ one too many

> I _hope_ this isn't really snipped directly from your program, since the
> compiler will choke on the parentheses... ;)

Whoops, they are indeed unbalanced! Sorry. :)

-- 
[-                               firewind                                   -]
[-   email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work)  -]
[-          "You're just jealous because the voices talk to -me-."          -]
[-                   Have a good day, and enjoy your C.                     -]
[-          (on a crusade of grumpiness where grumpiness is due)            -]

Re: Programming language vote - results

[Mike Smith]

firewind <firewind@metroid.dyn.ml.org> wrote in article
<64qsf0$ccc@dfw-ixnews11.ix.netcom.com>...
> Again this insulting analogy.
> 
> > Simple example from real life:
> 
> > if (call_this() || call_that());
> 
> > Valid, yes. Better than
> 
> > if (!call_this()) call_that();
> 
> > or more clear forms in other languages?
> > Some people actually think so.
> 
> I find myself using a construct like this a lot recently (snipped
directly
> from code I'm working on right now):
> 
> if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> 
> For 'verbose' code this would be written:
> 
> if(!to) {
> 	if(!to = malloc(sizeof *to)) {
> 		return(NULL);
> 	}
> }
> 

Yeah, and what's wrong with that?  Looks good to me - better than the
logical expression.  And in the first case, 

if (!call_this) call_that(); 

is also the better form.  A good programmer writes code that even
less-skilled programmers can easily read and maintain.  Unless, of course,
the code you write will never need to be maintained or updated, in which
case it is probably of little consequence in the real world.

> some people's minds work. To insult these people by comparing them to
> fickle adolescents is simply out of line.
> 

Okay, how about comparing them to snooty elitist "artists" or "craftsmen"
that are more interested in form than function?  (Function being defined by
a whole host of things other than the actual operation of the program
itself, like robustness, readability, maintainability, portability, etc.)

--Mike Smith

Re: Programming language vote - results

[Matt]

<snip>

> Yeah, and what's wrong with that?  Looks good to me - better than the
> logical expression.  And in the first case,
> 
> if (!call_this) call_that();
                ^
Uh, Mike.       |

A good programmer remembers to Call the function!  ;-)
                               ---- 
sorry, I couldn't resist!!!

Matt

Re: Programming language vote - results

[firewind]

Mike Smith <kld_msmith@earthlink.nospam.net> wrote:
> firewind <firewind@metroid.dyn.ml.org> wrote in article
> <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>...
> > I find myself using a construct like this a lot recently (snipped directly
> > from code I'm working on right now):
> > 
> > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> > 
> > For 'verbose' code this would be written:
> > 
> > if(!to) {
> > 	if(!to = malloc(sizeof *to)) {
> > 		return(NULL);
> > 	}
> > }
> > 

> Yeah, and what's wrong with that?  

Nothing, obviously.

> Looks good to me - better than the
> logical expression.  

This is purely your opinion. Either are correct, and either can be understood
with little or no effort.

(BTW, it's -still- a logical expression; it's just two now.)

> And in the first case, 

> if (!call_this) call_that(); 

> is also the better form.  

Incorrect. It is the form that conforms more to your way of thinking.

> A good programmer writes code that even
> less-skilled programmers can easily read and maintain.  

I hope even less-skilled programmers can understand the boolean operators.

> Unless, of course,
> the code you write will never need to be maintained or updated, in which
> case it is probably of little consequence in the real world.

> > some people's minds work. To insult these people by comparing them to
> > fickle adolescents is simply out of line.

> Okay, how about comparing them to snooty elitist "artists" or "craftsmen"
> that are more interested in form than function?  

Someone more interested in 'form' would write more 'pretty looking' 
constructs, would they not? I am still insulted by your statement. I code
the way I code. My code works. I frankly don't care whether or not you think
my style is 'pretty.' Anything above 'it works' is nothing more than a matter
of opinion. Period.

I find it pretty arrogant for you to think your way is the One True Style
of Coding, and that anyone who dares do differently is a 'snob' or an
'adolescent' or an 'elitist.'

-- 
[-                               firewind                                   -]
[-   email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work)  -]
[-          "You're just jealous because the voices talk to -me-."          -]
[-                   Have a good day, and enjoy your C.                     -]
[-          (on a crusade of grumpiness where grumpiness is due)            -]

Re: Programming language vote - results

[CVigue]

In the given example the shorter version is more obvious and easier to
understand while the longer example is IMO a waste of time and effort.
I think leaving good comments at critical points in the code is more
helpful than trying to predict the next programmers preferences. 

I wonder if anyone here REALLY finds the short version difficult, or
if they are trying to help the mythical 'other guy' who can't
understand it, or perhaps just want a discussion of style.



Charlie V.

Re: Programming language vote - results

[Lawrence Kirby]

In article <6501ih$r1a@dfw-ixnews10.ix.netcom.com>
           firewind@metroid.dyn.ml.org "firewind" writes:

>Mike Smith <kld_msmith@earthlink.nospam.net> wrote:
>> firewind <firewind@metroid.dyn.ml.org> wrote in article
>> <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>...
>> > I find myself using a construct like this a lot recently (snipped directly
>> > from code I'm working on right now):
>> > 
>> > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
>> > 
>> > For 'verbose' code this would be written:
>> > 
>> > if(!to) {
>> >     if(!to = malloc(sizeof *to)) {
>> >             return(NULL);
>> >     }
>> > }
>> > 
>
>> Yeah, and what's wrong with that?  
>
>Nothing, obviously.

The second form is invalid, it is interpreted the same as:

         if((!to) = malloc(sizeof *to)) {

What is required at the very least is:

         if(!(to = malloc(sizeof *to))) {

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Programming language vote - results

[FRS DES]

In article <880301061snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk
(Lawrence Kirby) writes:

>
The second form is invalid, it is interpreted the same as:


>if((!to) = malloc(sizeof *to)) {

What is required at the very least is:


>if(!(to = malloc(sizeof *to))) {



This thread no longer seems to have anything to do withg APL -- Please remove
comp.lang.apl from the list of newsgroups, or start a new thread.


              -David E. Siegel
               Software Developer, LEX2000, Inc 
               (Formerly Financial Reporting Software, or FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Andy Knight]

Your credibility is brought in to question when you present code that has
been "snipped directly from code..." that can not possibly compile. Then you
expand this codswallop into its supposed "verbose" form into something which
is equally nonsensical.

I'm off to adjust my filters.

firewind wrote in message <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>...
>Ingemar Ragnemalm <ingemar@lysator.liu.se> wrote:
>> Peter Seebach wrote:
>> > Can you honestly point to anyone claiming that "impenetrable" is a
>> > sign of superiority out of the IOCCC?
>
>> There are plenty of people who use C since it is "cool", but just can't
>> say what is so cool with it. It is cool because Mom can't understand it.
>> No, they won't say that.
>
>So, you insult a great many professional C programmers, and hobbyists, et
>cetra by comparing them to an adolescent who just follows the crowd? The
>crowd is gaping at OOP at the moment. C is not OOP.
>
>> You can identify that kind of people by the
>> lack of comments in the code. They *want* it that way - and they are
>> many!
>
>I very seldom comment my code at the first writing. I prefer to just code
>and get it done, then go back later and add comments, but -only- to
>code which is not easily understood.
>
>> > Efficient is good.  Tight can be good.  Impenetrable is generally not
>> > good.
>
>> When "efficient" and "tight" means as few keystrokes as possible, it
>> isn't good.
>
>Why not? You are associating 'few keystrokes' with 'unintelligible' and
>'brokenly using bad self-optimization techniques' which is not correct.
>
>> Efficient C code usually means that you take
>> responsabilities
>> that the optimizer should really do for you, and do that through
>> questionable backdoors in the language. Case switches jumping into
>> while loops is one example.
>
>'Questionable backdoors'? Some might disagree. BTW, last time I checked,
>the C standard didn't garuntee there is an optimizer around to babysit you.
>
>> > I disagree with at least the implications of your conclusion.  Writing,
>> > on purpose, impenetrable, bad, inefficient, and ugly code is one of the
>> > best ways to comprehend good code better.  It's all well and good to
say
>> > "look, here's a good way to do this".  It's just as good to say "and
look,
>> > here's a bad way".
>
>> > You can't understand fully what makes good code good without
understanding
>> > just as fully what makes bad code bad.
>
>> When you show the bad way to those kids, they think it is WAAAY cool!
>> They will use any stinking obscure construction just because "it is
>> valid C code".
>
>Again this insulting analogy.
>
>> Simple example from real life:
>
>> if (call_this() || call_that());
>
>> Valid, yes. Better than
>
>> if (!call_this()) call_that();
>
>> or more clear forms in other languages?
>> Some people actually think so.
>
>I find myself using a construct like this a lot recently (snipped directly
>from code I'm working on right now):
>
>if(!to && !(to = malloc(sizeof *to)))) return(NULL);
>
>For 'verbose' code this would be written:
>
>if(!to) {
> if(!to = malloc(sizeof *to)) {
> return(NULL);
> }
>}
>
>I find this unacceptable. The first form is understood well enough anyway:
>If 'to' is not valid and an attempt to make 'to' valid fails, return an
error.
>
>The
>
>if(foo() || bar())
>
>construct may seem obfuscated and weird to you, it is the way the logic of
>some people's minds work. To insult these people by comparing them to
>fickle adolescents is simply out of line.
>
>--
>[-
wind                                   -]
>[-   email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com
work)  -]
>[-          "You're just jealous because the voices talk
          -]
>[-                   Have a good day, and enjoy your
   -]
>[-          (on a crusade of grumpiness where grumpiness is
     -]

Re: Programming language vote - results

[firewind]

Andy Knight <KnighA@tetraworld.com> wrote:
> Your credibility is brought in to question when you present code that has
> been "snipped directly from code..." that can not possibly compile.

And I suppose you have never in your life made a typo?

> Then you
> expand this codswallop into its supposed "verbose" form into something which
> is equally nonsensical.

> I'm off to adjust my filters.

I'm deeply hurt.

-- 
[-                               firewind                                   -]
[-   email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work)  -]
[-          "You're just jealous because the voices talk to -me-."          -]
[-                   Have a good day, and enjoy your C.                     -]
[-          (on a crusade of grumpiness where grumpiness is due)            -]

Re: Coding for Obscurity

[Alan E & Carmel J Brain]

firewind wrote:

> I find myself using a construct like this a lot recently (snipped directly
> from code I'm working on right now):
> 
> if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> 
> For 'verbose' code this would be written:
> 
> if(!to) {
>         if(!to = malloc(sizeof *to)) {
>                 return(NULL);
>         }
> }
> 
> I find this unacceptable. The first form is understood well enough anyway

 
> The
> 
> if(foo() || bar())
> 
> construct may seem obfuscated and weird to you, it is the way the logic of
> some people's minds work.

No further evidence, I rest my case. 

Would anyone in comp.lang.c like to comment? 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Coding for Obscurity

[firewind]

Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote:
> firewind wrote:

> > I find myself using a construct like this a lot recently (snipped directly
> > from code I'm working on right now):
> > 
> > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> > 
> > For 'verbose' code this would be written:
> > 
> > if(!to) {
> >         if(!to = malloc(sizeof *to)) {
> >                 return(NULL);
> >         }
> > }
> > 
> > I find this unacceptable. The first form is understood well enough anyway

> > The
> > 
> > if(foo() || bar())
> > 
> > construct may seem obfuscated and weird to you, it is the way the logic of
> > some people's minds work.

> No further evidence, I rest my case. 

> Would anyone in comp.lang.c like to comment? 

From the new Subject: I assume you have drawn the conclusion that I code in
the above manner (the first 'weird' if(), I don't use the second, but the
point was that 'style imperialism' is stupid) to purposely obfuscate. Nothing
can be further from the truth. Obfuscated code can be written in absolutely
any language, by absolutely everyone. In a bad spot, a decidedly 'clean'
coder can churn out a potful of spaghetti code.

-- 
[-                               firewind                                   -]
[-   email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work)  -]
[-          "You're just jealous because the voices talk to -me-."          -]
[-                   Have a good day, and enjoy your C.                     -]
[-          (on a crusade of grumpiness where grumpiness is due)            -]

Re: Coding for Obscurity

[Jos A. Horsmeier]

firewind wrote:
| Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote:
| > firewind wrote:

| > > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
| > >
| > > For 'verbose' code this would be written:
| > >
| > > if(!to) {
| > >         if(!to = malloc(sizeof *to)) {
| > >                 return(NULL);
| > >         }
| > > }
| > >
| > > I find this unacceptable. The first form is understood well enough
anyway
| > > The if(foo() || bar()) construct may seem obfuscated and weird to
you, it 
| > > is the way the logic of some people's minds work.
 
| > No further evidence, I rest my case.
| > Would anyone in comp.lang.c like to comment?
 
| From the new Subject: I assume you have drawn the conclusion that I
code in
| the above manner (the first 'weird' if(), I don't use the second, but
the
| point was that 'style imperialism' is stupid) to purposely obfuscate.
Nothing
| can be further from the truth. Obfuscated code can be written in
absolutely
| any language, by absolutely everyone. In a bad spot, a decidedly
'clean'
| coder can churn out a potful of spaghetti code.

Absolutely true. I don't want to start a 'style war' but I do want to
comment;
I tend to accept any style of code that I can _pronounce_; for example,
your first
if statement above doesn't look weird or obfuscated to me at all; to me,
it reads: if I don't have a 'to' and if I can't get a 'to' I'm out of
here.

As a matter of fact I use (the negation of) this construct regularly:
if I have a 'to' or if I can get a 'to', do the job:

	if (to || (to= malloc(sizeof *to)))
		<do the job>
	else
		return NULL;

it saves me a couple of 'not's and it shows a bit more positive attitude
;-)

kind regards,

Jos aka jos@and.nl

Re: Coding for Obscurity

[Stephan Wilms]

Alan E & Carmel J Brain wrote:
> 
> firewind wrote:
> 
> > I find myself using a construct like this a lot recently (snipped directly
> > from code I'm working on right now):
> >
> > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> >
> > The
> > if(foo() || bar())
> >
> > construct may seem obfuscated and weird to you, it is the way the logic of
> > some people's minds work.
> 
> No further evidence, I rest my case.
> 
> Would anyone in comp.lang.c like to comment?

Yes, I'll volunteer a little comment: code like that has a lot of
disadvantages: it is obfuscated (it's only the author wh thinks that
the code is readable) and it's hard to debug and maintain. It sure
wouldn't pass through my code inspection.

To explain: readability of code is not targeted at the author of the
code or maybe his office pal, it is targeted at someone having to
read and understand a whole big package of source code, to make
some important modification or to find a bug a year after the software
has been written and archived. The author might not even be available
at this moment. Even the smallest effort helps a lot.

In detail: I would reqrite the first example like this:

    /* Sensible comment about what get's allocated. */
  if ( to == NULL )
  {
    to = malloc( sizeof *to);
    if ( to == NULL ) return NULL;
  }

Stephan
(initiator of the campaign against grumpiness in c.l.c)

Re: Coding for Obscurity

[Jos A. Horsmeier]

Stephan Wilms wrote:
> Alan E & Carmel J Brain wrote:
> > firewind wrote:

> > > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> > >
> > > The
> > > if(foo() || bar())
> > >
> > > construct may seem obfuscated and weird to you, it is the way the logic of
> > > some people's minds work.

> > No further evidence, I rest my case.
> > Would anyone in comp.lang.c like to comment?
 
> Yes, I'll volunteer a little comment: code like that has a lot of
> disadvantages: it is obfuscated (it's only the author wh thinks that
> the code is readable) and it's hard to debug and maintain. It sure
> wouldn't pass through my code inspection.
> 
> To explain: readability of code is not targeted at the author of the
> code or maybe his office pal, it is targeted at someone having to
> read and understand a whole big package of source code, to make
> some important modification or to find a bug a year after the software
> has been written and archived. The author might not even be available
> at this moment. Even the smallest effort helps a lot.
> 
> In detail: I would reqrite the first example like this:
> 
>     /* Sensible comment about what get's allocated. */
>   if ( to == NULL )
>   {
>     to = malloc( sizeof *to);
>     if ( to == NULL ) return NULL;
>   }

Although we're talking about style and taste here (which can't be
discussed IMHO), I jumped into (another thread of) this discussion
because I recognized the construct above. Something like 15 years
ago our team went OO (and gaga too, but that's an entirely different
story ;-) C++ was hardly concipiated yet, so we turned to SmallTalk
and borrowed (read 'stole') some features from that language. We were
still dealing with plain old C though ... 

We wanted to handle 'automatic or global' objects and 'dynamic objects'
(just
to borrow some terminology from C++) in C. Amongst other stuff we came 
up with the following macros:

#define NEW(x) ((x) && !((x)->dyn= NULL) || ((x)= malloc(sizeof *(x)))
&& ((x)->dyn= (x)))
#define OLD(x) free((x)->dyn)

(I'm typing this from the top of my head, so be gentle with me here)

An object was represented by a simple struct. One member of such a
struct 'dyn'
contained the address of the struct itself if it was allocated
dynamically, 
otherwise it would contain a NULL pointer. Given those macros we were
able 
to do things like:

	void foo() {

		obj_t	x;
		obj_t*	y= NULL;

		if (NEW(&x)) 
			/* init x; */

		if (NEW(y))
			/* init *y */

		/* do some useful stuff with x and y here */

		OLD(&x);
		OLD(&y);
	}

The NEW macro registered the fact that the memory of an object was
already there
if it were passed the address of an existing struct. The OLD macro would 
peek at the 'dyn' member and pass it to free (we were simply lucky that
free(NULL)
did what we wanted it to do in those days, but if you tell them
youngsters that,
they won't believe ya ;-)

I'm the one to blame for those macros. I just finished some boring
project using
RPG (I guess it was RPG2, but I don't recall exactly) and I did like
those tagged
statements, i.e.

	foo && bar

where 'bar' would only be executed if 'foo' were true (later RISC chips
even implemented
this nice little feature). Maybe my braincell was damaged by my former
RPG experience,
but I found (and still find) the logic behind this all quite readable.
So you're
at least partly right: 'it's the author who thinks that this is
readable'. But the
fun part of this all is, that our team found this construct (and the
accompanying
macros) quite readable too, I wasn't the only lunatic in town ...

I agree that such a construct shouldn't be written down just to inflate
your
ego, but a carefully constructed (or should I say 'crafted') expression
like
this can be highly readable for those who are at least familiar with it. 

But this notion leads to the question -- how qualified should software
maintaining
people be? If they're overqualified (and this very suitable for the
job), they
don't want this type of job (and vice versa is true too).

kind regards,

Jos aka jos@and.nl

Re: Coding for Obscurity

[Alex Krol]

Stephan Wilms wrote:
> 
> Alan E & Carmel J Brain wrote:
> >
> > firewind wrote:
> >
> > > I find myself using a construct like this a lot recently (snipped directly
> > > from code I'm working on right now):
> > >
> > > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> > >
> > > The
> > > if(foo() || bar())
> > >
> > > construct may seem obfuscated and weird to you, it is the way the logic of
> > > some people's minds work.
> >
> > No further evidence, I rest my case.
> >
> > Would anyone in comp.lang.c like to comment?
> 
> Yes, I'll volunteer a little comment: code like that has a lot of
> disadvantages: it is obfuscated (it's only the author wh thinks that
> the code is readable) and it's hard to debug and maintain. It sure
> wouldn't pass through my code inspection.
> 
> To explain: readability of code is not targeted at the author of the
> code or maybe his office pal, it is targeted at someone having to
> read and understand a whole big package of source code, to make
> some important modification or to find a bug a year after the software
> has been written and archived. The author might not even be available
> at this moment. Even the smallest effort helps a lot.
> 
> In detail: I would reqrite the first example like this:
> 
>     /* Sensible comment about what get's allocated. */
>   if ( to == NULL )
>   {
>     to = malloc( sizeof *to);
>     if ( to == NULL ) return NULL;
>   }

   Of course, style matters are extremely personal, but, IMHO,
there is nothing unreadable in the first example (except unmatched
parenthesis :-)). I agree that readability of code is not targeted
at the author himself, but must it be targeted at a newbie unfamiliar
with C idiomas? Comments, though are advisable in any case.

	Regards,
		Alex Krol

Re: Coding for Obscurity

[Jim Johnson]

>  I agree that readability of code is not targeted
> at the author himself, but must it be targeted at a newbie unfamiliar
> with C idiomas?

Yes, it must; because in most situations, that is who the maintenance
programmers are.

"unfamiliar with C idioms" could be any of us. There are so many ways to
write C code, there is no way to predict which ones your audience will have
used. (Personally, I never use ?: conditionals; I always have to think it
through when I see them.)

Jim Johnson


Alex Krol <Alex_Krol@scitex.com> wrote in article
<34788101.7367@scitex.com>...
> Stephan Wilms wrote:
> > 
> > Alan E & Carmel J Brain wrote:
> > >
> > > firewind wrote:
> > >
> > > > I find myself using a construct like this a lot recently (snipped
directly
> > > > from code I'm working on right now):
> > > >
> > > > if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> > > >
> > > > The
> > > > if(foo() || bar())
> > > >
> > > > construct may seem obfuscated and weird to you, it is the way the
logic of
> > > > some people's minds work.
> > >
> > > No further evidence, I rest my case.
> > >
> > > Would anyone in comp.lang.c like to comment?
> > 
> > Yes, I'll volunteer a little comment: code like that has a lot of
> > disadvantages: it is obfuscated (it's only the author wh thinks that
> > the code is readable) and it's hard to debug and maintain. It sure
> > wouldn't pass through my code inspection.
> > 
> > To explain: readability of code is not targeted at the author of the
> > code or maybe his office pal, it is targeted at someone having to
> > read and understand a whole big package of source code, to make
> > some important modification or to find a bug a year after the software
> > has been written and archived. The author might not even be available
> > at this moment. Even the smallest effort helps a lot.
> > 
> > In detail: I would reqrite the first example like this:
> > 
> >     /* Sensible comment about what get's allocated. */
> >   if ( to == NULL )
> >   {
> >     to = malloc( sizeof *to);
> >     if ( to == NULL ) return NULL;
> >   }
> 
>    Of course, style matters are extremely personal, but, IMHO,
> there is nothing unreadable in the first example (except unmatched
> parenthesis :-)). I agree that readability of code is not targeted
> at the author himself, but must it be targeted at a newbie unfamiliar
> with C idiomas? Comments, though are advisable in any case.
> 
> 	Regards,
> 		Alex Krol
> 

Re: Coding for Obscurity

[Mark Wilden]

Jim Johnson wrote:
> 
> >  I agree that readability of code is not targeted
> > at the author himself, but must it be targeted at a newbie unfamiliar
> > with C idiomas?
> 
> Yes, it must; because in most situations, that is who the maintenance
> programmers are.

If the only code newbies read is code directed toward newbies, then
they'll remain newbies. A good programmer is someone who can read an
unfamiliar idiom (if it is truly useful and not merely obscure), learn
it and apply it.

> "unfamiliar with C idioms" could be any of us. There are so many ways to
> write C code, there is no way to predict which ones your audience will have
> used. (Personally, I never use ?: conditionals; I always have to think it
> through when I see them.)

But ?: is not an idiom; it's a part of the language definition. I'll
give you the benefit of the doubt and assume that when you think it
through, you understand it.

Re: Coding for Obscurity

[Robert S. White]

In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says...

>But ?: is not an idiom; it's a part of the language definition. I'll
>give you the benefit of the doubt and assume that when you think it
>through, you understand it.

  I _understood_ it in 1983.   But right now in thinking about 
it, I'll say that it would have been better from a code maintenance
point of view, that K&R had never thought of it as a convenient
typing shortcut.  IMHO YMMV 

_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter

Re: Coding for Obscurity

[Leon Jones]

Robert S. White <nospam@somewhere.ia.us> wrote in article
<65fr08$vtu$1@flood.weeg.uiowa.edu>...
> In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says...
> 
> >But ?: is not an idiom; it's a part of the language definition. I'll
> >give you the benefit of the doubt and assume that when you think it
> >through, you understand it.
> 
>   I _understood_ it in 1983.   But right now in thinking about 
> it, I'll say that it would have been better from a code maintenance
> point of view, that K&R had never thought of it as a convenient
> typing shortcut.  IMHO YMMV 

Couldn't agree more.  Ternary operators are horrendous and I avoid them at
all costs.  I've been programming for years and I still have to study them
closely before I understand exactly what they do.  It is just not as
natural a representation as if/else statements.  Also it doesn't allow for
indentation which is surely good programming technique in anyone's book??

Leon.

<snip sig>

Re: Coding for Obscurity

[Lawrence Kirby]

In article <01bcfa5d$7aab9920$LocalHost@default>
           leon.jones@lineone.net "Leon Jones" writes:

>Robert S. White <nospam@somewhere.ia.us> wrote in article
><65fr08$vtu$1@flood.weeg.uiowa.edu>...
>> In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says...
>> 
>> >But ?: is not an idiom; it's a part of the language definition. I'll
>> >give you the benefit of the doubt and assume that when you think it
>> >through, you understand it.
>> 
>>   I _understood_ it in 1983.   But right now in thinking about 
>> it, I'll say that it would have been better from a code maintenance
>> point of view, that K&R had never thought of it as a convenient
>> typing shortcut.  IMHO YMMV 

I suppose it depends on what you are used to. I suspect that people with
a functional language background would be right at home with it.

>Couldn't agree more.  Ternary operators are horrendous and I avoid them at
>all costs.  I've been programming for years and I still have to study them
>closely before I understand exactly what they do.  It is just not as
>natural a representation as if/else statements.  Also it doesn't allow for
>indentation which is surely good programming technique in anyone's book??

This is perhaps the problem: people don't format it very well. However your
statement that it doesn't allow for indentation is patently false. There
are various ways to indent it for long expressions. My preferred method is
for example:

      (control expression 1)
          ? (control expression 2)
              ? value expression 1
              : value expression 2
          : value expression 3

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Coding for Obscurity

[Ron Natalie]

Leon Jones wrote:
>  Ternary operators are horrendous and I avoid them at
> all costs. 

I wouldn't say that.  They are very useful.

It's only when people don't use the result of the
ternary expression, but rather rely on side effects
that's egregious.

Those are the cases that can have if/else directly
subsituted for them with no change in meaning.

Re: Coding for Obscurity

[Joerg Rodemann]

Ron Natalie (ron@sensor.com) wrote:
> Leon Jones wrote:
> >  Ternary operators are horrendous and I avoid them at
> > all costs. 

> I wouldn't say that.  They are very useful.

> It's only when people don't use the result of the
> ternary expression, but rather rely on side effects
> that's egregious.

Well, maybe that is the point that disturbs me with the ? : expressions.
One of the examples given in a former post made quite sense although I
do not like these operators. Indeed, if used in a functional manner (no
side effects) they seem to be more readable than alternativ constructions
like "if ... else ...". Probably I saw to many occurences of these were 
everything was hidden behind side effects. Same is to be said about 
stand alone expressions like:
   a() || b();
Perhaps I developped kind of a distrust towards programmers and their
concerns about readability. *sigh* 

Regards

Joerg


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

Re: Coding for Obscurity

[Miguel Carrasquer Vidal]

On 26 Nov 1997 00:37:28 GMT, nospam@somewhere.ia.us (Robert S. White)
wrote:

>In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says...
>
>>But ?: is not an idiom; it's a part of the language definition. I'll
>>give you the benefit of the doubt and assume that when you think it
>>through, you understand it.
>
>  I _understood_ it in 1983.   But right now in thinking about 
>it, I'll say that it would have been better from a code maintenance
>point of view, that K&R had never thought of it as a convenient
>typing shortcut.  IMHO YMMV 

The idea of a conditinal expression was already in Algol, e.g. 

x := if i>0 then y else z;

Algol 68 extended this to case-expressions like b[case i in 6, 3 out 4
esac] := false, and allowed if then else and fi to be abbreviated to
(, |, |, ), giving either:

x := if i>0 then y else z fi;

or

x := ( i>0 | y | z );

In CPL and later BCPL the conditional expression was also abbreviated,
as in:

x := i>0 -> y , z;

This was changed to 

x = i>0 ? y : z;

in B, so the K in K&R you mention above is actually Ken Thompson.
This syntax was maintained unaltered in C.


==
Miguel Carrasquer Vidal                     ~ ~
Amsterdam                   _____________  ~ ~
mcv@wxs.nl                 |_____________|||

========================== Ce .sig n'est pas une .cig

Re: Coding for Obscurity

[ISONE]

BLISS is similar.  All valid blocks of code have value or evaluate to a
value.
x = if .y eq .z then .a else .b; is a valid statement... x now containing
the value pointed to by b.  (Assuming I remember the nuances of my BLISS
syntax :)

m.s.jessop


>
>Algol 68 extended this to case-expressions like b[case i in 6, 3 out 4
>esac] := false, and allowed if then else and fi to be abbreviated to
>(, |, |, ), giving either:
>
>x := if i>0 then y else z fi;
>
>or
>
>x := ( i>0 | y | z );
>
>In CPL and later BCPL the conditional expression was also abbreviated,
>as in:
>
>x := i>0 -> y , z;
>
>This was changed to
>
>x = i>0 ? y : z;
>
>in B, so the K in K&R you mention above is actually Ken Thompson.
>This syntax was maintained unaltered in C.
>
>
>==
>Miguel Carrasquer Vidal                     ~ ~
>Amsterdam                   _____________  ~ ~
>mcv@wxs.nl                 |_____________|||
>
>========================== Ce .sig n'est pas une .cig

Re: Coding for Obscurity

[ISONE]

BLISS is similar.  All valid blocks of code have value or evaluate to a
value.
x = if .y eq .z then .a else .b; is a valid statement... x now containing
the value pointed to by b.  (Assuming I remember the nuances of my BLISS
syntax :)

m.s.jessop


>
>Algol 68 extended this to case-expressions like b[case i in 6, 3 out 4
>esac] := false, and allowed if then else and fi to be abbreviated to
>(, |, |, ), giving either:
>
>x := if i>0 then y else z fi;
>
>or
>
>x := ( i>0 | y | z );
>
>In CPL and later BCPL the conditional expression was also abbreviated,
>as in:
>
>x := i>0 -> y , z;
>
>This was changed to
>
>x = i>0 ? y : z;
>
>in B, so the K in K&R you mention above is actually Ken Thompson.
>This syntax was maintained unaltered in C.
>
>
>==
>Miguel Carrasquer Vidal                     ~ ~
>Amsterdam                   _____________  ~ ~
>mcv@wxs.nl                 |_____________|||
>
>========================== Ce .sig n'est pas une .cig

Re: Coding for Obscurity

[Mark Wilden]

Robert S. White wrote:
> 
> In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says...
> 
> >But ?: is not an idiom; it's a part of the language definition. I'll
> >give you the benefit of the doubt and assume that when you think it
> >through, you understand it.
> 
>   I _understood_ it in 1983.

I was talking about understanding a line of code and you're talking
about understanding a syntax element, but never mind.

> But right now in thinking about
> it, I'll say that it would have been better from a code maintenance
> point of view, that K&R had never thought of it as a convenient
> typing shortcut.  IMHO YMMV

I don't look at it like that at all. I certainly would never use it
instead of an if-statement just to save some typing (in fact, I don't
use it very often at all). C/C++ is naturally a terse language, however,
and one of the advantages of terseness, used appropriately, is the
ability to let the reader "chunk" in order to understand the code
faster. Terseness also can have maintenance benefits, in reducing
duplication.

For example, here's a case where I used the conditional operator
recently:

  EnableMenuItem(hGameMenu, ID_NEWLIFE,
    (CanBeReborn() ? MF_ENABLED : MF_GRAYED) | MF_BYCOMMAND);

I think this is easier to read and maintain than either

  // redundant--bad for maintenance
  if (CanBeReborn())
     EnableMenuItem(hGameMenu, ID_NEWLIFE, MF_ENABLED | MF_BYCOMMAND);
  else
     EnableMenuItem(hGameMenu, ID_NEWLIFE, MF_GRAYED | MF_BYCOMMAND);

or

 // wordy--takes longer to read and understand
 // reader may wonder if flag is used further down
 unsigned flag;
 if (CanBeReborn())
    flag = MF_ENABLED;
 else
    flag = MF_GRAYED;
 EnableMenuItem(hGameMenu, ID_NEWLIFE, flag | MF_BYCOMMAND);

Re: Coding for Obscurity

[Richard A. O'Keefe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]


nospam@somewhere.ia.us (Robert S. White) writes:
>  I _understood_ it in 1983.   But right now in thinking about 
>it, I'll say that it would have been better from a code maintenance
>point of view, that K&R had never thought of it as a convenient
>typing shortcut.  IMHO YMMV 

They didn't think of it, and it isn't a typing shortcut.
Conditional expressions were, and remain, a common feature of many
programming languages, going back to 1959.  Perhaps K&R chose to
retain them, given their conscious contrast with Multics, because
they were aware of the horrible kluge PL/I (and Pascal) programmers
used to emulate them:
	ord(x >= 0)*x + ord(not(x >= 0))*(-x)
is a peculiarly horrible way to have to write
	if x >= 0 then x else -x fi.

Don't you find something rather repulsive about having to use side effects
just to select one of two values?

Much the same argument was used to justify the absence of 'and then'
and 'or else' from the original Pascal:  they are "only convenient typing
shortcuts for if statements".  But they aren't, and the current Pascal
standard includes them (spelled and_then and or_else, and still with the
wrong precedence).

-- 
John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok

Re: Coding for Obscurity

[Al Christians]

Somebody wrote:

>> From the new Subject: I assume you have drawn the conclusion that I >> code in the above manner (the first 'weird' if(), I don't use the 
>> second, but the point was that 'style imperialism' is stupid) to 
>> purposely obfuscate. Nothing can be further from the truth. >> >> Obfuscated code can be written in absolutely any language, by >> absolutely everyone. In a bad spot, a decidedly 'clean'
>> coder can churn out a potful of spaghetti code.

But if you are getting into C++, there's a clue on page 12 in the
_Notes_to_the_Reader_ of Stroustrup's _The_C++_Programming_Language_
(3rd edition).  "Million line C++ programs are not uncommon".  This form
of expression warns the reader right up front that non-avoidance of
non-unconvoluted expression by non-eschewers of C++ is not dissimilarly
not uncommon.   Or as Marx said, "I can't say that I don't disagree with
you."

Al

Re: Coding for Obscurity

[Richard A. O'Keefe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]


Stephan Wilms <Stephan.Wilms@CWA.de> writes:
>In detail: I would reqrite the first example like this:

>    /* Sensible comment about what get's allocated. */
>  if ( to == NULL )
>  {
>    to = malloc( sizeof *to);
>    if ( to == NULL ) return NULL;
>  }

I would be rather unhappy at _any_ of these being common in my C code.
One thing I would very much like to have in C is a '* __nonnull__' form.
One thing I love about LC-Lint is that it distinguishes between
	sometype *p;		/* p should not be null */
	sometype */*@null@*/ q;	/* q may or may not be null */

The reason that I dislike the C fragment above is that when you are forced
to do manual memory management, you have to be absolutely clear about who
`owns' a dynamically allocated object and who doesn't.  This fragment
muddies that up.  If you could specify in the interface that to _couldn't_
be NULL on entry, then you wouldn't have to patch around the problem at
run time.

By the way, I regard this as a defect in Ada as well.  Ada was supposed to
allow for garbage collection, but with the exception of a couple of recent
Ada->JVM compilers, this hasn't happened.  Since you _do_ have to do manual
memory management in practice, it is a pity that the language doesn't provide
more compile-time help for getting it right.  Perhaps Ada 2007 could borrow a
few ideas from LC-Lint.
-- 
John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok

Re: Coding for Obscurity

[Matt]

--snip--
> By the way, I regard this as a defect in Ada as well.  Ada was supposed to
> allow for garbage collection, but with the exception of a couple of recent
> Ada->JVM compilers, this hasn't happened.  Since you _do_ have to do manual
> memory management in practice, it is a pity that the language doesn't provide
> more compile-time help for getting it right.  Perhaps Ada 2007 could borrow a
> few ideas from LC-Lint.

Ada does provide for garbage collection.  It just doesn't mandate it. 
Requiring it would make the language almost useless in real-time systems
and we would see many
"We're-just-like-Ada-but-without-the-garbage-collection" languages pop
up.  

I do like the idea of being able to specifying that a pointer can never
be null.  It sould be handy in many situations.

Matt

Re: Coding for Obscurity

[Ed Falis]

By the way, ObjectAda for Windows and UNIX does work with the Great Circle
garbage collector from Geodesic Systems.

- Ed Falis
Aonix

Matt wrote in message <3479310A.2082@itsnet.com>...
>--snip--
>> By the way, I regard this as a defect in Ada as well.  Ada was supposed
to
>> allow for garbage collection, but with the exception of a couple of
recent
>> Ada->JVM compilers, this hasn't happened.  Since you _do_ have to do
manual
>> memory management in practice, it is a pity that the language doesn't
provide
>> more compile-time help for getting it right.  Perhaps Ada 2007 could
borrow a
>> few ideas from LC-Lint.
>
>Ada does provide for garbage collection.  It just doesn't mandate it.
>Requiring it would make the language almost useless in real-time systems
>and we would see many
>"We're-just-like-Ada-but-without-the-garbage-collection" languages pop
>up.
>
>I do like the idea of being able to specifying that a pointer can never
>be null.  It sould be handy in many situations.
>
>Matt

Re: Coding for Obscurity

[Samuel T. Harris]

Richard A. O'Keefe wrote:
> =

> Stephan Wilms <Stephan.Wilms@CWA.de> writes:
> >In detail: I would reqrite the first example like this:
> =

> >    /* Sensible comment about what get's allocated. */
> >  if ( to =3D=3D NULL )
> >  {
> >    to =3D malloc( sizeof *to);
> >    if ( to =3D=3D NULL ) return NULL;
> >  }
> =

> I would be rather unhappy at _any_ of these being common in my C code.
> One thing I would very much like to have in C is a '* __nonnull__' form=
=2E
> One thing I love about LC-Lint is that it distinguishes between
>         sometype *p;            /* p should not be null */
>         sometype */*@null@*/ q; /* q may or may not be null */
> =

> The reason that I dislike the C fragment above is that when you are for=
ced
> to do manual memory management, you have to be absolutely clear about w=
ho
> `owns' a dynamically allocated object and who doesn't.  This fragment
> muddies that up.  If you could specify in the interface that to _couldn=
't_
> be NULL on entry, then you wouldn't have to patch around the problem at=

> run time.
> =

> By the way, I regard this as a defect in Ada as well.  Ada was supposed=
 to
> allow for garbage collection, but with the exception of a couple of rec=
ent
> Ada->JVM compilers, this hasn't happened.  Since you _do_ have to do ma=
nual
> memory management in practice, it is a pity that the language doesn't p=
rovide
> more compile-time help for getting it right.  Perhaps Ada 2007 could bo=
rrow a
> few ideas from LC-Lint.

Yeah, I agree that Ada 83 was very weak in "helping" with memory
management.
And Ada 95 is somewhat better in this regards (i.e. providing access
parameters eliminates many needs for access types). However, Ada 95 does
provide the storage_pool scheme where I can build whatever memory
management system I need to include whatever elaborate facilities I
desire. I'm anxious to see what storage_pools become available as
reuse components. Indeed, I've used simple storage_pools simply
to guarantee certain pointers to heterogenous types are stored
in consecutive memory. I can then send that memory block across
an interface and eliminate all the normal code associate with
staging the values into a message record for sending and extracting
the values from a received message record.

> --
> John =C6neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
> Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok

-- =

Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Coding for Obscurity

[Jon S Anthony]

"Samuel T. Harris" <s_harris@hso.link.com> writes:

> reuse components. Indeed, I've used simple storage_pools simply to
> guarantee certain pointers to heterogenous types are stored in
> consecutive memory. I can then send that memory block across an
> interface and eliminate all the normal code associate with staging
> the values into a message record for sending and extracting the
> values from a received message record.

Now that is quite nice and clever.


-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Coding for Obscurity

[Samuel T. Harris]

Jon S Anthony wrote:
> 
> "Samuel T. Harris" <s_harris@hso.link.com> writes:
> 
> > reuse components. Indeed, I've used simple storage_pools simply to
> > guarantee certain pointers to heterogenous types are stored in
> > consecutive memory. I can then send that memory block across an
> > interface and eliminate all the normal code associate with staging
> > the values into a message record for sending and extracting the
> > values from a received message record.
> 
> Now that is quite nice and clever.
> 
> --
> Jon Anthony
> Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
> "Nightmares - Ha!  The way my life's been going lately,
>  Who'd notice?"  -- Londo Mollari


I'm glad you think so. Not being a expert at memory management
techniques, this storage_pool is rather simple, does not allow
deallocation, and simply allocates requested blocks in
consequetive memory locations. Not very "full-featured"
but for that simple job I described, it works nicely.
I just can't use it for much anything else :)

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

Re: Programming language vote - results

[Terry Richards]

[big snip]

> > Simple example from real life:
> 
> > if (call_this() || call_that());
> 
> > Valid, yes. Better than
> 
> > if (!call_this()) call_that();
> 
> > or more clear forms in other languages?
> > Some people actually think so.
> 
> I find myself using a construct like this a lot recently (snipped directly
> from code I'm working on right now):
> 
> if(!to && !(to = malloc(sizeof *to)))) return(NULL);
> 
> For 'verbose' code this would be written:
> 
> if(!to) {
>         if(!to = malloc(sizeof *to)) {
>                 return(NULL);
>         }
> }
> 
> I find this unacceptable. The first form is understood well enough anyway:
> If 'to' is not valid and an attempt to make 'to' valid fails, return an error.
> 
> The
> 
> if(foo() || bar())
> 
> construct may seem obfuscated and weird to you, it is the way the logic of
> some people's minds work. 

[more snippage]

Guys,

I'm not sure who wrote what here so I've removed all the names.

All of these constructs are flat out wrong. As far as I can remember,
neither C or C++ guarantees that the clauses in a condition will be
evaluated in the order you wrote them. IOW,

if (call_this() || call_that());

could compile as if it where written:

if (call_that() || call_this());

which could have different results.

The malloc example *probably* has enough parentheses to force it to work
in the right order but the fact is that the code is obscure at best and
wrong at worst. It is also no more efficient when compiled than the
equivalent construct:

if (!call_this())
  call_that();

Which, incidentally, is one *less* key stroke if you use a tab for the
indent. Count 'em - I added four and deleted 5.

I would not accept this code at a walkthrough.

-- 
Terry Richards
Terry Richards Software

Re: Programming language vote - results

[Andy Knight]

Terry Richards wrote in message <347440AD.35DF@idt.net>...

[ snip ]

>All of these constructs are flat out wrong. As far as I can remember,
>neither C or C++ guarantees that the clauses in a condition will be
>evaluated in the order you wrote them. IOW,
>
>if (call_this() || call_that());
>
>could compile as if it where written:
>
>if (call_that() || call_this());
>
>which could have different results.
>

No it won't. The left-to-right evaluation is well defined.

[ snip ]

Re: Programming language vote - results

[Alex Krol]

Terry Richards wrote:
> Guys,
> As far as I can remember,
> neither C or C++ guarantees that the clauses in a condition will be
> evaluated in the order you wrote them. IOW,
> 
> if (call_this() || call_that());
> 
> could compile as if it where written:
> 
> if (call_that() || call_this());
> 
> which could have different results.

  No, you are wrong. The Standard guarantees that in
 (expr1 || expr2)
expr2 would be evaluated if and only if expr1 is evaluated to 0;
in (expr1 && expr2)
expr2 would be evaluated if and onty if expr1 is evaluated to non-zero.
 To guarantee this, order of evaluation must be guaranteed also.
This is true both for C and C++.

	Regards,
		Alex Krol

Re: Programming language vote - results

[William Tanksley]

In article <347440AD.35DF@idt.net> trs@idt.net writes:
>[big snip]

>> > Simple example from real life:

>> > if (call_this() || call_that());

>> I find myself using a construct like this a lot recently (snipped directly
>> from code I'm working on right now):

>> if(!to && !(to = malloc(sizeof *to)))) return(NULL);

>All of these constructs are flat out wrong. As far as I can remember,
>neither C or C++ guarantees that the clauses in a condition will be
>evaluated in the order you wrote them. IOW,

According to the ANSI standard and K&R, as well as universal prior
practice, the boolean logical operators are short-circuiting.  This means
that they MUST exectute in order.  In fact, this is required explicitly by
ANSI and K&R.

>The malloc example *probably* has enough parentheses to force it to work
>in the right order but the fact is that the code is obscure at best and
>wrong at worst. It is also no more efficient when compiled than the
>equivalent construct:

It'll work, so long as the library returns zeroes for nulls.  I personally
find it more readable than its stretched alternative, although for most
other purposes I'd use the stretch.

>if (!call_this())
>  call_that();

>Which, incidentally, is one *less* key stroke if you use a tab for the
>indent. Count 'em - I added four and deleted 5.

But then, I use an editor which is made to cut down on such keystrokes.
But who's counting.

>I would not accept this code at a walkthrough.

I'd have to see the surrounding design -- the malloc example looks
dismaying, but there might be a reason which I can't imagine to not know
and not care whether a pointer was initialized.

The if( this() || that() ); example I would toss right out -- but then
I've NEVER seen that written anywhere.  this() || that(); works exactly as
well, and doesn't tempt the code maintainer to assume that the semicolon
was a typo.

It's worth noting that using the short circuiting of 'or' is very common
in many languages.  Note some of the nicer aspects of Perl: "open file or
die".  Now THAT'S an idiom -- and me a good Python man :).

>Terry Richards

-Billy

Re: Programming language vote - results

[Ron Natalie]

William Tanksley wrote:
> 
> 
> According to the ANSI standard and K&R, as well as universal prior
> practice, the boolean logical operators are short-circuiting.  This
> means that they MUST exectute in order.  In fact, this is required
> explicitly by ANSI and K&R.

The spec calls these sequence points.  Furthermore, && and ||
are required not to execute the right operand if the left
side evaluates to false (in the case of and) or true (in the
case of or).

> The malloc example *probably* has enough parentheses to force it to
> work in the right order but the fact is that the code is obscure at
> best and wrong at worst. It is also no more efficient when compiled
> than the equivalent construct:

Assuming to is a pointer, there's nothing wrong with the statement
as written by the original poster.  PARENS do NOT AFFECT ORDERING
in C/C++, they only affect the binding of the operations.

> It'll work, so long as the library returns zeroes for nulls.

It works no matter what.  The constant zero is the null pointer
constant.  If malloc returns a null pointer regardless of it's
machine representation, testing it for equality against an
integer zero (or the boolean not) will work.

Re: Programming language vote - results

[William Tanksley]

In article <347C420A.2B18@sensor.com> Ron Natalie <ron@sensor.com> writes:
>William Tanksley wrote:

>> The malloc example *probably* has enough parentheses to force it to
>> work in the right order but the fact is that the code is obscure at
>> best and wrong at worst. It is also no more efficient when compiled
>> than the equivalent construct:

I did NOT write this.  I replied to this.  I disagree utterly with it.

>> It'll work, so long as the library returns zeroes for nulls.

>It works no matter what.  The constant zero is the null pointer
>constant.  If malloc returns a null pointer regardless of it's
>machine representation, testing it for equality against an
>integer zero (or the boolean not) will work.

I did write this.

NULL is defined as "(void*)0".  I've never seen a compiler which failed to
have (int)NULL be equal to 0 as well, but seeing one would not shock me --
according to K&R 2 (I don't have ANS C available right now) ANS doesn't
explicitly require that.

The worst part of that code, as far as I'm concerned, isn't the use of
pointers as booleans; after all, I can't imagine why a vendor would EVER
make non-zero NULL returns, especially since it would have to do a LOT of
work to make them meet the other requirements.  The bad part is that it
assumes that a pointer in an unknown state will be either NULL or
allocated.  Ick.  However, it could be that all the other code in the
application is a model of clear and precise code, so those are obviously
the only two possible states of the pointer at that point.  If so, that's
acceptable code.

-Billy

Re: Programming language vote - results

[Lawrence Kirby]

In article <65ih8m$pqt$1@news1.ucsd.edu>
           wtanksle@sdcc10.ucsd.edu "William Tanksley" writes:

...

>NULL is defined as "(void*)0".

It could also be written as #define NULL 0 in C, and it must be written like
that in C++.

> I've never seen a compiler which failed to
>have (int)NULL be equal to 0 as well, but seeing one would not shock me --
>according to K&R 2 (I don't have ANS C available right now) ANS doesn't
>explicitly require that.

That is correct - converting a pointer to an integer has
an implementation-defined result if it will fit in the integer, undefined
if not. There are no special cases for conversion in that direction.

>The worst part of that code, as far as I'm concerned, isn't the use of
>pointers as booleans; after all, I can't imagine why a vendor would EVER
>make non-zero NULL returns, especially since it would have to do a LOT of
>work to make them meet the other requirements.

Actually that's not true. All the implementor has to do is that ensure that
whenever a null pointer constant is converted to a pointer type, the
result has the correct representation for a null pointer of that type.
For comparison against zero you can simply take the view that the zero
is converted to the appropriate pointer type so the comparison simply
works.

> The bad part is that it
>assumes that a pointer in an unknown state will be either NULL or
>allocated.  Ick.  However, it could be that all the other code in the
>application is a model of clear and precise code, so those are obviously
>the only two possible states of the pointer at that point.  If so, that's
>acceptable code.

A pointer value can be one of the following in C:

1. null

2. a pointer to a valid object (or function for a function pointer)

3. a pointer to one past the end of a valid object

4. Indeterminate.

In the last case it is not valid to even look at the value in the code.
Indeterminate pointers are, for example:

1. the values of uninitialised automatic variables

2. a pointer to an automatic variable which has since been destroyed
   because the function defining it returned or was longjmp'd out of

3. a pointer to dynamic memory that has been freed

4. a pointer to a FILE that has been closed.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Programming language vote - results

[Kaz Kylheku]

In article <65keij$mkd$1@nerd.apk.net>,
Jim Showalter <ald103@aldhfn.org> wrote:
>Lawrence Kirby (fred@genesis.demon.co.uk) wrote:
>: In the last case it is not valid to even look at the value in the code.
>                         ^^^^^^^^^^^^^^^^^^^^^^
>  Excuse my ignorance, but I've noticed several references to the
>above here lately and - although I don't think I lack imagination
>- I must admit I haven't a clue as to what ill fortune may befall
>a program that peeks at this ominous <indeterminate pointer value>.
>
>Really, I simply <must> know! :-)

One day you may study computer architecture and find out that in some
architectures, loading an invalid pointer into an address register 
will cause an exception.

Incidentally, you need look no further than you 80x86 based PC to find such an
architecture. In protected mode, if you load an illegal selector into a segment
register, guess what happens.

Any use of a pointer value may cause such an exception in the hardware.
By imposing no requirements on what should happen, the standard 
makes it easier to implement C on such architectures. Essentially, it says
``Implementor, in the true spirit of C, you may simply translate the use of
such an indeterminate value as usual and let all hell break loose''. :)))

Of course, this sort of permissiveness means that the programmer has to know
what he or she is doing, and must exercise care in order to create correct
programs.  Not having the patience or desire to learn the abstract language
definition, most immature programmers opt out by relying instead their
knowledge of how some particular hardware works---which is, after all, simpler
and easier to understand than an abstract programming language description.
Since their particular hardware does not trap on the use of illegal pointers,
they wonder why the behavior is undefined when an indeterminate pointer value
is used. Since their particular hardware allows any type to be aligned on any
byte address, they wonder what alignment is and why they should every worry
about it when casting pointers.  Since on their particular hardware, pointers
are all represented in the same way, they wonder why all the fuss about using
(void **) as a generic pointer to pointer. Etc.

Re: Programming language vote - results

[Shmuel (Seymour J.) Metz]

William Tanksley wrote:
 
> NULL is defined as "(void*)0".  I've never seen a compiler which failed to
> have (int)NULL be equal to 0 as well, but seeing one would not shock me --
> according to K&R 2 (I don't have ANS C available right now) ANS doesn't
> explicitly require that.
> 
> The worst part of that code, as far as I'm concerned, isn't the use of
> pointers as booleans; after all, I can't imagine why a vendor would EVER
> make non-zero NULL returns, 

The obvious reason is to ensure that attempts to use a null pointer to
access data will be trapped, instead of producing spurious output or
storage overlays. Of course, if the low end of the address space is
guarantied to be invalid, then the value 0 will accomplish that, but
often 0 is a valid address.

	Shmuel (Seymour J.) Metz

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

The values in from and reply-to are for the benefit of spammers:
reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
user smetz. Do not reply to spamtrap@library.lspace.org

Re: Programming language vote - results

[FRS DES]

In article <347F1CAC.6602@gsg.eds.com>, "Shmuel (Seymour J.) Metz"
<nospam@gsg.eds.com> writes:

>William Tanksley wrote:
 
> NULL is defined as "(void*)0".  I've never seen a
>compiler which failed to
> have (int)NULL be equal to 0 as well, but seeing
>one would not shock me --
> according to K&R 2 (I don't have ANS C available
>right now) ANS doesn't
> explicitly require that.
> 
> The worst part of that
>code, as far as I'm concerned, isn't the use of
> pointers as booleans; after
>all, I can't imagine why a vendor would EVER
> make non-zero NULL returns,
>

The obvious reason is to ensure that attempts to use a null pointer
>to
access data will be trapped, instead of producing spurious output
>or
storage overlays. Of course, if the low end of the address space
>is
guarantied to be invalid, then the value 0 will accomplish that, but
often
>0 is a valid address.

	Shmuel (Seymour J.) Metz

-- 


>Shmuel (Seymour J.) Metz
                        Senior Software SE

This msg has nothing to do with APL.  Please trim comp.lang.apl from replies to
this msg, or start a new (non-crossposted) thread.






              -David E. Siegel
               Software Developer, LEX2000, Inc 
               (Formerly Financial Reporting Software, or FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Kevin Swan]

Ingemar Ragnemalm (ingemar@lysator.liu.se) wrote:

: There are plenty of people who use C since it is "cool", but just can't
: say what is so cool with it. It is cool because Mom can't understand it.
: No, they won't say that. You can identify that kind of people by the
: lack of comments in the code. They *want* it that way - and they are
: many!

Huh?  What are you talking about?  Do you *really* think that's it?  I use
C, and I don't mind telling you why.  It has nothing to do with how easy or
hard it is, it has to do with how fast it is.  For small to medium sized
programs, development time is fairly quick.  In terms of execution speed,
it simply doesn't get any faster than compiled C code.  It puts you just
above the assembly level, even permitting you to very easily work in
assembly, if you want to optimize a tight little loop.

I try extra hard to make my C code EASY to read.  I comment generously.  I
find the syntax simple and intuitive, except when you get into pointers to
pointers to pointers to .... and even then, its logical.

Why would people *want* a language that was difficult to work in?  That's
called "assembly."  If you think C is so difficult, why the they choose to
model Java's syntax after C?  After all, Java was intended to be one of the
easiest possible languages to learn, with a very shallow learning curve,
and has been quite successful at it.

I can't even venture a guess at why you made the comments you did.  It
almost sounds like you're mad, or resentful at C programmers, but I can't
imagine why.  Perhaps you're jealous of something, or got a low mark in
your C course, and are taking it out on the language.  At any rate, I
suggest you give it a second look.  Its easy to learn, very fast, and an
industry standard.

Kev.
C, Java, and Smalltalk programmer.

--
Kevin Swan                                                           BCSH
My university broke my email.  If you want to email me, please send it to
013639s@dragon.acadiau.ca                               Acadia University
                   How's my posting?  Call 1-800-DEV-NULL
** Fatal Error [1]: 'Win95' virus detected on /dev/hda1; Formatting ...

Re: Programming language vote - results

[Ingemar Ragnemalm]

Kevin Swan wrote:
> 
> Ingemar Ragnemalm (ingemar@lysator.liu.se) wrote:
> 
> : There are plenty of people who use C since it is "cool", but just can't
> : say what is so cool with it. It is cool because Mom can't understand it.
> : No, they won't say that. You can identify that kind of people by the
> : lack of comments in the code. They *want* it that way - and they are
> : many!
> 
> Huh?  What are you talking about?  Do you *really* think that's it?

I am talking about people I have met, and don't want to work with.
I wasn't talking about everybody. Re-read.

> I use
> C, and I don't mind telling you why.  It has nothing to do with how easy or
> hard it is, it has to do with how fast it is.  For small to medium sized
> programs, development time is fairly quick.  In terms of execution speed,
> it simply doesn't get any faster than compiled C code.  It puts you just
> above the assembly level, even permitting you to very easily work in
> assembly, if you want to optimize a tight little loop.

Execution speed is no better or worse than any other high-level language
(although it is queastionable if C is high-level), unless the code
generator and optimizer are poor. I've made comparisons. Have you?

I find C fairly comfortable for small hacks, like UNIX text filters.
Entire applications in C require you to enforce lots of rules that the
language doesn't have, or you get a mess.

> I try extra hard to make my C code EASY to read.  I comment generously.

If you comment generously, there's no reason to take offense when I
complain about people who don't.

I work with people who make clean, straight, readable C-code and
comment it well. I have no problems with them. We regularily interface
Pascal code and C code with great results.

> I find the syntax simple and intuitive, except when you get into pointers
> to pointers to pointers to .... and even then, its logical.

I don't. I find it clumsy, unnecessarily far from english, and many
constructs are little more than primitive macros. When reading other
people's code, I find Pascal-like languages comfortable since they
translate straight to english. With C-style languages, I have to do
one more step. It isn't *hard*, but it is harder than the straight-
forward english-like syntax.

If you think in C, OK, then I guess it is for you.

> Why would people *want* a language that was difficult to work in?  That's
> called "assembly." If you think C is so difficult, why the they choose to
> model Java's syntax after C?  After all, Java was intended to be one of the
> easiest possible languages to learn, with a very shallow learning curve,
> and has been quite successful at it.

Not because it was *good* but because it was *popular*. And Java is
definitely not the easiest to learn. It is just hyped to the level where
everybody feels they *must* learn it. Do you find AWT easy to work with?

> I can't even venture a guess at why you made the comments you did.  It
> almost sounds like you're mad, or resentful at C programmers, but I can't
> imagine why.

I am a bit irritated at C users who refuse to make their code readable,
by using the least readable constructs and refusing to comment the code.
They do exist, and they are many, especially at universities.

Mad, well, perhaps at one thing: how C programmers tend to flame other
high-level languages without knowing what they are talking about. You
know, like "my dad is stronger than your dad".

> Perhaps you're jealous of something, or got a low mark in
> your C course, and are taking it out on the language.

Keep the personal flames out of this. If you need to know, I know C
well, have written much C code, including fairly large applications.
I used Pascal rather little at the university, since all the courses
only used vanilla Pascal. I remember Simula was fascinating for its
OO features (before C++ even existed). I mostly used assembly at home.

I started application programming in C, since that's what people said
was
what I "should" use. When I switched to Pascal, total development time
was cut in half. Yes, it takes a little more time to write the initial
code, but it takes *much* less time to get the bugs out.

My conclusion is that Algol-style syntax suits my programming style
well.

> At any rate, I
> suggest you give it a second look.  Its easy to learn, very fast, and an
> industry standard.

I look at it every day, thank you very much. I just wish I could do
that a bit less, with more time in Pascal, Ada, Simula etc.

/Ingemar

Re: Programming language vote - results

[Steven Katz]

On Sat, 29 Nov 1997 00:53:42 +0000, Ingemar Ragnemalm
<ingemar@lysator.liu.se> wrote:

There's a great programming language reference series published by
Macmillan. See http://www.mcp.com/offers/prog_promo/index.html

Re: Programming language vote - results

[Lawrence Kirby]

In article <3470EF6E.F74@lysator.liu.se>
           ingemar@lysator.liu.se "Ingemar Ragnemalm" writes:

...

>> Efficient is good.  Tight can be good.  Impenetrable is generally not
>> good.
>
>When "efficient" and "tight" means as few keystrokes as possible, it
>isn't good.

Agreed but that don't mean that in C any more than the do in any other
language. 

>Efficient C code usually means that you take
>responsabilities
>that the optimizer should really do for you, and do that through

No, it means you work in partnership with the optimiser. You deal with the
higher level issues such as algorithms and general approach and the
optimiser deals with the lower level details.

>questionable backdoors in the language. Case switches jumping into
>while loops is one example.

Perhaps you could give an example of something that is used more than once
in a blue moon? C supports goto. It is rarely used in practice but there
are some situations where it is simply the best approach. The vast majority
of cases of coding efficnently in C don't depend on these sort of tricks
but they are there when you need them and occasionally you do.

>> I disagree with at least the implications of your conclusion.  Writing,
>> on purpose, impenetrable, bad, inefficient, and ugly code is one of the
>> best ways to comprehend good code better.  It's all well and good to say
>> "look, here's a good way to do this".  It's just as good to say "and look,
>> here's a bad way".
>
>> You can't understand fully what makes good code good without understanding
>> just as fully what makes bad code bad.
>
>When you show the bad way to those kids, they think it is WAAAY cool!
>They will use any stinking obscure construction just because "it is
>valid C code".

Are you talking about people who are going to develop serious code or not?

>Simple example from real life:
>
>if (call_this() || call_that());
>
>Valid, yes. Better than
>
>if (!call_this()) call_that();

The latter is certainly better C style and isn't going to be less efficient
than the former.

>or more clear forms in other languages?

That is a matter of opinion. I doubt whether you will find a demonstrably
clearer form in another language.

>Some people actually think so.

I'm sure some do. It is possible to program using a bad style in any language.
You're arguing more about the culture that has grown up around C than about
the language itself. For better or for worse C became the mass-market
language of the 80's and the result of that is a lot of people out there
using it who have never really learnt the principles of good programming.
This isn't helped by the plethora of awful books that have been published
purporting to teach C. This is why the emphasis in comp.lang.c is on
programming in standard C in an efficient but more importantly clear way.
Desire to write "cool" code is an insignificant problem compared with
simple lack of knowledge and misinformation.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Programming language vote - results

[Martin M Dowie]

In article <879863453snz@genesis.demon.co.uk>, Lawrence Kirby
<fred@genesis.demon.co.uk> writes
>In article <3470EF6E.F74@lysator.liu.se>
>           ingemar@lysator.liu.se "Ingemar Ragnemalm" writes:
>
>...
>Perhaps you could give an example of something that is used more than once
>in a blue moon? C supports goto. It is rarely used in practice but there
>are some situations where it is simply the best approach.

i've heard many people use this "where it is simply the best approach"
'reason' - care to given an example? and please don't say to stop doing
one thing quickly in order to do another - that is simply indicative of
a poorly analysed and designed system.

Ada also supports a 'goto' statement (though with much tighter controls)
but the only valid reason i've ever come across for using it is for
automated code generators.

-- 
Martin M Dowie

Re: Programming language vote - results

[Mark Wilden]

Martin M Dowie wrote:
> 
> i've heard many people use this "where it is simply the best approach"
> 'reason' - care to given an example? [of goto]

I've found goto the best way to branch in a simple state machine.

Re: Programming language vote - results

[Martin M Dowie]

In article <347B17AC.5A53@mWilden.com>, Mark Wilden <Mark@mWilden.com>
writes
>Martin M Dowie wrote:
>> 
>> i've heard many people use this "where it is simply the best approach"
>> 'reason' - care to given an example? [of goto]
>
>I've found goto the best way to branch in a simple state machine.

in what why is this 'the best'? surely an enumeration type containing
each possible state together with a local static variable used in an
infinite loop would produce more readable safer and _provable_ code? or
is that loop up to the top of a case/guarded select statement too
much?..

-- 
Martin M Dowie

Re: Programming language vote - results

[Lawrence Kirby]

In article <$2oaKBAp0xe0EwNL@dowie-cs.demon.co.uk>
           martin@dowie-cs.demon.co.uk "Martin M Dowie" writes:

>In article <347B17AC.5A53@mWilden.com>, Mark Wilden <Mark@mWilden.com>
>writes
>>Martin M Dowie wrote:
>>> 
>>> i've heard many people use this "where it is simply the best approach"
>>> 'reason' - care to given an example? [of goto]

A good example is breaking out of nested loops, say for code that is
searching for a value in a 2 dimensional array datastructure. Possibly
a more flexible form of the break statement would have been the answer
here but since we don't have that goto is the best solution. The Pascal
solution would probably be to create some sort of flag variable but that
just obscures the algorithm which is not a good idea if it can be avoided.

>>I've found goto the best way to branch in a simple state machine.
>
>in what why is this 'the best'? surely an enumeration type containing
>each possible state together with a local static variable used in an
>infinite loop would produce more readable safer and _provable_ code?

You would need to demonstrate that it is any of these things. Most of the
state machines I've written have taken the form you suggest but that is
for a specific reason that I've tended to want to preserve the state between
calls to the function containing the FSM, therefore the state needs to
be held in a variable. Where that isn't the case a goto based implementation
is quite natural. A FSM has structure but it is not of the same form
as that supported by structured languages. So trying to implement it
using structured language concepts isn't an automatic win. In fact by doing
so you're adding an extra layer of complexity.

>or
>is that loop up to the top of a case/guarded select statement too
>much?..

We're comparing two approaches, not asking in an absolute sense whether
one approach is acceptable or not. 

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Programming language vote - results

[FRS DES]

<< >Perhaps you could give an example of something that is used more than once
>in a blue moon? C supports goto. It is rarely used in practice but there
>are some situations where it is simply the best approach.

>i've heard many people use this "where it is simply the best approach"
>'reason' - care to given an example? and please don't say to stop doing
>one thing quickly in order to do another - that is simply indicative of
>a poorly analysed and designed system.
>
>Ada also supports a 'goto' statement (though with much tighter controls)
>but the only valid reason i've ever come across for using it is for
>automated code generators.

This thread seems to have lost all connection to APL -- please delete
comp.lang.apl for the newsgroup line or start a new thread.


              -David E. Siegel
               Software Developer, LEX2000, Inc 
               (Formerly Financial Reporting Software, or FRS)
               FRSdes@AOL.COM

Re: Programming language vote - results

[Kaz Kylheku]

In article <t6Le5BAnmde0EwO$@dowie-cs.demon.co.uk>,
Martin M Dowie  <martin@dowie-cs.demon.co.uk> wrote:
>In article <879863453snz@genesis.demon.co.uk>, Lawrence Kirby
><fred@genesis.demon.co.uk> writes
>>In article <3470EF6E.F74@lysator.liu.se>
>>           ingemar@lysator.liu.se "Ingemar Ragnemalm" writes:
>>
>>...
>>Perhaps you could give an example of something that is used more than once
>>in a blue moon? C supports goto. It is rarely used in practice but there
>>are some situations where it is simply the best approach.
>
>i've heard many people use this "where it is simply the best approach"
>'reason' - care to given an example? and please don't say to stop doing
>one thing quickly in order to do another - that is simply indicative of
>a poorly analysed and designed system.

The ``to goto or not goto'' debate has been settled decades ago. Both sides
were wrong. :)

Whether or not it is appropriate to use a goto depends on the programming
language---namely, what control structures the language supports.
If the language only supports GOTO-like structures, then your choice is
made for you. In other cases it's not that clear. Suppose that you want
to break out of some deeply nested block statement. If your language
supports a ``break N'' statement, to break out of N nesting levels,
or a ``break <name>'' where <name> is the name of the enclosing block
from which you want to jump out,  then you will use the break. If you
don't have it, you either use a simple goto, or an extra variable plus a number
of tests at each level. 

It must be remembered that goto is the most general and powerful control
mechanism and is an important ``escape hatch''. 

Today, goto no longer calls for fear and disdain, because it isn't the monster
that it was thought to be in the 60's.  

How recently have you come across a program that was rotten due to the abuse of
goto? Is this really a valid concern?

>Ada also supports a 'goto' statement (though with much tighter controls)
>but the only valid reason i've ever come across for using it is for
>automated code generators.

That's an important application, given that some CASE tools generate code.
In some cases, you could probably trust a goto-ridden automatically generated
code more readily than hand-written structured code.

Re: Programming language vote - results

[Peter Seebach]

In article <65gaoj$f8u$1@helios.crest.nt.com>,
Kaz Kylheku <kaz@helios.crest.nt.com> wrote:
>How recently have you come across a program that was rotten due to the abuse of
>goto? Is this really a valid concern?

A friend of mine has been working with code like that.

The author spent a week or two insisting that my friend's code was
at fault for not opening files correctly.

Files with names like
	"c:\temp\foo.tmp"
no less.

So, yes, there still is shoddy spaghetti code out there.

-s
-- 
seebs@plethora.net -- I am not speaking for my employer.  Copyright '97
All rights reserved.  This was not sent by my cat.  C and Unix wizard -
send mail for help, or send money for a consultation.  Visit my new ISP
<URL:http://www.plethora.net/> --- More Net, Less Spam!  Plethora . Net

Re: Programming language vote - results

[ANDREAS LEITNER]

Names are snipped (dont know who wrote what, sorry)

: Whether or not it is appropriate to use a goto depends on the programming
: language---namely, what control structures the language supports.
: If the language only supports GOTO-like structures, then your choice is
: made for you. In other cases it's not that clear. Suppose that you want
: to break out of some deeply nested block statement. If your language
: supports a ``break N'' statement, to break out of N nesting levels,
: or a ``break <name>'' where <name> is the name of the enclosing block
: from which you want to jump out,  then you will use the break. If you
: don't have it, you either use a simple goto, or an extra variable plus a 
: number
: of tests at each level. 

Well, in my opinion the need to use a goto is in most (if not all) cases a
sign that the design or the language lacks. (if (!design lacks) language 
lacks; :) 
I think goto debate is not recent anymore is because the majority of people
have accepted the fact that goto provide unreadable code. Once we got a
"coder" that produced lots of gotos, he was fired not onyl because of gotos
but also because of the fact that a different programmer was able to rewrite
a function without using one goto and also reducing the size of the function
from 60 to 15 lines (as I remember correctly)


I think this is the main reason why the goto-argument is not held anymore
(or is it help by now?) 

: How recently have you come across a program that was rotten due to the
: abuse of
: goto? Is this really a valid concern?

Yes, I've debugged a program that rebuild took over 30 minutes. Here to use
the trail and error aproach to get an idea of the code costs too much time
and money. (And is anoing)

-- 
ANDREAS LEITNER alias nozone@sbox.tu-graz.ac.at

Re: Programming language vote - results

[Robert Dewar]

<<Well, in my opinion the need to use a goto is in most (if not all) cases a
sign that the design or the language lacks. (if (!design lacks) language
lacks; :)
I think goto debate is not recent anymore is because the majority of people
have accepted the fact that goto provide unreadable code. Once we got a
"coder" that produced lots of gotos, he was fired not onyl because of gotos
but also because of the fact that a different programmer was able to rewrite
a function without using one goto and also reducing the size of the function
from 60 to 15 lines (as I remember correctly)


I think this is the main reason why the goto-argument is not held anymore
(or is it help by now?)
>>


I certainly don't want a rerun of the goto debate, but you should know that
the above absolutely stated opinion is rejected by many people. It is 
certainly not the case that all gotos produce unreadable code. Good
programmers often use a goto to improve the readability of the code (indeed
that is the only reason for using gotos). A common exception for many
people is that finite state machines are sometimes more easily represented
with code using gotos.

If this thread starts again, one hopes it does not, nothing new will be
said, but you will see that the bottom line is that *some* people agree
that gotos are evil and should never be used, but many people (including
for example Wirth and Knuth) don't have this allergic reaction to gotos,
and find useful uses for them.

Note that the fact that the design of Ada 83 contains the goto, and that
noone suggested putting the goto into annex J in Ada 95, should indicate
that the sentiment that gotos are *sometimes* useful is widespread.

Yes, of course we all know that an excessive use of gotos is a bad thing.
So is an excessive amount of almost anything, e.g. salt, but that does
not mean you should ban salt!

Re: Programming language vote - results

[Lawrence Kirby]

In article <6616ej$llt@fstgal00.tu-graz.ac.at>
           nozone@sbox.tu-graz.ac.at "ANDREAS LEITNER" writes:

>Names are snipped (dont know who wrote what, sorry)
>
>: Whether or not it is appropriate to use a goto depends on the programming
>: language---namely, what control structures the language supports.
>: If the language only supports GOTO-like structures, then your choice is
>: made for you. In other cases it's not that clear. Suppose that you want
>: to break out of some deeply nested block statement. If your language
>: supports a ``break N'' statement, to break out of N nesting levels,
>: or a ``break <name>'' where <name> is the name of the enclosing block
>: from which you want to jump out,  then you will use the break. If you
>: don't have it, you either use a simple goto, or an extra variable plus a 
>: number
>: of tests at each level. 
>
>Well, in my opinion the need to use a goto is in most (if not all) cases a
>sign that the design or the language lacks. (if (!design lacks) language 
>lacks; :) 

It depends on how often that need arises. If (pulling vague numbers out of
the air) a goto is appropriate every 10000 lines of code then the
language can't seriously be considered deficient. Trying to eliminate the
remaining gotos with manguage extensions would be over-engineering the
language and counter-productive.

>I think goto debate is not recent anymore is because the majority of people
>have accepted the fact that goto provide unreadable code.

It isn't a large debate any more because the issues involved are now pretty
much understood. goto still has its place but it needs to be used carefully.
The situations where it is apporpriate still exist when using a good
structured language but are rare.

>Once we got a
>"coder" that produced lots of gotos, he was fired not onyl because of gotos
>but also because of the fact that a different programmer was able to rewrite
>a function without using one goto and also reducing the size of the function
>from 60 to 15 lines (as I remember correctly)

In that case the goto's were just a symptom, the programmer simply didn't
know how to program well. He/she would most likely have managed to write
bad and inefficient code in a language that doesn't support goto.

>I think this is the main reason why the goto-argument is not held anymore
>(or is it help by now?) 

I think many people avoid goto entirely now simply because of peer pressure.
To actually type the word in their code would bring them out in a cold
sweat! :-) This isn't a response based on reason however.

Even in languages that don't support structured constructs to nay great
extent (so you can't seriously avoid using goto) you can still write in
a structured way. It just takes discipline and a degree of knowledge of how
to go about it.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Programming language vote - results

[Billy Chambless]

In article <881106132snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes:
|> In article <6616ej$llt@fstgal00.tu-graz.ac.at>
|>            nozone@sbox.tu-graz.ac.at "ANDREAS LEITNER" writes:

|> >Once we got a
|> >"coder" that produced lots of gotos, he was fired not onyl because of gotos
|> >but also because of the fact that a different programmer was able to rewrite
|> >a function without using one goto and also reducing the size of the function
|> >from 60 to 15 lines (as I remember correctly)
 
|> In that case the goto's were just a symptom, the programmer simply didn't
|> know how to program well. He/she would most likely have managed to write
|> bad and inefficient code in a language that doesn't support goto.
 
Indeed. While goto is, in K&R's words, "infinitely abusable", many other
common programming language features are infinitely abusable. The
programmer mentioned sounds incompetent; if you take goto's away from
an incompetent programmer, they'll just find some other feature
(pointers, for instance) to abuse. ;)

GOTO is infinitely abusable, but so is the C-style switch statement,
operator overloading, polymorphism, etc.

|> I think many people avoid goto entirely now simply because of peer pressure.
|> To actually type the word in their code would bring them out in a cold
|> sweat! :-) This isn't a response based on reason however.

Yup. CS grads especially, have had a religious prohibition of GOTO beat
into their head.

|> Even in languages that don't support structured constructs to nay great
|> extent (so you can't seriously avoid using goto) you can still write in
|> a structured way. It just takes discipline and a degree of knowledge of how
|> to go about it.

Exactly. One can write structured FORTRAN or BASIC with a little
effort... or, for that matter, spaghetti Ada or C++. 

Re: Programming language vote - results

[Robert Dewar]

<<Yup. CS grads especially, have had a religious prohibition of GOTO beat
into their head.
>>

That's an over-generalization, certainly it is something that I avoid. The
trouble is of course that most university CS professors know zilch about
programming, and manage to pass on their lack of knowledge very effectively
to their students.

Please note I said "most", not all. I know of several exceptions, in fact
the Ada community tends to have quite a few university folks around who
*do* know how to program (this of course is not a coincidence, those who
know zilch about programming are much less likely to understand the
advantages of Ada :-)

Re: Programming language vote - results

[John Sullivan]

In article <6616ej$llt@fstgal00.tu-graz.ac.at>, ANDREAS LEITNER
<nozone@sbox.tu-graz.ac.at> writes
[snip]
>Well, in my opinion the need to use a goto is in most (if not all) cases a
>sign that the design or the language lacks. (if (!design lacks) language 
>lacks; :) 
>I think goto debate is not recent anymore is because the majority of people
>have accepted the fact that goto provide unreadable code. Once we got a
>"coder" that produced lots of gotos, he was fired not onyl because of gotos
>but also because of the fact that a different programmer was able to rewrite
>a function without using one goto and also reducing the size of the function
>from 60 to 15 lines (as I remember correctly)

Amazing how people's attitudes change over the years, isn't it?

From the May/June'94 IEEE Institute, an article about John Backus
receiving the Draper Prize for having developed Fortran:

"Another of Fortran's breakthroughs was the GOTO statement, which
was a uniquely simple and understandable means of structuring and
modularizing programs."

(Thanks to Seth Breidbart for finding this quote)

John Sullivan
-------------
remove the dots from the first three (Welsh) words for my real address

Re: Programming language vote - results

[Alan E & Carmel J Brain]

Ingemar Ragnemalm wrote:

> There are plenty of people who use C since it is "cool", but just can't
> say what is so cool with it. It is cool because Mom can't understand it.
> No, they won't say that. You can identify that kind of people by the
> lack of comments in the code. They *want* it that way - and they are
> many!

> When you show the bad way to those kids, they think it is WAAAY cool!
> They will use any stinking obscure construction just because "it is
> valid C code".
> 
> Simple example from real life:
> 
> if (call_this() || call_that());
> 
> Valid, yes. Better than
> 
> if (!call_this()) call_that();
> 
> or more clear forms in other languages?
> Some people actually think so.


Here's a post from some time ago. I've had numerous requests from people
to circulate it around their offices. But no rebuttals....


> C is better than Ada because....
> 
> The first real-world C program I did was in 1980. Since 1983 I've been trying to 
> convince C hackers about the benefits of Ada. Those that actually were forced to do 
> some real project in Ada were quickly converted. But mainly, no-one tried.
> 
> Trying to tell people about the benefits often leads to complete stonewalling. There 
> has to be a logical reason for this - few programmers have low IQs.
> 
> I've finally become convinced that C really IS better than Ada, for the following 
> reasons:
> 
> 
> FOR THE PROGRAMMER
> 
> ..Hacking away in C is fun, you can add trapdoors and trojan horses real easy
> 
> ..You can write neat stuff like the following code fragments:
> 
>     #define BITCOUNT(x) (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255)
>     #define BX_(x)            ((x) - (((x)>>1)&0x77777777)  \
>                                    - (((x)>>2)&0x33333333)  \
>                                    - (((x)>>3)&0x11111111)
>     p = BX_(n);
> 
>     n = ((n>>1)  & 0x55555555) | ((n<<1)  & 0xaaaaaaaa);
>     n = ((n>>2)  & 0x33333333) | ((n<<2)  & 0xcccccccc);
>     n = ((n>>4)  & 0x0f0f0f0f) | ((n<<4)  & 0xf0f0f0f0);
>     n = ((n>>8)  & 0x00ff00ff) | ((n<<8)  & 0xff00ff00);
>     n = ((n>>16) & 0x0000ffff) | ((n<<16) & 0xffff0000);
> 
>    which is difficult to understand, and makes you look really, really clever,
>    even though it does something utterly trivial ( p is the number of bits in n,
>    and n ends up with its bit order reversed )
> 
> ..You'll always have a secure job, trying to make sense of other people's code
>    after they've left
> 
> ..You'll always have a secure job, as with well-written, terse, tight and
>    efficient C YOU are the ONLY one who can easily understand your own code!
> 
> ..You'll always have a secure job, as large C programs always have lots of bugs,
>    and require oodles of maintenance
> 
> ..Compiling is really easy - even when the stuff you're compiling is utter
>    garbage, the compiler won't tell on you
> 
> ..You can ignore most of your coding errors until quite late in the day - with
>    any luck, until you've left the project
> 
> 
> FOR THE SUPPLIER
> 
> ..You can always find C hackers, and they're dirt cheap
> 
> ..With C, you get the initial build done quick, cheap and dirty, and make a
>    fortune over the next 10 years putting in new bugs while removing old ones.
> 
> 
> FOR THE CUSTOMER
> 
> ..Because programmers and suppliers tell you so.
> 
> 
> 
> Ada is worse than C because
> 
> ..Only Anal-retentive weenies who mumble about Quality and Professionalism
>    would get any fun out of Ada
> 
> ..You'd get into the habit of writing stuff like
> 
>    with MACHINE_SPECIFIC;
> 
>    procedure COUNT_BITS_AND_REVERSE
>      ( THE_WORD  : in out MACHINE_SPECIFIC.WORD_TYPE,
>        THE_COUNT :    out MACHINE_SPECIFIC.BIT_COUNT_TYPE
>      ) is
> 
>    declare
> 
>      package BIT_OPS renames MACHINE_SPECIFIC.BIT_OPERATIONS;
> 
>    begin
> 
>      THE_COUNT := BIT_OPS.BIT_COUNT_OF(THE_WORD);
>      BIT_OPS.REVERSE_BIT_ORDER_OF(THE_WORD);
> 
>    exception
>  
>      when others => raise CODE_CORRUPTED_OR_HARDWARE_ERROR;
> 
>    end COUNT_BITS_AND_REVERSE;
> 
>    which any fool can easily understand, even though it does trap some of
>    the errors caused by the over-running array bounds in the C you've had
>    to PRAGMA INTERFACE to, soft errors, and hardware glitches.
>    Not only that, it works on 16, 32, 64, 48 etc bit machines as well. so
>    can't get lots of bucks writing different versions.
>    And then the compiler barfs, and tells you what you've done wrong!
> 
> ..You spend a long time looking for a job, as your code on the last project
>    worked so well that the project completed on time, and you were no longer
>    needed.
> 
> ..You spend a long time looking for a job, as the maintenance effort needed
>    consisted of 2 part-timers rather than the whole development team
> 
> ..You spend a long time looking for a job, as no-one uses Ada
> 
> ..Getting a Clean Compile of anything non-trivial is quite difficult.
> 
> ..Your Ego takes a hammering by the compiler constantly showing you where
>    you made mistakes. And if not the compiler, the Linker!
> 
> 
> FOR A SUPPLIER
> 
> ..Ada programmers are rare and expensive. You can't hire cheap graduate coolies.
> 
> ..It costs more initially to make a system, and it takes longer. Much worse,
>    there's almost no maintenance, so your only revenue is from the initial sale.
> 
> 
> FOR A CUSTOMER
> 
> ..Because the programmers and suppliers tell you so.
> 
> 
> That's the bottom line, people. The only people who benefit from Ada are the
> customers and users. The user riding on a 777 generally doesn't know that any
> programming was involved, and the customers rely on advice from their suppliers.
> 
> Until we understand that, all arguments regarding the qualities of Ada are
> irrelevant.     

 

-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Programming language vote - results

[Peter Seebach]

In article <3470EF6E.F74@lysator.liu.se>,
Ingemar Ragnemalm  <ingemar@lysator.liu.se> wrote:
>Simple example from real life:

>if (call_this() || call_that());

UGH!

>Valid, yes. Better than

>if (!call_this()) call_that();

>or more clear forms in other languages?
>Some people actually think so.

I have a hard time believing that.

I will argue that
	call_this() || call_that();
is clear to sh and perl programmers.

The redundant if() is just plain stupid, though - happily granted.

Perhaps it devolved from an original doing something like
	if (call_this() || call_that())
		do_something();

in which case, it would (arguably) make sense, and be perfectly idiomatic,
just as it's idiomatic, though not the most simple, to say
	If you're going to the store, or you have a free moment, could
	you get me some orange juice?

(Of course, in this case, if you stop wanting orange juice, you remove
the entire statement.)

Simplicity is not always the best mechanism for clarity.  Anyone who
thinks otherwise is entitled to try to read children's books for
comprehension - it's very tiring, and in the end, *hard*, to read
a lot of little tiny sentences.

-s
-- 
seebs@plethora.net -- I am not speaking for my employer.  Copyright '97
All rights reserved.  This was not sent by my cat.  C and Unix wizard -
send mail for help, or send money for a consultation.  Visit my new ISP
<URL:http://www.plethora.net/> --- More Net, Less Spam!  Plethora . Net

Re: Programming language vote - results

[Randy MacDonald]

In article <3444BFC6.794BDF32@druid.net>, "D'Arcy J.M. Cain" <darcy@druid.net> wrote:
>Alan E & Carmel J Brain wrote:
>> Every time someone says how terse and powerful C is, I think of APL.
>
>My favourite quote about APL - "I refuse to use any computer language
>in which the proponents shove snippets of code under each other's
>nose saying 'I bet you can't guess what this does!'"
>
As opposed to presenting reams of code, which, although with full
explanations, the function of which can probably only be taken on faith?
Given equivalent functionality, I would rather have a hope of understanding
a snippet as opposed to a volume.

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[D'Arcy J.M. Cain]

Jan Karman wrote:
> > My favourite quote about APL - "I refuse to use any computer language
> > in which the proponents shove snippets of code under each other's
> > nose saying 'I bet you can't guess what this does!'"
> >
> 
> There are millions of kids who can read a music score.
> For a lot of people it looks like a Jackson Pollock painting.

Uh, OK.  The quote suggested an interaction between people who
understood the language.  Certainly I don't expect to be able
to show any program to someone who doesn't know the language
(say mooreon and C for example) and have them understand it.

It was a joke, son.  Even APL programmers usually find it humorous.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: Programming language vote - results

[Robert I. Eachus]

In article <34458CE3.507C@dynamite.com.au> Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes:

 > I guess I'm probably the only contributor here whose preferred language
 > is Ada-95, and who has used a lot of APL in the commercial environment.

   Guess again...  APL Is great for what it does, and you can do
things in it, in a few lines, that take doezens or hundreds of pages
in other languages.  However, it takes just as long to understand the
code.  I even have code prototyped as a dozen lines of APL that
eventually became about 25 pages of well structured, well commented
Ada 83.  (The Ada, of course, runs much faster, and that is not
something I could have done in APL--I had to write a sparse matrix
package tuned to the particular application.)

   In any case I wouldn't make any changes in either version without
several weeks to refamiliarize myself with the algorithms and code.
(And, yes the documentation outbulks by far either source version.)

   But I couldn't have written the code without the freedom granted by
Ada, APL, and Lisp to redefine the things at one level, and work with
the higher level abstract ONLY in other parts of the code.

 
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Programming language vote - results

[Randy MacDonald]

In article <34428914.2D71D0F@ibm.net>, dness@ibm.net wrote:
>How about dropping comp.lang.apl from this thread? It doesn't seem
>to have much to do with APL/J...

Note that APL is #4 on the list.  Your vote seems to _really_ count, so don't
delay, act today.

--
|\/| Randy A MacDonald       | Bring me... BLUE PAGES!!!!
|\\| randy@godin.on.ca       | 
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | *** GLi Info: info@godin.on.ca ***
                             | Also http://www.godin.on.ca/randy
------------------------------------------------<-NTP>----{ gnat }-

Re: Programming language vote - results

[Matthew Heaney]

In article <343FD05C.8986A557@flash.net>, scottg@flash.net wrote:

>Oh the horror stories about Ada just about anyone in the defense
>industry could tell you...(inefficiency, bloat, development delays,
>budget overruns)...I dare you to fit a Jovial application that already
>max's out a computer's capabilities in the same box using OO techniques
>in Ada...In fact, multiply memory and CPU throughput by 10 and try it.
>You will likely be forced to back off OO quite a bit, making an even
>bigger mess of maintainability/reusability...

This statement is obviously incorrect, as Ada's OO facilities are actually
quite efficient.  A type for which inheritance is available - in Ada, a
"tagged" type (called a "class" in other languages) - only requires 1 extra
memory word to store the tag, and primitive operations (called "methods" in
other languages) are bound statically by default.

I have been happily programming in Ada for 10 years - by choice - but sorry
to say have no "horror stories" to share with you, since my experience in
Ada has only been pleasant.

It may seem too fantastic to be true :-), but there are actually real Ada
"success" stories!  Visit the Ada home page for a list, to get a healthy
dose of reality.  

<http://www.adahome.com>

If you'd like to learn Ada, so you can avoid making vacuous comments about
a language you know nothing about, you can get a free, high-quality Ada
compiler, GNAT, at NYU.

<ftp://ftp.cs.nyu.edu/gnat>

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Programming language vote - results

[Gary L. Scott]

I guess I should clarify.  The comment was not specifically about Ada,
but about inappropriate use of "OO" analysis and design to produce
unworkable code.  These are far from vacuous comments.

Matthew Heaney wrote:

> In article <343FD05C.8986A557@flash.net>, scottg@flash.net wrote:
>
> >Oh the horror stories about Ada just about anyone in the defense
> >industry could tell you...(inefficiency, bloat, development delays,
> >budget overruns)...I dare you to fit a Jovial application that
> already
> >max's out a computer's capabilities in the same box using OO
> techniques
> >in Ada...In fact, multiply memory and CPU throughput by 10 and try
> it.
> >You will likely be forced to back off OO quite a bit, making an even
> >bigger mess of maintainability/reusability...
>
> This statement is obviously incorrect, as Ada's OO facilities are
> actually
> quite efficient.  A type for which inheritance is available - in Ada,
> a
> "tagged" type (called a "class" in other languages) - only requires 1
> extra
> memory word to store the tag, and primitive operations (called
> "methods" in
> other languages) are bound statically by default.
>
> I have been happily programming in Ada for 10 years - by choice - but
> sorry
> to say have no "horror stories" to share with you, since my experience
> in
> Ada has only been pleasant.
>
> It may seem too fantastic to be true :-), but there are actually real
> Ada
> "success" stories!  Visit the Ada home page for a list, to get a
> healthy
> dose of reality.
>
> <http://www.adahome.com>
>
> If you'd like to learn Ada, so you can avoid making vacuous comments
> about
> a language you know nothing about, you can get a free, high-quality
> Ada
> compiler, GNAT, at NYU.
>
> <ftp://ftp.cs.nyu.edu/gnat>
>
> --------------------------------------------------------------------
> Matthew Heaney
> Software Development Consultant
> <mailto:matthew_heaney@acm.org>
> (818) 985-1271



--
Gary L. Scott
scottg@flash.net

Re: Programming language vote - results

[Robert S. White]

In article <343FD05C.8986A557@flash.net>, scottg@flash.net says...
>
>Oh the horror stories about Ada just about anyone in the defense
>industry could tell you...(inefficiency, bloat, development delays,
>budget overruns)...I dare you to fit a Jovial application that already
>max's out a computer's capabilities in the same box using OO techniques
>in Ada.

  I bounce between Jovial (worse yet J73/I) and Ada all the time at 
work.  Yes _some_compiler implementations are not as good as others - 
but others are just fine.  Ever look at the code quality of Tartan Ada?
Don't blame the language when coders go OO beserk.  In _real_life_ we
watch our processor utilization carefully and use pragma inline and turn
off runtime checks in the "hot spot" code routines.  You _can_ use
Stucture Analysis with Ada to come up with an equivalent software design
just like you used to get with Jovial.  But it is so much easier to
maintain and modify software that is designed with an object oriented (or
at least object based) high level structure.  You do have to know when to
stop at low level routines, have to watch out for inefficiencies from 
virtual dispatching (avoid late binding), heap usage, and subroutine
nesting.  

  But the problem you describe with an already "max'd out" application 
written in Jovial (or C) using older Structure Analysis/(functional
decomposition), would also have problems if you used any other OO 
capable language (C++, Eiffel, Delphi, etc.) and OOA/OOD without concern
for processor utilization.

>..In fact, multiply memory and CPU throughput by 10 and try it.
 
  I have seen an Ada implementation take about 10 - 15% more (1.1x to 1.15x)
than a very mature (very efficient code) J73/I compiler on same 
processor target when equivalent compiler switches thrown.  Never - never
have I seen a 10x case due to the compilers alone.  Even way back in 1984
with early immature compilers worse case max was 3x.  Did your 
compiler that you are complaining about even have peephole optimization?

>You will likely be forced to back off OO quite a bit, making an even
>bigger mess of maintainability/reusability...

  And the original Jovial was wonderful in those areas?

_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter

Re: Programming language vote - results

[Gary L. Scott]

Sorry, this is a little off-topic...

Robert S. White wrote:

> In article <343FD05C.8986A557@flash.net>, scottg@flash.net says...
> >
> >Oh the horror stories about Ada just about anyone in the defense
> >industry could tell you...(inefficiency, bloat, development delays,
> >budget overruns)...I dare you to fit a Jovial application that
> already
> >max's out a computer's capabilities in the same box using OO
> techniques
> >in Ada.
>
>   I bounce between Jovial (worse yet J73/I) and Ada all the time at
> work.  Yes _some_compiler implementations are not as good as others -
> but others are just fine.  Ever look at the code quality of Tartan
> Ada?
> Don't blame the language when coders go OO beserk.  In _real_life_ we
> watch our processor utilization carefully and use pragma inline and
> turn
> off runtime checks in the "hot spot" code routines.  You _can_ use
> Stucture Analysis with Ada to come up with an equivalent software
> design
> just like you used to get with Jovial.  But it is so much easier to
> maintain and modify software that is designed with an object oriented
> (or
> at least object based) high level structure.  You do have to know when
> to
> stop at low level routines, have to watch out for inefficiencies from
> virtual dispatching (avoid late binding), heap usage, and subroutine
> nesting.

Of course, this was partly a problem of "design philosophy".  The
problem was that they didn't seem to know when to stop in the low level
routines.  But they eventually found a happy medium.  Spent a lot of
money doing so though.

>
>
>   But the problem you describe with an already "max'd out" application
>
> written in Jovial (or C) using older Structure Analysis/(functional
> decomposition), would also have problems if you used any other OO
> capable language (C++, Eiffel, Delphi, etc.) and OOA/OOD without
> concern
> for processor utilization.

That was my point.  "OO" not Ada specifically.  By the time the project
is over, the hardware will be obsolete (actually already is in terms of
commercial products (CPU speed anyway)).  So the schedule has basically
extended beyond what was originally intended as the middle of its life
span with no product in sight, lots of money spent.  We could have just
rehosted the JOVIAL and saved schedule, money, and had significantly
more reserve in the computer at completion.

>
>
> >..In fact, multiply memory and CPU throughput by 10 and try it.
>
>   I have seen an Ada implementation take about 10 - 15% more (1.1x to
> 1.15x)
> than a very mature (very efficient code) J73/I compiler on same
> processor target when equivalent compiler switches thrown.  Never -
> never
> have I seen a 10x case due to the compilers alone.  Even way back in
> 1984
> with early immature compilers worse case max was 3x.  Did your
> compiler that you are complaining about even have peephole
> optimization?

Well, early on they had to turn off optimization in order to figure out
why nothing was working.  To be fair there were significant hardware
problems as well that had to be worked around in software.

>
>
> >You will likely be forced to back off OO quite a bit, making an even
> >bigger mess of maintainability/reusability...
>
>   And the original Jovial was wonderful in those areas?

Depends a little on your point of view and the design of the code.  The
JOVIAL code is a lot easier to read/understand than the Ada code.  This
by itself can lead to advantages in terms of maintenance.  We have been
able to create very "modular" JOVIAL code which can essentially be
dropped in/taken out with little impact to other functions.  This is as
valid of an approach as true "OO" in many cases.
_____________________________________________________________________

> Robert S. White         -- An embedded systems software engineer
> e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter



--
Gary L. Scott
scottg@flash.net

Re: Programming language vote - results

[William Rapp]

wEl@yddraiggoch.demon.co.uk> <34481248.4F0A@dynamite.com.au>
Organization: CRL Network Services      (415) 705-6060  [Login: guest]
Distribution: 

In comp.lang.c Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote:

Did you remember to make all the variables using only  '1' 'I' 'O' '0'.