ADA SUCKS, C/C++/JAVA RULES!!!!

Showing 1-614 of 614 messages
ADA SUCKS, C/C++/JAVA RULES!!!! John Black 10/28/97 12:00 AM

I have tried and tried to program with Ada, but it is downright
impossible.  I just don't see how anyone could - or would want to -
use this outdated piece of crap.  It's back to C++ and Java for me.
Hopefully Ada and other languages will go the way of the dinosaur and
get hit by a meteor, disappearing from the face of the earth.

ADA SUCKS, C/C++/JAVA RULES!!!! Marco Schramp 10/28/97 12:00 AM

John Black <nospam@nospam> wrote in article
<34557f2b...@news.mindspring.com>...I'm glad that you know which languages you like and which you
don't. There is however no reason for putting it down like
this.

In all the groups that you posted to have been discussions about
which language is better and which isn't. The end-conclusion
has always been: personal taste, programs and programmers objectives
and other (somewhat subjective) opinions.
Let's not start a holy war against yet another language (in this
case ADA).

Marco.
---------------------
Swearing is the only language spoken proficiently by programmers.


ADA SUCKS, C/C++/JAVA RULES!!!! Shayne Flint 10/28/97 12:00 AM

John Black wrote:
>
> I have tried and tried to program with Ada, but it is downright
> impossible.  I just don't see how anyone could - or would want to -
> use this outdated piece of crap.

I wouldn't usually react like this, but:

If you had so much trouble with Ada you must be completely STUPID and
USELESS!!

Let this be the end of this thread.

------------------------------------------------------------------
-- Shayne Flint, MIEAust, CPEng        sha...@ainslie-software.com
-- Ainslie Software Pty Limited    http://www.ainslie-software.com
--
--      ShapeDB, a database and form drawing add-on for Visio
------------------------------------------------------------------

ADA SUCKS, C/C++/JAVA RULES!!!! Adam Beneschan 10/28/97 12:00 AM

I once heard of a computer language named TROLL; I have no idea what
it's like, but I think you should look into it.  I'll bet it's
something you'd really enjoy programming in.

                                -- Adam

(sorry, couldn't resist)

ADA SUCKS, C/C++/JAVA RULES!!!! Tucker Taft 10/28/97 12:00 AM

BRIAN LANGENBERGER (lang...@itlabs.umn.edu) wrote:

: While I've never done any significant programming in Ada (anyone know
: of a good GNUada compiler? ;)  

FWIW, there is a good GNUAda compiler, known as "GNAT"
(cf. www.gnat.com), which has, among others, real-live
"GNU" folks as part of their development staff.

It has the usual download price of $0.00, with commercial support
contracts available from a company called "ACT" (analogous
to Cygnus for GCC).

There are also other freely-downloadable "personal" versions of
Ada95 compilers as well; cf www.aonix.com and www.appletmagic.com.

--
-Tucker Taft   s...@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

2.)  I find it interesting that YOU fail, and then blame the language for
YOUR inability to grasp it.

3.)  It is admirable that you are able to come out and let everyone know
that you are incapable of adapting to a new language, even though I cannot
think of anything you can do in the other languages mentioned that you
cannot do in some way using Ada.  Maybe you are just lost without your
wizards?

4.)  Many of the Ada projects that I have worked on would have been much
more difficult, or down right impossible, to manage in C or C++ (I have not
done large scale development (or even testing) of anything written in Java,
so I cannot comment on that).  Add to that the fact that for certain types
of projects, you also get a lower cost of development and (especially)
maintenance, a tendency for less bugs, etc.

Of course, if you are mostly writing Windows apps, then VC++ is a lot better
environment than _anything_ you are going to get for Ada (at least at this
time).  Then again, we are coming back to "use the right tool for the right
job", and right now, VC++ or VB (or maybe even Java) is often the right tool
for that job (though Ada is making some in roads there, but the tools are
not quite on par with VC++ yet (IMHO)).

--
with Std_Disclaimer;  use Std_Disclaimer;
Signature.Put (Name => Ken Sodemann,
    E_Mail => kwso...@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);


ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

ADA SUCKS, C/C++/JAVA RULES!!!! Steve Ropa 10/28/97 12:00 AM

On Tue, 28 Oct 1997, Kenneth W. Sodemann wrote:

<snip very good points>


>
> 4.)  Many of the Ada projects that I have worked on would have been much
> more difficult, or down right impossible, to manage in C or C++ (I have not
> done large scale development (or even testing) of anything written in Java,
> so I cannot comment on that).  Add to that the fact that for certain types
> of projects, you also get a lower cost of development and (especially)
> maintenance, a tendency for less bugs, etc.
>
> Of course, if you are mostly writing Windows apps, then VC++ is a lot better
> environment than _anything_ you are going to get for Ada (at least at this
> time).  Then again, we are coming back to "use the right tool for the right
> job", and right now, VC++ or VB (or maybe even Java) is often the right tool
> for that job (though Ada is making some in roads there, but the tools are
> not quite on par with VC++ yet (IMHO)).
>

I hate to keep a thread going that started with such an inane comment(see
subject) but *your* points were very well articulated, and lead me to a
question.
As you said, it all boils down to the right tool for the right job.  What
types of jobs are Ada best suited for? I got into development through self
learning, so I never really had the benefit of experiencing a lot of
different languages.

Thanks
Steve


ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

2.)  I find it interesting that YOU fail, and then blame the language for
YOUR inability to grasp it.

3.)  It is admirable that you are able to come out and let everyone know
that you are incapable of adapting to a new language, even though I cannot
think of anything you can do in the other languages mentioned that you
cannot do in some way using Ada.  Maybe you are just lost without your
wizards?

4.)  Many of the Ada projects that I have worked on would have been much


more difficult, or down right impossible, to manage in C or C++ (I have not
done large scale development (or even testing) of anything written in Java,
so I cannot comment on that).  Add to that the fact that for certain types
of projects, you also get a lower cost of development and (especially)
maintenance, a tendency for less bugs, etc.

Of course, if you are mostly writing Windows apps, then VC++ is a lot better
environment than _anything_ you are going to get for Ada (at least at this
time).  Then again, we are coming back to "use the right tool for the right
job", and right now, VC++ or VB (or maybe even Java) is often the right tool
for that job (though Ada is making some in roads there, but the tools are
not quite on par with VC++ yet (IMHO)).

--


with Std_Disclaimer;  use Std_Disclaimer;
Signature.Put (Name => Ken Sodemann,
    E_Mail => kwso...@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);


ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

ADA SUCKS, C/C++/JAVA RULES!!!! Dann Corbit 10/28/97 12:00 AM

John Black wrote in message <34566fe...@news.mindspring.com>...
>You guys say what you want but it's true.  ADA is good for nothing.
>C++, on the other hand, is the only language you need.
Boy, this is just great.  The "C or C++" thread was not good enough.  Now that
it has passed the previous world record for spam harvesting, we pull Ada and
Java into the mix.  Pretty please, down on my knees, I'm begging you to trim
comp.lang.c from the header when replying to this post.

I like Ada.  I like Java.  I like C.  I like C++.  I hate these inane threads.
Gargantuan avalanches of pseudo-information, opinions stated as facts, and
name calling.

Oh, goody.
--
C-FAQ ftp sites: ftp://ftp.eskimo.com ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ Book: ISBN 0-201-84519-9.
Want Software?  Algorithms?  Pubs? http://www.infoseek.com

ADA SUCKS, C/C++/JAVA RULES!!!! John Black 10/28/97 12:00 AM
ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Black 10/28/97 12:00 AM

ADA and Pascal are two of the most useless inventions Man has ever
wasted space on this planet with.  These languages are hard to learn,
have zero applications, and people who only know these languages can
only find jobs at Taco Bell!  Smart programmers spend their time
learning only C, C++, and Java in that order.

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Robert S. White 10/28/97 12:00 AM

In article <Pine.SUN.3.96.971028125423.20605D-100000@flatland.dimensional.com>,
ther...@dimensional.com says...

>As you said, it all boils down to the right tool for the right job.  What
>types of jobs are Ada best suited for? I got into development through self
>learning, so I never really had the benefit of experiencing a lot of
>different languages.

  IME Ada has worked out very well for difficult embedded systems
maintained by a team of software engineers for a significant period
of time.  Stuff like avionics, spaceborne electronics, munitions and
other things you don't want to fail.  I've heard that some banks also
found that reliable and easy to maintain software systems are a plus.
Check out:  http://www.adahome.com for more answers to this question.

 And again IME it is _not_ hard to teach a new college grad engineer
(who has never used Ada) how to effectively use Ada in a very short
time.  With development environments ranging from Rational Apex to
very nice (but simple) AdaGIDE/GNAT, it is very simple to develope
Ada code.  

 Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
code generation.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter


ADA SUCKS, C/C++/JAVA RULES!!!! Charles R. Lyttle 10/28/97 12:00 AM

--------------108E80454C4234ACA219AC32
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve Ropa wrote:

I find Ada best for really big jobs (1_000_000 or more lines) with lots of formal
methodologies and a need for high reliability. I hope Java will fill the under
1_000_000 spot one day soon.

--

Russ Lyttle

email : lyt...@mail.flash.net

--------------108E80454C4234ACA219AC32
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<HTML>
Steve Ropa wrote:
<BLOCKQUOTE TYPE=CITE>On Tue, 28 Oct 1997, Kenneth W. Sodemann wrote:

<P>&lt;snip very good points>
<BR>>
<BR>> 4.)&nbsp; Many of the Ada projects that I have worked on would have
been much
<BR>> more difficult, or down right impossible, to manage in C or C++ (I
have not
<BR>> done large scale development (or even testing) of anything written
in Java,
<BR>> so I cannot comment on that).&nbsp; Add to that the fact that for
certain types
<BR>> of projects, you also get a lower cost of development and (especially)
<BR>> maintenance, a tendency for less bugs, etc.
<BR>>
<BR>> Of course, if you are mostly writing Windows apps, then VC++ is a
lot better
<BR>> environment than _anything_ you are going to get for Ada (at least
at this
<BR>> time).&nbsp; Then again, we are coming back to "use the right tool
for the right
<BR>> job", and right now, VC++ or VB (or maybe even Java) is often the
right tool
<BR>> for that job (though Ada is making some in roads there, but the tools
are
<BR>> not quite on par with VC++ yet (IMHO)).
<BR>>

<P>I hate to keep a thread going that started with such an inane comment(see
<BR>subject) but *your* points were very well articulated, and lead me
to a
<BR>question.
<BR>As you said, it all boils down to the right tool for the right job.&nbsp;
What
<BR>types of jobs are Ada best suited for? I got into development through
self
<BR>learning, so I never really had the benefit of experiencing a lot of
<BR>different languages.

<P>Thanks
<BR>Steve</BLOCKQUOTE>
I find Ada best for really big jobs (1_000_000 or more lines) with lots
of formal methodologies and a need for high reliability. I hope Java will
fill the under 1_000_000 spot one day soon.&nbsp;
<PRE>--&nbsp;

Russ Lyttle&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<http://www.flash.net/~lyttlec>&nbsp;
email : lyt...@mail.flash.net</PRE>
&nbsp;</HTML>

--------------108E80454C4234ACA219AC32--


ADA SUCKS, C/C++/JAVA RULES!!!! Rob Eamon 10/28/97 12:00 AM

John Black wrote in message <34557f2b...@news.mindspring.com>...

This seems to be a fairly typical reaction by C/C++ programmers.
(And I don't mean this in a negative way.) The Ada syntax is
more verbose and tends to make those who are comfortable
with a terse language a little crazy. Also the strong type checking
will make a C/C++ programmer who is used to playing loose
and easy with pointers and casting pull their hair out.

Ada has some good features, including having multitasking
support built into the language. Ada is useful in many contexts,
but unless you had a specific reason for using Ada, it's not
surprising that you abandoned it for what you already know.


ADA SUCKS, C/C++/JAVA RULES!!!! BRIAN LANGENBERGER 10/28/97 12:00 AM

John Black (nospam@nospam) wrote:
: I have tried and tried to program with Ada, but it is downright

While I've never done any significant programming in Ada (anyone know
of a good GNUada compiler? ;)  I wouldn't want it going away.
More programming languages mean more variety, and with the vast multitudes
of hardware availible (and, consequently, problems to be solved),
programmers need all the tools (i.e. languages) we can get.

I'd like to see more languages rather than less.

ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

2.)  I find it interesting that YOU fail, and then blame the language for
YOUR inability to grasp it.

3.)  It is admirable that you are able to come out and let everyone know
that you are incapable of adapting to a new language, even though I cannot
think of anything you can do in the other languages mentioned that you
cannot do in some way using Ada.  Maybe you are just lost without your
wizards?

4.)  Many of the Ada projects that I have worked on would have been much


more difficult, or down right impossible, to manage in C or C++ (I have not
done large scale development (or even testing) of anything written in Java,
so I cannot comment on that).  Add to that the fact that for certain types
of projects, you also get a lower cost of development and (especially)
maintenance, a tendency for less bugs, etc.

Of course, if you are mostly writing Windows apps, then VC++ is a lot better
environment than _anything_ you are going to get for Ada (at least at this
time).  Then again, we are coming back to "use the right tool for the right
job", and right now, VC++ or VB (or maybe even Java) is often the right tool
for that job (though Ada is making some in roads there, but the tools are
not quite on par with VC++ yet (IMHO)).

--


with Std_Disclaimer;  use Std_Disclaimer;
Signature.Put (Name => Ken Sodemann,
    E_Mail => kwso...@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);


ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/28/97 12:00 AM

John Black, in message <34557f2b...@news.mindspring.com> spewed
forth...

1.)  Nice troll!!

ADA SUCKS, C/C++/JAVA RULES!!!! Rob 10/28/97 12:00 AM

BRIAN LANGENBERGER wrote:
>>While I've never done any significant programming in Ada (anyone know
of a good GNUada compiler? ;)  <<

as a matter of fact:  gnat

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! David A. Frantz 10/28/97 12:00 AM

ADA and Pascal hard to learn he he.    Just how many programmers out there
have a handle on C++.    The whole package; STL, IOstreams, Class,
Templates - I could go on and on but the point is that there are only a
handful of people out there with a complete understanding of C++.    Then
there is the Question of how many of those are actually productive with it.
If C++ is that simple then we should be able to find VALIDATED compilers on
the market, far as I Know there is none out there.

The problem with ADA is that it is rejected by the hacker cult that started
out on C.    Mean while C & C++ have been rejected by anybody who has to
ship a product under tight deadlines and high quality expectations.   i.e.
anyone working for a corporation.

Dave

John Black wrote in message <345673af...@news.mindspring.com>...

ADA SUCKS, C/C++/JAVA RULES!!!! John Bode 10/28/97 12:00 AM

In article <34566fe...@news.mindspring.com>, nospam@nospam (John
Black) wrote:

> You guys say what you want but it's true.  ADA is good for nothing.
> C++, on the other hand, is the only language you need.

C++?!?!  The COBOL of the Nineties (with apologies to COBOL)?  The most
God-awful kludge of a language in the history of Western civilization?  The
most complicated, un-object-oriented OOL?  A language with no standard,
conflicting goals, and inconsistent implementations?  A language where Herb
Schildt is just as likely to be right about a particular feature as anyone?

Question:  How object-oriented is a language that still relies on #include
files?

--
John Bode
one grumpy code monkey

"Paranoia is just reality on a finer scale" -- Strange Days

To email me directly, remove the 'nospam.' from my address.

ADA SUCKS, C/C++/JAVA RULES!!!! John Bode 10/28/97 12:00 AM

In article <34557f2b...@news.mindspring.com>, nospam@nospam (John
Black) wrote:

> I have tried and tried to program with Ada, but it is downright
> impossible.  I just don't see how anyone could - or would want to -
> use this outdated piece of crap.  It's back to C++ and Java for me.
> Hopefully Ada and other languages will go the way of the dinosaur and
> get hit by a meteor, disappearing from the face of the earth.

My, what a *cute* little troll.  Just makes you want to grab a 2x4 and beat
the crap out of it, doesn't it?

--
John Bode
one grumpy code monkey

"Paranoia is just reality on a finer scale" -- Strange Days

To email me directly, remove the 'nospam.' from my address.

ADA SUCKS, C/C++/JAVA RULES!!!! Dennis Weldy 10/28/97 12:00 AM

I wouldnt say he'c completely stupid. Really, we oughta thank him for
publicizing his approach to problem solving, particularly when he has
difficulties. This way, if y'see a resume cross your desk with the name
"John Black", you'll know where to file it ;-)

Dennis
Shayne Flint wrote in message <3455D9...@ainslie-software.com>...


>John Black wrote:
>>
>> I have tried and tried to program with Ada, but it is downright
>> impossible.  I just don't see how anyone could - or would want to -
>> use this outdated piece of crap.
>
>I wouldn't usually react like this, but:
>
>If you had so much trouble with Ada you must be completely STUPID and
>USELESS!!
>
>Let this be the end of this thread.
>
>------------------------------------------------------------------
>-- Shayne Flint, MIEAust, CPEng        sha...@ainslie-software.com
>-- Ainslie Software Pty Limited    http://www.ainslie-software.com
>--
>--      ShapeDB, a database and form drawing add-on for Visio
>------------------------------------------------------------------

ADA SUCKS, C/C++/JAVA RULES!!!! BRIAN LANGENBERGER 10/29/97 12:00 AM

John Black (nospam@nospam) wrote:
: You guys say what you want but it's true.  ADA is good for nothing.
: C++, on the other hand, is the only language you need.

If you wanted a progam to clean our your netscape cache every time
you logged-out, would you really write it in C++?  A shell script
seems like a better alternative to me.  What about a simple text
filter that turns newlines to spaces?  Regular C seems just fine
for that task.  

IMO, a real programmer wouldn't ignore potentially
useful programming languages any more than a real carpenter would
try building a house with only a screwdriver.

As long as the job gets done properly, who really cares what
language(s) was/were used?

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Timo Salmi 10/29/97 12:00 AM

In article <345673af...@news.mindspring.com>,
John Black <nospam@nospam> wrote:
:ADA and Pascal are two of the most useless inventions Man has ever
:wasted space on this planet with.  These languages are hard to learn,

*** TROLL ALERT *** TROLL ALERT *** TROLL ALERT *** TROLL ALERT ***

*** IGNORE THE BAIT *** IGNORE THE BAIT *** IGNORE THE BAIT ***

   All the best, Timo

....................................................................
Prof. Timo Salmi   Co-moderator of news:comp.archives.msdos.announce
Moderating at ftp:// & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance  ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/>  ; FIN-65101,  Finland

Spam foiling in effect.  My email filter autoresponder will return a
required email password to users not yet in the privileges database.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Shombe Kroll 10/29/97 12:00 AM

Hello everyone, I hate to say it but my sentiments are with Mr. Black to a
small degree.  My first programming class in college was in ADA and I found
it very difficult to learn because of the lack of documentation and help
aids for the language.  That  forced me to rely on my Professor for help
which unfortunately was like pulling teeth.  The lack of being able to
obtain outside sources from my local computer store ie : "ADA for Dummies"
left me with a feeling of complete frustration while I spent the semester
copying and reediting code from my fellow struggling classmates in order to
pass the course.
However, struggling with ADA did give me an appreciation for the process of
writing source code, and I have found that the fundamentals that I learned
with ADA are applicable to me as I learn C++.  <-- By the way this time I am
writing my own code),

>John Black wrote in message <345673af...@news.mindspring.com>...


>>ADA and Pascal are two of the most useless inventions Man has ever
>>wasted space on this planet with.  These languages are hard to learn,

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Black 10/29/97 12:00 AM

Shombe, I feel your pain.  I'm embroiled in a Comparative Programming
Language class where we have to program in Ada, and the thing is so
impossible, I'm lucky to even get it to compile, never mind Constraint
Errors.  And why bother sweating over a language that nobody uses!?
At least I know C++, and I can pick up Java relatively easily.
Knowing Ada and Pascal are almost as useful as knowing outer space
basket weaving.
ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Black 10/29/97 12:00 AM

Then why do the want ads for C, C++ programmers could stretch from
here to the moon, while Ada/Pascal programmers are nonexistent?  Like
I said, if you program in Ada or Pascal, your best job is going to be
taking orders at Red Lobster.

>The problem with ADA is that it is rejected by the hacker cult that started
>out on C.    Mean while C & C++ have been rejected by anybody who has to
>ship a product under tight deadlines and high quality expectations.   i.e.
>anyone working for a corporation.

ADA SUCKS, C/C++/JAVA RULES!!!! Alan E & Carmel J Brain 10/29/97 12:00 AM

Shayne Flint wrote:
>
> John Black wrote:
> >
> > I have tried and tried to program with Ada, but it is downright
> > impossible.  I just don't see how anyone could - or would want to -
> > use this outdated piece of crap.
>
> I wouldn't usually react like this, but:
>
> If you had so much trouble with Ada you must be completely STUPID and
> USELESS!!
>
> Let this be the end of this thread.

At the risk of contradicting you, Shayne, consider:

either this is a guy who finds

#include stdio.h
void main()
{
  printf("Hello World/n/n/n");
|

easy, neat, and generally "better" while

with TEXT_IO;
procedure MAIN is
begin
  TEXT_IO.PUT("Hello World")
  NEW_LINE(3);
end;

is impossibly hard, obsolete and "worse", XOR it's a troll. Given the
pre-pubescent "X sucks Y rules" header, you're right in either case.
--
aeb...@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abr...@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale


ADA SUCKS, C/C++/JAVA RULES!!!! Dale Stanbrough 10/29/97 12:00 AM

Mr John (I'm not going to reveal my secret identity) Black writes:

"Shombe, I feel your pain.  I'm embroiled in a Comparative Programming
 Language class where we have to program in Ada, and the thing is so
 impossible, I'm lucky to even get it to compile, never mind Constraint
 Errors."

Translation:

I'm so hopeless i can't even understand a few rules on how to program
a language.

"And why bother sweating over a language that nobody uses!?
 At least I know C++, and I can pick up Java relatively easily.
 Knowing Ada and Pascal are almost as useful as knowing outer space
 basket weaving."

Translation:

I'm so incapable of realising that another language may have other
points of view to present, that I'll claim it's useless.


Unbelievable!


Dale

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Xu Yifeng 10/29/97 12:00 AM

John Black wrote:
>
> ADA and Pascal are two of the most useless inventions Man has ever
> wasted space on this planet with.  These languages are hard to learn,
> have zero applications, and people who only know these languages can
> only find jobs at Taco Bell!  Smart programmers spend their time
> learning only C, C++, and Java in that order.

Let Pascal and ADA exist in the world, otherwise, we won't feel C/C++
is better language.

Regards,
Xu Yifeng

ADA SUCKS, C/C++/JAVA RULES!!!! Philip Brashear 10/29/97 12:00 AM

In article <34566fe...@news.mindspring.com>,

John Black <nospam@nospam> wrote:
>You guys say what you want but it's true.  ADA is good for nothing.
>C++, on the other hand, is the only language you need.


Remember the old Persian proverb:

He who knows and knows that he knows is wise -- follow him
He who knows and knows not that he knows is asleep -- waken him
He who knows not and knows that he knows not is a child -- teach him
He whos knows not and knows not that he knows not is a fool -- shun him

Which category does John fall into?

Phil Brashear
(14 years of Ada experience, including teaching it to college freshmen)


Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Steve Ropa 10/29/97 12:00 AM

On 28 Oct 1997, Robert S. White wrote:

>
>   IME Ada has worked out very well for difficult embedded systems
> maintained by a team of software engineers for a significant period
> of time.  Stuff like avionics, spaceborne electronics, munitions and
> other things you don't want to fail.  I've heard that some banks also
> found that reliable and easy to maintain software systems are a plus.
> Check out:  http://www.adahome.com for more answers to this question.
>
>  And again IME it is _not_ hard to teach a new college grad engineer
> (who has never used Ada) how to effectively use Ada in a very short
> time.  With development environments ranging from Rational Apex to
> very nice (but simple) AdaGIDE/GNAT, it is very simple to develope
> Ada code.  
>
>  Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
> code generation.

Personally, I would like to see less emphasis on wizards anyway.  I have
had too many developers tell me they knew what they were doing, but when I
took their wizards away, they were lost!  

Steve


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Mike Copeland 10/29/97 12:00 AM

> Hello everyone, I hate to say it but my sentiments are with Mr. Black to a
> small degree.  My first programming class in college was in ADA and I found
> it very difficult to learn because of the lack of documentation and help
> aids for the language.  

   Well, it seems you missed a fundamental fact: it's "Ada", not "ADA".  
This language, like Pascal (not "PASCAL"), is named for someone (it's a
proper name, not an acronym).  I daresay if you had learned this and a
few other points, you might not be so antagonistic about some of these
things...

> That  forced me to rely on my Professor for help
> which unfortunately was like pulling teeth.  The lack of being able to
> obtain outside sources from my local computer store ie : "ADA for Dummies"
> left me with a feeling of complete frustration while I spent the semester
> copying and reediting code from my fellow struggling classmates in order to
> pass the course.

   You poor thing - you actually had to _learn_ something on its own
merits, by your own work and instructor interaction, and there wasn't a
"Cliff's Notes" to work from.  It's truly a shame how the education
system has fallen in these last 10-20 years...

> However, struggling with ADA did give me an appreciation for the process of
> writing source code, and I have found that the fundamentals that I learned
> with ADA are applicable to me as I learn C++.  <-- By the way this time I am
> writing my own code),

   Did you think that computer programs somehow "wrote themselves" and  
that you _wouldn't_ have to do such things?  Did you sleep through your
high school computer classes, as well?  What did you _expect_???

> >>ADA and Pascal are two of the most useless inventions Man has ever
> >>wasted space on this planet with.  These languages are hard to learn,

   Him, too - what _did_ he expect?...

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Mike Copeland 10/29/97 12:00 AM

   This has almost nothing to do with the "ease of learning" either
language (and I feel C/C++ is much harder to do so than Pascal), but by
some other factors:
  1. The portability issue.  C/C++ are basically portable across
platforms, and this is an extremely important issue to corporate
thinking.  It's more important to the executives/decision makers of most
companies that their key applications can be moved to other vendor's
hardware when financial issues force such switches, than to have
implementation languages which their programmers like and find easy to
learn.
  2. Pascal and Ada (which is often called a highly enriched Pascal)
weren't designed as application development vehicles - whereas C/C++
were.  Pascal was invented as a teaching tool for structured and module
problem solving, to show and overcome the faults of weakly typed and
inherently undisciplined coding languages of the past (e.g. COBOL,
ForTran, BASIC, assembler, etc.).  There was almost no thought given to
I/o, databases, strings, and performance issues with Wirth's Pascal, and
he designed the language to teach the initial concepts of program
correctness, and modular design.  It wasn't until Borland marketed Turbo
Pascal (which they didn't initially write) that Pascal became a real
implementation tool, instead of the "teaching toy" it really was.  
However, Pascal is almost non-existent in the business environment,
regardless of how many hobbiests and PC programmers make effective use of
it....sigh
   Ada, OTOH, was designed for implementation of secure and fail-safe
systems for the Government.  It was based on Pascal concepts (very strong
typing, modularity, consistency, etc.), but was taken much farther than
was useful to the general world.  Learning Ada should be considered an
educational experience, at best, because no one uses it.  And I agree
it's very hard to learn and work with, even coming from a Pascal
background.  Nonetheless, Ada provides some interesting and useful things
for any serious programmer to think about and use in his/her work.
ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 10/29/97 12:00 AM

In article <MPG.ec125666...@news.primenet.com>,

Mike Copeland <mrc...@primenet.com> wrote:
>was useful to the general world.  Learning Ada should be considered an
>educational experience, at best, because no one uses it.  And I agree

That is nonse. Perhaps by ``noone'' you mean ``nobody in Windows land'',
and even after that correctio it is false.

Next door to me, a prominent company is developing an air traffic control
system using Ada in a joint venture with other companies.
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA SUCKS, C/C++/JAVA RULES!!!! CodeRed 10/29/97 12:00 AM

Alan E & Carmel J Brain wrote in message <34581F...@dynamite.com.au>...

>with TEXT_IO;
>procedure MAIN is
>begin
>  TEXT_IO.PUT("Hello World")
>  NEW_LINE(3);
>end;

He also wrote in another group that Ada and Pascal are hard to learn :)
Pascal is perhaps even easier (I know pascal pretty good, and Ada I'm
looking
to get into which is why I'm reading this newsgroup).  But Ada looks pretty
cool.

>is impossibly hard, obsolete and "worse", XOR it's a troll. Given the
>pre-pubescent "X sucks Y rules" header, you're right in either case.

Truth is, I've learned all major languages (and some not major) like:
Super Easy, Basic, Pascal, C, C++, Cobol, and Assembly (for x86).

I've found C and C++ to be very hard to be productive in, and Pascal to be
the
easiest to be productive in.  Truthfully, I liked ASM better then C++, but I
didn't
get into advanced things in either.  I'm definitly interested in adding Ada
to my
list though, so if you could, can you e-mail me a place to download an Ada
compiler for x86's?  (preferably Dos or Win95 because Linux was deleted
for lack of space).

Thank you, my e-mail is gri...@erols.com


Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Phlip C Plumlee 10/29/97 12:00 AM

JT (from Fritz) wrote:

> I code a bit in C and C++ and the more I have to debug other people's
> C/C++
> the more I like Ada.

You might consider your choice of other people...

  --  Phlip


Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!! David A. Frantz 10/29/97 12:00 AM

This sums up my thoughts, there are many C/C++ programs that are a nightmare
to understand from a maintenance stand point.      Even a non ADA programmer
will get a sense for what a ADA program is doing after a quick look at the
code.     A C++ programmer could have his own code in front of him and have
a Maintenance nightmare!

Dave

JT (from Fritz) wrote in message <3457E8B3...@shsu.edu>...


>I code a bit in C and C++ and the more I have to debug other people's C/C++
>the more I like Ada.
>

ADA SUCKS, C/C++/JAVA RULES!!!! Adam Beneschan 10/29/97 12:00 AM

"Dann Corbit" <dco...@solutionsiq.com> writes:
 >John Black wrote in message <34566fe...@news.mindspring.com>...

 >>You guys say what you want but it's true.  ADA is good for nothing.
 >>C++, on the other hand, is the only language you need.
 >Boy, this is just great.  The "C or C++" thread was not good enough.
 >Now that it has passed the previous world record for spam
 >harvesting, we pull Ada and Java into the mix.  Pretty please, down
 >on my knees, I'm begging you to trim comp.lang.c from the header
 >when replying to this post.

Not good enough.  Not *nearly* good enough.  I'm on my knees begging
you all to trim ALL the newsgroups from the header when responding.
In other words, send your responses to /dev/null.  This guy is just
interested in inciting anger, and responding just satisfies his desire
for attention.

                                -- Adam


Wasted words W. Wesley Groleau x4923 10/29/97 12:00 AM

It is written:

  "Never attribute to malice that which can be adequately explained
   by stupidity"

To which I add:

  "Never answer malice which is clearly accompanied by stupidity."

So will you guys please stop answering John Black?  Or at least
change the subject line and change from news to mail.

--
----------------------------------------------------------------------
    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!
----------------------------------------------------------------------

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Nat Pryce 10/29/97 12:00 AM

Shombe Kroll wrote:
>
> Hello everyone, I hate to say it but my sentiments are with Mr. Black to a
> small degree.  

I'm trying to understand your thought processes...

> My first programming class in college was in ADA and I found
> it very difficult to learn because of the lack of documentation and help
> aids for the language.  That  forced me to rely on my Professor for help
> which unfortunately was like pulling teeth.  The lack of being able to
> obtain outside sources from my local computer store ie : "ADA for Dummies"
> left me with a feeling of complete frustration while I spent the semester
> copying and reediting code from my fellow struggling classmates in order to
> pass the course.

Hmm... so Ada is crap because your teacher is not helpful and your
nearest
bookstore has a small selection of books?  Did you ever think of
*ordering*
a good book on Ada?

> However, struggling with ADA did give me an appreciation for the process of
> writing source code, and I have found that the fundamentals that I learned
> with ADA are applicable to me as I learn C++.  <-- By the way this time I am
> writing my own code),

So, you think that C++ is good because you have already learnt the
basics of
programming?

Have you ever considered that *programming* is difficult?  Whether you
learn
in Ada or C++, there is a learning curve to climb.  Once you have
understood
the principles then any language becomes easier to learn.  You might
very well
have learnt the languages the other way round, in which case you would
be
on the opposite side of this flame-fest :-)

--
+------------------------------------------+---------------------+
| Name:   Nat Pryce MEng ACGI              | Dept. of Computing, |
| Email:  n...@doc.ic.ac.uk                 | Imperial College,   |
| Tel:    +44 (0)171 594 8394              | 180 Queen's Gate,   |
| Fax:    +44 (0)171 581 8024              | London SW7 2BZ,     |
| WWW:    http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom      |
+------------------------------------------+---------------------+

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 10/29/97 12:00 AM

In article <345673af...@news.mindspring.com>,

John Black <nospam@nospam> wrote:
>ADA and Pascal are two of the most useless inventions Man has ever
>wasted space on this planet with.  These languages are hard to learn,

Nothing personal, but you must be seriously retarded if you find _Pascal_ hard
to learn. It's a teaching language for programming neophytes!

What's more likely is not that you are retarded, but that you have never tried
learning Pascal or writing a program in it. It's even more likely that you are
too young to remember Pascal.

>have zero applications, and people who only know these languages can

The TeX document processing system was written in Pascal.

Ada is used in all kinds of embedded systems and military applications. I know
at least one huge air traffic control system that is developed in Ada.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Bode 10/29/97 12:00 AM

In article <636m6l$5...@bgtnsc01.worldnet.att.net>, "Shombe Kroll"
<Sho...@worldnet.att.net> wrote:

> Hello everyone, I hate to say it but my sentiments are with Mr. Black to a
> small degree.  My first programming class in college was in ADA and I found
> it very difficult to learn because of the lack of documentation and help
> aids for the language.  

I had the exact same experience, but the language was C.

>                          That  forced me to rely on my Professor for help
> which unfortunately was like pulling teeth.  The lack of being able to
> obtain outside sources from my local computer store ie : "ADA for Dummies"
> left me with a feeling of complete frustration while I spent the semester
> copying and reediting code from my fellow struggling classmates in order to
> pass the course.

I had the exact same experience, but the language was C.

> However, struggling with ADA did give me an appreciation for the process of
> writing source code, and I have found that the fundamentals that I learned
> with ADA are applicable to me as I learn C++.  <-- By the way this time I am
> writing my own code),
>

Having learned C before Ada, I too found Ada overy picky -- at first.
However, after writing several thousand lines of code, I came to appreciate
it.  Yes, Ada has a steeper *initial* learning curve than C.  The tradeoff
comes after several months of practice.  With Ada, the learning curve
tapers off rather quickly, whereas with C or C++, the learning curve is
flatter -- it's easier to get started coding, but it takes a longer time to
become truly *proficient* with the language.

So why isn't Ada in more widespread use?  Ada compilers, being somewhat
larger and more complex than C compilers, are likewise more expensive.  Ada
was never marketed toward business -- it was designed for a specific
problem domain, and some of the more esoteric features were not perceived
to be immediately valuable (unfortunately -- hell, the exception handling
mechanism *alone* could simplify things by orders of magnitude).  The Ada
development environment typically requires more horsepower than the C
development environment -- up until very recently, *serious* Ada
development required workstation-class machines.

But the *biggest* reason C is in such demand?  Inertia.  People started
using C for no other reason than it was available and it was cheap and you
could develop C code on an AT-class machine.  It certainly wasn't for
technical superiority.  Over the past twenty years, a *lot* of code has
been written in C, so you need a lot of developers familiar with C to
maintain it, and since all they know is C, all new development is done in
C, etc., etc., etc.  

Suddenly, along comes C++, and all that C experience gets leveraged into
what appears to be a fully buzzword-compliant OOL that, in reality, falls
short of what an OOL could and should be.  Ada certainly isn't the be-all
and end-all of OOP, but I find it a lot easier to deal with than C++.

--
John Bode
one grumpy code monkey

"Paranoia is just reality on a finer scale" -- Strange Days

To email me directly, remove the 'nospam.' from my address.

Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!! JT (from Fritz) 10/29/97 12:00 AM
ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! nospam_...@sm.luth.se 10/30/97 12:00 AM

John Black <nospam@nospam> wrote:
>ADA and Pascal are two of the most useless inventions Man has ever
>wasted space on this planet with.  These languages are hard to learn,
>have zero applications, and people who only know these languages can
>only find jobs at Taco Bell!  Smart programmers spend their time
>learning only C, C++, and Java in that order.

Are you kidding?!? One of Pascal:s strengths is that the language
ENFORCES sound programming habits. C++, on the other hand, is based
on the philosophy that no programming paradigm is better than another.
C++ perhaps has the advantage of being more important than Pascal in
the industry, but that is changing more and more when people realize
that other languages often make it possible to deliver code faster,
code that has fewer bugs and is easier to maintain and extend.  

I like Java, Pascal and Eiffel.

Just my two cents...

--

Erik Alapaeae
email: NOSPAM_...@sm.luth.se


Ada, Pascal, Eiffel and others Alan Brain 10/30/97 12:00 AM

In which case, may I ask you to spend some of your time having a squizz
at Ada? The Lovelace turorial via http://www.adahome.com for example. I
just wish there was a tutorial this good for Eiffel.

--
Not the Australian Dairy Farmers Association,
   the Australian Defence Force Academy.
aeb...@dynamite.com.au abr...@cs.adfa.oz.au

ADA SUCKS, C/C++/JAVA RULES!!!! Alan Brain 10/30/97 12:00 AM

CodeRed wrote:


>  I'm definitly interested in adding Ada
> to my
> list though, so if you could, can you e-mail me a place to download an Ada
> compiler for x86's?  (preferably Dos or Win95 because Linux was deleted
> for lack of space).

try http://www.adahome.com

This has links to all sorts of useful places (like the Public Ada
Library which contains several free/shareware Ada compilers for DOS).
More to the point for newsgroups other than comp.lang.ada, it's a great
place to get to things like CMM, Mil-Std-498 (the base of IEEE
 standard on Software Life Cycle), Software Metrics et alia. Which are
good no matter what language you use.


 
--
Not the Australian Dairy Farmers Association,
   the Australian Defence Force Academy.
aeb...@dynamite.com.au abr...@cs.adfa.oz.au

Ada, Pascal, Eiffel and others nospam_...@sm.luth.se 10/30/97 12:00 AM

Alan Brain <abr...@cs.adfa.oz.au> wrote:

>at Ada? The Lovelace turorial via http://www.adahome.com for example. I
>just wish there was a tutorial this good for Eiffel.

The old version ao Bertrand Meyers book on OO and Eiffel, I think it is
called "Object-Oriented Software Construction" has a great language-
independent intro on OO, the best I've ever seen!

Greetings

--

Erik Alapaeae
email: NOSPAM_...@sm.luth.se


Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Bob Horvath 10/30/97 12:00 AM

Steve Ropa wrote:

> On 28 Oct 1997, Robert S. White wrote:
>
> >  Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
> > code generation.
>
> Personally, I would like to see less emphasis on wizards anyway.  I have
> had too many developers tell me they knew what they were doing, but when I
> took their wizards away, they were lost!

I have often wondered the same thing.  I head people talk about IDEs and
coming from a vi/make environment, I wonder what I am missing, if anything.
Perhaps these are two different things.

It seems to me that if you know language, you don't need an IDE.  And if you
need an IDE, then you don't know the language.


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Dr E. Buxbaum 10/30/97 12:00 AM

John Black wrote:
>
> ADA and Pascal are two of the most useless inventions Man has ever
> wasted space on this planet with.  These languages are hard to learn,
> have zero applications, and people who only know these languages can
> only find jobs at Taco Bell!  Smart programmers spend their time
> learning only C, C++, and Java in that order.

The Modula-3 FAQ reports an interesting experiment: Students of a
programming class were given an assignment to be completed by a
specified date. They were given the choice of 3 implementation
languages: Modula-3, Borland Pascal and C++. Modula-3 was the recomended
language, and most of the programming novices choose that. All students
which choose C++ had previous knowledge of this language and rated
themselfs as "experienced programmers".

The results were as follows: From the students who choose Modula-3, 4
out of 5 completed their assignment on time. With Borland Pascal, 2 out
of 3 managed to do this. From the students using C++, none did. Even
after been given an extension to complete their project, these students
delivered code of inferior quality compared to those using Modula and
Pascal.

In other words: Novices using Modula produced better code quicker, than
"experienced programmers" using C++!

On the jobs issue, it is certainly true that there are plenty of jobs
for C and C++ programmers. However, there are also lots of jobs for
people using Borland Pascal or Delphi, and if you want to do anything
for the US goverment, than you better know your Ada. Few people would
dare to programm mission critical applications (like nuclear power plant
or weapons system control software) in C, objective C or C++, and I
would not expect Java to turn out any different.

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Larry Kilgallen 10/30/97 12:00 AM

In article <345881C4...@horvath.com>, Bob Horvath <b...@horvath.com> writes:

> It seems to me that if you know language, you don't need an IDE.  And if you
> need an IDE, then you don't know the language.

In my experience IDEs are most helpful not with the language but with
the environment.  Just because I know Ada, that does not mean I know
everything about calling Win32S, or MacApp, or Motif.  If my goal is to
have my Ada program run on multiple platforms, IDEs could be a blessing
in making my otherwise correct software run in these environments.

Unfortunately, the best IDEs are often not oriented toward standardized
languages.  Consider Think Pascal and Delphi, the leading dialects of
Pascal on their respective platforms in their prime, but vastly different
languages.  Visual Basic supports another language without a strong
tradition of adherence to standards.  And even Visual C++ is for a
language whose standard is still in committee.

Larry Kilgallen

Ada, Pascal, Eiffel and others t...@panix.com 10/30/97 12:00 AM

On Thu, 30 Oct 1997 13:34:24 +1100, Alan Brain <abr...@cs.adfa.oz.au>
wrote:

>NOSPAM_...@sm.luth.se wrote:
>>
>> John Black <nospam@nospam> wrote:
>> >ADA and Pascal are two of the most useless inventions Man has ever
>> >wasted space on this planet with.  These languages are hard to learn,
>> >have zero applications, and people who only know these languages can
>> >only find jobs at Taco Bell!  Smart programmers spend their time
>> >learning only C, C++, and Java in that order.
Apparently you havn't tried TMT Pascal.  Check it out on www.tmt.com
Also please not that average debugging time for a Pascal Program is
about 1/4 what it is with C.  This "secret" is known, but apparently
not as well known as it might be.

>>
>> Are you kidding?!? One of Pascal:s strengths is that the language
>> ENFORCES sound programming habits. C++, on the other hand, is based
>> on the philosophy that no programming paradigm is better than another.
>> C++ perhaps has the advantage of being more important than Pascal in
>> the industry, but that is changing more and more when people realize
>> that other languages often make it possible to deliver code faster,
>> code that has fewer bugs and is easier to maintain and extend.
>>
>> I like Java, Pascal and Eiffel.
>
>In which case, may I ask you to spend some of your time having a squizz
>at Ada? The Lovelace turorial via http://www.adahome.com for example. I
>just wish there was a tutorial this good for Eiffel.
>
>--
>Not the Australian Dairy Farmers Association,
>   the Australian Defence Force Academy.
>aeb...@dynamite.com.au abr...@cs.adfa.oz.au


Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Kaz Kylheku 10/30/97 12:00 AM

In article <3458072B...@deltanet.com>,

When you graduate from elementary school, you might realize that that choice
isn't as easy as choosing schooyard friends.

Making that choice might mean quitting your job which pays the bills.

I have to side with JT: C and C++ are languages suited to the lone guru who
perfects code in isolation.  Many programmers who write in these languages are
just code butchers who don't understand the languages. They assume that a long
integer is four bytes long, that incrementing a maximum integer wraps back to
the minimum, that main() can have any old return value, that pointers all have
the same representation and hence void ** is a generic pointer to pointer, that
string literals are modifiable, that arrays are really pointers, a byte is
exactly eight bits, that plain chars are unsigned, that one can check
feof(stream) without first attempting a read operation, and so on ad nauseum.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Yet another stupid language war (was: ... the only languages you need!!) Wes Groleau 10/30/97 12:00 AM

>   1. The portability issue.  C/C++ are basically portable across
> platforms,

Consider the languages you are comparing to (see newsgroups line)
that's a pretty ignorant claim.  Ada is the most portable of the above
languages.  Rarely do I need to change anything in an Ada program
when I change operating systems, CPUs, or compiler vendors.  With
C on the other hand, I recently had to track down the new location
of a .h file because the O.S. vendor decided between versions that
they didn't like the path they chose before.  (Not only that, but they
changed the return value of sprintf, from the string written in, to
the number of chars written.)  Java was intended to be the most portable
of all, but Microsoft is trying hard to prevent that.

>   2. Pascal and Ada (which is often called a highly enriched Pascal)
> weren't designed as application development vehicles - whereas C/C++
> were.

Another untrue claim.  True, Pascal was designed to support teaching,
but Ada was _designed_ to support known-to-be-effective principles for
devloping applications--as you said in your own self-contradiction
following.  C and C++ were partly designed and partly thrown
together to support whatever thing the few people involved thought was
cool at the time.  Many of these "coolnesses" have long been proven
counter-productive.  Many of the ones that have any value were in Ada
long before they were in C or C++.  Many of the bad ones were
intentionally
omitted from Ada and more recently from Java.  (In fairness, note that
he (Mike C.) contradicts the above claim in the following.)

>    Ada, OTOH, was designed for implementation of secure and fail-safe
> systems for the Government.  It was based on Pascal concepts (very strong
> typing, modularity, consistency, etc.), but was taken much farther than
> was useful to the general world.  ....

> ....  Learning Ada should be considered an


> educational experience, at best, because no one uses it.  

No one?  The ignorance is showing again.

--
----------------------------------------------------------------------
    Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA
Senior Software Engineer - AFATDS                  Tool-smith Wanna-be

The Ten Commandments of C:
I. Thou shalt run 'lint' frequently and study its pronouncements
with care, for verily its perception and judgement oft exceed thine.

II. Thou shalt repeatedly and loudly condemn those languages that
behave in a manner like 'lint', for verily they do implement the
plotting of the wicked which desire to take away thy freedom and
thy perception, yea, even thy judgment.
----------------------------------------------------------------------

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Rickard 10/30/97 12:00 AM

John Black <nospam@nospam> wrote:
>ADA and Pascal are two of the most useless inventions Man has ever
>wasted space on this planet with.  These languages are hard to
learn,
>have zero applications, and people who only know these languages can

Apparently you are again one of the infamous stuck up C programmers
who think they are a programming god... well i got a newsflasg for
you... i own Turbo Pascal, Turbo C++ and of course QuickBasic...
i have/am successfully learning QuickBasic and Pascal... the c++ on
the other hand... blah... language is a matter of preference...
I like basic, pascal, and some scripting languages like Visual
DialogScript...
that is my preference... but do you see me in the C newsgroup saying
C and C++ SUCK. Basic, Pascal, and Script are the only languages you
need...
no you dont...
and about the zero applications...
my mother works for Noland co. a rather large HVAC Distributer
company(sells heating/cooling and bath stuff to small companies)
and i would have to inform you that every damn Load and Calculation
program they have(I am guessing(cant remember exact)about 30 programs
i have seen in use and read about) are all written in Pascal or other
Pascal-Like languages... the only thing on there computer even
written in C or C++ is the damn operating system...

oh heheh yeah this to:
Pascal is EASY to learn

Yet another stupid language war (was: ... the only languages you need!!) Peter Seebach 10/30/97 12:00 AM

In article <3458D1...@pseserv3.fw.hac.com>,

W. Wesley Groleau x4923 <wwg...@pseserv3.fw.hac.com> wrote:
>Consider the languages you are comparing to (see newsgroups line)
>that's a pretty ignorant claim.  Ada is the most portable of the above
>languages.

But only to the systems it's available for.  If you talk about code
being portable to all implementations, great, but there are still
systems which have C compilers, but no Ada.

>Rarely do I need to change anything in an Ada program
>when I change operating systems, CPUs, or compiler vendors.  With
>C on the other hand, I recently had to track down the new location
>of a .h file because the O.S. vendor decided between versions that
>they didn't like the path they chose before.  (Not only that, but they
>changed the return value of sprintf, from the string written in, to
>the number of chars written.)

You can't have it both ways.

The C language, and every implementation of C, has had the same definition
of sprintf, and the same locations for all the headers, since 1989.  If
you want to use compilers for similar languaes, and complain about the
portability of C, we get to taunt you about every implementation that's
ever claimed to be similar to Ada, too.

>Java was intended to be the most portable
>of all, but Microsoft is trying hard to prevent that.

Java is intended to produce executables and programs which are portable
across all implementations; this does not necessarily make it a widely
portable language.

>C and C++ were partly designed and partly thrown
>together to support whatever thing the few people involved thought was
>cool at the time.

Speak for C++.  :)  C has a bit of history, but is really fairly
consistent.  :)

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

ADA SUCKS, C/C++/JAVA RULES!!!! John Gluth 10/30/97 12:00 AM

In article <MPG.ec125666...@news.primenet.com> Mike Copeland,

mrc...@primenet.com writes:
>Learning Ada should be considered an
>educational experience, at best, because no one uses it.

Dang...what HAVE I been doing then, these past few years?

You ever fly on the 777?  The flight control system is in Ada.
If you land in Canada, their air traffic control system is (or will
be...not
sure if it's been delivered) in Ada.
We fly missiles with Ada.  Shoot 'em down with Ada, too...

But hey, I've never done an applet for the web in Ada, or anything else
important like that...

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 10/30/97 12:00 AM

In article <3459AC...@dynamite.com.au>,
Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:

>Mike Copeland wrote:
>>
>>    This has almost nothing to do with the "ease of learning" either
>> language (and I feel C/C++ is much harder to do so than Pascal), but by
>> some other factors:
>>   1. The portability issue.  C/C++ are basically portable across
>> platforms, and this is an extremely important issue to corporate
>> thinking.
>
>While I agree with most of your post, I must take issue here. C and C++
>are perceived as being portable. Inasmuch as there are almost no major

No. C is perceived as being portable. Those who perceive C++ as portable
are naive or mistaken.

>computers which don't have a C or C++ compiler, this is true. And that's
>a big, big selling point.

>Now C++ on the other hand, written using CodeWarrior 10 on a Mac, ported
>to CodeWarrior 10 on an IBM... or even MVC++ 4 vs MVC++ 5... or worse
>still CodeWarrior 9 on a Mac to CodeWarrior 10 on a Mac to MVC++ 5 on an
>IBM... In 15,000 LOCs of C++ how many would you reasonably expect to
>have to be changed? (yes, these were actual examples too)  

C++ is not C however. What are your experiences with porting ANSI/ISO C code
from one ISO compiler to another?

C++ is not a standardized language, unlike Ada 83 or Ada 95, so you would
expect to have porting problems with it. C has been standardized for close to a
decade.

Even though it's easy to introduce machine dependencies into C or C++ code, I
would expect that most of your C++ headaches would be related to a lack of
standardization, or the different pace of adaptation of the draft features by
various vendors. (That alone is, to me, reason enough to avoid C++ if I can).

C porting headaches usually stem from legacy ``classic'' C code, in which the
chief difficulty is bugs uncovered when one adds function prototypes.  Then
there are dependencies of implementation characteristics: byte order, size of
various types, and so forth.  Mind you, it's also possible to write Ada
programs with similar dependencies.

Then there are uses of non-portable functions that are not in the standard
library. E.g. it's impossible to port an XWindow application to Microsoft
Windows without rewriting portions of it, but it's not really the fault of the
underlying language.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA SUCKS, C/C++/JAVA RULES!!!! Shmuel (Seymour J.) Metz 10/30/97 12:00 AM

Adam Beneschan wrote:
>
> I once heard of a computer language named TROLL; I have no idea what
> it's like, but I think you should look into it.  I'll bet it's
> something you'd really enjoy programming in.

Why? John sounds like a JOVIAL person, even if he does prefer the
"language that dares not speak its name".

--

                        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 spam...@library.lspace.org

ADA work, C/C++/JAVA crashes!!!! Shmuel (Seymour J.) Metz 10/30/97 12:00 AM

Steve Ropa wrote:

> As you said, it all boils down to the right tool for the right job.  What
> types of jobs are Ada best suited for? I got into development through self
> learning, so I never really had the benefit of experiencing a lot of
> different languages.

One very importnat point is to worry about the efficiency of your
algoriths before you worry about the efficiency of your compilers. I was
once tasked with rewriting a low level graphics routine to improve its
performance. The old, slow, version was in Intel 80286 assembler
language. My new faster version was in Ada.

Could I have made it even faster by doing it in assembler? Absolutely.
Would it have been cost effective to do so? Not bloody likely.

Unfortunately, my Ada experience is limited to Ada 83, which had serious
limitations in character processing and in multithreading. But for most
tasks I'd pick it over C/C++ in a heartbeat.

Where C/C++ has an edge is that there is more likely to be existing
bindings for complex environments, e.g., WinDoze. If I had to interface
with ms software then I would probably hold my nose and use C++.

For an environment where the compiler is affordable, I prefer PL/I.
Also, there are specialized languages like ICON and SETL that do what
they do much better than any of the more common languages. Learn a lot
of different languages and you'll be in a better position to judge such
issues.

--

                        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 spam...@library.lspace.org

Yet another stupid language war (was: ... the only languages you need!!) Al Christians 10/30/97 12:00 AM

> >    Ada, OTOH, was designed for implementation of secure and fail-safe
> > systems for the Government.  It was based on Pascal concepts (very strong
> > typing, modularity, consistency, etc.), but was taken much farther than
> > was useful to the general world.  ....

There has been some (more) bad press about DOD technology lately.
Computerworld recently ran a story about an Army battlefield management
system of some kind that has been under development since 1980 (some
kids who weren't even born when it started might do better) and still
doesn't work real good.  But it's only something like a $760 million
debacle for the taxpayers, which, spread over 17 years, is much less
than we are used to paying.  Of course, it was started before Ada came
down the pipe, but has Ada been used in this project at all?  If so, why
didn't it help?  If not, whynot?  Can anybody explain how the DOD keeps
doing things (for 17 years!) to lower the regard of sensible people
everywhere for the things (like Ada) in which they invest between wars?

Al

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Charles Hixson 10/30/97 12:00 AM

Bob Horvath wrote:

> Steve Ropa wrote:
>
> /* snip */


> I have often wondered the same thing.  I head people talk about IDEs and
> coming from a vi/make environment, I wonder what I am missing, if anything.
> Perhaps these are two different things.
>
> It seems to me that if you know language, you don't need an IDE.  And if you
> need an IDE, then you don't know the language.

 Wizards are excellent tools for doing frequent tasks with lots of details.  One
shouldn't NEED a wizard, but they can sure speed thing up.  They also, if well
done, considerably decrease debugging time.  In a good system the wizard will
generate the code, and surround it with markers.  As long as you don't remove
the markers, the wizard will expect to be able to parse and regenerate the code
freely (in case you edit the "screen image").  Once you decide to get into the
details, you just remove the markers, and then you can edit the code as
desired.  This can be LOTS faster than creating everything from scratch, and IF
the purpose is to design a visual image, then a visual design editor definitely
the best way to go.
--
Charles Hixson charle...@earthling.net
(510) 464-7733 or chi...@mtc.dst.ca.us

ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! Shmuel (Seymour J.) Metz 10/30/97 12:00 AM

Mike Copeland wrote:

>   1. The portability issue.  C/C++ are basically portable across
> platforms,

NOT! You are confusing portability of the compiler for the language with
portability of applications written in the language. C is full of things
that are implimentation defined, e.g., "long", whereas Ada lets you
easily define precision in a platform-independent fashion. And, yes, I
know that you can mask those deficiencies of C by using the
preprocessor, but that just adds another layer of complexity that isn't
needed in Ada.

>   2. Pascal and Ada (which is often called a highly enriched Pascal)
> weren't designed as application development vehicles - whereas C/C++
> were.

Wrong on both counts. Ada was designed for applications development, and
C was designed to be easily compilable on a small machine.

> Pascal was invented as a teaching tool for structured and module
> problem solving, to show and overcome the faults of weakly typed and
> inherently undisciplined coding languages of the past (e.g. COBOL,
> ForTran, BASIC, assembler, etc.).  

Actually, ALGOL 60 had already done that.

>  Ada, OTOH, was designed for implementation of secure and fail-safe
> systems for the Government.  It was based on Pascal concepts (very strong
> typing, modularity, consistency, etc.), but was taken much farther than
> was useful to the general world.  Learning Ada should be considered an

> educational experience, at best, because no one uses it.

Correct, no one but business, education and government uses it. This
news group wouldn't exist if no one used Ada, nor would publishers
bother with books about it.

> And I agree it's very hard to learn and work with, even coming from a
> Pascal background.

Really? I found Ada to be a snap to learn; perhaps Ada 95 is more
difficult? I certainly found Ada 83 to be far more natural than C ;-)

--

                        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 spam...@library.lspace.org

Yet another stupid language war (was: ... the only languages you need!!) John Rickard 10/30/97 12:00 AM

can you guys take these idiotic flames to alt.flame...
i am here to learn/help/etc.. and it is damn near impossible with all
of this bickering...
--
--
Remove .DONTSPAMME from my
email address to send me REAL email.
--

Al Christians <ach...@easystreet.com> wrote in article
<345904...@easystreet.com>...
: > >    Ada, OTOH, was designed for implementation of secure and:

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Kaz Kylheku 10/30/97 12:00 AM

In article <1997Oct30.094442.1@eisner>,

Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
>In article <345881C4...@horvath.com>, Bob Horvath <b...@horvath.com> writes:
>
>> It seems to me that if you know language, you don't need an IDE.  And if you
>> need an IDE, then you don't know the language.
>
>In my experience IDEs are most helpful not with the language but with
>the environment.  Just because I know Ada, that does not mean I know
>everything about calling Win32S, or MacApp, or Motif.  If my goal is to

That's what reference manuals are for, no?

>have my Ada program run on multiple platforms, IDEs could be a blessing
>in making my otherwise correct software run in these environments.

How would an IDE in one environment help your program work on another platform?
It seems like an IDE would just induce you to make your program specific to one
platform, particularly if it has ``easy'' procedures for adding extensions
to your program or for generating UI code for you, and such.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Jon S Anthony 10/30/97 12:00 AM

nospam@nospam (John Black) writes:

>
> Then why do the want ads for C, C++ programmers could stretch from
> here to the moon, while Ada/Pascal programmers are nonexistent?  Like
> I said, if you program in Ada or Pascal, your best job is going to be
> taking orders at Red Lobster.

I have this overwhelming impression that you either are or soon will
be taking orders at Red Lobster or flippin' burgers at MuckDucks...
Certainly no one in their right mind would even consider hiring
someone like you for anything approaching an swe job or even a lowly
programmer job.

/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

ADA SUCKS, C/C++/JAVA RULES!!!! Jon S Anthony 10/30/97 12:00 AM

nospam@nospam (John Black) writes:

> You guys say what you want but it's true.  ADA is good for nothing.
> C++, on the other hand, is the only language you need.

Any particular reason why anyone should give one rat's ass for your
opinion?  Any reason why you "think" the whole world should be
subjected to your overly cross posted and empty opinion?

Maybe the thread title should be "Megalomaniacal idiots (such as John
Black) SUCK, Intelligent people with some discretion RULE."

/Jon

>
> You guys say what you want but it's true.  ADA is good for nothing.
> C++, on the other hand, is the only language you need.

--
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

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 10/30/97 12:00 AM

In article <Pine.SUN.3.96.971030093508.12308F-100000@flatland.dimensional.com>,
Steve Ropa  <ther...@dimensional.com> wrote:
>As far as daring to use C or C++ for mission critical systems, I would
>point out that the majority of the telecommunications systems in the world
>are running on top of Unix, which as we all know is written in C.  I
>myself(along with a half dozen other team members) have written several
>long distance Network Management systems in C++.  My team is about to
>start on a Satellite communications system in C++.  Oddly, it is replacing
>a system written in Ada.  This is not to put down Ada, as I feel every
>language has its place.  Just don't rule out the stability and reliability
>of C or C++.

A failure in a network management system doesn't actually amount to a real
catastrophy. It just means that you are perhaps not getting timely visibility
of some operational measurements or alarms, or an interruption in your ability
to control network elements. Only if such a condition is prolonged can it lead
to a failure to diagnose and possibly correct some fault in the network, such
as congestion due to to out of service units.

Telecommunication management software is large and complex, but not safety
critical, and quasi-real-time at best. Shut-down software for a nuclear reactor
may be less complex, but requires much more verification.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA SUCKS, C/C++/JAVA RULES!!!! Ed Muldoon 10/30/97 12:00 AM

You have been much too hard on John Black.  He is performing a valuable
service for all of us.  One John_Black_type (and he is a generic type,
although I'm sure he's uncomfortable about it) can easily provide
employment for two other people as they clean up the messes he leaves
behind.  This increases the demand for our services and drives up our
incomes.  In the end, we all owe a lot to the John_Black_type.

WARNING: Too many instantiations of the John_Black_type in a company can
lead to serious financial difficulties for that company.

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Bob Horvath 10/30/97 12:00 AM


David A. Frantz wrote:

> Bob Horvath wrote in message <345881C4...@horvath.com>...


> >Steve Ropa wrote:
> >
> >> On 28 Oct 1997, Robert S. White wrote:
> >>
> >> >  Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
> >> > code generation.
> >>
> >> Personally, I would like to see less emphasis on wizards anyway.  I have
> >> had too many developers tell me they knew what they were doing, but when
> I
> >> took their wizards away, they were lost!
> >
> >I have often wondered the same thing.  I head people talk about IDEs and
> >coming from a vi/make environment, I wonder what I am missing, if anything.
> >Perhaps these are two different things.
> >
> >It seems to me that if you know language, you don't need an IDE.  And if
> you
> >need an IDE, then you don't know the language.
> >
>
> An IDE in my opinion has nothing to do with knowing the language.     An IDE
> if successful should make the programmer more productive!     Can't really
> see the relationship of the user interface, wether a make/command line
> environment or a fancy IDE, to knowing the lanquage.

How do they make you more productive?  I've never used one.  I have seen CASE
tools years ago that I thought were very unproductive.  Perhaps I don't know
what I am missing, but I can't imagine anything really helping out, except for
something that might make building GUIs a little easier, but for the guts of an
application, what do they buy you?


Yet another stupid language war (was: ... the only languages you need!!) Bob Horvath 10/30/97 12:00 AM

Peter Seebach wrote:

> In article <3458D1...@pseserv3.fw.hac.com>,
> W. Wesley Groleau x4923 <wwg...@pseserv3.fw.hac.com> wrote:
> >Consider the languages you are comparing to (see newsgroups line)
> >that's a pretty ignorant claim.  Ada is the most portable of the above
> >languages.
>
> But only to the systems it's available for.  If you talk about code
> being portable to all implementations, great, but there are still
> systems which have C compilers, but no Ada.

I have heard of an Ada to Java bytecode compiler, so now I guess you can have
Ada everywhere!

> Java is intended to produce executables and programs which are portable
> across all implementations; this does not necessarily make it a widely
> portable language.

I don't understand this statement.

> >C and C++ were partly designed and partly thrown
> >together to support whatever thing the few people involved thought was
> >cool at the time.
>
> Speak for C++.  :)  C has a bit of history, but is really fairly
> consistent.  :)

Hmmmm.  How big is an int?


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Scott Baierl 10/30/97 12:00 AM

Xu Yifeng wrote in message <3456A3...@public.hz.zj.cn>...


>John Black wrote:
>>
>> ADA and Pascal are two of the most useless inventions Man has ever
>> wasted space on this planet with.  These languages are hard to learn,
>> have zero applications, and people who only know these languages can
>> only find jobs at Taco Bell!  Smart programmers spend their time
>> learning only C, C++, and Java in that order.
>
>Let Pascal and ADA exist in the world, otherwise, we won't feel C/C++
>is better language.
>
>Regards,
>Xu Yifeng

Smart programmers spend their time learning programming languages that help
them solve the real-world problems in their particular application domain.

I know Pascal, C, C++, COBOL, Fortran, Java, Basic and several variants of
Assembler.  None of them is difficult to learn.  Each language has its
strong and weak points.  I happen to think that C++ is probably the most
versatile language of the bunch, which is why I use it more than the others.
Making statements as to the relative utility of langauges is a waste of
time.  Passing judgement about the intelligence of the users of such
languages is contemptible.

I don't think we need any more biggots.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Corey Barcus 10/30/97 12:00 AM


John Black wrote:

> ADA and Pascal are two of the most useless inventions Man has ever
> wasted space on this planet with.  These languages are hard to learn,
> have zero applications, and people who only know these languages can
> only find jobs at Taco Bell!  Smart programmers spend their time
> learning only C, C++, and Java in that order.

This is total hyperbole. Ada is used heavily in the US DoD, probably many
other places. Pascal has its current incarnation in a product called
Delphi (from Borland of course) that is a very good tool for building
Windows applications.

Why not dispense with this ignorant and inflamatory position? Instead ask
others if Ada is indeed difficult to learn as you suspect (coming from a
C/C++/Java background I found it somewhat confusing), where it's used,
where's Pascal used, etc. I'm sure advocates of these other languages
would be more than happy to give you answers.

It may very well be that C/C++/Java is best suited for what you endeavor
to do. It would be well to know that there are many ways to program and
some languages are much better suited to particular problems. There are
reasons why languages like Forth, ML, Prolog, Smalltalk, Lisp, etc exist.
If you want to learn something, it's better to try and formulate a
question.

--
Corey Barcus
Simpler Software
co...@simplersw.com

ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/30/97 12:00 AM

Sorry about the multiple posts there.  Minor malfunction with either my news
reader, or the companies news server (it went down soon after).

--
with Std_Disclaimer;  use Std_Disclaimer;
Signature.Put (Name => Ken Sodemann,
    E_Mail => kwso...@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);


ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/30/97 12:00 AM

Steve Ropa wrote ...
>
>I hate to keep a thread going that started with such an inane comment(see
>subject) but *your* points were very well articulated, and lead me to a
>question.

>As you said, it all boils down to the right tool for the right job.  What
>types of jobs are Ada best suited for?

Personally, all of the Ada based projects that I have worked on have been
real-time embedded avionics systems.  Ada is a very good language for use in
these projects since these type of projects tend to be:

o  Large scale -- many LOC, and many engineers
o  Mission (or in this case, life) critical
o  Maintained over several years.

Ada also allows low level access to the hardware, and produces efficient
object code, both of which are essential to those types of programs.

Having used two different Ada tools for Windows application development
(ObjectAda is one, the other is a soon to be released tool from a different
company), I would say that Ada would be a good fit for large scale
applications development also.  However, the tools are not quite "up to par"
with a product like VC++ yet, and it would be harder to find developers, so
for small to medium sized Windows development projects, VC++ or VB is
probably a better choice (IMHO).

 --
with Std_Disclaimer;  use Std_Disclaimer;
Signature.Put (Name => Ken Sodemann,
    E_Mail => kwso...@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Marin David Condic, 561.796.8997, M/S 731-96 10/30/97 12:00 AM

Mike Copeland <mrc...@PRIMENET.COM> writes:
>  1. The portability issue.  C/C++ are basically portable across
>platforms, and this is an extremely important issue to corporate
>thinking.  It's more important to the executives/decision makers of most
>companies that their key applications can be moved to other vendor's
>hardware when financial issues force such switches, than to have
>implementation languages which their programmers like and find easy to
>learn.
    This seems to be misinformation. C was originally invented as a
    systems programming language and for years had no standard at all.
    Implementations varied quite a bit and many of the things that
    were legal to do (and frequently done) were notoriously
    non-portable. From practical experience in porting C programs
    (albeit, not in the last couple of years) I can attest to the fact
    that it is far more work than porting an equivalent Ada program.
    If anybody considers C (and by extension C++) to be "portable"
    then they ought to be extremely impressed with Ada since it is
    much more rigorous in its language definition and designed with
    portability as one of its major objectives.

>  2. Pascal and Ada (which is often called a highly enriched Pascal)
>weren't designed as application development vehicles - whereas C/C++
>were.  Pascal was invented as a teaching tool for structured and module
<snip>
    As stated above. C was developed as a systems programming language
    which has dramatically different requirements from an applications
    programming language. Arguably, C++ might have been oriented more
    towards applications, but it's roots in C means its dragging along
    many characteristics aimed at systems programming.

>   Ada, OTOH, was designed for implementation of secure and fail-safe
>systems for the Government.  It was based on Pascal concepts (very strong
>typing, modularity, consistency, etc.), but was taken much farther than
>was useful to the general world.  Learning Ada should be considered an
>educational experience, at best, because no one uses it.  And I agree

>it's very hard to learn and work with, even coming from a Pascal
>background.  Nonetheless, Ada provides some interesting and useful things
>for any serious programmer to think about and use in his/her work.
>
    I'd beg to differ on the "no one uses it" part of this statement.
    While it seems obvious that other languages may be more widely
    used than Ada, it is not as if there is no Ada programming going
    on in the real world. It is a non-trivial market and I don't
    expect it will disappear any time soon.

    Hard to learn? Sure - there's features in the language that deal
    with difficult concepts, such as multitasking/concurrency,
    numerical analysis, et cetera. When you deal with difficult
    concepts, you're going to find it difficult to learn. But I teach
    an "Intro to Ada" in-house course aimed at engineers with a
    familarity with other languages and it's not hard at all getting
    them up to speed with a Pascal-like subset of the features.

    The only area that gets difficult is teaching the use of the
    generic I/O packages. (Forces you to discuss generic instantiation
    early on and this always seems to be a difficult concept to get
    across until some experience with the language is gained.) Text_IO
    can be turgid, but by sticking to Put_Line and 'Image (EVERYTHING
    ought to have a 'Image attribute!!!) you can get folks rolling on
    basic terminal I/O without any more complication than trying to
    teach the "printf" calls (and all its variants) in C.

    The thing that bothers me about the "Hard To Learn" falacy is that
    when you dig into it a little you tend to discover that it is a
    variation of "It's not what I already know, so it's 'Hard To
    Learn'" or "I'm used to a language that has no advanced features
    so I find it 'Hard To Learn' a language that does." You can learn
    the Pascal-like subset of Ada with no more difficulty than you
    would experience learning Pascal - and all learning requires
    effort and therefore, by definition is not going to be easy. (If
    it were easy, everybody would do it.) When you've mastered the
    Pascal-like subset, you can gradually add on features just like
    you learned the more advanced, arcane, dark features of C. And no
    language design is *ever* going to make concepts like concurrency
    "simple" so you're going to have to bite the bullet and learn the
    theory behind the advanced features before the features themselves
    are going to make sense.

    Language wars are futile, like most wars are, so we shouldn't
    ought to start one. I don't mean to give the impression that
    there's something wrong with preferring one language over another.
    There's nothing wrong with saying "This is the language I know and
    am comfortable with, so that's what I use to get my job done." But
    in criticizing a language, there needs to be some emphasis on
    avoiding vague generalities or subjective judgments.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  COND...@PWFL.COM
===============================================================================
    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."
        --  G.K. Chesterton
===============================================================================

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 10/30/97 12:00 AM

In article <jfbode-ya023380002910972057140001@news.earthlink.net>,
John Bode <jfb...@nospam.mail.earthlink.net> wrote:
>Having learned C before Ada, I too found Ada overy picky -- at first.
>However, after writing several thousand lines of code, I came to appreciate
>it.  Yes, Ada has a steeper *initial* learning curve than C.  The tradeoff
>comes after several months of practice.  With Ada, the learning curve
>tapers off rather quickly, whereas with C or C++, the learning curve is
>flatter -- it's easier to get started coding, but it takes a longer time to
>become truly *proficient* with the language.

Is suspect that the difference has partly to do with the level of diagnosis.  A
beginner in C or C++ is lulled into a sense that he or she is writing a correct
program just because the compiler accepts it.

But to actually become a student of C or C++ and learn the languages _properly_
takes a great deal of effort.

I can't say that I know ISO 9899:1990 C one hundred percent, even though I read
random sections of the standard practically on a daily basis.

>So why isn't Ada in more widespread use?  Ada compilers, being somewhat
>larger and more complex than C compilers, are likewise more expensive.  Ada

GNAT is 16 megabytes of Ada source code, I believe. :) Which probably
translates to roughly 5 or 6 megs of C due to the extra verbiage. :)

>was never marketed toward business -- it was designed for a specific
>problem domain, and some of the more esoteric features were not perceived
>to be immediately valuable (unfortunately -- hell, the exception handling
>mechanism *alone* could simplify things by orders of magnitude).  The Ada
>development environment typically requires more horsepower than the C
>development environment -- up until very recently, *serious* Ada
>development required workstation-class machines.
>
>But the *biggest* reason C is in such demand?  Inertia.  People started
>using C for no other reason than it was available and it was cheap and you
>could develop C code on an AT-class machine.  It certainly wasn't for

Or XT, even. :) Also, don't forget that even eight bit micros had C compilers
running on them. I didn't use C on an eight bit machine, but I did dare run
Borland's Turbo Pascal 3.0 on a Z80-based CP/M machine with 48K ram. :) The
compiler and executed code performed quite adequately, and with overlays it was
possible to run large programs. Real work was done in assembly language, of
course.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Steve Ropa 10/30/97 12:00 AM

On Thu, 30 Oct 1997, Bob Horvath wrote:

> Steve Ropa wrote:
>
> > On 28 Oct 1997, Robert S. White wrote:
> >
> > >  Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
> > > code generation.
> >
> > Personally, I would like to see less emphasis on wizards anyway.  I have
> > had too many developers tell me they knew what they were doing, but when I
> > took their wizards away, they were lost!
>
> I have often wondered the same thing.  I head people talk about IDEs and
> coming from a vi/make environment, I wonder what I am missing, if anything.
> Perhaps these are two different things.
>
> It seems to me that if you know language, you don't need an IDE.  And if you
> need an IDE, then you don't know the language.
>
Well, I come from an IDE environment, and I do like some of the tools they
give you, but only as tools, not solutions(drives some of my programmers
nuts!)  In my opinion, the only value of the wizards is to save some
typing.  Even that can be fraught with danger, though.

What are you missing in IDEs?  Some tools that make it easier to edit your
code.  Although I know some people who can edit faster in vi than in any
IDE.  I actually had one programmer buy a vi emulator for VC++ to increase
his productivity.  Most IDEs also have a convenient way to organize and
access your files.  In other words, if you are happy with vi and make,
you aren't missing a thing!  i wouldn't say if you need an IDE you don't
know the language.  I would say if you need a Wizard you don't know the
language.


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Steve Ropa 10/30/97 12:00 AM

On Thu, 30 Oct 1997, Dr E. Buxbaum wrote:

> The Modula-3 FAQ reports an interesting experiment: Students of a
> programming class were given an assignment to be completed by a
> specified date. They were given the choice of 3 implementation
> languages: Modula-3, Borland Pascal and C++. Modula-3 was the recomended
> language, and most of the programming novices choose that. All students
> which choose C++ had previous knowledge of this language and rated
> themselfs as "experienced programmers".
>
> The results were as follows: From the students who choose Modula-3, 4
> out of 5 completed their assignment on time. With Borland Pascal, 2 out
> of 3 managed to do this. From the students using C++, none did. Even
> after been given an extension to complete their project, these students
> delivered code of inferior quality compared to those using Modula and
> Pascal.
>
> In other words: Novices using Modula produced better code quicker, than
> "experienced programmers" using C++!
>
> On the jobs issue, it is certainly true that there are plenty of jobs
> for C and C++ programmers. However, there are also lots of jobs for
> people using Borland Pascal or Delphi, and if you want to do anything
> for the US goverment, than you better know your Ada. Few people would
> dare to programm mission critical applications (like nuclear power plant
> or weapons system control software) in C, objective C or C++, and I
> would not expect Java to turn out any different.

Your example is fascinating.  I wonder, though how "experienced" those C++
programmers were.  Many people seem to think that just because they can
run a couple of wizards, they are C++ programmers.  The end result is that
they don't learn the language, and are incapable of producing a high
quality product, on time or otherwise.

As far as daring to use C or C++ for mission critical systems, I would
point out that the majority of the telecommunications systems in the world
are running on top of Unix, which as we all know is written in C.  I
myself(along with a half dozen other team members) have written several
long distance Network Management systems in C++.  My team is about to
start on a Satellite communications system in C++.  Oddly, it is replacing
a system written in Ada.  This is not to put down Ada, as I feel every
language has its place.  Just don't rule out the stability and reliability
of C or C++.

Steve


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Jon S Anthony 10/30/97 12:00 AM

Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:

> C and C++ compilers differ by so much that porting is often a Nightmare.
> Before I get flamed, I'd like to talk to people who've actually ported
> code cross-platform.

That's about right.  Porting anything of substance written in C even
between compilers on the _same_ platform is depressing.  FOE here...

> In my own, albeit limited experience, the problems I've had with any
> C or C++ port are greater than all the problems I've had with Ada
> crossplatform put together!

That rings true as well.  Typically porting Ada code between platforms
or compilers amounts to a recompilation.

/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

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Derek A Benner 10/30/97 12:00 AM

Bob Horvath wrote:
>
>
> I have often wondered the same thing.  I head people talk about IDEs
> and
> coming from a vi/make environment, I wonder what I am missing, if
> anything.
> Perhaps these are two different things.
>

In some ways, yes.

> It seems to me that if you know language, you don't need an IDE.  And
> if you
> need an IDE, then you don't know the language.

Not true.  Some IDEs are more of the wizards approach, but produce very
little in the way of real code.  These do indeed form a crutch for the
programmer as they are usually present in a development environment
where the underlying toolset is still too complex (Just like MFC! <G>)

In other environments, the IDE enhances the productivity of the
programmer by merely creating the shell code for oft-repeated visual
components while allowing the programmer to concentrate on writing the
actual business rules code.  (This is the approach taken by Delphi and
C++ Builder and Power++)  In such languages, the initial toolset is rich
enough to provide a clean and relatively high-level interface to the
underlying OS API so that the programmer doesn't have to fight the
forest-for-the-trees syndrome that comes with, say, MFC programming.
Thus the programmer finds the IDE actually enhances productivity without
dumbing down the potential of the development language.

Derek

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Alan E & Carmel J Brain 10/31/97 12:00 AM

Mike Copeland wrote:
>
>    This has almost nothing to do with the "ease of learning" either
> language (and I feel C/C++ is much harder to do so than Pascal), but by
> some other factors:
>   1. The portability issue.  C/C++ are basically portable across
> platforms, and this is an extremely important issue to corporate
> thinking.

While I agree with most of your post, I must take issue here. C and C++


are perceived as being portable. Inasmuch as there are almost no major
computers which don't have a C or C++ compiler, this is true. And that's
a big, big selling point.

However....

C and C++ compilers differ by so much that porting is often a Nightmare.
Before I get flamed, I'd like to talk to people who've actually ported
code cross-platform. In my own, albeit limited experience, the problems

I've had with any C or C++ port are greater than all the problems I've
had with Ada crossplatform put together! If you have an Ada compiler by
brand A on target X, the same code has a high probability of being
correct out-of-the-box by brand B on target X, and will often work with
brand C on target Y.

Example: 15,000 LOCs originally written on an IBM-386 using Thomson (now
Aonix) Ada-83, ported to a microVax running an Irvine compiler in
Australia for checking, then transmitted to Germany to run on a microVax
using DecAda, and finally using the Winterstein Compiler onto a KAV-30
embedded system.
3 lines of code had to be changed (in Australia). Due to bugs.
Yes, this is an actual example, of a Knowledge-based real-time
subsytem's components.

Now C++ on the other hand, written using CodeWarrior 10 on a Mac, ported
to CodeWarrior 10 on an IBM... or even MVC++ 4 vs MVC++ 5... or worse
still CodeWarrior 9 on a Mac to CodeWarrior 10 on a Mac to MVC++ 5 on an
IBM... In 15,000 LOCs of C++ how many would you reasonably expect to
have to be changed? (yes, these were actual examples too)  

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

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Robert S. White 10/31/97 12:00 AM

In article <345881C4...@horvath.com>, b...@horvath.com says...

>
>Steve Ropa wrote:
>
>> On 28 Oct 1997, Robert S. White wrote:
>>
>> >  Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
>> > code generation.
>>
>> Personally, I would like to see less emphasis on wizards anyway.  I have
>> had too many developers tell me they knew what they were doing, but when I
>> took their wizards away, they were lost!
>
>I have often wondered the same thing.  I head people talk about IDEs and
>coming from a vi/make environment, I wonder what I am missing, if anything.
>Perhaps these are two different things.
>
>It seems to me that if you know language, you don't need an IDE.  And if you
>need an IDE, then you don't know the language.

   Exactly!  You can only occasionally use the language yet have
excellant help immediately at your fingertips (a Gates'ism I know)
and have it very easy in pointing out your errors - fixing them and
then moving on to the next error.  When you use ctags with EMACS or
Rational Apex or Visual C it is very very easy to browse the source
code and quickly understand the calling requirments and who needs
what.  I think I even heard of VI users hooking up ctags to browse
source :)

  Of course us _REAL_ programmers don't need no stinkin' IDE  :-) :-)
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Craig Franck 10/31/97 12:00 AM

Jon S Anthony <j...@synquiry.com> wrote:
>Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:
>
>> C and C++ compilers differ by so much that porting is often a Nightmare.
>> Before I get flamed, I'd like to talk to people who've actually ported
>> code cross-platform.
>
>That's about right.  Porting anything of substance written in C even
>between compilers on the _same_ platform is depressing.  FOE here...

Sounds like you may have been a victim of the run of your patients.
Well written C code is very portable. I've seen compiler upgrades
break code, but only because it was trash to begin with.

>> In my own, albeit limited experience, the problems I've had with any
>> C or C++ port are greater than all the problems I've had with Ada
>> crossplatform put together!
>
>That rings true as well.  Typically porting Ada code between platforms
>or compilers amounts to a recompilation.

Something like a Windows to Mac port? How platform specific was the
code? A recompilation port would be the ideal we all chase after. If
you have such great splatfrom tools, you should feel lucky.

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


Yet another stupid language war (was: ... the only languages you need!!) Jerry Sams 10/31/97 12:00 AM

In article <01bce587$2efe61a0$8691440c@worldnet>,
saskan@worldnet.att.net.DONTSPAMME says...

>
>can you guys take these idiotic flames to alt.flame...
>i am here to learn/help/etc.. and it is damn near impossible with all
>of this bickering...


This is an advocacy group, my friend.

Jerry


Yet another stupid language war (was: ... the only languages you need!!) Timo Salmi 10/31/97 12:00 AM

/ADA and Pascal SUCK/j
/Yet another stupid/j
/^Newsgroups: .*,.*,.*,.*,.*,.*,.*,/h:=:j

-From: ftp://garbo.uwasa.fi/pc/pd2/tspost17.zip information file
-Subject: Re: A kill file example

[Q: How to avoid on the Usent news hostile or boring posters,
incessant bickering and net abuse.]

Consider using KILL files. Here is information that just might be of
some interest.

--------------- clip clip clipety clip clip clip ----------------
# This is an example rn kill file ~/News/rec/humor/KILL
# By prof. Timo Salmi, Mon 3-Jun-96
#
# It discards unread all postings from me in news:rec.humor
# Easy to adapt to other newsgroups or other posters!
#
# ts@ is the first part of my email address.
# The modifier h means look through the headers of the articles.
# The command j means junk.
# The command = shows the subjects of the messages being discarded.
# The : is a command separator.
#
/^From: ts@/h:=:j
#
# Or to make it more specific
# /^From: ts@uwasa.fi/h:=:j
#
# Let's not stop here, but also discard all articles that have any
# reference to me anywhere in the message. Of course this might lead
# to an overkill (eg Timothy would be a trigger). A better choice
# of keys might be necessary / useful in actual practice.
#
/timo/a:=:j
/salmi/a:=:j
#
# After you have seen that your customization works, you might wish
# to leave out the subject lister := like this
# /salmi/a:j
#
# A tip adapted from the news:news.admin.net-abuse.misc FAQ
# If you wish to kill excessively crossposted articles, use e.g.
# /^Newsgroups: .*,.*,.*,.*,.*,.*,.*,/h:=:j
# This marks as killed articles crossposted to more than 7 newsgroups.
#
# For more information on kill files plese see e.g.
#  7280 Oct 21 1995 ftp://garbo.uwasa.fi/pc/doc-net/killfile.zip
#  killfile.zip rn newsreader KILL file FAQ from Leanne Phillips
#
---------------------- clip clip clip -----------------------------


Another useful system to know against abuse are the email filters.
They enable you to sort the incoming email and to avoid email you
don't want to have. If you are an elm user, try
  man filter
and
  which filter
to ascertain whether your system has a filter program.  If it does,
put a line like this into your ~/.forward file
  "| /usr/local/bin/filter -o ${HOME}/.elm/filter.errors"

Then create a ~/.elm/filter-rules file. If you wish to avoid, say,
my email, put the following line into it
  if (from = "t...@uwasa.fi") then delete
or more benevolently
  if (from = "listserv@") then save /your/full/path/MailFromListserv

Note that you should not put empty lines into the said files, but
you can make it more readable since comments are allowed. It you put
# (the hash) as the first character on the row, it will be deemed a
comment.

As you see my signature ends with this notification:
>Spam foiling in effect.  My email filter autoresponder will return a
>required email password to users not yet in the privileges database.

I am frequently asked by the similarly spam-targeted fellow users
about my spam foiling password method (on Unix). Since I cannot
answer these questions individually, I have made the information
available via WWW. You'll find it through my home page (see my
signature) by clicking the "no-spam" thumbnail image.

   All the best, Timo

....................................................................
Prof. Timo Salmi   Co-moderator of news:comp.archives.msdos.announce
Moderating at ftp:// & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance  ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/>  ; FIN-65101,  Finland

Spam foiling in effect.  My email filter autoresponder will return a
required email password to users not yet in the privileges database.

Yet another stupid language war (was: ... the only languages you need!!) Ole-Hjalmar Kristensen FOU.TD/DELAB 10/31/97 12:00 AM

Bob Horvath <b...@horvath.com> writes:

On most platforms, exactly as big as an integer in Ada. None of those
languages guarantee the exact size of their (predefined) integers. :-)

Ole-Hj. Kristensen

Yet another stupid language war (was: ... the only languages you need!!) Bob Horvath 10/31/97 12:00 AM


Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> Bob Horvath <b...@horvath.com> writes:
>
> > Peter Seebach wrote:
> >
> > > Speak for C++.  :)  C has a bit of history, but is really fairly
> > > consistent.  :)
> >
> > Hmmmm.  How big is an int?
>
> On most platforms, exactly as big as an integer in Ada. None of those
> languages guarantee the exact size of their (predefined) integers. :-)

The parenthetical and the emoticon are keys here.  Only the predefined INTEGER type
in Ada is implementation dependant.  You can define integer types based on ranges
and are guaranteed consistent results across compilers.  This is unlike int in C
which can be of many sizes, or Java where the size of an int is defined by the
language.

I had forgotten about the implementation dependencies with the INTEGER type in Ada
because you would be a fool to use it when you can so easily create an integer type
using a range constraint.


Porting (was ADA and Pascal etc) Ole-Hjalmar Kristensen FOU.TD/DELAB 10/31/97 12:00 AM

Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:

> Craig Franck wrote:
> >
> > Jon S Anthony <j...@synquiry.com> wrote:
> > >Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:
> > >
> > >> C and C++ compilers differ by so much that porting is often a Nightmare.
> > >> Before I get flamed, I'd like to talk to people who've actually ported
> > >> code cross-platform.
> > >
> > >That's about right.  Porting anything of substance written in C even
> > >between compilers on the _same_ platform is depressing.  FOE here...
> >
> > Sounds like you may have been a victim of the run of your patients.
> > Well written C code is very portable. I've seen compiler upgrades
> > break code, but only because it was trash to begin with.
>
> May I respectfully offer a counterexample?
> Code Warrior accepts
>
> void Main()
> {
>   for (int i ; i < SomeValue ; i++ )
>   {
>   // Do something
>   }
>
>   for (int i ; i < SomeOtherValue ; i++ )
>   {
>   // Do something else
>   }
> }
>
> As by one reading of the (yet-to-be-standardised C++ spec) the scope of
> each
> i is limited to reside within the parens {} of each loop.
>
> Yet MVC++ 5 barfs: as the scope of i is deemed to be within the main
> program, so the two int i declarations clash.
>
> I do not consider the above code to be "trash". If you do, please
> elucidate as to why (heck, I could be wrong, have been before, will be
> again)

Note that he says C code, not C++.

<stuff deleted>


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

Yet another stupid language war (was: ... the only languages you need!!) Dr E. Buxbaum 10/31/97 12:00 AM

Peter Seebach wrote:

> If
> you want to use compilers for similar languaes, and complain about the
> portability of C, we get to taunt you about every implementation that's
> ever claimed to be similar to Ada, too.

You won't have much luck there. There is an extensive validation suite
which Ada compilers have to pass. Remember, Ada is a US goverment
invention to make sure that different maschines can run the same
programs. If you have a validated Ada compiler, you can be reasonable
sure that it will compile a correct Ada program out of the box and that
the compiled program will perform the same way as on the maschine it was
written on. I personally know of only one other language for which that
is true: TeX.

Yet another stupid language war (was: ... the only languages you need!!) Peter Seebach 10/31/97 12:00 AM

In article <345947D2...@horvath.com>,

Bob Horvath  <b...@horvath.com> wrote:
>I have heard of an Ada to Java bytecode compiler, so now I guess you can have
>Ada everywhere!

Java only runs on a smallish number of popular desktop platforms.

>> Java is intended to produce executables and programs which are portable
>> across all implementations; this does not necessarily make it a widely
>> portable language.

>I don't understand this statement.

There are not implementations for some platforms, so, even if a program
runs on all java implementations, it may not run on all that many different
platforms.

>> Speak for C++.  :)  C has a bit of history, but is really fairly
>> consistent.  :)

>Hmmmm.  How big is an int?

Do you want storage space or range?  Storage space is 'sizeof(int)',
range is [INT_MIN, INT_MAX].

C is portable in a way unlike the way Java is.  Code that doesn't need
to know what size an int is can be portable among all implementations.
Code which needs a specific size of object is frequently intrinsically
not portable by nature.  C wouldn't want to offer you a guaranteed, 32
bit type, because that might be horrendously inefficient on a 36-bit
machine.  :)

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Yet another stupid language war (was: ... the only languages you need!!) Peter Seebach 10/31/97 12:00 AM

Yes, but will an Ada 83 compiler handle all Ada 95 programs correctly?
If not, then why is an Ada advocate complaining about C78 implementations
not agreeing with C89 implementations?  (I don't normally have trouble with
Ada advocates; most of the people I meet who use Ada are quite rational.
But sometimes, you get people who blame standard C for all the failings
of pre-standard C.)

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Porting (was ADA and Pascal etc) Peter Seebach 10/31/97 12:00 AM

In article <345AB8...@dynamite.com.au>,

Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>May I respectfully offer a counterexample?

If you don't mind us making fun of you.  You posted an incorrect
C++ example without including comp.lang.c++.

>Code Warrior accepts

>void Main()

Does it?  Traditionally, C has used a lower case M on main, and
I seem to recall that the Mac implementations were case sensitive.
C++ likewise.

Further, if it accepts it at all, it does so out of bemused
tolerance for your misguided efforts, in both C and C++, main
is a function returning int, not void.

>{
>  for (int i ; i < SomeValue ; i++ )
>  {
>  // Do something
>  }

Well, this is certainly C++; C doesn't let you declare things in the
first expression of a for, and uses /*...*/ for comments.

>  for (int i ; i < SomeOtherValue ; i++ )
>  {
>  // Do something else
>  }
>}

>As by one reading of the (yet-to-be-standardised C++ spec) the scope of
>each
>i is limited to reside within the parens {} of each loop.

Your problem here is that C++ is random.  There have been holy wars
fought among the faithful over whether i's scope should end at the
end of the loop (those aren't parens, btw, they're braces), or
should continue into the surrounding code.  The "rationale" (hah!)
given by the "surrounding code" fanatics is
        for (i = 0; i < 20; ++i)
                if (condition)
                        break;
- they want to be able to see whether or not i made 20

I don't honestly know, or care, which of these C++ has officially
settled on; I know that there's been a lot of debate, and it's been
both ways.

C9X, of course, has the scope end with the end of the for; if you
want i to scope beyond the for, declare it outside the for.

>I do not consider the above code to be "trash". If you do, please
>elucidate as to why (heck, I could be wrong, have been before, will be
>again)

As C, it's trash in more ways than I can conveniently enumerate.  As
C++, it's trash because:
        You misspelled and misdeclared main
        You depended on a not-standardized feature
This is stupid.  When you are working with a pre-standardized language,
with implementations which may be tracking the standard to different
degrees, you *NEVER* push the envelope.

>The above code isn't exactly platform specific, is it? The problems with
>porting any language isolates and contains. No, it's in things like the
>STC library, where CodeWarrior 9 accepts instantiation of a  vector of
>objects for which the '<' operation isn't defined, providing you never
>try sorting, whereas MVC++ 5 doesn't. But IIRC MVC++ 4 does.

Ahh.  So, what you're saying is that C++ is not yet standardized, and
you can't be sure where in the process a compiler is.

Pray tell, what would you have said to someone having similar problems
with "Ada 95" compilers in 1992 or 1993?

>To recapitulate: often (not always, but more times than not) a port of
>Ada crossplatform requires only recompilation. Port from compiler to
>compiler ditto,
>but more so. I have yet to see such a thing when porting C++. I've seen
>it once in C, because we had a pre-compiler that heavily massaged the
>source code first ( a diff showed about 5% difference)

Drop by my web page; all of my non-POSIX-dependant C is expected to compile
and run correctly on all C compilers.  All of them.  No exceptions.  I
consider any failure to do this a bug, and will happily fix it.

Yes, I really mean it.

I do know of systems that won't run the code correctly; none of them make
even a convincing claim of being C89 compilers.

>Try having a go at the lovelace Ada tutorial at http://www.adahome.com .
>You may hate it, of course. But it also may give you insights into how
>to code C and C++ better. IMHO it's worth a look for any C programmer
>anyway, just as all Ada programmers should be exposed to C { if only to
>beef up their resistance :) }

I probably will.  Learning multiple natural languages makes you more
literate, fluent, and expressive in your native tongue, and I believe
the same goes for programming languages.  Familiarity with other idioms
can help you see a way around a sticky problem.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Yet another stupid language war (was: ... the only languages you need!!) Pat Rogers 10/31/97 12:00 AM

Peter Seebach <se...@plethora.net> wrote in article
<63d34m$ap7$1...@darla.visi.com>...

<snip>

> C is portable in a way unlike the way Java is.  Code that doesn't need
> to know what size an int is can be portable among all implementations.
> Code which needs a specific size of object is frequently intrinsically
> not portable by nature.  

Size yes, range no.  It is a shame that one cannot specify the range of an
integer type, or the accuracy of a floating point type in C, for the sake
of portability.  It is nice to have the compiler tell you that your
application requirements cannot be met, rather than not knowing unless a
(possibly obscure) bug is detected.

> C wouldn't want to offer you a guaranteed, 32
> bit type, because that might be horrendously inefficient on a 36-bit
> machine.  :)

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Scott A. Moore 10/31/97 12:00 AM

This subject is a complete waste of time, and completely off topic to
comp.lang.pascal.ansi-iso.
Would people who are polite please remove that newsgroup from the
reply list ?

                                                   Thanks in advance


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 10/31/97 12:00 AM

In article <3456e71b...@news.mindspring.com>,
John Black <nospam@nospam> wrote:
>Then why do the want ads for C, C++ programmers could stretch from
>here to the moon, while Ada/Pascal programmers are nonexistent?  Like
>I said, if you program in Ada or Pascal, your best job is going to be
>taking orders at Red Lobster.

I see advertisements for development jobs involving Ada quite frequently.
They are usually good jobs too!

Most of the C++ programming jobs are ones that you wouldn't want to do.
Like developing some boring user interface crap to some dull database.
Ho hum.

Incidentally, there are lots of jobs out there for COBOL, PL/I and RPG
programming under MVS or AS/400. I guess that must really be ``happening''!


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Yet another stupid language war (was: ... the only languages you need!!) John Rickard 10/31/97 12:00 AM

Jerry Sams <jsNOSPAM@abcNOSPAM.com> wrote in article
<63bpfa$dnt$1...@usenet1.interramp.com>...
: In article <01bce587$2efe61a0$8691440c@worldnet>,
:
:
advocacy? ummm then why am i reading this in the pascal groups?


ADA SUCKS, C/C++/JAVA RULES!!!! Bernard J. Girardot 10/31/97 12:00 AM

John Gluth wrote:
>
> In article <MPG.ec125666...@news.primenet.com> Mike Copeland,

> mrc...@primenet.com writes:
> >Learning Ada should be considered an
> >educational experience, at best, because no one uses it.
>
> Dang...what HAVE I been doing then, these past few years?
>
> You ever fly on the 777?  The flight control system is in Ada.
> If you land in Canada, their air traffic control system is (or will
> be...not
> sure if it's been delivered) in Ada.
> We fly missiles with Ada.  Shoot 'em down with Ada, too...
>
> But hey, I've never done an applet for the web in Ada, or anything else
> important like that...

HEY!  Ada works great as a CGI back end (and I think my code is pretty
important!)

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! David A. Frantz 10/31/97 12:00 AM

Bob Horvath wrote in message <345946D5...@horvath.com>...
>
>
>David A. Frantz wrote:
>
>> Bob Horvath wrote in message <345881C4...@horvath.com>...


>> >Steve Ropa wrote:
>> >
>> >> On 28 Oct 1997, Robert S. White wrote:
>> >>
>> >> >  Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
>> >> > code generation.
>> >>
>> >> Personally, I would like to see less emphasis on wizards anyway.  I
have
>> >> had too many developers tell me they knew what they were doing, but
when
>> I
>> >> took their wizards away, they were lost!
>> >
>> >I have often wondered the same thing.  I head people talk about IDEs and
>> >coming from a vi/make environment, I wonder what I am missing, if
anything.
>> >Perhaps these are two different things.
>> >
>> >It seems to me that if you know language, you don't need an IDE.  And if
>> you
>> >need an IDE, then you don't know the language.
>> >
>>
>> An IDE in my opinion has nothing to do with knowing the language.     An
IDE
>> if successful should make the programmer more productive!     Can't
really
>> see the relationship of the user interface, wether a make/command line
>> environment or a fancy IDE, to knowing the lanquage.
>
>How do they make you more productive?  I've never used one.  I have seen
CASE
>tools years ago that I thought were very unproductive.  Perhaps I don't
know
>what I am missing, but I can't imagine anything really helping out, except
for
>something that might make building GUIs a little easier, but for the guts
of an
>application, what do they buy you?
>
Actually I think we agree here.    For the GUTS of the application the GUI
or the make/command line environment buy you nothing.    You must know your
lang. and its libriaries to be successful.    The problem is, granted this
is Windowing environment specific, there are many other parts to a
application besides the code.     A GUI does allow one to build and tack on
components (resources) to that application in a much easier manner (more
productive).

I do from time to time machine tool programming targeted at PLC.    In the
past you could build a PLC program one opcode at a time in a manner simmilar
to assemmbly.    That was quickly replaced with "ladder logic".     All
successful PLC manufactures now supply thier ladder logic developement
systems with some sort of GUI.     Some of these GUI are poorly done some
are of great help to the programmer.     The key is to pick a tool that
helps with application developement.

Now a question like: does MFC help a developer deliever an application for
WINDOWS is much harder to answer.     For most I would suspect that it is
not the best tool.

DAVE


Porting (was ADA and Pascal etc) Matt Austern 10/31/97 12:00 AM

se...@plethora.net (Peter Seebach) writes:

> Your problem here is that C++ is random.  There have been holy wars
> fought among the faithful over whether i's scope should end at the
> end of the loop (those aren't parens, btw, they're braces), or
> should continue into the surrounding code.  The "rationale" (hah!)
> given by the "surrounding code" fanatics is
>         for (i = 0; i < 20; ++i)
>                 if (condition)
>                         break;
> - they want to be able to see whether or not i made 20

The draft C++ standard is quite specific, and not at all random.  If
you write
    for (int i = 0; i < N; +i) {
      // loop body
    }
then the scope of the variable i does not extend past the end of the
loop.  The same holds for while loops and if statements.


> C9X, of course, has the scope end with the end of the for; if you
> want i to scope beyond the for, declare it outside the for.

For C89 and C9X, the issue does not arise.  Neither the C89 standard
nor the draft C9X standard allows variables to be declared in the
controlling expression of for, while, or if.

I don't know whether Ada has any constructs where an analogous issue
arises.

Porting (was ADA and Pascal etc) Kaz Kylheku 10/31/97 12:00 AM

In article <345AB8...@dynamite.com.au>,
Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>> Sounds like you may have been a victim of the run of your patients.
>> Well written C code is very portable. I've seen compiler upgrades
>> break code, but only because it was trash to begin with.
>
>May I respectfully offer a counterexample?
>Code Warrior accepts
>
>void Main()
>{
>  for (int i ; i < SomeValue ; i++ )
>  {
>  // Do something
>  }
>
>  for (int i ; i < SomeOtherValue ; i++ )
>  {
>  // Do something else
>  }
>}

This isn't C. No conforming ANSI C compiler can accept the above external
function definition without diagnosing at least one syntax error.

You are confusing C++ with C. Do not attribute your C++ porting headaches to
the C programming language.  C++ isn't even standardized yet, and compilers for
that language differ in their level of incorporation of the latest draft
features. On the other hand, the 1989 ANSI standard for the C language was
approved by ISO in 1990. I find that the level of conformance in C compilers
tends to be very good. C++ is a ``moving target'' on the other hand.

It annoys me that the C language gets a ``bad rap'' due to C++. C++ should
never have happened. Stroustrup should have done BCPL with Classes, Fortran
with Classes or Pascal with Classes. What's even more annoying is people who
can't recognize that C and C++ are distinct languages, that there is no
such language as C/C++, and that the set of C++ programs is not a superset
of the set of C programs. Everytime I see C juxtaposed with C++ with an
intervening slash, I cringe.

>As by one reading of the (yet-to-be-standardised C++ spec) the scope of
>each
>i is limited to reside within the parens {} of each loop.

Yes, they C++ committee finally seem to have sorted out this trivial issue.

What's worse is that mixed declarations and statements are likely going to be
part of the new C language.

Ada makes so much more sense by requiring data declarations to precede the
function body. Only scatter-brained programmers see a stylistic advantage in
declarations interspersed with statements. It's perhaps a remnant of brain
damage inflicted by programming in BASIC. I try to even avoid declarations at
the beginnings of nested blocks, even though C allows it. It's not necessary.

I think that the following form would have been great for C function
definitions:

int main(int argc, char **argv)                /* formal parameters                */
int x;                                        /* locally scoped declarations        */
double y;
static char z = 'z';
extern float w;
{
    /* body, no declarations allowed anywhere */

}

This obviously borrows from the old-style declaration syntax in which parameter
types were declared just before the opening brace of the function, and only
their identifiers were named in the paramter list. Here, parameters are fully
declared in the parenthesized parameter declaration list, and the declarations
that precede the opening brace are for locals, like a VAR block in Pascal.

In my opinion, this would make a much nicer language, and is something to
consider by anyone who wants to invent a language with a C-like syntax.

>Yet MVC++ 5 barfs: as the scope of i is deemed to be within the main
>program, so the two int i declarations clash.
>
>I do not consider the above code to be "trash". If you do, please
>elucidate as to why (heck, I could be wrong, have been before, will be
>again)

I consider it to be trash by definition, because C++ is trash. :)

>Try having a go at the lovelace Ada tutorial at http://www.adahome.com .
>You may hate it, of course. But it also may give you insights into how
>to code C and C++ better. IMHO it's worth a look for any C programmer
>anyway, just as all Ada programmers should be exposed to C { if only to
>beef up their resistance :) }

I went through it a while ago. It's a good tutorial. (I don't think that this
beginner tutorial will help anyone write better C, though! :)

On the other hand, I find that the Ada95 standard doesn't make a great
reference manual, unfortunately! The ISO 9899-1990 standard for C is so much
more readable (for the most part).

Ada95 needs to be revised and typeset a little better. Because it's freely
available, it discourages an independent author from writing a clear reference
manual targetted at the working programmer.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting (was ADA and Pascal etc) Peter Seebach 10/31/97 12:00 AM

In article <fxtbu05...@isolde.mti.sgi.com>,

Matt Austern  <aus...@isolde.mti.sgi.com> wrote:
>The draft C++ standard is quite specific, and not at all random.  If
>you write
>    for (int i = 0; i < N; +i) {
>      // loop body
>    }
>then the scope of the variable i does not extend past the end of the
>loop.  The same holds for while loops and if statements.

Yes, but that's not what *used* to be C++.  ARM p. 88
        If the /for-init-statement/ is a declaration, the scope of
        the names declared extends to the end of the block enclosing
        the |for| statement.

        * There is no special scope rule for a name declared in the
        initializing statement in a /|for/| statement.  This implies that the
        scope of such a name extends to the end of the block enclosing the
        /|for/| statement.  For example,
                ...
        The absence of a special rule implies that the same name cannot be
        used to control two /|for/| loops in the same scope.
                ...
        On balance, it would probably have been better to introduce a special
        rule to limit the scope of a name introduced in the initializing
        statement of a /|for/| statement to the /|for/? statement, but much
        code now exists that dependss on the general rule.

Now, what does this tell us?

1.  C++, as of 1990, included something that was understood to be cruft,
because there was existing code, already, depending on a poor decision.
2.  It's okay to change this later, despite the existing code, including
code written for a compiler you say is available *today*.

>> C9X, of course, has the scope end with the end of the for; if you
>> want i to scope beyond the for, declare it outside the for.

>For C89 and C9X, the issue does not arise.  Neither the C89 standard
>nor the draft C9X standard allows variables to be declared in the
>controlling expression of for, while, or if.

Uhm.  Which C9X draft are *YOU* looking at?  The one *I* have sez
that for's 'clause 1' can declare a statement, and further, gets the
scope right without introducing a special rule.

How do we do it?  How is it that a bunch of lowly idiots unworthy to
comprehend the glory that is C++ managed to get the scope right without
a special scope rule?  Easy!  for() is declared to be equivalent,
except for the behavior of continue, to
        {
                clause1;
                while (clause2) {
                        statement;
                        clause3;
                }
        }

Poof!  The scope is correct, and we have no special rule.

And yes, we do have this in C9X.  Good thing, IMHO; while I'm not
a great fan of mixing declarations and code (it's necessary in C++
because constructors are expensive, So Sez The Book, but sort of pointless
in C), but a thing which has no function but iterating should, indeed,
be local to the loop iterating it.

Please research your claims more before posting.  I mean, it's really
pretty bad for a C pusher to be able to quote the ARM at you.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Jon S Anthony 10/31/97 12:00 AM

Craig Franck <clfr...@worldnet.att.net> writes:

> Jon S Anthony <j...@synquiry.com> wrote:
> >Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:
> >
> >> C and C++ compilers differ by so much that porting is often a Nightmare.
> >> Before I get flamed, I'd like to talk to people who've actually ported
> >> code cross-platform.
> >
> >That's about right.  Porting anything of substance written in C even
> >between compilers on the _same_ platform is depressing.  FOE here...
>
> Sounds like you may have been a victim of the run of your patients.
> Well written C code is very portable. I've seen compiler upgrades
> break code, but only because it was trash to begin with.

Yes, I thnk I can agree with that.  But the point is it is so _easy_
(though not as much with ANSI C) to write such trash.  Even by
"accident".


> >That rings true as well.  Typically porting Ada code between platforms
> >or compilers amounts to a recompilation.
>
> Something like a Windows to Mac port? How platform specific was the
> code? A recompilation port would be the ideal we all chase after. If
> you have such great splatfrom tools, you should feel lucky.

I've not had any need (or opportunity) to port to Mac.  The code in
question went between VMS (VAX&Alpha), Sparc Solaris, Sparc SunOS,
HP-UX, Intel Win/NT and across three different compilers.

One was about 60K lines with lots of generics and tasks.

Another was around 200K lines with lots of (goofy use) of generics.

No #ifdefs stuff anywhere in site.

/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

ADA SUCKS, C/C++/JAVA RULES!!!! Ken Mays 10/31/97 12:00 AM

Hi,

Fact is to ask yourself if it is worth the trouble. I learned Ada83
(college) and Ada95 (self-taught). There are jobs out there for Ada
programmers-if that is what you want to do. Now, what is it you want to do
after you learn the language? This is where a lot of minds falls short.
People don't know why they are learning the language in the first place or
what to do with it.

Ada is used in government software projects and avionics. Its background is
in
using it for embedded systems programming (think of the software that is
used in your
Microwave oven's control panel or digital watches). Its nature was that you
can look at the code and easily figure out what its doing or maintain it in
the future. Well, don't know how TRUE that is but I hope you get the idea.
Ada95 strength is its ability to use tasking (multitasking). You only learn
this is advanced C/C++ courses (depends).

Java is the web's language for interactive programming using browsers. It
was designed for that. Ada95 and C/C++ were not designed (by default) for
that. Here we go comparing an apple to a banana. Both are fruit, but have
their own characteristics.
A software engineer would only use Java for web development (mainly),
embedded system programming, or where it seems to make sense.

C/C++ strength is its knowledge base of software developers and industry
support.
If you want a job, just learn C/C++ and x86 assembly language. You can go
through college learning only those courses and geometry. Its a no brainer.
Java can also be done this way or any other major language used in your
area. But C/C++ is one of the MOST popular and supported computer
languages-which allows you to work just about anywhere. Its actually the
language that a lot of other languages were developed in.

If you were to ask me my top languages to know I would say Visual Basic,
C/C++ and Java. You'll find jobs in almost all of the popular languages (or
just pick up a newspaper and look at the jobs section). Hell, Visual Basic 5
would do you well. MicroSoft actually uses this for many of their GUI
programming projects!!!

Before I get flamed, I do advocate Ada95. Just that clients tend to look for
the languages I named. There is a war going on getting people to use Ada95
over C/C++ since there is a tremendous amount of time-tested applications
and programming libraries in C/C++ over Ada95. A no brainer.

Ken Mays, Systems Engineer
SAIC @Yourservice
http://www.yourservice.net
http://www.saic.com

P.S. If I asked you to find me ten Ada programmers and ten C programmers in
an hour
within you city before its destroyed...who do you think you'll find first?


Yet another stupid language war (was: ... the only languages you need!!) Shmuel (Seymour J.) Metz 10/31/97 12:00 AM

Jerry Sams wrote:
>
> This is an advocacy group, my friend.

What do you mean "this"? Of the six news groups this is posted to, only
one is an advocacy group. Either the poster is to lame brained to read a
charter or he simply doesn't care about netiquette (or both!) Whatever
the merits of Ada, B, BCPL, C, C++, etc., such crossposting of an
advocacy thread is either gross incompetence or trolling. alt.flame is
indeed a better choice.

--

                        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 spam...@library.lspace.org

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Shmuel (Seymour J.) Metz 10/31/97 12:00 AM

No, people who are polite will leave the Newsgroups header alone. If you
feel that responses to your article belong somewhere else, use
Followup-To, but trimming the Newsgroups in your response is rude.

--

                        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 spam...@library.lspace.org

Ada, Pascal, Eiffel and others geld...@progsoc.uts.edu.au 10/31/97 12:00 AM

In article <3457F2...@cs.adfa.oz.au>,
  Alan Brain <abr...@cs.adfa.oz.au> wrote:
>
> NOSPAM_...@sm.luth.se wrote:

[...]

> > I like Java, Pascal and Eiffel.
>
> In which case, may I ask you to spend some of your time having a squizz
> at Ada? The Lovelace turorial via http://www.adahome.com for example. I
> just wish there was a tutorial this good for Eiffel.

Take a look at Alan Snyder's and Brian Vetter's:

   ``Eiffel: An Advanced Introduction''

available in html/ps/pdf formats from:

   http://www.progsoc.uts.edu.au/~geldridg/eiffel/

Geoff Eldridge

-- email:  geld...@progsoc.uts.edu.au
-- web:    http://www.progsoc.uts.edu.au/~geldridg/eiffel/

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Shmuel (Seymour J.) Metz 10/31/97 12:00 AM

Robert S. White wrote:
 
>   Of course us _REAL_ programmers don't need no stinkin' IDE  :-) :-)

What you mean "we", paleface? Real programmers are lazy and hate doing
the same things repetitively. If I don't have an IDE for my language of
choice then I use the macro facilities of my editor to build one. Maybe
not fancy, but at least things like automatically dragging in templates
for IF at the proper indentation level. The last time I used Ada we
saved for more time than it took us to build the tools (written in KEXX
and REXX for Mansfield KEDIT).

Mind you, I have no use for IDEs that get underfoot or that try to keep
me from using particular language features. But I insist on automating
the stuff that I know how to do manually and do fairly often.

--

                        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 spam...@library.lspace.org

Yet another stupid language war (was: ... the only languages you need!!) Shmuel (Seymour J.) Metz 10/31/97 12:00 AM

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> > Hmmmm.  How big is an int?
>
> On most platforms, exactly as big as an integer in Ada. None of those
> languages guarantee the exact size of their (predefined) integers. :-)

Pardon me, but have you ever written production code in Ada? I don't
recall *ever* writing code using the default integer size; it always
either specified a range in the declaration or used a type that was
defined as a specific range (usually the latter.) There is no C
equivalent.

--

                        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 spam...@library.lspace.org

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Scott A. Moore 10/31/97 12:00 AM

In article <345A5E...@gsg.eds.com>, nos...@gsg.eds.com says...

>
>Scott A. Moore wrote:
>>
>> This subject is a complete waste of time, and completely off topic to
>> comp.lang.pascal.ansi-iso.
>> Would people who are polite please remove that newsgroup from the
>> reply list ?
>
>No, people who are polite will leave the Newsgroups header alone. If you
>feel that responses to your article belong somewhere else, use
>Followup-To, but trimming the Newsgroups in your response is rude.
>

What is RUDE is to send your mail to newsgroups UNRELATED to the topic
at hand. The original poster made this mistake. Everyone who follows is
simply repeating this mistake.
This discussion is about ADVOCACY and POLITICS. There is a place
for these discussions: either the advocacy or the misc sections.
comp.lang.pascal.ansi-iso is a technical discussion newsgroup. It is already
trashed with stupid ads and people confused about what ansi-iso pascal
IS. This nonsense only makes it worse. PLEASE STOP.

                                               [sam]


Yet another stupid language war (was: ... the only languages you need!!) Shmuel (Seymour J.) Metz 10/31/97 12:00 AM

Bob Horvath wrote:
 
> Hmmmm.  How big is an int?

How big do you want it to be <g, d & r>

That's one of the reasons that I prefer Ada and PL/I to C and its ilk.

--

                        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 spam...@library.lspace.org

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Steve Ropa 10/31/97 12:00 AM

On 31 Oct 1997, Robert S. White wrote:

> In article <345881C4...@horvath.com>, b...@horvath.com says...


> >
> >Steve Ropa wrote:
> >
> >> On 28 Oct 1997, Robert S. White wrote:
> >>
> >> >  Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
> >> > code generation.
> >>
> >> Personally, I would like to see less emphasis on wizards anyway.  I have
> >> had too many developers tell me they knew what they were doing, but when I
> >> took their wizards away, they were lost!
> >
> >I have often wondered the same thing.  I head people talk about IDEs and
> >coming from a vi/make environment, I wonder what I am missing, if anything.
> >Perhaps these are two different things.
> >
> >It seems to me that if you know language, you don't need an IDE.  And if you
> >need an IDE, then you don't know the language.
>
>    Exactly!  You can only occasionally use the language yet have
> excellant help immediately at your fingertips (a Gates'ism I know)
> and have it very easy in pointing out your errors - fixing them and
> then moving on to the next error.  When you use ctags with EMACS or
> Rational Apex or Visual C it is very very easy to browse the source
> code and quickly understand the calling requirments and who needs
> what.  I think I even heard of VI users hooking up ctags to browse
> source :)

>
>   Of course us _REAL_ programmers don't need no stinkin' IDE  :-) :-)

Oh, Please!!  I know(I hope) your just kidding, but please!  In IDE is a
tool.  It can make things easier, and sometimes faster.  It is not a
replacement for decent programming, but it can definitely be a help.  As
I've mentioned before, the key is to not let it become a crutch.  I can
develop an application using any editor, but the convenience of having my
debugging tools, compiler, and even the reference materials in one nice
package is very nice.  

Of course _REAL_ carpenters don't need hammers!  They can use any
available rock to pound their nails!  :-)


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Steve Ropa 10/31/97 12:00 AM

On 31 Oct 1997, Kaz Kylheku wrote:

> In article <3456e71b...@news.mindspring.com>,
> John Black <nospam@nospam> wrote:
> >Then why do the want ads for C, C++ programmers could stretch from
> >here to the moon, while Ada/Pascal programmers are nonexistent?  Like
> >I said, if you program in Ada or Pascal, your best job is going to be
> >taking orders at Red Lobster.
>
> I see advertisements for development jobs involving Ada quite frequently.
> They are usually good jobs too!
>
> Most of the C++ programming jobs are ones that you wouldn't want to do.
> Like developing some boring user interface crap to some dull database.
> Ho hum.
>
> Incidentally, there are lots of jobs out there for COBOL, PL/I and RPG
> programming under MVS or AS/400. I guess that must really be ``happening''!
> --
Don't fall into the John Black trap of overgeneralizing!  I am a C++
developer and when I was looking at jobs I saw a wide and varied
interesting and, yes, _REAL_ development jobs for C++.  I have used it for
telecommunications networks(long distance switching, etc...) and satellite
systems.  Call me a foolish optimist, but I think there are enough
interesting jobs out there for all of us, in many different languages.
But just in case, let me practice..."You want some fries to go with that?"
:-)

Steve


Yet another stupid language war (was: ... the only languages you need!!) Ed Falis 10/31/97 12:00 AM

Bob Horvath wrote in message <3459DA2C...@horvath.com>...
>
>I had forgotten about the implementation dependencies with the INTEGER type
in Ada
>because you would be a fool to use it when you can so easily create an
integer type
>using a range constraint.
>

But it goes further than this, because the standard package Interfaces
provides for size-specifed signed and unsigned integer types (e.g.
Unsigned_32, Integer_16).

- Ed

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Steve Ropa 10/31/97 12:00 AM

On Thu, 30 Oct 1997, Bob Horvath wrote:

>
>
> David A. Frantz wrote:
>
> > Bob Horvath wrote in message <345881C4...@horvath.com>...


> > >Steve Ropa wrote:
> > >
> > >> On 28 Oct 1997, Robert S. White wrote:
> > >>
> > >> >  Ada's current weak points, IMHO / IME, are in "wizard smart" GUI
> > >> > code generation.
> > >>
> > >> Personally, I would like to see less emphasis on wizards anyway.  I have
> > >> had too many developers tell me they knew what they were doing, but when
> > I
> > >> took their wizards away, they were lost!
> > >
> > >I have often wondered the same thing.  I head people talk about IDEs and
> > >coming from a vi/make environment, I wonder what I am missing, if anything.
> > >Perhaps these are two different things.
> > >
> > >It seems to me that if you know language, you don't need an IDE.  And if
> > you
> > >need an IDE, then you don't know the language.
> > >
> >
> > An IDE in my opinion has nothing to do with knowing the language.     An IDE
> > if successful should make the programmer more productive!     Can't really
> > see the relationship of the user interface, wether a make/command line
> > environment or a fancy IDE, to knowing the lanquage.
>
> How do they make you more productive?  I've never used one.  I have seen CASE
> tools years ago that I thought were very unproductive.  Perhaps I don't know
> what I am missing, but I can't imagine anything really helping out, except for
> something that might make building GUIs a little easier, but for the guts of an
> application, what do they buy you?
>
I think you hit on the key.  An IDE is NOT as CASE tool.  What the IDE
buys me is the convenient packaging of all of my development tools.  In
other words you can think of an IDE as a real nice editor, with automatic
links to your compiler,debugger, etc.  I don't assert that the IDE makes
me more productive than you, or anyone else for that matter.  It assert
that it makes me more productive than i would be without it.  Remember all
the fancy code generation pieces of VC++ are not all that the IDE is
about.  It is mostly about having all of your tools in one place.  Also, I
like some of the features of the editor(automatic indents, etc.)  I can
develop without them, and have, but I find it to be convenient, so I can
concentrate more on what I'm writing and not what keystroke combination I
need in order to delete a line of text(for instance).  To each his own.
And for the record, I almost _NEVER_ use the wizards that MS adds to the
IDE.

Steve


ADA SUCKS, C/C++/JAVA RULES!!!! Charles R. Lyttle 10/31/97 12:00 AM

Ken Mays wrote:

 If you learned Ada and can write good Ada programs, you learned proper
programming. You are now permitted to call yourself a programmer and write
readable c/c++ programs. Anyone who says "I am a C/C++ programmer" or "I am a
Windows Programmer" or "I am an Ada programmer" isn't any kind of programmer.
For real programmers all this "My language can beat your language" is trash.
--

Russ Lyttle

email : lyt...@mail.flash.net

Yet another stupid language war (was: ... the only languages you need!!) Bob Horvath 10/31/97 12:00 AM


Richard Curzon wrote:

> On Thu, 30 Oct 1997 18:25:26 GMT, "W. Wesley Groleau x4923"
> <wwg...@pseserv3.fw.hac.com> wrote:
>
> >Java was intended to be the most portable
> >of all, but Microsoft is trying hard to prevent that.
>
> No, Sun is trying hard to prevent that...  They are tying it to their
> proprietary platform, and trying to handicap it on Windows.  Which is
> against the interests of the majority of computer owners.
>
> MS is trying hard to liberate the language from the Sun proprietary
> platform.

?


Yet another stupid language war (was: ... the only languages you need!!) Bob Horvath 10/31/97 12:00 AM


Peter Seebach wrote:

> In article <345947D2...@horvath.com>,
> Bob Horvath  <b...@horvath.com> wrote:
> >I have heard of an Ada to Java bytecode compiler, so now I guess you can have
> >Ada everywhere!
>
> Java only runs on a smallish number of popular desktop platforms.
>
> >> Java is intended to produce executables and programs which are portable
> >> across all implementations; this does not necessarily make it a widely
> >> portable language.
>
> >I don't understand this statement.
>
> There are not implementations for some platforms, so, even if a program
> runs on all java implementations, it may not run on all that many different
> platforms.

Got it now.  Thanks.

>
>
> >> Speak for C++.  :)  C has a bit of history, but is really fairly
> >> consistent.  :)


>
> >Hmmmm.  How big is an int?
>
> Do you want storage space or range?  Storage space is 'sizeof(int)',
> range is [INT_MIN, INT_MAX].

Range.  I want something that maps directly onto the problem domain.  Isn't that
what all of this OOD paradigm is all about?  If I need somethat goes from

> C is portable in a way unlike the way Java is.  Code that doesn't need
> to know what size an int is can be portable among all implementations.

I would agree with you that Java has solved a portability problem by specifying
the size of integer types, but I think the Ada method of having types based on
ranges is a better way of doing things.  I would disagree that code that doesn't
need to know the size of an int can be portable among all implementations.  The
size of an int defines the range of values that will behave predictably.  Change
to an implementation that changes the size of an int, and the type definition has
just changed.

> Code which needs a specific size of object is frequently intrinsically
> not portable by nature.  C wouldn't want to offer you a guaranteed, 32

> bit type, because that might be horrendously inefficient on a 36-bit machine.
> :)

I can't think of many problem domains that require an integer to be a certain
size.  Most problem domains require that a numeric value be capable of
representing a certain range of values.

A guaranteed 32 bit integer in C would be welcome (which is why they have defined
integer sizes in Java).  If you assume an int is 32 bits, then it will break on a
machine that defines it as 16 bits, and if signed, might sign extend differently
on a 64 bit machine.


Trolling... Jerry van Dijk 10/31/97 12:00 AM

In article <345673af...@news.mindspring.com> nospam@nospam writes:

>ADA and Pascal are two of the most useless inventions Man has ever
>wasted space on this planet with.  These languages are hard to learn,
>have zero applications, and people who only know these languages can
>only find jobs at Taco Bell!  Smart programmers spend their time
>learning only C, C++, and Java in that order.

It's that Eiffel is not included, otherwise one might start to
think that you-know-who was back :-)

--

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

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Richard A. O'Keefe 10/31/97 12:00 AM

k...@helios.crest.nt.com (Kaz Kylheku) writes:
>No. C is perceived as being portable. Those who perceive C++ as portable
>are naive or mistaken.

>In article <3459AC...@dynamite.com.au>,
>Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>>Now C++ on the other hand, written using CodeWarrior 10 on a Mac, ported
>>to CodeWarrior 10 on an IBM... or even MVC++ 4 vs MVC++ 5... or worse
>>still CodeWarrior 9 on a Mac to CodeWarrior 10 on a Mac to MVC++ 5 on an
>>IBM... In 15,000 LOCs of C++ how many would you reasonably expect to
>>have to be changed? (yes, these were actual examples too)  

Let me provide a data point.
I am using a modern UNIX system, based on an architecture that has been
around for 10 years or so.  We have the very latest C++ compiler from
the vendor.  We have another C++ compiler.

I picked up the September 1997 issue of the C/C++ Users Journal,
and downloaded all of the source code for that issue.
How many of the C++ programs could I compile?

        NONE OF THEM.

I got one of them working after about half an hour of hacking; the
others defeated me.

Porting from one version of CodeWarrior to another is no real test of
portability; no test at all really.  C++ compiler differences are
*much* bigger than machine differences.

Porting from one version of MVC++ to another is no real test of
portability; no test at all really.  C++ compiler differences are
*much* bigger than machine differences.

Porting between CodeWarrior and MVC++ *is* a test of portability,
but it still is a rather pathetic test.

If I had to port 15 kSLOC of C++ from a Mac or a PC to this system,
I would expect major changes to every translation unit and minor
changes to every class.  I would not be in the least suprised if
a week's work led to total failure.  I am aware of several C++
projects which have had to abandon initial plans to release the code
on more than one machine; there was one commercial development
started here that ran into that very problem last year, and another
up the road the year before.

Let's just take a few of the things I'm seeing in C++ these days that
are NOT supported by all compilers:
        namespace
        mutable
        explicit
        static data members initialised in a class definition
        template<>        (that is, a template with no parameters).

>Even though it's easy to introduce machine dependencies into C or C++ code, I
>would expect that most of your C++ headaches would be related to a lack of
>standardization, or the different pace of adaptation of the draft features by
>various vendors. (That alone is, to me, reason enough to avoid C++ if I can).

That is precisely the problem.

>Then there are uses of non-portable functions that are not in the standard
>library. E.g. it's impossible to port an XWindow application to Microsoft
>Windows without rewriting portions of it, but it's not really the fault of the
>underlying language.

(A) Let us all thank and praise Ousterhout for Tk.  (And there's an Ada/Tk
    interface.  Portable GUIs in Ada.)

(B) There's an outfit called Mainsoft (www.mainsoft.com) selling something
    called MainWin, which they claim lets you run NT code under UNIX.
    I know _nothing_ about the company or their products other than what
    I've seen in their ad.  Anyone know how well it works with the Ada
    Win32 binding?

--
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

Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Alan E & Carmel J Brain 10/31/97 12:00 AM

JT (from Fritz) wrote:
>
> I code a bit in C and C++ and the more I have to debug other people's C/C++
> the more I like Ada.

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

Porting (was ADA and Pascal etc) Alan E & Carmel J Brain 10/31/97 12:00 AM

Craig Franck wrote:
>
> Jon S Anthony <j...@synquiry.com> wrote:
> >Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:
> >
> >> C and C++ compilers differ by so much that porting is often a Nightmare.
> >> Before I get flamed, I'd like to talk to people who've actually ported
> >> code cross-platform.
> >
> >That's about right.  Porting anything of substance written in C even
> >between compilers on the _same_ platform is depressing.  FOE here...
>
> Sounds like you may have been a victim of the run of your patients.
> Well written C code is very portable. I've seen compiler upgrades
> break code, but only because it was trash to begin with.

May I respectfully offer a counterexample?
Code Warrior accepts

void Main()
{
  for (int i ; i < SomeValue ; i++ )
  {
  // Do something
  }

  for (int i ; i < SomeOtherValue ; i++ )
  {
  // Do something else
  }
}

As by one reading of the (yet-to-be-standardised C++ spec) the scope of


each
i is limited to reside within the parens {} of each loop.

Yet MVC++ 5 barfs: as the scope of i is deemed to be within the main


program, so the two int i declarations clash.

I do not consider the above code to be "trash". If you do, please
elucidate as to why (heck, I could be wrong, have been before, will be
again)
 
> >> In my own, albeit limited experience, the problems I've had with any
> >> C or C++ port are greater than all the problems I've had with Ada
> >> crossplatform put together!

> >
> >That rings true as well.  Typically porting Ada code between platforms
> >or compilers amounts to a recompilation.
>
> Something like a Windows to Mac port? How platform specific was the
> code? A recompilation port would be the ideal we all chase after. If
> you have such great splatfrom tools, you should feel lucky.

The above code isn't exactly platform specific, is it? The problems with
porting
C++ aren't in the areas of platform-specificity, which careful coding in
any
language isolates and contains. No, it's in things like the STC library,
where
CodeWarrior 9 accepts instantiation of a  vector of objects for which
the '<' operation isn't defined, providing you never try sorting,
whereas MVC++ 5 doesn't. But IIRC MVC++ 4 does.

To recapitulate: often (not always, but more times than not) a port of
Ada crossplatform requires only recompilation. Port from compiler to
compiler ditto,
but more so. I have yet to see such a thing when porting C++. I've seen
it once in C, because we had a pre-compiler that heavily massaged the
source code first ( a diff showed about 5% difference)


 
Try having a go at the lovelace Ada tutorial at http://www.adahome.com .
You may hate it, of course. But it also may give you insights into how
to code C and C++ better. IMHO it's worth a look for any C programmer
anyway, just as all Ada programmers should be exposed to C { if only to
beef up their resistance :) }
--
aeb...@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abr...@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale


Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!! Kenneth W. Sodemann 10/31/97 12:00 AM

Bob Horvath wrote in message <345946D5...@horvath.com>...

>David A. Frantz wrote:
[snip]


>> An IDE in my opinion has nothing to do with knowing the language.     An
IDE
>> if successful should make the programmer more productive!     Can't
really
>> see the relationship of the user interface, wether a make/command line
>> environment or a fancy IDE, to knowing the lanquage.
>
>How do they make you more productive?  I've never used one.  I have seen
CASE
>tools years ago that I thought were very unproductive.  Perhaps I don't
know
>what I am missing, but I can't imagine anything really helping out, except
for
>something that might make building GUIs a little easier, but for the guts
of an
>application, what do they buy you?

For one, they tend to lower the training time needed, especially if you are
dealing with a system like Apex where the version control is well integrated
with the development environment.  It is a lot easier to tell the new guys
on the project which buttons to push as opposed to telling them which
scripts to run, how, and when.

If it is a good IDE, it provides a very intuitive interface for editing,
building, and (often) debugging the application.  A good IDE will also make
the programmer more productive by automating or helping to organize many of
the tasks. VC++'s wizards are a good example of both the automation, and the
help in organization.  The fact that with most IDEs, the developer rarely
has to resort to messing with the make file also attests to IDEs automating
the more mundane tasks.


--
with Std_Disclaimer;  use Std_Disclaimer;
Signature.Put (Name => Ken Sodemann,
    E_Mail => kwso...@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);


Yet another stupid language war (was: ... the only languages you need!!) Peter Seebach 10/31/97 12:00 AM

In article <01bce627$82afbec0$400d...@my-pc.neosoft.com>,
Pat Rogers <pro...@acm.org> wrote:
>Size yes, range no.  It is a shame that one cannot specify the range of an
>integer type, or the accuracy of a floating point type in C, for the sake
>of portability.  It is nice to have the compiler tell you that your
>application requirements cannot be met, rather than not knowing unless a
>(possibly obscure) bug is detected.

This is true; C9X provides ways to do this for some common cases.
(Regrettably, IMHO, none of the "give me N bit integers, no matter how
slow they are" proposals made it.  I'd sort of like these...)

So, in C9X, if you want a 32 bit int, you can use 'int32_t'.  If there
isn't one, the compiler will let you know.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Porting (was ADA and Pascal etc) Jon S Anthony 10/31/97 12:00 AM

Matt Austern <aus...@isolde.mti.sgi.com> writes:

> The draft C++ standard is quite specific, and not at all random.  If
> you write
>     for (int i = 0; i < N; +i) {
>       // loop body
>     }
> then the scope of the variable i does not extend past the end of the
> loop.  The same holds for while loops and if statements.
...

> I don't know whether Ada has any constructs where an analogous issue
> arises.

Construct: yes.  Issue: no, the semantics are nailed down and have
been since Ada83.

    for I in 1..N loop  -- Implicit declaration of I
        -- loop body
    end loop;           -- End of scope for I

/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

Porting (was ADA and Pascal etc) Shmuel (Seymour J.) Metz 10/31/97 12:00 AM

Kaz Kylheku wrote:
>
> Ada makes so much more sense by requiring data declarations to precede the
> function body. Only scatter-brained programmers see a stylistic advantage in
> declarations interspersed with statements. It's perhaps a remnant of brain
> damage inflicted by programming in BASIC.

Sigh! More ad hominem arguments. Maybe you're having an off day.

--

                        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 spam...@library.lspace.org

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Richard A. O'Keefe 10/31/97 12:00 AM

"Shombe Kroll" <Sho...@worldnet.att.net> writes:
>My first programming class in college was in ADA and I found
>it very difficult to learn because of the lack of documentation and help
>aids for the language.  That  forced me to rely on my Professor for help
>which unfortunately was like pulling teeth.

This is by no means an Ada problem.
There are a couple of good on-line tutorials.
There are some truly excellent text-books.
Our first-year students here have easy on-line access to the RM,
which _isn't_ introductory educational material, but if you have
a specific question, it's amazing what you can find.
There are Ada-aware editors including some with on-line help.

Your lecturer and tutors are *paid* to give you help;
if getting it is 'like pulling teeth', you have a legitimate
complaint which you should bring to your department.

We teach Ada in first year and C in second year (as a bread-and-butter
subject, not because C has any special merits).  I have inspected quite
a lot of Ada textbooks and more C textbooks than I can recall without
turning my stomach.  It is important to understand that most C _books_
are bad, except for the ones that are very very bad.  I have in mind,
for example, the textbook that said on p6 that all the code conformed
to the ANSI standard but had an example on p7 that violated it.  Beware
in particular of "A Book on C" and anything by Herbert Schildt.

Curiously, C is in many respects a much harder language than Ada.
You _can_ write excellent programs in C, but it is much more work
than it is in Ada.  I'm marking some graduate student code at the
moment.  One student in particular has written a program that is
actually going to be used in a major department store.  (They have
paid for it, and indeed, it's an upgrade of a program he wrote for
them last year.)  It's _supposed_ to be written in C, but in fact
it isn't.  I mean by this that it violates the C standard in many
completely pointless ways, which prevent it compiling under any
compiler except the particular compiler he used.  He didn't _mean_
to violate the standard (except for calling a couple of DOS-specific
'interrupts'), but that's what he ended up with.

--
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

Yet another stupid language war (was: ... the only languages you need!!) Richard Curzon 11/1/97 12:00 AM

regards,
Richard.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Gary A. Wiltshire 11/1/97 12:00 AM

nospam@nospam (John Black) wrote:

>ADA and Pascal are two of the most useless inventions Man has ever
>wasted space on this planet with.  These languages are hard to learn,
>have zero applications, and people who only know these languages can
>only find jobs at Taco Bell!  Smart programmers spend their time
>learning only C, C++, and Java in that order.

Does your daddy know that you're using his computer?

BTW, you're ugly and your mommy dresses you funny.

   --- Gary Wiltshire

Porting (was ADA and Pascal etc) Alan E & Carmel J Brain 11/1/97 12:00 AM

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:
>

> > > Sounds like you may have been a victim of the run of your patients.
> > > Well written C code is very portable. I've seen compiler upgrades
> > > break code, but only because it was trash to begin with.
> >
> > May I respectfully offer a counterexample?

Example -->8---------

> > I do not consider the above code to be "trash".

> Note that he says C code, not C++.

I noticed this _after_ posting. Mea Culpa. Open mouth, insert foot...
Never mind, I think the post made a useful point.

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

Ada, Pascal, Eiffel and others Alan E & Carmel J Brain 11/1/97 12:00 AM

geld...@progsoc.uts.edu.au wrote:

> In article <3457F2...@cs.adfa.oz.au>,
>   Alan Brain <abr...@cs.adfa.oz.au> wrote:

> > In which case, may I ask you to spend some of your time having a squizz
> > at Ada? The Lovelace turorial via http://www.adahome.com for example. I
> > just wish there was a tutorial this good for Eiffel.
>
> Take a look at Alan Snyder's and Brian Vetter's:
>
>    ``Eiffel: An Advanced Introduction''
>    http://www.progsoc.uts.edu.au/~geldridg/eiffel/

Many thanks. This is a good, even great, introduction, but not a
tutorial as such. Nonetheless, thanks for bringing it to my attention,
as it should do the job (for me at least, dunno about absolute
beginners)


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


Porting (was ADA and Pascal etc) Alan E & Carmel J Brain 11/1/97 12:00 AM

Peter Seebach wrote:

> If you don't mind us making fun of you.  You posted an incorrect
> C++ example without including comp.lang.c++.

Mind? Nah! For one thing, your post was educational and helpful.

> >Code Warrior accepts
>
> >void Main()
>
> Does it?  Traditionally, C has used a lower case M on main, and
> I seem to recall that the Mac implementations were case sensitive.
> C++ likewise.
 
> Further, if it accepts it at all, it does so out of bemused
> tolerance for your misguided efforts, in both C and C++, main
> is a function returning int, not void.

Correct! Why do you assume that
  int main()
had anything whatsoever to do with
  void Main()

Sorry, I wanted to make a point here, and laid a dastardly trap.

> Well, this is certainly C++; C doesn't let you declare things in the
> first expression of a for, and uses /*...*/ for comments.

...but only if the switch for strict ASCII is on, otherwise YMMV. Eg HP
C.

> Your problem here is that C++ is random.

WORDS WORTHY OF ENGRAVEMENT IN LETTERS OF GOLD ON JADE!

I program in Ada-83. I program in Ada-95.I program in C. I program in
C++.
Not just privately, or academically, but on systems that really do
things.

IMHO there _is_ a significant difference. There has been vastly more
heat than light generated in "the great language debate", and the
general
conclusion is that it's a matter of religion, with no real reason to
prefer one language to another.
Yet all the studies that have been done indicate otherwise. This has led
to
the phenomenon of (sometimes quite valid) attacks on the limitations of
the
studies. While ignoring the results.

> As C, it's trash in more ways than I can conveniently enumerate.  As
> C++, it's trash because:
>         You misspelled and misdeclared main
>         You depended on a not-standardized feature
> This is stupid.  When you are working with a pre-standardized language,
> with implementations which may be tracking the standard to different
> degrees, you *NEVER* push the envelope.

If having 2 loops in the same procedure, using the recommended way of
doing things (localisation of indices) is "pushing the envelope", then
maybe the envelope is a little too constraining. How does one tell when
one is venturing into "Here Be Dragons" territory? As far as I can tell,
not even setting the switch for strict ANSI C compliance will save you
in
every case, just the vast majority of them. Can you tell me a good "rule
of thumb" to use for finding out which C++ statements are "safe" and
which
are "dangerous"?

> Ahh.  So, what you're saying is that C++ is not yet standardized, and
> you can't be sure where in the process a compiler is.

True, exactly my point.
 
> Pray tell, what would you have said to someone having similar problems
> with "Ada 95" compilers in 1992 or 1993?

There weren't any (compilers, that is). That's the whole point. Ada 9X
compilers existed, but not for production use, as they weren't
completely stable. Much like C++ will be in a few years. A better
example for you to choose would be Ada-83 compilers in 1984-85. For then
there were different interpretations (not quite as bad as the example
for C++) of the standard that were unclarified.
One that comes to mind is the Ada-83 "delay" statement. This was in the
Language
Reference Manual as, basically "Delay 5.0 means delay at least 5
seconds, but with no guarentee that it will be exactly 5.0 seconds as
other more high priority concurrent processes may pre-empt you". Later
on, a codicil was added "but it should be about 5.0 seconds, a delay for
an infinite time is not sensible" as one compiler of my acquaintance
treated "delay 5.0" as "delay forever, even if you're the only process".
Which was within the letter, but not the spirit, of the LRM.
Such rubbish (there wasn't much of it) gave Ada a bad name, that it
still hasn't lived down. The fact that all of these inconsistencies were
cleared up by 1987 is not well known. The Ada-83 LRM
straight-out-of-the-box was far more useful as a guide to expected
behaviour than even the ISO C standard, which abounds with unclear
statements that require "sensible interpretation" (like the original
Ada-83 delay statement).
Summary: If the ISO C standard is more unclear after 20 years than the
Ada-83 standard was after 20 days, what can we expect from the C++
standard? I respectfully submit, "more of the same" with no end in
sight. Will C++ have a standard by the turn of the century? My guess is
Yes, but I'd reckon the odds are about even. Will the standard prevent
all the problems? Not a hope. The best we can hope for is a reduction of
inconsistencies to the level of ANSI C, in about 20 years.( A level
which Ada-95 has already achieved, after 2 years, but that's irrelevant)
 
> Drop by my web page; all of my non-POSIX-dependant C is expected to compile
> and run correctly on all C compilers.  All of them.  No exceptions.  I
> consider any failure to do this a bug, and will happily fix it.
>
> Yes, I really mean it.

I like your attitude, Sir, a man after my own heart! Yes, I will drop by
your web page. My thanks for bringing it to my attention, I'm sure I'll
learn a lot from it.
 
> I do know of systems that won't run the code correctly; none of them make
> even a convincing claim of being C89 compilers.


>
> >Try having a go at the lovelace Ada tutorial at http://www.adahome.com .
> >You may hate it, of course. But it also may give you insights into how
> >to code C and C++ better. IMHO it's worth a look for any C programmer
> >anyway, just as all Ada programmers should be exposed to C { if only to
> >beef up their resistance :) }
>
> I probably will.  Learning multiple natural languages makes you more
> literate, fluent, and expressive in your native tongue, and I believe
> the same goes for programming languages.  Familiarity with other idioms
> can help you see a way around a sticky problem.

Agree completely.

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

Porting (was ADA and Pascal etc) Peter Seebach 11/1/97 12:00 AM

In article <345BB0...@dynamite.com.au>,

Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>Mind? Nah! For one thing, your post was educational and helpful.

>> >void Main()

>Correct! Why do you assume that
>  int main()
>had anything whatsoever to do with
>  void Main()

Because, in C89, the implementation is *allowed* to be case-insensitive,
on externally visible symbols, so you *may have been* declaring the
one true main(), and doing so incorrectly!

>Sorry, I wanted to make a point here, and laid a dastardly trap.

Lucky for me that C89 supported a brain-dead linker.  :)

>> Your problem here is that C++ is random.

>WORDS WORTHY OF ENGRAVEMENT IN LETTERS OF GOLD ON JADE!

>I program in Ada-83. I program in Ada-95.I program in C. I program in
>C++.  Not just privately, or academically, but on systems that really do
>things.

Cool!  At some point, I should look you up and ask you questions about
Ada.

>If having 2 loops in the same procedure, using the recommended way of
>doing things (localisation of indices) is "pushing the envelope", then
>maybe the envelope is a little too constraining.

This is why I use C, not C++.

>How does one tell when
>one is venturing into "Here Be Dragons" territory? As far as I can tell,
>not even setting the switch for strict ANSI C compliance will save you
>in every case, just the vast majority of them. Can you tell me a good "rule
>of thumb" to use for finding out which C++ statements are "safe" and
>which are "dangerous"?

This is *soooo* tempting...

:)

Basically, no, I can't.  I can tell you that the example was (modulo
main issues) supposedly conforming draft-standard ANSI C++, and that
(once again, modulo main issues) it will be C9X.  But I can't tell you
how to guess when a compiler will get in the same decade with you.

>> Pray tell, what would you have said to someone having similar problems
>> with "Ada 95" compilers in 1992 or 1993?

>The fact that all of these inconsistencies were


>cleared up by 1987 is not well known. The Ada-83 LRM
>straight-out-of-the-box was far more useful as a guide to expected
>behaviour than even the ISO C standard, which abounds with unclear
>statements that require "sensible interpretation" (like the original
>Ada-83 delay statement).

Yeah, but it's getting a lot better.  :)

>Summary: If the ISO C standard is more unclear after 20 years than the
>Ada-83 standard was after 20 days, what can we expect from the C++
>standard?

I would take issue with an assertion that ISO C was unclear after 20
years.  ISO C didn't start until around 1984, as I recall, so they had
five years, and further, they had a lot of existing practice to account
for... They couldn't just sit down and describe what *ought* to be.

I am fairly confident that C9X will be a significant improvement over
C89 - serious effort is going on to make sure that potential confusions
are eliminated.

>I respectfully submit, "more of the same" with no end in
>sight. Will C++ have a standard by the turn of the century? My guess is
>Yes, but I'd reckon the odds are about even.

I'd say "most likely".  Last I heard, they're on a schedule that may well
complete before C9X, so they'd *better* be done this century...

>Will the standard prevent
>all the problems? Not a hope. The best we can hope for is a reduction of
>inconsistencies to the level of ANSI C, in about 20 years.( A level
>which Ada-95 has already achieved, after 2 years, but that's irrelevant)

Ada has an advantage similar to that enjoyed by perl - the language
was developed under controllable circumstances.  C was mildly crippled
by the vast amounts of existing code which couldn't be broken.  C++
is *much* more badly hurt by this.

I don't think ISO C really has many inconsistencies left, even afer only
7 years.  (C89 is really C90...)  There are some confusions, but you can
write a lot of code with a lot of confidence now.

>> Drop by my web page; all of my non-POSIX-dependant C is expected to compile
>> and run correctly on all C compilers.  All of them.  No exceptions.  I
>> consider any failure to do this a bug, and will happily fix it.

>> Yes, I really mean it.

>I like your attitude, Sir, a man after my own heart! Yes, I will drop by
>your web page. My thanks for bringing it to my attention, I'm sure I'll
>learn a lot from it.

Cool!  I always like getting feedback on my code, it's helped a lot.
Sadly, I had some 8-bit char dependancies in my string library a while
back, but I believe they're all fixed.  :)

(Actually, it also has a logic bug in the allocation rules, that seems to
be "mostly harmless", but which really implies that it's time to move
my -current code out as a release.)

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Gary A. Wiltshire 11/1/97 12:00 AM

jfb...@nospam.mail.earthlink.net (John Bode) wrote:
.....
>So why isn't Ada in more widespread use?
.....

Because the Federal government mandated its use?<g>

   --- Gary Wiltshire

Portability: C, C++, Ada Peter Seebach 11/1/97 12:00 AM

In article <345BA5...@dynamite.com.au>,

Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>> C++ is not C however. What are your experiences with porting ANSI/ISO C code
>> from one ISO compiler to another?

>Fairly awful. You see, often there are compiler directives buried in
>there that assume a pre-processor of a particular variety. Usually named
>after a ruminant herbivore.

Ahh!  Then you weren't really porting "ANSI/ISO C code".  You were probably
porting GNU C, which is a very different beast, or worse, the sort of
vague, ill-defined language that generally goes by "the C we used to have
on that one computer when I was in college".

>> C porting headaches usually stem from legacy ``classic'' C code, in which the
>> chief difficulty is bugs uncovered when one adds function prototypes.  Then
>> there are dependencies of implementation characteristics: byte order, size of
>> various types, and so forth.

>Completely agree. Regardless of the reason though, C porting headaches
>exist, as a general rule, do they not?

Not very much any more.  I have a couple of systems.  They're classic
portability hell - they use 64 bit file sizes, rename and/or redefine
"classic" features (like 'sys_errlist'), and so on...

I've recently been compiling a *lot* of software on them.  The only
package I've had any trouble with was last modified in 1993; it used
'sys_errlist'.  That's it.  Everything else has been nice and quiet.

It's gotten a lot better over time; not just with the standard, but with
the widespread availability of compilers done since the standard...

gcc, for all its faults, has done a lot to make C more accessible.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Yet another stupid language war (was: ... the only langu Jerry van Dijk 11/1/97 12:00 AM

In article <63bpfa$dnt$1...@usenet1.interramp.com>  < no name >  writes:

>This is an advocacy group, my friend.
>
>Jerry

_A_ Jerry, but not this Jerry :-)

--

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

Porting (was ADA and Pascal etc) Alan E & Carmel J Brain 11/1/97 12:00 AM

Matt Austern wrote:

> The draft C++ standard is quite specific, and not at all random.  If
> you write
>     for (int i = 0; i < N; +i) {
>       // loop body
>     }
> then the scope of the variable i does not extend past the end of the
> loop.  The same holds for while loops and if statements.

> I don't know whether Ada has any constructs where an analogous issue
> arises.

Both Ada-83 and Ada-95 allow the following:

procedure ExampleProcedure is

  type SomeDiscreteType is new INTEGER range -14..45;
  type SomeOtherDiscreteType is ( Red,Yellow, Green, Blue);

begin

  for I in SomeDiscreteType loop
    -- do something
    -- within this scope, I is of SomeDiscreteType, between -14 and 45
  end loop;

  for I in SomeOtherDiscreteType loop
    -- do something else  
    -- within this loop, I is of SomeOtherDiscreteType, Red etc
  end loop;

end ExampleProcedure;

Thus the scope of I is defined only within the loop.

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

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Timo Salmi 11/1/97 12:00 AM

In article <345A5E...@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
:Scott A. Moore wrote:
:> This subject is a complete waste of time, and completely off topic to
:> comp.lang.pascal.ansi-iso.
:> Would people who are polite please remove that newsgroup from the
:> reply list ?
:
:No, people who are polite will leave the Newsgroups header alone. If you
:feel that responses to your article belong somewhere else, use
:Followup-To, but trimming the Newsgroups in your response is rude.

Dear Shmuel,

In accordance to the common netiquette and elementary newsgroup
courtesy what is "rude" here is the original extensive, crossposting
of the troll/flame bait (not Sam nor you) to off-topic newsgroups.
Unfortunately, there always is a such number of unexperienced
readers who fall for these ploys, and the others will have to
weather it, or use killfiles until the debacle subsides.

   All the best, Timo

....................................................................
Prof. Timo Salmi   Co-moderator of news:comp.archives.msdos.announce
Moderating at ftp:// & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance  ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/>  ; FIN-65101,  Finland

Spam foiling in effect.  My email filter autoresponder will return a
required email password to users not yet in the privileges database.

Yet another stupid language war (was: ... the only languages you need!!) Peter Seebach 11/1/97 12:00 AM

In article <345AAAF5...@horvath.com>,

Bob Horvath  <b...@horvath.com> wrote:
>> Do you want storage space or range?  Storage space is 'sizeof(int)',
>> range is [INT_MIN, INT_MAX].

>Range.  I want something that maps directly onto the problem domain.

Then use Ada.  :)  If you can make do with "at least this much range",
and the range isn't more than +/- 2^31 -1, or 0..2^32-1, C can help.

>I would agree with you that Java has solved a portability problem by specifying
>the size of integer types, but I think the Ada method of having types based on
>ranges is a better way of doing things.  I would disagree that code that
>doesn't need to know the size of an int can be portable among all
>implementations.  The size of an int defines the range of values that will
>behave predictably.  Change to an implementation that changes the size of
>an int, and the type definition has just changed.

Right; this is why "strictly conforming" code is careful not to use values
outside that range.  :)

>I can't think of many problem domains that require an integer to be a certain
>size.  Most problem domains require that a numeric value be capable of
>representing a certain range of values.

Well, yes, but a range like
        0..2^32 -1
is going to need a 32 bit int.

>A guaranteed 32 bit integer in C would be welcome (which is why
>they have defined integer sizes in Java).  If you assume an int is
>32 bits, then it will break on a machine that defines it as 16
>bits, and if signed, might sign extend differently on a 64 bit
>machine.

Right.  If you assume an int has the range INT_MIN..INT_MAX, you'll
be fine.  :)

C9X offers optional exact types, and a few other enhancements... Still,
it's not going to guarantee you that int32_t exists.  I dunno if that's
good or bad, but it's what's happening this time around.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Yet another stupid language war (was: ... the only languages you need!!) Ken Deboy 11/1/97 12:00 AM
 Are you trying to make me puke? How does MicroSoft adding proprietary shit
to Java so it ONLY runs on Winblows "liberate" it? I can run (pure) Java on
Linux and Win95, it comes with OS/2. Do you also think a web-browser or word
processor is a "component" of the operating system? Do you Work for M$?

Ken

Yet another stupid language war (was: ... the only languages you need!!) Russ 11/1/97 12:00 AM

[... dripping with sarcasm ...]

Richard, you really need to expand on your comment above.
It appears as though you are saying that Sun/JavaSoft is not
trying to create a portable Java.  I sure that's not what you
really meant to say.  It also appears that you are saying
that Microsoft _is_ trying to create a truely cross-platform
Java environment.

Maybe you should try again.

Yet another stupid language war (was: ... the only languages you need!!) Kaz Kylheku 11/1/97 12:00 AM

In article <345a880a...@news.interlog.com>,

Let's see: Sun defines a standard (which is freely available, by the way) for
constructing a Java implementation. This Java works on many platforms,
*including* Windows. Their specification has even enabled Microsoft to create
their own compatible implementation.

On the other hand, Microsoft's extended Java is proprietary and for Windows
*only*.

In what way is Sun tying Java to their proprietary platform? What platform
would that be? Solaris? In what way is Java designed to specifically take
advantage of Solaris, but be crippled in Windows? (Other than the obvious
reliability and performance limitations of Windows which handicap any program,
of course...)
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting Experiences (was Ada and Pascal etc ) Craig Franck 11/1/97 12:00 AM

Alan E & Carmel J Brain <aeb...@dynamite.com.au> wrote:
>Jon S Anthony wrote:

>>
>> Craig Franck <clfr...@worldnet.att.net> writes:
>>
>> > Jon S Anthony <j...@synquiry.com> wrote:
>>
>> > >That rings true as well.  Typically porting Ada code between platforms
>> > >or compilers amounts to a recompilation.
>> >
>> > Something like a Windows to Mac port? How platform specific was the
>> > code? A recompilation port would be the ideal we all chase after. If
>> > you have such great splatfrom tools, you should feel lucky.
>>
>> I've not had any need (or opportunity) to port to Mac.  The code in
>> question went between VMS (VAX&Alpha), Sparc Solaris, Sparc SunOS,
>> HP-UX, Intel Win/NT and across three different compilers.
>>
>> One was about 60K lines with lots of generics and tasks.
>>
>> Another was around 200K lines with lots of (goofy use) of generics.
>>
>> No #ifdefs stuff anywhere in site.
>
>If that's C code you're talking about, I'm radically impressed.
>If that's C++ code, then you're qualified to walk on water, or more
>likely you're a purveyor of Tall Stories.
>If that's Ada, then it's par for the course.

What is it about Ada that makes it portable? I would say it is the
types of applications being developed, as well as the platforms,
and, perhaps, quality of implementation. Last time I was in Barnes
& Noble I saw "Ada 95 for C and C++ Programmers" by Simon Johnston,
from Add-Wes. I almost got it because it had a compiler from Aonix
called "Objective Ada for Windows" on the accompanying CD. It would
be interesting to see what that would be like. I just do not see
how once I start throwing windows up on the screen and responding
to messages, that that code is porting anywhere.

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Lawrence Kirby 11/1/97 12:00 AM

In article <ufzpnpw...@synquiry.com>  ** none **   writes:

>Craig Franck <clfr...@worldnet.att.net> writes:
>
>> Jon S Anthony <j...@synquiry.com> wrote:
>> >Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:
>> >
>> >> C and C++ compilers differ by so much that porting is often a Nightmare.
>> >> Before I get flamed, I'd like to talk to people who've actually ported
>> >> code cross-platform.
>> >
>> >That's about right.  Porting anything of substance written in C even
>> >between compilers on the _same_ platform is depressing.  FOE here...
>>
>> Sounds like you may have been a victim of the run of your patients.
>> Well written C code is very portable. I've seen compiler upgrades
>> break code, but only because it was trash to begin with.
>
>Yes, I thnk I can agree with that.  But the point is it is so _easy_
>(though not as much with ANSI C) to write such trash.  Even by
>"accident".

It depends on how well you know the language. One of the problems with
C is that it has become a "mass-market" language that is badly taught.
Not enough distinction is made between the standard language and what
it guarantees (and indeed how to make good use of those guarantees) and
implementation attributes and extensions. Once you do know the difference
it is quite easy to write portable code in C. It is also what the
comp.lang.c regulars try to promote.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Yet another stupid language war (was: ... the only languages you need!!) Dr John Stockton 11/1/97 12:00 AM

In article <01bce627$82afbec0$400d...@my-pc.neosoft.com> of Fri, 31 Oct
1997 18:05:12 in comp.lang.pascal.ansi-iso, Pat Rogers <pro...@acm.org>
wrote:

>  It is a shame that one cannot specify the range of an
>integer type, or the accuracy of a floating point type in C, for the sake
>of portability.  It is nice to have the compiler tell you that your
>application requirements cannot be met, rather than not knowing unless a
>(possibly obscure) bug is detected.

There are tricks in Pascal, which might adapt to Ada or C/C++ -

Type T = { integer or shortint or longint } ;

U = array [SizeOf(T)..2] of byte { should fail if T >16 bits } ;
V = array [2..SizeOf(T)] of byte { should fail if T< 16 bits } ;
W = array [SizeOf(T)..2, 2..SizeOf(T)] of byte
                                 { should fail if T<>16 bits } ;
Or,
UU = string [SizeOf(T)-2] ...
 
--
John Stockton, Surrey, UK.    j...@merlyn.demon.co.uk    Turnpike v1.12    MIME.
  Web URL: http://www.merlyn.demon.co.uk/ - FAQqish topics, acronyms and links.
  Correct 4-line sig separator is as above, a line comprising "-- " (SoRFC1036)
  Before a reply, quote with ">" / "> ", known to good news readers (SoRFC1036)

Flame bait count 146 (Re: ADA SUCKS, C/C++/JAVA RULES!!!!) Ken Garlington 11/1/97 12:00 AM

John Black wrote:
>
> I have tried and tried to program with Ada, but it is downright
> impossible.  I just don't see how anyone could - or would want to -
> use this outdated piece of crap.  It's back to C++ and Java for me.
> Hopefully Ada and other languages will go the way of the dinosaur and
> get hit by a meteor, disappearing from the face of the earth.

Acoording to my server, this is the 146th response to your flame bait.
Not sure how many you're trying for, but good luck!

Yet another stupid language war (was: ... the only languages you need!!) Craig Franck 11/1/97 12:00 AM

k...@helios.crest.nt.com (Kaz Kylheku) wrote:

>On the other hand, Microsoft's extended Java is proprietary and for Windows
>*only*.

I've heard a rumor that parts Windows 98 was going to be implemented
in Java so you can't boot without IE 4 or above on your system. :-)

[I think Bill is considering paying Interplanet Janet (Galaxy Girl
from another world) Reno her million dollar a day fine, basically
saying "screw you" on the browser issue...]

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


Portability: C, C++, Ada Alan E & Carmel J Brain 11/1/97 12:00 AM

Kaz Kylheku wrote:

> No. C is perceived as being portable. Those who perceive C++ as portable
> are naive or mistaken.

> C++ is not C however. What are your experiences with porting ANSI/ISO C code
> from one ISO compiler to another?

Fairly awful. You see, often there are compiler directives buried in
there that assume a pre-processor of a particular variety. Usually named
after a ruminant herbivore.

I agree that my experience is probably unusual, and that the ISO
standardisation of C has to make it vastly more portable than otherwise.
 
> Even though it's easy to introduce machine dependencies into C or C++ code, I
> would expect that most of your C++ headaches would be related to a lack of
> standardization, or the different pace of adaptation of the draft features by
> various vendors. (That alone is, to me, reason enough to avoid C++ if I can).

Concur.


 
> C porting headaches usually stem from legacy ``classic'' C code, in which the
> chief difficulty is bugs uncovered when one adds function prototypes.  Then
> there are dependencies of implementation characteristics: byte order, size of
> various types, and so forth.

Completely agree. Regardless of the reason though, C porting headaches
exist, as a general rule, do they not?

> Mind you, it's also possible to write Ada programs with similar dependencies.

Agree again. It's just difficult, and usual, is it not?
 
> Then there are uses of non-portable functions that are not in the standard
> library. E.g. it's impossible to port an XWindow application to Microsoft
> Windows without rewriting portions of it, but it's not really the fault of the
> underlying language.

Concur yet again. At least in part. What's needed is a standard platform
independent C/C++ header, which then allows a standard library (supplied
by the compiler, platform dependent) that allows the use of OSF/Motif or
whatever flavour of GUI you wish. Make this an ISO standard (stdgui.h
instead of stdio.h), and you've put a lot of programmers out of work (or
at least onto more productive tasks).

I might add the same thing would be very useful for Ada. Just as we have
TEXT_IO, why not GUI_IO? In fact, it would be _more_ useful for Ada, as
it would then clear up 90% of the porting problem, rather than 20% (says
he, picking representative figures out of thin air).

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

Porting Experiences (was Ada and Pascal etc ) Alan E & Carmel J Brain 11/1/97 12:00 AM

Jon S Anthony wrote:
>
> Craig Franck <clfr...@worldnet.att.net> writes:
>
> > Jon S Anthony <j...@synquiry.com> wrote:
>
> > >That rings true as well.  Typically porting Ada code between platforms
> > >or compilers amounts to a recompilation.
> >
> > Something like a Windows to Mac port? How platform specific was the
> > code? A recompilation port would be the ideal we all chase after. If
> > you have such great splatfrom tools, you should feel lucky.
>
> I've not had any need (or opportunity) to port to Mac.  The code in
> question went between VMS (VAX&Alpha), Sparc Solaris, Sparc SunOS,
> HP-UX, Intel Win/NT and across three different compilers.
>
> One was about 60K lines with lots of generics and tasks.
>
> Another was around 200K lines with lots of (goofy use) of generics.
>
> No #ifdefs stuff anywhere in site.

If that's C code you're talking about, I'm radically impressed.
If that's C++ code, then you're qualified to walk on water, or more
likely you're a purveyor of Tall Stories.
If that's Ada, then it's par for the course.
 
--
aeb...@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abr...@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

ADA SUCKS, C/C++/JAVA RULES!!!! nospam_...@sm.luth.se 11/1/97 12:00 AM

Charles R. Lyttle <lyt...@flash.net> wrote:

>For real programmers all this "My language can beat your language" is trash.

I disagree. In general, Eiffel is far superior to C++ as a language, for
example. Sadly, C++ has gained more industry acceptance, and thus it has
more tools, compilers e t c. MS-DOS also gained more acceptance than NeXT
Step, but MS-DOS was, in general, inferior to NeXT Step.

--

Erik Alapaeae
email: NOSPAM_...@sm.luth.se


Porting (was ADA and Pascal etc) Kaz Kylheku 11/1/97 12:00 AM

In article <fxtbu05...@isolde.mti.sgi.com>,

Matt Austern  <aus...@isolde.mti.sgi.com> wrote:
>The draft C++ standard is quite specific, and not at all random.  If
>you write
>    for (int i = 0; i < N; +i) {
>      // loop body
>    }
>then the scope of the variable i does not extend past the end of the
>loop.  The same holds for while loops and if statements.

That may be true of the current draft, but were there not some vaccilation
previously with regard to this issue?  Isn't it true that at some point, the
scope of variable i was confined to within the () parentheses of the for(),
making i invisible/unreachable in the statement that follows?


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting Experiences (was Ada and Pascal etc ) Jon S Anthony 11/1/97 12:00 AM

Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:

> Jon S Anthony wrote:
> >
> > Craig Franck <clfr...@worldnet.att.net> writes:
> >
> > > Jon S Anthony <j...@synquiry.com> wrote:
> >
> > > >That rings true as well.  Typically porting Ada code between platforms
> > > >or compilers amounts to a recompilation.
> > >
> > > Something like a Windows to Mac port? How platform specific was the
> > > code? A recompilation port would be the ideal we all chase after. If
> > > you have such great splatfrom tools, you should feel lucky.
> >
> > I've not had any need (or opportunity) to port to Mac.  The code in
> > question went between VMS (VAX&Alpha), Sparc Solaris, Sparc SunOS,
> > HP-UX, Intel Win/NT and across three different compilers.
> >
> > One was about 60K lines with lots of generics and tasks.
> >
> > Another was around 200K lines with lots of (goofy use) of generics.
> >
> > No #ifdefs stuff anywhere in site.
>
> If that's C code you're talking about, I'm radically impressed.

Of _course_ it's not C code, :-).  Check the context again: It refers to
Ada code.

> If that's C++ code, then you're qualified to walk on water, or more
> likely you're a purveyor of Tall Stories.

Exactly.  Actually, come to think of it, I don't even think being God
would help much...


> If that's Ada, then it's par for the course.

It's Ada code as the context confirms.

/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

ADA SUCKS, C/C++/JAVA RULES!!!! Charles R. Lyttle 11/1/97 12:00 AM

NOSPAM_...@sm.luth.se wrote:

As you know about Eiffel, you are probably one of the more experienced people.
Please understand that I am really talking to the newer guys.

I do hope that Eiffel and Java win out and C++ dies a well deserved death. But
in some cases, even though C++ is not as robust (big laugh) as Eiffel, it is
often the choice for the reasons you stated.  If life safety is involved Eiffel
or Ada are the only way to go. If low up-front cost is the ruling factor, then
C++ under some MS operating system is about the only thing available.  Be
flexible, learn more than one language, and do software engineering instead of
"programming".

--

Russ Lyttle

email : lyt...@mail.flash.net


Yet another stupid language war (was: ... the only languages you need!!) Jerry Sams 11/2/97 12:00 AM

In article <345A37...@gsg.eds.com>, nos...@gsg.eds.com says...

>
>Jerry Sams wrote:
>>
>> This is an advocacy group, my friend.
>
>What do you mean "this"? Of the six news groups this is posted to, only
>one is an advocacy group. Either the poster is to lame brained to read a
>charter or he simply doesn't care about netiquette (or both!) Whatever
>the merits of Ada, B, BCPL, C, C++, etc., such crossposting of an
>advocacy thread is either gross incompetence or trolling. alt.flame is
>indeed a better choice.
>

BROUGHT TO YOU BY THE POWER OF CUT-AND-PASTE

Why was the request to remove the offensive post itself posted to
"comp.lang.java.advocacy" where I am. I'm not in the pascal group (nor other
non-advocacy groups).

Looks like the requestor is doing the same thing as the offender complained
of, ie unwanted cross posting, also known as over-post-replying, or
too-difficult-to-remove-extraneous-newsgroups reply-posting.

Jerry


Flame bait count 146 (Re: ADA SUCKS, C/C++/JAVA RULES!!!!) Marcus Agrippa 11/2/97 12:00 AM

I think that guy made a record troll. Why people even bother responding to
such trash is beyond me.


John - N8086N

------------------------------------------------
Is Janet Reno completely incompetent or
simply a crook?

Home Page:
http://home.att.net/~miano

Home of the Delphi Component Writers' FAQ

EMail Address:
|m.i.a.n.o @    |
|w.o.r.l.d.n.e.t . |
|a.t.t .|
|n.e.t |


Full Name:
-------------------
-J.o.h.n?M.i.a.n.o-
-------------------


Flame bait count 146 (Re: ADA SUCKS, C/C++/JAVA RULES!!!!) Carsten Engelmann 11/2/97 12:00 AM

Marcus Agrippa (pres...@whitehouse.gov) wrote:

: In article <345B90...@flash.net>, Ken.Gar...@computer.org wrote:
: >John Black wrote:
: >>
: >> I have tried and tried to program with Ada, but it is downright
: >> impossible.  I just don't see how anyone could - or would want to -
: >> use this outdated piece of crap.  It's back to C++ and Java for me.
: >> Hopefully Ada and other languages will go the way of the dinosaur and
: >> get hit by a meteor, disappearing from the face of the earth.
: >
: >Acoording to my server, this is the 146th response to your flame bait.
: >Not sure how many you're trying for, but good luck!

: I think that guy made a record troll. Why people even bother responding to
: such trash is beyond me.
"C or C++" beats the Ada bait easily.
But well, it isn't that far off-topic here.

-Carsten


Yet another stupid language war (was: ... the only languages you need!!) Simon Wright 11/2/97 12:00 AM

Dr John Stockton <j...@merlyn.demon.co.uk> writes:

> In article <01bce627$82afbec0$400d...@my-pc.neosoft.com> of Fri, 31 Oct
> 1997 18:05:12 in comp.lang.pascal.ansi-iso, Pat Rogers <pro...@acm.org>
> wrote:
> >  It is a shame that one cannot specify the range of an
> >integer type, or the accuracy of a floating point type in C, for the sake
> >of portability.  It is nice to have the compiler tell you that your
> >application requirements cannot be met, rather than not knowing unless a
> >(possibly obscure) bug is detected.
>
> There are tricks in Pascal, which might adapt to Ada or C/C++ -

Who needs tricks?

pogner[8]$ cat sizes.ads
package Sizes is
  type T is range -32768 .. 32768;
  for T'Size use 16;
end Sizes;
pogner[9]$ gcc -c -gnatc sizes.ads
sizes.ads:3:18: size for "T" too small, minimum allowed is 17

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

ADA SUCKS, C/C++/JAVA RULES!!!! Supreme 11/2/97 12:00 AM

I understand your frustration. John I am a student who is in his second
year of programming in Ada adn I am very frustrated with it. But I am
willing to give Ada a chance if I can get some real world expericence
with it .Any info on that out there ?
Yet another stupid language war (was: ... the only languages you need!!) Jerry Sams 11/2/97 12:00 AM

In article <63d4d6$h...@bgtnsc03.worldnet.att.net>,
saskan@worldnet.att.net.DONTSPAMME says...
>
>Jerry Sams <jsNOSPAM@abcNOSPAM.com> wrote in article
><63bpfa$dnt$1...@usenet1.interramp.com>...
>: In article <01bce587$2efe61a0$8691440c@worldnet>,
>: saskan@worldnet.att.net.DONTSPAMME says...
>: >
>: >can you guys take these idiotic flames to alt.flame...
>: >i am here to learn/help/etc.. and it is damn near impossible with
>all
>: >of this bickering...
>:
>:
>: This is an advocacy group, my friend.
>:
>: Jerry
>:
>:
>advocacy? ummm then why am i reading this in the pascal groups?
>

Why was the request to remove the offensive post itself posted to
"comp.lang.java.advocacy" where I am. I'm not in the pascal group.

Looks like the requestor is doing the same thing as the offender complained
of, ie unwanted cross posting, also known as over-post-replying, or
too-difficult-to-remove-extraneous-newsgroups reply-posting.

Jerry


Yet another stupid language war (was: ... the only languages you need!!) Robert Dewar 11/2/97 12:00 AM

Simon wrote

  pogner[8]$ cat sizes.ads
  package Sizes is
    type T is range -32768 .. 32768;
    for T'Size use 16;
  end Sizes;
  pogner[9]$ gcc -c -gnatc sizes.ads
  sizes.ads:3:18: size for "T" too small, minimum allowed is 17


Robert notes

For the above program, the error message from GNAT is most certainly
correct, the given range does require 17 bits. Probably what is intended
here is -32768 .. +32767, which on a 2's complement machine (i.e. pretty
much all machines in practice), will fit in 16 bits fine.

Robert Dewar
Ada Core Technologies


ADA SUCKS, C/C++/JAVA RULES!!!! David A. Frantz 11/2/97 12:00 AM

Charles R. Lyttle wrote in message <345B7A48...@flash.net>...I would agree that to achieve low up front cost a microsoft platform would
have to be chosen.   But C++ has as many problems there as anywhere else why
not choose Visual Basic for a Win * platform.

dave


Porting (was ADA and Pascal etc) Lawrence Kirby 11/2/97 12:00 AM

In article <63d5l4$tub$1...@helios.crest.nt.com>
           k...@helios.crest.nt.com "Kaz Kylheku" writes:

...

>What's worse is that mixed declarations and statements are likely going to be
>part of the new C language.

Actually that finally resolves one of the biggest bugbears I have when
writing C. My experience has shown clearly that localising declarations
can be a big win for readability. Currently I have to use extra { }'s to do
that in some cases (notably for switch cases). With C9X I will finally be
able to write code in a natural way according to my preferred coding style.
Of course like may other features of C it will be possible to abuse this
to horrific effect. Nevertheless overall it is a win for the language.

>Ada makes so much more sense by requiring data declarations to precede the
>function body. Only scatter-brained programmers see a stylistic advantage in
>declarations interspersed with statements.

Perhaps I'm scatter-brained. I see advantage for locality of scope. This
also helps in specifying invariants with careful use of const.

>It's perhaps a remnant of brain
>damage inflicted by programming in BASIC. I try to even avoid declarations at
>the beginnings of nested blocks, even though C allows it. It's not necessary.

Of course it is not necessary but it can be very beneficial when used
sensibly.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Yet another stupid language war (was: ... the only languages you need!!) Richard A. O'Keefe 11/3/97 12:00 AM

Dr John Stockton <j...@merlyn.demon.co.uk> writes:
>There are tricks in Pascal, which might adapt to Ada or C/C++ -

>Type T = { integer or shortint or longint } ;

shortint and longint are not in any Pascal standard.

>U = array [SizeOf(T)..2] of byte { should fail if T >16 bits } ;

sizeof is not in any Pascal standard (7185, 10206, or the draft OOP stuff).

--
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

Porting Experiences (was Ada and Pascal etc ) Alan E & Carmel J Brain 11/3/97 12:00 AM

Craig Franck wrote:

> What is it about Ada that makes it portable? I would say it is the
> types of applications being developed, as well as the platforms,
> and, perhaps, quality of implementation.

You may have a point: A language that has the capability to make a a
well-defined interface, ie a language encouraging components, may well
mean that the type of applications it's used for are, by their very
nature, 'portable-friendly'.
OTOH Embedded systems, avionics, air etc don't strike me as being more
inherently 'similar' to one another as, for example, spreadsheets or
operating systems. Any evidence on this one?

> I just do not see
> how once I start throwing windows up on the screen and responding
> to messages, that that code is porting anywhere.

OK, so GUIs vary. My point is that even in two implementations where the
GUI is isolated/wrapped and so not "part of the problem", that
portability with C++ (forex) is considerably less than great.


> Last time I was in Barnes
> & Noble I saw "Ada 95 for C and C++ Programmers" by Simon Johnston,
> from Add-Wes. I almost got it because it had a compiler from Aonix
> called "Objective Ada for Windows" on the accompanying CD. It would
> be interesting to see what that would be like.

I can recommend it. Have a look at http://www.adahome.com/ which has a
link to an pre-publication version/extract from it.

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

ADA SUCKS, C/C++/JAVA RULES!!!! Nick Leaton 11/3/97 12:00 AM

http://www.eiffel.com/products/linux/index.html

At least one vendor of Eiffel compilers provides a low up-front cost at
$69.95
or ($99.95 with all the manuals and CD).  This is for personal non
corporate use, and is not crippled.

--

Nick

Trolling... Ron Thompson 11/3/97 12:00 AM

Jerry van Dijk wrote:
>
> It's that Eiffel is not included, otherwise one might start to
> think that you-know-who was back :-)

Ohno.  Don't even THINK that one.
--

rct

The opinions above are mine and mine alone.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Olof Oberg 11/3/97 12:00 AM

John Black wrote:
>
> Shombe, I feel your pain.  I'm embroiled in a Comparative Programming
> Language class where we have to program in Ada, and the thing is so
> impossible, I'm lucky to even get it to compile, never mind Constraint
> Errors.  And why bother sweating over a language that nobody uses!?
> At least I know C++, and I can pick up Java relatively easily.
> Knowing Ada and Pascal are almost as useful as knowing outer space
> basket weaving.

Well I think you have misunderstood what programming is. You
don't pick your problems after your favorite tool. You pick
your tools after the problems. I.e. knowing how Ada works is
not unuseful (Pascal is an other issue when Modula is a better
choice). Btw, isn't the goal of that course to get an insight
in different languages? Picking one you (and maybe most of your
class mates) know is generally a bad idea. Like here we get
ML as a first language. A language people rarely even heard
about and therefore they all stand on equal grounding when they
are supposed to go from writing programs to building software.

Personally I have only briefly covered Ada in a Programming
Langauge Theory course.

 /mill

--
#############################################################
# mil...@SPAMludd.luth.se # http://pedgr571.sn.umu.se/~mill #
#############################################################

ADA SUCKS, C/C++/JAVA RULES!!!! von...@ibm.net 11/3/97 12:00 AM

In <jfbode-ya023380002810972146390001@news.earthlink.net>, jfb...@nospam.mail.earthlink.net (John Bode) writes:
>In article <34557f2b...@news.mindspring.com>, nospam@nospam (John

>Black) wrote:
>
>> I have tried and tried to program with Ada, but it is downright
>> impossible.  I just don't see how anyone could - or would want to -
>> use this outdated piece of crap.  It's back to C++ and Java for me.
>> Hopefully Ada and other languages will go the way of the dinosaur and
>> get hit by a meteor, disappearing from the face of the earth.
>
>My, what a *cute* little troll.  Just makes you want to grab a 2x4 and beat
>the crap out of it, doesn't it?
>
>--
>John Bode
>one grumpy code monkey
>
>"Paranoia is just reality on a finer scale" -- Strange Days
>
>To email me directly, remove the 'nospam.' from my address.

Concur.  Wouldn't it be nice if there were a way to keep the children
off the newsgroup until they grow up.

Mark Von Hendy


Porting (was ADA and Pascal etc) Jon S Anthony 11/3/97 12:00 AM

fr...@genesis.demon.co.uk (Lawrence Kirby) writes:

> In article <63d5l4$tub$1...@helios.crest.nt.com>
>            k...@helios.crest.nt.com "Kaz Kylheku" writes:
...
> >Ada makes so much more sense by requiring data declarations to precede the
> >function body. Only scatter-brained programmers see a stylistic advantage in
> >declarations interspersed with statements.
>
> Perhaps I'm scatter-brained. I see advantage for locality of scope. This
> also helps in specifying invariants with careful use of const.

Actually, Ada supports this just fine.  But it does require that you
explicitly note such declarations:

function Foo (...) return ... is

    -- some local declarations preceding the body...

begin
    ... blah blah blah using the above declarations

    declare
        -- some declarations used for only the following code block...
    begin
        ... use the more localized declarations and
        ... possibly the outer ones as well
    end;
    ... the above declare block decls no longer available

end Foo;

The declarations in the declare block can be basically anything,
including generic instantiations, packages, tasks, dynamically sized
objects, etc.


> Of course it is not necessary but it can be very beneficial when used
> sensibly.

Fair enough.  Just note it is completely supported in Ada...

/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

Porting Experiences (was Ada and Pascal etc ) Jon S Anthony 11/3/97 12:00 AM

Craig Franck <clfr...@worldnet.att.net> writes:

> What is it about Ada that makes it portable? I would say it is the
> types of applications being developed, as well as the platforms,
> and, perhaps, quality of implementation.

I'm not sure that the types of applications or platforms have much to
do with it.  Quality of implementations, yes, sure.  However, I'd say
that the major reasons for portability are:

a) A pretty darn tight and precise standard.

b) Few "implementation defined" areas in that standard which are
visible to the programmer's model.

Makes a _HUGE_ difference.

/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

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/3/97 12:00 AM

Craig Franck wrote:
 
> What is it about Ada that makes it portable?

How about the ability to define variables by their range instead of
using implimentation-dependent terms like long and short? That's
certainly the most glaring deficiency in C with regard to portability.

--

                        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 spam...@library.lspace.org

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Shmuel (Seymour J.) Metz 11/3/97 12:00 AM

Scott A. Moore wrote:
 
> What is RUDE is to send your mail to newsgroups UNRELATED to the topic
> at hand. The original poster made this mistake. Everyone who follows is
> simply repeating this mistake.

While the original cross posting was a violation of netiquette, the
proper response is to set the followup to where it belongs, not to just
trim the newsgroups list.

> This discussion is about ADVOCACY and POLITICS.

Then why are you posting in comp.lang.ada? By *your* reasoning you
should have posted only to the advocacy groups, e.g.,
comp.lang.java.advocacy.

--

                        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 spam...@library.lspace.org

Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/3/97 12:00 AM

In article <345E3A...@gsg.eds.com>,

Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
>Craig Franck wrote:
>
>> What is it about Ada that makes it portable?
>
>How about the ability to define variables by their range instead of
>using implimentation-dependent terms like long and short? That's
>certainly the most glaring deficiency in C with regard to portability.

That depends on how you look at it. I'd say that it requires a little
more thought and skill to write portably with types that have sizes
that are not fully specified, but it's not impossible.

C gives you a header, <limits.h>, which gives you the constants LONG_MIN
and LONG_MAX. These tell you what the implementation's least and
greatest values of type long are. These values are guaranteed to be
at least -2^31+1 and 2^31-1 respectively.

If you assume that the long type has a range that is no larger than this,
you are OK. If you write your code under the assumption that the
range is LONG_MIN to LONG_MAX, you are also OK.

Sure, you might not be able to declare subtypes with more restricted ranges
like in Ada, but that doesn't mean that portability has gone out the window!


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting (was ADA and Pascal etc) Simon Wright 11/3/97 12:00 AM

fr...@genesis.demon.co.uk (Lawrence Kirby) writes:

> In article <63d5l4$tub$1...@helios.crest.nt.com>
>            k...@helios.crest.nt.com "Kaz Kylheku" writes:
>
> ...
>
> >What's worse is that mixed declarations and statements are likely going to be
> >part of the new C language.
>
> Actually that finally resolves one of the biggest bugbears I have when
> writing C. My experience has shown clearly that localising declarations
> can be a big win for readability. Currently I have to use extra { }'s to do
> that in some cases (notably for switch cases). With C9X I will finally be
> able to write code in a natural way according to my preferred coding style.
> Of course like may other features of C it will be possible to abuse this
> to horrific effect. Nevertheless overall it is a win for the language.

How does the C++ style localise scope? With the exception of variables
declared in "for" loops, the scope's from the point of declaration to
the end of the current block, not so?

I think that you're better off with the {}!


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

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Christopher Eltschka 11/3/97 12:00 AM

John Black wrote:
>
> ADA and Pascal are two of the most useless inventions Man has ever
> wasted space on this planet with.  These languages are hard to learn,
> have zero applications, and people who only know these languages can
> only find jobs at Taco Bell!  Smart programmers spend their time
> learning only C, C++, and Java in that order.

Sorry, I have to disagree very much.

1. Ada and Pascal are not useless. You might f.ex. think that space
   rockets are useless; but there's probably a good reason they are
   programmed in Ada, and not in C...

2. Smart programmers learn Pascal first (because then they learn
   *programming*, not hacking). Next they go on to C++, as doing
   C first would be a waste of time (and learning C++ first will
   make you a better C programmer later, as well). Then they have
   a look at other languages (functional, logical, ...) so they
   get used to other paradigms as well. And they learn some
   Assembler, so they have a clue about what's going on beyond
   the surface of their programming language.
   Someone who doesn't want to know anything but C, C++ and Java
   can't be called a smart programmer (s.o. who only wants to know
   about Pascal can't be called one, as well, though).

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 11/3/97 12:00 AM

In article <63c3n8$nhp$1...@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <o...@goanna.cs.rmit.edu.au> wrote:
>I picked up the September 1997 issue of the C/C++ Users Journal,
>and downloaded all of the source code for that issue.
>How many of the C++ programs could I compile?
>
>        NONE OF THEM.

Part of your problem was the publication you refer to above.   As you probably
know, the CUJ is only good for playing ``spot the error'' when you are done
flipping through Playboy at your local magazine rack. :)

Your are extremely optimistic if you expect code from the CUJ to compile, not
to mention adhere to some programming language standard and have conservative
portability assumptions.  :)

>I got one of them working after about half an hour of hacking; the
>others defeated me.

You probably spent more time right there than what it took to write and verify
the entire article before printing. :)


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting Experiences (was Ada and Pascal etc ) Marin David Condic, 561.796.8997, M/S 731-96 11/3/97 12:00 AM

Craig Franck <clfr...@WORLDNET.ATT.NET> writes:
>What is it about Ada that makes it portable? I would say it is the
>types of applications being developed, as well as the platforms,
>and, perhaps, quality of implementation. Last time I was in Barnes

>& Noble I saw "Ada 95 for C and C++ Programmers" by Simon Johnston,
>from Add-Wes. I almost got it because it had a compiler from Aonix
>called "Objective Ada for Windows" on the accompanying CD. It would
>be interesting to see what that would be like. I just do not see

>how once I start throwing windows up on the screen and responding
>to messages, that that code is porting anywhere.
>
    I'd agree with the assessment about putting windows up on a
    screen. The only way this *might* be considered portable is that,
    for example, WinNT runs on more platforms than Pentium boxes, so
    sticking to the Win32api, your code will port. No such luck if you
    try to take it to a Motif box.

    I've had lots of success porting Ada code both from Ada83
    compilers to Ada95 compilers, between different vendors compilers
    for the same hardware and between dramatically different machine
    architectures. (Embedded M680x0 to Sun Unix & similar) Since I'm
    dealing primarily with embedded application code that does no I/O
    of its own, the ports have been very successful and mostly
    painless. (I had to modify some packages that had embedded
    assembler statements and eliminate a couple of calls to some
    vendor supplied code and that was about it.) Its always the I/O
    that gets you on a port because that's where the language has to
    interface to things beyond its control. Even with Text_IO as your
    only interface, you'll find variations in behavior across
    platforms - even with the same compiler vendor. (I've found some
    variance using GNAT between Sun/Unix and Pentium/WinNT concerning
    terminal I/O behavior and GNAT is a perfectly fine example of
    portable compiler technology.)

    I don't know that there will ever be a good answer to this issue.
    Certainly this is not a problem peculiar to Ada - C, C++, et alia
    are all going to be plagued with the same troubles so it would not
    be fair to say "Ada sucks because when I program I/O code, it
    doesn't port from Sun/Unix/Motif to IBM-370/MVS/Punchcards..." Yet
    all too often Ada (and other languages) are attacked for
    completely silly reasons - usually by inexperienced students who
    have not yet learned much about computers, operating systems and
    programming languages.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  COND...@PWFL.COM
===============================================================================
    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."
        --  G.K. Chesterton
===============================================================================

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Marin David Condic, 561.796.8997, M/S 731-96 11/3/97 12:00 AM

John Black <nos...@NOSPAM.AMERICAN.EDU> writes:
>ADA and Pascal are two of the most useless inventions Man has ever
>wasted space on this planet with.  These languages are hard to learn,
>have zero applications, and people who only know these languages can
>only find jobs at Taco Bell!  Smart programmers spend their time
>learning only C, C++, and Java in that order.
>
    Does anybody remember a certain Right Reverend who used to lurk
    about this newsgroup from time to time. Is it possible that he's
    returned under a different guise? I guess I'll find out if my boss
    starts getting calls about what an asshole I am and there are
    public threats of lawsuits.

    Or maybe Mr. Black is just some graduate student's artificial
    intelligence experiment? So far, I'd only give it a grade of C-
    (C-- ?) since it hasn't exhibited much "intelligence" - artificial
    or otherwise.

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  COND...@PWFL.COM
===============================================================================
    "Having an open mind is nothing. The object of opening the mind, as
    of opening the mouth, is to shut it again on something solid."
        --  G.K. Chesterton
===============================================================================

Yet another stupid language war (was: ... the only languages you need!!) John G. Volan 11/3/97 12:00 AM

Richard Curzon wrote:
>
> No, Sun is trying hard to prevent that...  They are tying it to their
> proprietary platform, and trying to handicap it on Windows.  Which is
> against the interests of the majority of computer owners.
>
> MS is trying hard to liberate the language from the Sun proprietary
> platform.

Good Lord! This is like saying that the glorious and benevolent Red Army
"liberated" Eastern Europe whereas the Marshall Plan was an insidious
capitalist Allied plot to enslave Western Europe and incarcerate West
Berlin behind a Wall! :-) :-) :-)

--
usenet.Signature signature = new usenet.Signature (
    /*name:       */ "John G. Volan",
    /*employer:   */ "Raytheon/TI Advanced C3I Systems, San Jose",
    /*workEmail:  */ "jo...@ac3i.dseg.ti.com",
    /*homeEmail:  */ "john...@sprintmail.com",
    /*twoCents:   */ "Java would be even cooler with Ada95's " +
                     "generics, enumerated types, function types, " +
                     "named parameter passing, etc...",
    /*disclaimer: */ "These views not packaged in COM.ti.dseg.ac3i, " +
                     "so loading them throws DontQuoteMeError. :-) ");

Yet another stupid language war (was: ... the only languages you need!!) Simon Wright 11/3/97 12:00 AM

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

Well, after I'd posted it occurred to me that I wasn't perhaps stricly
on the point that the original poster was making.

However, what I was trying to show was that if you make a demand for a
size that can't be met, for whatever reason, *any* Ada compiler is
going to tell you that what you want can't be done; there's no need
for "tricks".

So I deliberately chose a range that wouldn't work, to demonstrate the
delightfully accurate error message that GNAT gives.

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

Porting Experiences (was Ada and Pascal etc ) Jerry van Dijk 11/4/97 12:00 AM

In article <9711031...@psavax.pwfl.com> cond...@PWFL.COM writes:

>                 WinNT runs on more platforms than Pentium boxes, so
>    sticking to the Win32api, your code will port.

Well, I guess experiences vary...

--

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

Yet another stupid language war (was: ... the only languages you need!!) Christopher Eltschka 11/4/97 12:00 AM

Bob Horvath wrote:

[...]

> Hmmmm.  How big is an int?

sizeof(int)

always.

:-)

ADA SUCKS, C/C++/JAVA RULES!!!! Alan E & Carmel J Brain 11/4/97 12:00 AM

Supreme wrote:
>
> I understand your frustration. John I am a student who is in his second
> year of programming in Ada adn I am very frustrated with it. But I am
> willing to give Ada a chance if I can get some real world expericence
> with it .Any info on that out there ?

Any problems in particular?

The following is a bit of a plug, but may just help you:

http://www.adfa.oz.au/CS/student-info/ada/index.html

This contains the Ada lecture notes for the CS1 course here at ADFA
(Australian Defence Force Academy). Are they perfect? Nope. But they're
not too bad, and have heaps of examples (even if the style is not that
great IMHO - I hope to help 'better' it soon).

If your problems are not covered by the above URL, drop me a line, and
I'll give you as much help as I can (just like I do to my own students).

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

Porting Experiences (was Ada and Pascal etc ) Lawrence Kirby 11/4/97 12:00 AM

In article <345E3A...@gsg.eds.com> nos...@gsg.eds.com "Seymour J." writes:

>Craig Franck wrote:
>
>> What is it about Ada that makes it portable?
>
>How about the ability to define variables by their range instead of
>using implimentation-dependent terms like long and short? That's
>certainly the most glaring deficiency in C with regard to portability.

The portability implications of this are small or non-existent (there may
be performace implications in rare circumstances, and issues relating to
data sizes and external data formats). As ever the C language is designed
with the assumption that the programmer knows what he is doing. The use
of ranges implies that you know beforehand what those ranges will be.
In C you follow a set of rules:

1. If the range is contained within -32767 to 32767 then you use int

2. If the range is contained within -2147483647 to 2147483647 then you
   use long.

3. If you want to minimise space usage (such as for array elements or
   structure members) and the range is contained within -32767 to 32767 then
   you can use short. For -127 to 127 you can use signed char.

4. The unsigned types have larger positive ranges if your range is
   non-negative. Notably unsigned char typically corresponds to the
   notion of "byte" in most languages.

Stick to the guaranteed minimum ranges guaranteed by the standard and allow
for the ranges to be larger and there are no portability issues. This
covers the overwhelming majority of cases. C currently doesn't guarantee
anything beyond a 32 bit integer type so you will get portability issues if
you need something larger. That is a recognised problem that will be addressed
in C9X.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Porting Experiences (was Ada and Pascal etc ) Pat Rogers 11/4/97 12:00 AM

Kaz Kylheku <k...@helios.crest.nt.com> wrote in article
<63mcmm$r3s$1...@helios.crest.nt.com>...

> In article <345E3A...@gsg.eds.com>,
> Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
> >Craig Franck wrote:
> >
> >> What is it about Ada that makes it portable?
> >
> >How about the ability to define variables by their range instead of
> >using implimentation-dependent terms like long and short? That's
> >certainly the most glaring deficiency in C with regard to portability.
>
> That depends on how you look at it. I'd say that it requires a little
> more thought and skill to write portably with types that have sizes
> that are not fully specified, but it's not impossible.
>
> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
> and LONG_MAX. These tell you what the implementation's least and
> greatest values of type long are. These values are guaranteed to be
> at least -2^31+1 and 2^31-1 respectively.
>
> If you assume that the long type has a range that is no larger than this,
> you are OK. If you write your code under the assumption that the
> range is LONG_MIN to LONG_MAX, you are also OK.

That's missing the point.  By having application-specific ranges for
integers and accuracy for floating point types, an Ada programmer finds out
*at compile time* that their new target cannot handle the program they are
porting.  Sure, we can all play with assuming what the portable ranges are,
but compile-time checking finds them earlier and thereby cheaper, than
hopefully having users detecting a bug.  In Ada, we know predefined Integer
is at least 16 bits, but best approach is to avoid it when possible, since
the more portable alternative is available.

In all honesty, I think the reason this point is missed by so many is that
some languages cannot express ranges, so the concept of portability is
differing.

Another side of the issue is what can be done with the information that the
compile-time info provides.  For languages like C++ which can at least
check ranges by overloading indexing and checking the range of the
specified parameter, (and throwing an exception if violated), can the
compiler optimize away the check in the static (compile-time-known) cases?
Languages which know at compile time what the ranges can be and can do the
flow analysis can remove unnecessary checks.  (Ada is such a language.)

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Ted Lyngmo 11/4/97 12:00 AM

Bob Horvath wrote:
>
> Hmmmm.  How big is an int?

As I've understood it, an int has two legal sizes. A short has only one,
and the same goes for a long. I believe that there were a lot of
different compilers on the market before C was standardised. Some used 2
byte int and some used 4 byte ints.

short = 2      bytes
int   = 2 or 4 bytes
long  = 4      bytes

If this is true, I see no reason for ever using ints in new C programs.

Kind regards,
Ted Lyngmo

________________________________________________________________________
  Ericsson Hewlett-Packard                             Lyncon
     Telecommunications                      Computer & Music Consulting
  phone :+46-(0)31-7462691                     phone :+46-(0)31-129234
mailto:qhs...@aom.ericsson.se                  mailto:t...@lyncon.se

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Marcelo Meira 11/4/97 12:00 AM

Daniel Anderson wrote:
>
> In article <345F49A2...@aom.ericsson.se>, qhs...@aom.ericsson.se says...

> >
> >Bob Horvath wrote:
> >>
> >> Hmmmm.  How big is an int?
> >
> >As I've understood it, an int has two legal sizes. A short has only one,
> >and the same goes for a long. I believe that there were a lot of
> >different compilers on the market before C was standardised. Some used 2
> >byte int and some used 4 byte ints.
> >
> >short = 2      bytes
> >int   = 2 or 4 bytes
> >long  = 4      bytes
> >
> >If this is true, I see no reason for ever using ints in new C programs.
>
> Actually, the size of the variables (the byte sizes) depend on the operating
> system.

Illustrating, in an IRIX64 system:

short = 2 bytes
int   = 4 bytes
long  = 8 bytes

E agora, Jose'?

--

----------------
Marcelo L. Meira
Programmer
Western Geophysical - (713) 963-2679

Mixing declarations and statements (Re: Porting (was ADA and Pascal etc)) Éamonn McManus 11/4/97 12:00 AM

fr...@genesis.demon.co.uk writes:

>            k...@helios.crest.nt.com "Kaz Kylheku" writes:
> >What's worse is that mixed declarations and statements are likely going to be
> >part of the new C language.
> Actually that finally resolves one of the biggest bugbears I have when
> writing C. My experience has shown clearly that localising declarations
> can be a big win for readability. Currently I have to use extra { }'s to do
> that in some cases (notably for switch cases). With C9X I will finally be
> able to write code in a natural way according to my preferred coding style.

I think switch cases are a particularly bad example of where this
feature is advantageous.  Where in current C you write either:

    int x;

    switch (thing) {
    case one:
        x = whatever();
        use(x);
        break;
    case two:
        x = maybe();
        use(x);
        break;
    }

or

    switch (thing) {
    case one:
        {
            int x = whatever();
            use(x);
            break;
        }
    case two:
        {
            int x = maybe();
            use(x);
            break;
        }
    }

with the exciting new feature you can write:

    switch (thing) {
    case one:
        int x = whatever();
        use(x);
        break;
    case two:
        int x = maybe();
        use(x);
        break;
    }

Except I very much hope that you can't, since that would be a multiple
declaration of x.  Which x would be referred to in common code that
you arrived at via goto?  Presumably the new C will allow the first
declaration but require the `int' to be left off the second, turning
it back into a lowly statement.  That's terrible programming practice of
course because you're having the meaning of one switch case depend on
the way another one was written.

If you start introducing declarations into your switch cases you're
going to run into this sort of problem all the time.  I did in Java
before I stopped doing it; in fact I find that in Java declarations tend
to migrate up towards the start of the method, where they would be in C.
Nonetheless the new C feature is easy to implement and understand and is
fairly often useful.

,
Eamonn                                        http://www.gr.opengroup.org/~emcmanus
  "Then I realized I was in France and, in fact, the gibberish was French"
  -- R Johnson

Mixing declarations and statements (Re: Porting (was ADA and Pascal etc)) Charles Hixson 11/4/97 12:00 AM

Peter Seebach wrote:
/* snip */

>
> >That's terrible programming practice of
> >course because you're having the meaning of one switch case depend on
> >the way another one was written.
>
Actually, I believe that it's worse than that.  The variables are
allocted at run time, so if the first case doesn't end with a break,
then if you follow the path through the first case, then the second case
MUST NOT declare the int, but only use it.  However if you follow the
path directly through the second case, then the second case MUST delcare
the int.  And this can only be detected at run-time (I hope I'm wrong
about this.  It's been a few of years since I did any significant amout
of C programming, and I stayed away from this kind of construct then,
but that's the way I remember it).
--
Charles Hixson        charle...@earthling.net
(510) 464-7733        or chi...@mtc.dst.ca.us

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Ron Natalie 11/4/97 12:00 AM

Marcelo Meira wrote:

> > Actually, the size of the variables (the byte sizes) depend on the operating
> > system.
>
> Illustrating, in an IRIX64 system:
>
> short = 2 bytes
> int   = 4 bytes
> long  = 8 bytes
>
Actually, it's even worse than that, it varies on the implementation,
not just the OS.  It's perfectly valid (and happens on IRIX) that
different compilers (or settings) can cause the sizes to change.

Yet another stupid language war (was: ... the only languages you need!!) Phosphor 11/4/97 12:00 AM

On Mon, 3 Nov 1997, John G. Volan wrote:

|Richard Curzon wrote:
|>
|> No, Sun is trying hard to prevent that...  They are tying it to their
|> proprietary platform, and trying to handicap it on Windows.  Which is
|> against the interests of the majority of computer owners.
|>
|> MS is trying hard to liberate the language from the Sun proprietary
|> platform.
|
|Good Lord! This is like saying that the glorious and benevolent Red Army
|"liberated" Eastern Europe whereas the Marshall Plan was an insidious
|capitalist Allied plot to enslave Western Europe and incarcerate West
|Berlin behind a Wall! :-) :-) :-)

Hey! Go ahead and make fun of MS all you want, but not the Red Army... And
yes, those two statement you made were pretty much true--or, more true
than you may think. You don't think we implemented the Marshall plan for
purely benevolent reasons, do you? No, of course not. And the Red Army was
implemented for reasons other than benevolence as well.

_____________________________________________________________________ Phosphor
"Religion is the sigh of the opressed creature, the heart of a heartless
world, and the soul of soulless conditions. It is the opium of the
people." --Karl Marx


Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/4/97 12:00 AM

In article <01bce929$4a8cbe80$560b...@my-pc.neosoft.com>,

Pat Rogers <pro...@acm.org> wrote:
>Kaz Kylheku <k...@helios.crest.nt.com> wrote in article
><63mcmm$r3s$1...@helios.crest.nt.com>...
>> In article <345E3A...@gsg.eds.com>,
>> Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
>> >Craig Franck wrote:
>> >
>> >> What is it about Ada that makes it portable?
>> >
>> >How about the ability to define variables by their range instead of
>> >using implimentation-dependent terms like long and short? That's
>> >certainly the most glaring deficiency in C with regard to portability.
>>
>> That depends on how you look at it. I'd say that it requires a little
>> more thought and skill to write portably with types that have sizes
>> that are not fully specified, but it's not impossible.
>>
>> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
>> and LONG_MAX. These tell you what the implementation's least and
>> greatest values of type long are. These values are guaranteed to be
>> at least -2^31+1 and 2^31-1 respectively.
>>
>> If you assume that the long type has a range that is no larger than this,
>> you are OK. If you write your code under the assumption that the
>> range is LONG_MIN to LONG_MAX, you are also OK.
>
>That's missing the point.  By having application-specific ranges for
>integers and accuracy for floating point types, an Ada programmer finds out
>*at compile time* that their new target cannot handle the program they are
>porting.

But then the program is not portable. You are no longer talking about
portable programming. Your Ada program has failed to translate for a
target for which a conforming Ada implementation exists. It is therefore
not a portable Ada program.

I'm talking about writing programs that work anywhere, for which it is not
acceptable to fail to translate. I don't think that I'm missing the point.

What if you _have_ to get that program running on that target? You have
some revising to do, in effect creating a new variant of that program
which is more portable.

In C you can also write programs that fail to translate depending on the
capabilities of the target. E.g.

    #include <limits.h>

    #if CHAR_BIT != 9
    #error require a 9 bit char
    #endif

but this sort of thing isn't of particular interest to programmers who keep
utmost portability in mind. It's not an acceptable answer to issues of
portability.

>Sure, we can all play with assuming what the portable ranges are,
>but compile-time checking finds them earlier and thereby cheaper, than

In C, the portable ranges are given to you by the standard, so there is no need
to find them at compile time.

>hopefully having users detecting a bug.  In Ada, we know predefined Integer
>is at least 16 bits, but best approach is to avoid it when possible, since
>the more portable alternative is available.

What is the more portable alternative? To declare a type that has the specific
range -32767 to 32767? This has some clear advantages over using plain Integer,
but I don't see portability as being one of them. Or are you worried about some
implementation of Ada which only gives you a 15 bit Integer? Would that
not be a non-conforming implementation?


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting (was ADA and Pascal etc) Peter Seebach 11/4/97 12:00 AM

In article <x7v90v5...@pogner.demon.co.uk>,

Simon Wright  <si...@pogner.demon.co.uk> wrote:
>How does the C++ style localise scope? With the exception of variables
>declared in "for" loops, the scope's from the point of declaration to
>the end of the current block, not so?

Of course not!  How could anyone be so *stupid* as to think that
the clear explanation in the ARM is correct?  C++ being a very stable
language, and well designed at all times, the scope of the variable
is the for loop; it goes out of scope after the for loop's statement.

You may now drop the ARM down the memory hole.  C++ has always been
at war with Eurasia.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Kaz Kylheku 11/4/97 12:00 AM

In article <345F49A2...@aom.ericsson.se>,

Ted Lyngmo  <qhs...@aom.ericsson.se> wrote:
>Bob Horvath wrote:
>>
>> Hmmmm.  How big is an int?
>
>As I've understood it, an int has two legal sizes. A short has only one,

You haven't understood it.

A short is large enough to represent numbers in the range -32767 to
32767. An int is also large enough to represent numbers in the
same range. A long can represent numbers in the range -2147483647
to +2147483647.

A C implementation can supply larger actual ranges. Each conforming
implementation supplies a <limits.h> header that provides constants
that tell you what the actual ranges are.

For example, some implementations of C for IBM mainframes have 36 bit longs and
9 bit chars. Thus the ranges are actually greater than the minimum
requirements.

>and the same goes for a long. I believe that there were a lot of
>different compilers on the market before C was standardised. Some used 2
>byte int and some used 4 byte ints.
>
>short = 2      bytes
>int   = 2 or 4 bytes
>long  = 4      bytes

This table is a familiar part of popular C mythology, and is not grounded in
the language definition. For one thing, it is not true that an int
has the same representation as either short or long. It's possible for
an implementation to have three distinct representations for the three
types. For example: 16 bit two's complement short, 32 bit int, and 64 bit
long.

Knowing the number of bytes required to store a given integral type
is not useful to the vast majority of C programming tasks. Any program
which depends on a particular size or storage layout is non-portable.
It isn't the least bit interesting that an int is 4 bytes wide.
On a system with 16 bit bytes, the same 32 bit integer would be
only 2 bytes wide.

There may be unused bits in an integral type's storage layout---bits
which do not contribute to its value. Thus the number of bytes is not
directly related to the range of the type. And of course, bytes are
not necessarily eight bits wide.

A character type (char, signed char, unsigned char) is always one byte
wide, however, and all of its bits are value-contributing. The number
of bits in a byte is defined by the macro CHAR_BITS in <limits.h>.

>If this is true, I see no reason for ever using ints in new C programs.

There are lots of good reasons for using int in new C programs. If you don't
require the range to be greater than -32767 to 32767, and you are concerned
about performance, then int is a great choice. If you are concerned about
saving storage in aggregates, then short is your choice.  If you require a
larger range, but wish to remain portable, you have to switch to the type long.
If you don't need to represent quantities beyond -127 to 127, and want to save
storage, then you can use char.  But doing so may cost you some performance. To
save even more storage, you can declare small bit-field structure members.

On some modern compilers, the type long is actually a 64 bit type, so you might
waste space and memory bandwidth needlessly if you use it without a good reason
to do so.

--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/4/97 12:00 AM

In article <345f4...@isc-newsserver.isc.rit.edu>
           dwa...@rit.edu "Daniel Anderson" writes:

>>If this is true, I see no reason for ever using ints in new C programs.
>
>Actually, the size of the variables (the byte sizes) depend on the operating
>system.

The size of the variables is determined by the compiler. Some even provide
options to allow you to select different sizes.

I see that this has been excessively cross-posted. Follow-ups set to
comp.lang.c and comp.lang.c++ only (and then only a single instance of
each).

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/4/97 12:00 AM

Kaz Kylheku wrote:
>
> That depends on how you look at it. I'd say that it requires a little
> more thought and skill to write portably with types that have sizes
> that are not fully specified, but it's not impossible.
>
> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
> and LONG_MAX. These tell you what the implementation's least and
> greatest values of type long are. These values are guaranteed to be
> at least -2^31+1 and 2^31-1 respectively.
>
> If you assume that the long type has a range that is no larger than this,
> you are OK. If you write your code under the assumption that the
> range is LONG_MIN to LONG_MAX, you are also OK.
>
> Sure, you might not be able to declare subtypes with more restricted ranges
> like in Ada, but that doesn't mean that portability has gone out the window!

So the portable way to declare 33-bit integers is to declare them as
long and let them be 128 bits on some machines? I don't consider that a
viable option. To restate, there is no portable way to cause the
compiler to chose a size that is the best compromise between the problem
requirements and the natural byte sizes of the machine.

In Ada I give a range of values and the compiler figures out whether to
use, e.g., words, half words or double words. In PL/I I give a number of
bits (for binary) or a number of digits (for decimal) and the compiler
figures it out. In C I have to play games with, e.g., multiple versions
of my headers. Unless and until the new standard passes, this aspect of
C will remain a serious blot on the claims of portability.

--

                        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 spam...@library.lspace.org

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/4/97 12:00 AM

Craig Franck wrote:
 
> That was mentioned in an several e-mails I received.

Since I last posted I saw an article stating that the next C standard
will include a way to specify the required precision. That will be a
welcome change!

> It seems you can define the interface with the machine in Ada; in
> C, what you would do is keep the values in the portable range as
> defined by the standard. This isn't as bad as it would seeem. If
> an implementation decides 64-bit ints are the best representation,
> a short, int, and long could all be 64-bits. Portable software just
> wouldn't exceed 32,767 for an int.

Which is the same situation that we had when C first emrged, except that
8-bit processors are no longer an issue. If I need more than 32 bits,
how fo I declare it without getting 128 bits on some machines? With Ada
or PL/I the issue doesn't arise.

--

                        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 spam...@library.lspace.org

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/4/97 12:00 AM

Lawrence Kirby wrote:
>
> The portability implications of this are small or non-existent (there may
> be performace implications in rare circumstances, and issues relating to
> data sizes and external data formats). As ever the C language is designed
> with the assumption that the programmer knows what he is doing. The use
> of ranges implies that you know beforehand what those ranges will be.
> In C you follow a set of rules:
>
> 1. If the range is contained within -32767 to 32767 then you use int
>
> 2. If the range is contained within -2147483647 to 2147483647 then you
>    use long.
>
> 3. If you want to minimise space usage (such as for array elements or
>    structure members) and the range is contained within -32767 to 32767 then
>    you can use short. For -127 to 127 you can use signed char.
>
> 4. The unsigned types have larger positive ranges if your range is
>    non-negative. Notably unsigned char typically corresponds to the
>    notion of "byte" in most languages.

Those rules only apply if you are going from one 32-bit machine to
another; they have nothing to do with the definition of C itself and are
inapplicable when you have to move between different word sizes.

The C standard makes the size of an int implimentation dependent, and on
16-bit machines it is normally 16. On 64-bit machines int is usually 64,
and if you want 32 you specify short.

Now, admittedly this will change with the new standard, but as long as
it is still a draft it has nothing to do with the current language.

--

                        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 spam...@library.lspace.org

Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/4/97 12:00 AM

In article <345F95...@gsg.eds.com>,

Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
>Kaz Kylheku wrote:
>>
>> That depends on how you look at it. I'd say that it requires a little
>> more thought and skill to write portably with types that have sizes
>> that are not fully specified, but it's not impossible.
>>
>> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
>> and LONG_MAX. These tell you what the implementation's least and
>> greatest values of type long are. These values are guaranteed to be
>> at least -2^31+1 and 2^31-1 respectively.
>>
>> If you assume that the long type has a range that is no larger than this,
>> you are OK. If you write your code under the assumption that the
>> range is LONG_MIN to LONG_MAX, you are also OK.
>>
>> Sure, you might not be able to declare subtypes with more restricted ranges
>> like in Ada, but that doesn't mean that portability has gone out the window!
>
>So the portable way to declare 33-bit integers is to declare them as

There is no portable way to declare 33 bit integers. The current ISO standard
only guarantees 32 bits for the largest integral types that C offers.

>long and let them be 128 bits on some machines? I don't consider that a
>viable option.

Why not? It might not be the _cleanest_ option, but it's certainly viable.

>To restate, there is no portable way to cause the
>compiler to chose a size that is the best compromise between the problem
>requirements and the natural byte sizes of the machine.

Sure there is. Say we are talking about a signed quantity. You first identify
the range that it shall require. If it is within -127 to 127, you may use a
char type---IF it is important for you to save storage.  Otherwise you use int.
If the range is within -32767 to 32767, you use a short if saving storage is
important. Otherwise you use int.  If the range is outside -32767 to 32767 but
within -2^32+1 to 2^32-1, you use the type long. Otherwise if you require a
larger range, you are out of luck. To stay within the limits of strictly
conforing C, you must emulate some higher precision arithmetic.

So you see, it is quite easy to choose the appropriate type for a given range
with just a few simple guidelines. Of course, it's probably a good idea to
insulate yourself using typedef alias names in case your requirements change in
the future.

>In Ada I give a range of values and the compiler figures out whether to
>use, e.g., words, half words or double words. In PL/I I give a number of

How do you express the idea that storage is to be minimized? Just because
your type requires only the range -50 to +50 doesn't necessarily mean
that you want to pack it into a single byte! Or perhaps you _do_ want to
pack it into a single byte.

>bits (for binary) or a number of digits (for decimal) and the compiler

The people who invented UNIX and C were no strangers to PL/I. :) Multics
was written in it. You know where those /* */ comments come from.

>figures it out. In C I have to play games with, e.g., multiple versions
>of my headers. Unless and until the new standard passes, this aspect of

You don't need to do any such thing if you understand the language.
I've never had to play with multiple versions of a header or #ifdef nests.

I have seen plenty of code that does just that. In each case, it was because
the author hadn't learned to use the language properly.

>C will remain a serious blot on the claims of portability.

This simply isn't true. There may be blots on that claim, but this isn't one of
them. It's an imagined problem that perhaps stems from your inexperience with
that particular language.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/4/97 12:00 AM

In article <345F97...@gsg.eds.com>,

Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
 >Lawrence Kirby wrote:
 >>
 >> The portability implications of this are small or non-existent (there may
 >> be performace implications in rare circumstances, and issues relating to
 >> data sizes and external data formats). As ever the C language is designed
 >> with the assumption that the programmer knows what he is doing. The use
 >> of ranges implies that you know beforehand what those ranges will be.
 >> In C you follow a set of rules:
 >>
 >> 1. If the range is contained within -32767 to 32767 then you use int
 >>
 >> 2. If the range is contained within -2147483647 to 2147483647 then you
 >>    use long.
 >>
 >> 3. If you want to minimise space usage (such as for array elements or
 >>    structure members) and the range is contained within -32767 to 32767 then
 >>    you can use short. For -127 to 127 you can use signed char.
 >>
 >> 4. The unsigned types have larger positive ranges if your range is
 >>    non-negative. Notably unsigned char typically corresponds to the
 >>    notion of "byte" in most languages.
 >
 >Those rules only apply if you are going from one 32-bit machine to
 >another; they have nothing to do with the definition of C itself and are
 >inapplicable when you have to move between different word sizes.
 >
 >The C standard makes the size of an int implimentation dependent, and on
 >16-bit machines it is normally 16. On 64-bit machines int is usually 64,
 >and if you want 32 you specify short.

No C programmer who has a clue about portable coding would specify short
to get a 32 bit type---unless he was worried about using the smallest possible
type which fits, thus minimizing resource usage!

Note that Lawrence mentions ``performance implications'' because he knows that
if you follow the conservative rules, you might not necessarily use the
machine's resources in the best way. This is true if that machine provides data
types that have much larger ranges than what is minimally required.

If you want a type that is at least 32 bits wide, you specify long or unsigned
long. The language currently has no support for anything more. If you need 33
bits or more, there is no type which is guaranteed to satisfy. You either write
code to emulate the greater precision, or you leave the realm of portable C
coding and use some implementation-provided type like __longlong.

A good C89 compiler for a 64+ bit platform should have a mode which flips
longs back to 32 bits for compiling maximally portable programs that don't
make use of the extra generosity.

Look, if you find something factually wrong in a Lawrence Kirby posting, I
shall promptly mail you a lollipop! :)


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Rud Merriam 11/4/97 12:00 AM

Jon S Anthony wrote in message ...
>Alan E & Carmel J Brain <aeb...@dynamite.com.au> writes:
>
>> C and C++ compilers differ by so much that porting is often a Nightmare.
>> Before I get flamed, I'd like to talk to people who've actually ported
>> code cross-platform.
>
>That's about right.  Porting anything of substance written in C even
>between compilers on the _same_ platform is depressing.  FOE here...

Gee, I guess that C satellite communications system I designed in the late
80's must not have been as well done as I thought. There were three
components for the system. Each would run on a PC using Borland C and on the
target system cross-compiled C to a 6809. The trick - cross-compile and test
frequently and often. To write portable code you have to start with that
goal in mind.

>
>> In my own, albeit limited experience, the problems I've had with any
>> C or C++ port are greater than all the problems I've had with Ada
>> crossplatform put together!
>
>That rings true as well.  Typically porting Ada code between platforms
>or compilers amounts to a recompilation.

I have a C++ app that is intended to be portable. We are currently having
problems with STL because the first pass is in VC++ using that STL which is
pretty close to the standard draft. But once we can get an STL that works
with the other compilers (Watcom for one) I expect 80% or more of the code
to port with no changes. The other 20% is mainly OS specific code and all
that is isolated in separate functions. Implement those functions and you
have ported the code.

I used to have a serial comm library that was portable across 4 compilers
*and* 5 different types of serial ports. All that was needed to support new
systems was to tie into a real-time clock tick, the serial port interrupt,
and write the low level get/put characters.

>
>/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

Rud Merriam
Houston


ADA SUCKS, C/C++/JAVA RULES!!!! Guest 11/4/97 12:00 AM

The question is not if you like or not a thing. I myself prefer C++, but
I respect other people, and think that your article is very rude and
ignorant. If you hate Ada, ignore its newsgroup. Simple, isn't it?

Best wishes,

Gabor Varga

ADA SUCKS, C/C++/JAVA RULES!!!! Michael Stark 11/4/97 12:00 AM

John Gluth wrote:
>
> In article <MPG.ec125666...@news.primenet.com> Mike Copeland,
> mrc...@primenet.com writes:
> >Learning Ada should be considered an
> >educational experience, at best, because no one uses it.
>
> Dang...what HAVE I been doing then, these past few years?
>
> You ever fly on the 777?  The flight control system is in Ada.
> If you land in Canada, their air traffic control system is (or will
> be...not
> sure if it's been delivered) in Ada.
> We fly missiles with Ada.  Shoot 'em down with Ada, too...
>
> But hey, I've never done an applet for the web in Ada, or anything else
> important like that...
Oh, but I have (well, actually the applet is Ada application code
compiled w/ AppletMagic and Java GUI code).  Check

http://fdd.gsfc.nasa.gov/orb_prop/version2/orbit_propagator.html

if you want to look at the ground tracks of actual satellites or
play with orbit parameters of your own.  Yeah, it's a toy program,
but we are looking at doing larger programs in Java and by compiling
existing Ada into Java.

However, John's point about the superiority of Ada in safety critical
systems (I am infering that is the point ;) is well taken.  But Ada can
do so much more -- I've used it for over 10 years without doing anything
safety critical, and still prefer it to the other languages I've used
professionally (although now I'm back in school I'm having fun w/ LISP,
but I wouldn't want to implement 777 flight software in it ;)


Mike
--
Michael Stark
Goddard Research & Study Fellow
University of Maryland, College Park
e-mail: mst...@cs.umd.edu
"The beautiful thing about learning is that
 nobody can take it away from you" -- B.B. King
http://fdd.gsfc.nasa.gov/orb_prop/version2/orbit_propagator.html

How big is an int? Richard Stamp 11/4/97 12:00 AM

In article <345F49A2...@aom.ericsson.se>,
Ted Lyngmo  <qhs...@aom.ericsson.se> wrote:
>
>short = 2      bytes
>long  = 4      bytes

These are the effective _minimum_ lengths (though in fact, the size is
defined in terms of a minimum range of values to be held) but individual
compilers are free to exceed them if they wish.

>int   = 2 or 4 bytes

Right idea, but an int doesn't have to be the same as a short or a long;
it can be anywhere in between.

>If this is true, I see no reason for ever using ints in new C programs.

ints are supposed to have the natural size for the architecture, so
should be fast to work with: this makes them good choices for things
like loop counters.

Cheers,
Richard
--
Richard Stamp
Churchill College, Cambridge

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Daniel Anderson 11/4/97 12:00 AM

In article <345F49A2...@aom.ericsson.se>, qhs...@aom.ericsson.se says...
>
>Bob Horvath wrote:
>>
>> Hmmmm.  How big is an int?
>
>As I've understood it, an int has two legal sizes. A short has only one,
>and the same goes for a long. I believe that there were a lot of
>different compilers on the market before C was standardised. Some used 2
>byte int and some used 4 byte ints.
>
>short = 2      bytes
>int   = 2 or 4 bytes
>long  = 4      bytes
>
>If this is true, I see no reason for ever using ints in new C programs.

Actually, the size of the variables (the byte sizes) depend on the operating
system.


Mixing declarations and statements (Re: Porting (was ADA and Pascal etc)) Peter Seebach 11/4/97 12:00 AM

In article <swu...@kaa.gr.osf.org>,

Éamonn McManus <emcm...@gr.opengroup.org> wrote:
>with the exciting new feature you can write:

>    switch (thing) {
>    case one:
>        int x = whatever();
>        use(x);
>        break;
>    case two:
>        int x = maybe();
>        use(x);
>        break;
>    }

>Except I very much hope that you can't, since that would be a multiple
>declaration of x.

I think you are correct.

>Presumably the new C will allow the first
>declaration but require the `int' to be left off the second, turning
>it back into a lowly statement.

Yes.

>That's terrible programming practice of
>course because you're having the meaning of one switch case depend on
>the way another one was written.

So, what you might do is
        switch (thing) {
        int x;
        case one:
        ...
        }
and, of course, you can't count on x being initialized, because you'll
be jumping in past the initializer.

>Nonetheless the new C feature is easy to implement and understand and is
>fairly often useful.

That's my reading of it.  I still slightly prefer blocks, so I can
clearly end the scope of a declaration, but that's just a matter
of personal style.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

s/w manual Nameir Ismeil 11/4/97 12:00 AM


Hi all, I am soory if this subject is not related to your newsgroup. I am sending

Newsgroups: comp.lang.c,comp.lang.c++,news.groups, comp.os.linux.advocacy, news.softw
are.readers, comp.infosystems.www.browsers,news.software.misc, alt.censorship,news.so
ftware.anu-news, news.software.b,news.software.readers,news.newusers.questions
Subject: s/w manuals


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Peter Mayne 11/4/97 12:00 AM

On Tue, 04 Nov 1997 18:33:45 GMT, mark@$tecnomen$.ie (Mark Burkley)
wrote:

> int is *normally* the register size of the machine you
>are using.  If you are using a 64-bit platform, an int will probably
>be 8 bytes.

On an Alpha (a 64 bit platform) running DIGITAL UNIX using cc:

short = 2
int   = 4
long  = 8

On an Alpha (a 64 bit platform) running Windows NT using VC++ 5 or
OpenVMS using DECC:

short = 2
int   = 4
long  = 4

>>Actually, the size of the variables (the byte sizes) depend on the operating
>>system.
>
>More usually, it depends on the CPU.

I'd say both of these statements are wrong. It depends on the
compiler. I've used languages with 64 bit integers on 8 bit systems:
why should the operating system or the CPU determine what the language
does, beyond the K&R suggestion of "typically reflecting the natural
size of integers on the host machine"?

In the case of Alpha, it may have 64 bit registers, but it has natural
32 bit and 64 bit datatypes. Is one more "natural" than the other?

PJDM
Digital Equipment Corporation (Australia), Canberra, ACT
-------------------------------------------------------------------------------
These are my opinions, and have nothing to do with Digital.
This was edited by a wheelbarrow full of walruses.

Mixing declarations and statements (Re: Porting (was ADA and Pascal etc)) Kaz Kylheku 11/4/97 12:00 AM

In article <345F6265...@earthling.net>,

Charles Hixson  <charle...@earthling.net> wrote:
>Peter Seebach wrote:
>/* snip */
>>
>> >That's terrible programming practice of
>> >course because you're having the meaning of one switch case depend on
>> >the way another one was written.
>>
>Actually, I believe that it's worse than that.  The variables are
>allocted at run time, so if the first case doesn't end with a break,
>then if you follow the path through the first case, then the second case
>MUST NOT declare the int, but only use it.  However if you follow the
>path directly through the second case, then the second case MUST delcare
>the int.  And this can only be detected at run-time (I hope I'm wrong
>about this.  It's been a few of years since I did any significant amout
>of C programming, and I stayed away from this kind of construct then,
>but that's the way I remember it).

That isn't how these languages generally work. Declarations are gathered
by the translator, and it can then decide how automatic storage shall be
laid out prior to the program's execution.

In C, an object has defined storage whether or not you skip its declarator.  A
declarator is not an executable statement which dynamically allocates storage!
However, if you skip over declarations, their associated initializations
will not be performed.

For example:

        goto there;        /* no problem */

        {
                int x = 2;
        there:
                x = 1;


There is nothing incorrect about doing this. The object x is defined even if
you jump into the middle of the block. But at that point, it has an
indeterminate value, rather than the value 2. This is corrected in the
subsequent statement which assigns it the value 1.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Mixing declarations and statements (Re: Porting (was ADA and Pascal etc)) Peter Seebach 11/5/97 12:00 AM

In article <345F6265...@earthling.net>,
Charles Hixson  <charle...@earthling.net> wrote:
>Actually, I believe that it's worse than that.  The variables are
>allocted at run time, so if the first case doesn't end with a break,
>then if you follow the path through the first case, then the second case
>MUST NOT declare the int, but only use it.  However if you follow the
>path directly through the second case, then the second case MUST delcare
>the int.

No.  To the best of my knowledge, the rule is that any line of code which,
if there were no jumps, is in the scope for a variable has that variable
in scope, although an initializer may not occur unless control passes through
the declaration.

>And this can only be detected at run-time (I hope I'm wrong
>about this.  It's been a few of years since I did any significant amout
>of C programming, and I stayed away from this kind of construct then,
>but that's the way I remember it).

I believe you're wrong; the initialization is up in the air, but the
declaration works sensibly.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Porting Experiences (was Ada and Pascal etc ) Craig Franck 11/5/97 12:00 AM

"Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>Lawrence Kirby wrote:
>>
>> The portability implications of this are small or non-existent (there may
>> be performace implications in rare circumstances, and issues relating to
>> data sizes and external data formats). As ever the C language is designed
>> with the assumption that the programmer knows what he is doing. The use
>> of ranges implies that you know beforehand what those ranges will be.
>> In C you follow a set of rules:
>>
>> 1. If the range is contained within -32767 to 32767 then you use int
>>
>> 2. If the range is contained within -2147483647 to 2147483647 then you
>>    use long.
>>
>> 3. If you want to minimise space usage (such as for array elements or
>>    structure members) and the range is contained within -32767 to 32767 then
>>    you can use short. For -127 to 127 you can use signed char.
>>
>> 4. The unsigned types have larger positive ranges if your range is
>>    non-negative. Notably unsigned char typically corresponds to the
>>    notion of "byte" in most languages.
>
>Those rules only apply if you are going from one 32-bit machine to
>another; they have nothing to do with the definition of C itself and are
>inapplicable when you have to move between different word sizes.

Huh? Those limits are contained in the standard.

       5.2.4.2 Numerical limits.
       ...
       5.2.4.2.1 Sizes of integral types <limits.h>
       ...
       Their implementation-defined values shall be equal or greater
       in magnitude (absolute value) to those shown, with the same
       sign.
       ...
       -- minimum value for an object of type int
       INT_MIN                                  -32767

       -- maximum value for an object of type int
       INT_MAX                                  +32767

>The C standard makes the size of an int implimentation dependent, and on
>16-bit machines it is normally 16. On 64-bit machines int is usually 64,
>and if you want 32 you specify short.

Yes, but portable ranges are defined by the standard, and that's
what you should go by.

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Corey Minyard 11/5/97 12:00 AM

mark@$tecnomen$.ie (Mark Burkley) writes:

>
> dwa...@rit.edu (Daniel Anderson) wrote:
>
> >In article <345F49A2...@aom.ericsson.se>, qhs...@aom.ericsson.se says...
> >>
> >>Bob Horvath wrote:
> >>>
> >>> Hmmmm.  How big is an int?
> >>
> >>As I've understood it, an int has two legal sizes. A short has only one,
> >>and the same goes for a long. I believe that there were a lot of
> >>different compilers on the market before C was standardised. Some used 2
> >>byte int and some used 4 byte ints.
> >>
> >>short = 2      bytes
> >>int   = 2 or 4 bytes
> >>long  = 4      bytes
> >>
> >>If this is true, I see no reason for ever using ints in new C programs.
>
> It's not true.  int is *normally* the register size of the machine you

> are using.  If you are using a 64-bit platform, an int will probably
> be 8 bytes.  A long must be at least as long as this.  In this case,
> it would be quite reasonable to have a 4 byte short.
>
> Of course, the standard says it can be any size you like so long as an
> int is at least as long as a short and a long is as least as long as
> an int and they are all meet the minimum sizes.  AFAIK, they could
> legitimately be all the same size.

>
> >Actually, the size of the variables (the byte sizes) depend on the operating
> >system.
>
> More usually, it depends on the CPU.
>

I can strongly validate this.  I have used C on a TMS320C30 and
TMS320C40 (fine DSPs for the job I was doing).  On that platform,
EVERYTHING is 32-bits.  char, short, int, long, float, and double.
sizeof(<any basic type>) would return 1.  The DSP could only address
32-bit quantities.  I managed to write portable code (the shared
memory buffer pipe code between the DSP and host used exactly the same
code on each side) but it took great care.

You can write portable low-level C code if you do it very carefully
and are willing to put up with some messiness with macros and some
header files that require porting between platforms.  Writing
high-level portable C would be easy if all OS's include files were
in the same place and everyone was careful about data ranges.
Unfortunately, that is not the case.

I think Ada is where this thread all started.  It is easier to write
portable low-level Ada code because of the precise sizing, alignment
and layout facilities it provides.  It still requires care, though,
but it is a lot cleaner, more clear, and easier to maintain.  I have
written many hundreds of thousands of lines of C code and maybe 50,000
lines of Ada code.  I personally prefer Ada because it lets me be in
complete control of what is happenning while still abstracting things
to a higher level.  It is not a silver bullet and it takes some
learning and discipline to use Ada well.  However, I don't want to go
back.  I might have to, though, because IMHO the biggest problem with
Ada is getting it on the needed target platforms.  My boss gave me the
news I was dreading, if we can't get an Ada compiler we can afford for
our target we are probably porting the code I have written to C.

I guess I've rambled on enough.  Sorry, but I thought the int size
needed some validation.

--
Corey Minyard               Internet:  min...@acm.org
  Work: min...@nortel.ca       UUCP:  min...@wf-rch.cirr.com

Porting Experiences (was Ada and Pascal etc ) James Youngman 11/5/97 12:00 AM

>>>>> "Shmuel" == Shmuel (Seymour J ) Metz <nos...@gsg.eds.com> writes:

  Shmuel> Lawrence Kirby wrote:
  >> 1. If the range is contained within -32767 to 32767 then you use
  >> int
  >>
  >> 2. If the range is contained within -2147483647 to 2147483647
  >> then you use long.
  >>
  >> 3. If you want to minimise space usage (such as for array
  >> elements or structure members) and the range is contained within
  >> -32767 to 32767 then you can use short. For -127 to 127 you can
  >> use signed char.
  >>
  >> 4. The unsigned types have larger positive ranges if your range
  >> is non-negative. Notably unsigned char typically corresponds to
  >> the notion of "byte" in most languages.

  Shmuel> Those rules only apply if you are going from one 32-bit
  Shmuel> machine to another; they have nothing to do with the
  Shmuel> definition of C itself and are inapplicable when you have to
  Shmuel> move between different word sizes.

No, Lawrence is right; refer to page 257 of Kernighan and Ritchie 2ed
(section B11, "Implementation-defined Limits: <limits.h> and
<float.h>", or section [mumble] of the actual standard document.


ADA SUCKS, C/C++/JAVA RULES!!!! Luis Espinal 11/5/97 12:00 AM

Anytime I see some posting saying "X language sucks" reminds me of a
teenager that does not know what he/she is talking about. A language is a
tool, just that, for better or worse suited for a programming task. Having
a favorite programming language is one thing, but having grudges or unfair
biases on a language is just crappy,  kid-like mentality that eventually
impairs the programmer's ability to solve a problem ( or even think about
it ) without its favorite language. He/she becomes a language-dependent
zombie rather than a programmer capable to adapt whenever he/she needs to.

Luis Espinal.

Porting Experiences (was Ada and Pascal etc ) Boyd Roberts 11/5/97 12:00 AM

In article <63p0u1$uvm$1...@helios.crest.nt.com>, k...@helios.crest.nt.com (Kaz Kylheku) writes:
>
>Sure there is. Say we are talking about a signed quantity. You first identify
>the range that it shall require. If it is within -127 to 127, you may use a
>char type---IF it is important for you to save storage.  Otherwise you use int.
>If the range is within -32767 to 32767, you use a short if saving storage is
>important. Otherwise you use int.  If the range is outside -32767 to 32767 but
>within -2^32+1 to 2^32-1, you use the type long. Otherwise if you require a
>larger range, you are out of luck. To stay within the limits of strictly
>conforing C, you must emulate some higher precision arithmetic.

Absolutely.  You decide whether the type will be large enough to hold
the values you want to represent and you use it.  You do this rather
than cluttering up the language with a lot of excess baggage that could
be expressed far more simply.

Code all the ADA you like.  Small amount of overflow and there goes an Ariane 5.

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: g...@t-1net.com

Porting Experiences (was Ada and Pascal etc ) Steve Summit 11/5/97 12:00 AM

[followups trimmed slightly]

In article <345F97...@gsg.eds.com>, nos...@gsg.eds.com writes:


> Lawrence Kirby wrote:
>> As ever the C language is designed
>> with the assumption that the programmer knows what he is doing. The use
>> of ranges implies that you know beforehand what those ranges will be.
>> In C you follow a set of rules:
>> 1. If the range is contained within -32767 to 32767 then you use int
>> 2. If the range is contained within -2147483647 to 2147483647 then you
>>    use long.
>>...

>
> Those rules only apply if you are going from one 32-bit machine to
> another; they have nothing to do with the definition of C itself and are
> inapplicable when you have to move between different word sizes.

What on earth are you talking about?  The rules Lawrence cited
(including the two I snipped) are taken *directly* from "the
definition of C itself", both the original K&R definition and the
modern ANSI/ISO definition.

> The C standard makes the size of an int implimentation dependent...

Correct.

> and on
> 16-bit machines it is normally 16. On 64-bit machines int is usually 64,
> and if you want 32 you specify short.

And on both of those machines, a program that attempted to store
numbers in the range +-32767 in ints or short ints would work
without change.

If you write C programs that "want" ints of certain sizes, such
as 16 or 32 bits, you will have portability headaches 'til the
end of your days.  If you write programs that assume that types
int and short int have a range of +-32767, and that long int has
a range of +-2147483647, your programs will work under every C
compiler everywhere, including compilers you've never heard of,
or that haven't been written yet, for machines that haven't been
built or even dreamed of yet, including those with 17-bit short
ints and 23-bit ints and 41-bit long ints.  *That's* portability.
Rewriting your program or adjusting all its typedefs every time
you port it to a new machine is an exercise in futility.

                                        Steve Summit
                                        s...@eskimo.com

Porting Experiences (was Ada and Pascal etc ) Samuel T. Harris 11/5/97 12:00 AM

Reading the arguments between Kaz and others, I'm struck
with the realization that Kaz is missing a significant
point. As long as application code is not concerned
with the representation of variables, Kaz is correct
in his statements that a few simple guidelines insure
good type choices for portable C code. What Kaz has
failed to consider, but has been state by others, is
that sometimes the representation of the type IS
important to the application, or at least to the
context in which the application is running.

The classic example here is a 32-bit integer. While
application usually are only concerned witht he RANGE
supported by the type (and Kaz's guidelines do insure
a proper choice of type) the context in which the
app is running may force the use of a 32-bit integer,
especially when interfacing to hardware, COTS libraries,
or in a distributed environment where heterogenous
architectures must interface with each other. These
are common examples of the context forcing a representation.
C does not support forcing the representation in a
portable way. Ada does. The need for such cannot
be simply dismissed because the need is real.

In fact, Ada provides me facilities to exactly map
the representation of a record right down to the
location and size of each field to conform to the
requirements of memory-mapped hardware registers.
This is very powerful and convenient. I can even
use this facility to insure the record structures
across different hardware/compiler combination are
compatible and simply send the records themselves
over the interface with little or no pre/post
processing.

With Ada, I can force a particular variable to
sit upon a particular address without any cumbersome
intermediate pointer. This is how I place my
exactly constructured record variable on top of
the actual memory area where the hardware has
placed its registers.

While it is true that support for these facilities
is optional and can involve implementations specific
limitations, in practise, commercial compilers do
in fact support these facilities to a great degree.
Such concerns simply become requirements as to
compiler selection. All compilers which support these
facilities (which is indeed nearly all compilers
I've used) will represent said structures in exactly
the same manner because the repsentation clauses
leave no room for interpretation. Hence my specific
machine, operating system, nor compiler affects
my portability since my source remains invariant
across all there of these variations.

So, I can't say to Kaz that he is wrong, because
he is not, as far as he goes. What I do say to Kaz
is "You have only pricked the tip of the portability
iceberg." Portability involves much more than guaranteeing
the base range of types. Code with specific ranges
and specific representations (including size and layout)
must also be portable, especially with the rise of
distributed computing and the integration of COTS
products with custom code. C simply does not have the
language features to support any but the most
rudimentary porting requirements of single-machine,
black-box applications that run by themselves or
with others in a strictly homogeneous environment
all of which are built with a strictly compatible
set of tools. Any variation in the above, rather
limiting set of circumstances, forces the C developer
to address many considerations to insure proper
type choice. Issues which simply do not concern me
when I'm using Ada.

--
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!"

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) nos...@spam.com 11/5/97 12:00 AM

Peter...@digital.com (Peter Mayne) writes:

>
> On Tue, 04 Nov 1997 18:33:45 GMT, mark@$tecnomen$.ie (Mark Burkley)
> wrote:
>

[snip]

>
> In the case of Alpha, it may have 64 bit registers, but it has natural
> 32 bit and 64 bit datatypes. Is one more "natural" than the other?

You can emulate 32-bit mode in DIGITAL UNIX. I suspect that NT/VC++ are
doing something similar, which doesn't suprise me since M$ has only just
managed to get to 32 bits, and is hardly likely to want to run 64bit
software just yet...

Besides, they have to implement QWORDs first ;-)

/Mike


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) nos...@spam.com 11/5/97 12:00 AM

k...@helios.crest.nt.com (Kaz Kylheku) writes:

>
> In article <345F49A2...@aom.ericsson.se>,
> Ted Lyngmo  <qhs...@aom.ericsson.se> wrote:
> >Bob Horvath wrote:
> >>
> >> Hmmmm.  How big is an int?
> >
> >As I've understood it, an int has two legal sizes. A short has only one,
>
> You haven't understood it.
>
> A short is large enough to represent numbers in the range -32767 to
> 32767. An int is also large enough to represent numbers in the
> same range. A long can represent numbers in the range -2147483647
> to +2147483647.

Nor have you. The definitions are as follows.

short <= int <= long
short < long
short > char

If your system does not conform to this, it isn't ISO (I thinhk it was ISO)
compliant.

What you stated above is true for (I would assume) all 32bit systems. It
will not necessarily hold for 64 bit or 128 bit systems.

I even had one person in the past try and tell me that when Intel went to
64bits, that M$ was going to have:

  short = 2 bytes
  long  = 4 bytes
  int   = 8 bytes

<rofl>

/Mike


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Peter Seebach 11/5/97 12:00 AM

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>,

 <nos...@spam.com> wrote:
>Nor have you. The definitions are as follows.

>short <= int <= long
>short < long
>short > char

No.  Short is not required to be any smaller than long, nor any larger
than char.  A system where all four types are 64-bits is conforming.

>If your system does not conform to this, it isn't ISO (I thinhk it was ISO)
>compliant.

This would be true if you used always <= and >= operators in your
table.

The "minimum maxima" given by the standard hold on all systems.  Whether
your system's native word size is 8 bits or 128 bits, a long must have
at *least* a 32-bit range.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Porting Experiences (was Ada and Pascal etc ) Chris Brand 11/5/97 12:00 AM

Kaz Kylheku wrote:
>
> In article <345F97...@gsg.eds.com>,
> Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
>  >Lawrence Kirby wrote:
>  >>
[big snip]

>  >>
>  >> 2. If the range is contained within -2147483647 to 2147483647 then you
>  >>    use long.
>  >>
[bigger snip]

>
> Look, if you find something factually wrong in a Lawrence Kirby posting, I
> shall promptly mail you a lollipop! :)

and in a differnet posting,

Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
>Kaz Kylheku wrote:
>>
[snip]

>>
>> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
>> and LONG_MAX. These tell you what the implementation's least and
>> greatest values of type long are. These values are guaranteed to be
>> at least -2^31+1 and 2^31-1 respectively.
>>
>> If you assume that the long type has a range that is no larger than this,
>> you are OK. If you write your code under the assumption that the
>> range is LONG_MIN to LONG_MAX, you are also OK.
>>
[another snip]

So, Lawrance Kirby claims that -2147483647 to 2147483647 will fit in a
long, while you claim that you can only rely on -2^31+1 to 2^31-1.

Do I get a lollipop, or are you wrong ?

--
Chris
Stating my own opinions, not those of my company.

[Ignore lines down here, they're just to satisfy my newsserver]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

Porting Experiences (was Ada and Pascal etc ) Lawrence Kirby 11/5/97 12:00 AM

In article <3460CF...@ccgate.hac.com>
           cbr...@ccgate.hac.com "Chris Brand" writes:

...

>So, Lawrance Kirby claims that -2147483647 to 2147483647 will fit in a
>long, while you claim that you can only rely on -2^31+1 to 2^31-1.
>
>Do I get a lollipop, or are you wrong ?

Assuming you realise that ^ is a common way to represent "raised to the
power of" (not C's exclusive-OR operator here!) and in maths expressions
it tends to get a very high precedence, I'm not quite sure what you believe
the difference to be. (2 raised to the power of 31)-1 is 2147483647.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/5/97 12:00 AM

In article <3460CF...@ccgate.hac.com>,

Chris Brand  <cbr...@ccgate.hac.com> wrote:
>So, Lawrance Kirby claims that -2147483647 to 2147483647 will fit in a
>long, while you claim that you can only rely on -2^31+1 to 2^31-1.
>
>Do I get a lollipop, or are you wrong ?

The ^ symbol means exponent rather than exclusive or, and is intended to have a
higher precedence than the unary minus or the addition operator, so
that -2^8 means -(2^8) or -256.

Thus

    -2^31+1  =  -2147483647

and

     2^31-1  =   2147483647

Lawrence and I are claiming the exact same thing stated in different terms.
I'm sometimes too lazy to write the decimal constants.

No lollipop.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Kaz Kylheku 11/5/97 12:00 AM

In article <63qkp9$bqr$3...@darla.visi.com>,

Peter Seebach <se...@plethora.net> wrote:
>In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>,
> <nos...@spam.com> wrote:
>>Nor have you. The definitions are as follows.
>
>>short <= int <= long
>>short < long
>>short > char
>
>No.  Short is not required to be any smaller than long, nor any larger
>than char.  A system where all four types are 64-bits is conforming.

But it cannot be a conforming hosted implementation, as I pointed out
in the other article, because the getc() and putc() functions require
the int type to represent everything in the range of 0 to UCHAR_MAX,
plus the extra value EOF. It therefore follows that a hosted implementation
requires the additional requirement:

    char < int

This sort of thing would be good subject matter for a C-language version of
Trivial Pursuit.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Kaz Kylheku 11/5/97 12:00 AM

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>,
 <nos...@spam.com> wrote:
>k...@helios.crest.nt.com (Kaz Kylheku) writes:
>
>>
>> In article <345F49A2...@aom.ericsson.se>,
>> Ted Lyngmo  <qhs...@aom.ericsson.se> wrote:
>> >Bob Horvath wrote:
>> >>
>> >> Hmmmm.  How big is an int?
>> >
>> >As I've understood it, an int has two legal sizes. A short has only one,
>>
>> You haven't understood it.
>>
>> A short is large enough to represent numbers in the range -32767 to
>> 32767. An int is also large enough to represent numbers in the
>> same range. A long can represent numbers in the range -2147483647
>> to +2147483647.
>
>Nor have you. The definitions are as follows.
>
>short <= int <= long
>short < long
>short > char

Where in the ISO standard did you dig up this definition? I can't find it.

>If your system does not conform to this, it isn't ISO (I thinhk it was ISO)
>compliant.

Actually there are embedded systems in which every integral type, including
char, has the same size (namely 1, of course).

Trivia time: hosted implementations of C require character types to be smaller
than the type int. Why? Because the getc() and putc() functions require the
type int to be able to represent every possible unsigned char value, _and_ the
special value EOF to indicate end of input. The embedded implementation in
which every integral type is one byte wide (32 bit byte, mind you) can't
support these functions.

Thus your little table is wrong. It should be:

    char <= short <= int <= long

with the aditional requirement to make a hosted implementation possible:

    char < int

>What you stated above is true for (I would assume) all 32bit systems. It
>will not necessarily hold for 64 bit or 128 bit systems.

No. What I stated is in the C standard, so it's true for all conforming
implementations. It defines the minimum ranges that all arithmetic types must
have. I wasn't making any claim about the relative sizes of the integral types,
just repeating the minimum range requirements.

--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Ulric Eriksson 11/5/97 12:00 AM

In article <346a4ce9....@pncnt.tecnomen.ie>,
Mark Burkley <mark@$tecnomen$.ie> wrote:
>Peter...@digital.com (Peter Mayne) wrote:
>
>[snip]

>
>>>>Actually, the size of the variables (the byte sizes) depend on the operating
>>>>system.
>>>
>>>More usually, it depends on the CPU.
>>
>>I'd say both of these statements are wrong. It depends on the
>>compiler. I've used languages with 64 bit integers on 8 bit systems:
>>why should the operating system or the CPU determine what the language
>>does, beyond the K&R suggestion of "typically reflecting the natural
>>size of integers on the host machine"?
>
>IMHO, the *natural* size implies the default register size.  I'm not
>familiar with Alpha processors so I can't comment on them.

It depends on the OS, the CPU, the compiler *and* the register size.
I have in my home computers with 8-bit, 16-bit and 32-bit CPU's.
On all of those systems, 16 bits is the most natural integer size.

8 bits is clearly to little to store an int, so that's out of the question.
16 bits is natural on a 16-bitter, naturally. ;-)
The reason for using 16 bits on the CPU with 32 bit registers is that
the OS on that computer tries to mimic MS-DOS.

Ulric
--
Should we or should we not follow the advice of the galactically stupid?
"Ya gonna neuter him too?"


Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/5/97 12:00 AM

Kaz Kylheku wrote:
 
> >C will remain a serious blot on the claims of portability.
>
> This simply isn't true. There may be blots on that claim, but this isn't one of
> them. It's an imagined problem that perhaps stems from your inexperience with
> that particular language.

Ah, the old ad hominem argument! I suppose it's all right when you have
no other arguments to bolster your case.

--

                        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 spam...@library.lspace.org

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/5/97 12:00 AM

Craig Franck wrote:
>
> C is no less portable because of this. You may have a case if you
> state that, perhaps, in this particular aspect of constructing
> portable programs, Ada is more efficient. You can define your basic
> types and have the compiler figure it all out. That may make for
> more optimal code generation. But optimal code generation is not
> the main goal of portable software. If the code runs half as fast
> as a native assembler coded routine done by some asm guru whose
> been pounding away at it for a week, you should be happy with your
> tools.

It's not just an efficiency issue. As an example, if I have to process
data from the outside world, there is no portable way to declare them in
C.

As to the comparison with assembler, there are two problems with it.
First, the alternative under discussion was Ada, and that's more
maintainable than C, not less. Second, if you are using a modern
assembler with a decent macro processor, the assembler code is likely to
be more maintainable than C code as well (yes, I know that it won't be
as tight as hand coded one-for-one, but that doesn't bother me.)

--

                        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 spam...@library.lspace.org

Porting Experiences (was Ada and Pascal etc ) Craig Franck 11/5/97 12:00 AM

"Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>Craig Franck wrote:
>
>> That was mentioned in an several e-mails I received.
>
>Since I last posted I saw an article stating that the next C standard
>will include a way to specify the required precision. That will be a
>welcome change!
>
>> It seems you can define the interface with the machine in Ada; in
>> C, what you would do is keep the values in the portable range as
>> defined by the standard. This isn't as bad as it would seeem. If
>> an implementation decides 64-bit ints are the best representation,
>> a short, int, and long could all be 64-bits. Portable software just
>> wouldn't exceed 32,767 for an int.
>
>Which is the same situation that we had when C first emrged, except that
>8-bit processors are no longer an issue. If I need more than 32 bits,
>how fo I declare it without getting 128 bits on some machines?

There are ways to tune code for a particular platform in C and
have it still remain portable.

The case of an int being 32-bits and a long 64 (on a particular
platform), and you want something larger than UINT_MAX, boy,
isn't it a waste to declare it as a long, is that what you are
getting at?

I don't see it as a major issue.

>With Ada
>or PL/I the issue doesn't arise.

I imagine it arises with the compiler people! :-)

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


Porting Experiences (was Ada and Pascal etc ) Craig Franck 11/5/97 12:00 AM

"Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>Kaz Kylheku wrote:
>>
>> That depends on how you look at it. I'd say that it requires a little
>> more thought and skill to write portably with types that have sizes
>> that are not fully specified, but it's not impossible.

>>
>> C gives you a header, <limits.h>, which gives you the constants LONG_MIN
>> and LONG_MAX. These tell you what the implementation's least and
>> greatest values of type long are. These values are guaranteed to be
>> at least -2^31+1 and 2^31-1 respectively.
>>
>> If you assume that the long type has a range that is no larger than this,
>> you are OK. If you write your code under the assumption that the
>> range is LONG_MIN to LONG_MAX, you are also OK.

>Unless and until the new standard passes, this aspect of


>C will remain a serious blot on the claims of portability.

C is no less portable because of this. You may have a case if you


state that, perhaps, in this particular aspect of constructing
portable programs, Ada is more efficient. You can define your basic
types and have the compiler figure it all out. That may make for
more optimal code generation. But optimal code generation is not
the main goal of portable software. If the code runs half as fast
as a native assembler coded routine done by some asm guru whose
been pounding away at it for a week, you should be happy with your
tools.

--

Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


Mixing declarations and statements (Re: Porting (was ADA and Pascal etc)) Éamonn McManus 11/5/97 12:00 AM

se...@plethora.net (Peter Seebach) writes:
> So, what you might do is
>         switch (thing) {
>         int x;
>         case one:
>         ...
>         }
> and, of course, you can't count on x being initialized, because you'll
> be jumping in past the initializer.

Right, I neglected to mention that possibility in my article.  Of
course it is legal in current C so the ability to mix declarations and
statements gains you nothing here; I still maintain that switch
statements are a bad example of where that is useful.

I do think the new feature is handy in biggish functions that have
several phases but are not big enough to justify splitting those
phases out into separate functions; or where the initialisation of a
declared variable requires work to have been done on previous
variables that can't easily be squeezed into their declarations.

,
Eamonn                                        http://www.gr.opengroup.org/~emcmanus
  "Je ne suis pas celle que vous croyez!"  --  Dimitri from Paris

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/5/97 12:00 AM

In <345f9c32....@mrnews.mro.dec.com> Peter...@digital.com (Peter Mayne) writes:

>I'd say both of these statements are wrong. It depends on the
>compiler.

But the compiler itself is influenced by the CPU and the OS.  Proof:
Digital UNIX, OpenVMS and NT/Alpha use essentially the same compiler.
Yet the size of a long depends on which operating system the compiler
is running under (64 bits for 64-bit OSes and 32 bits for 32-bit OSes).
This is a clear case of the OS influencing the implementation: there is
no other reason for not a having a *standard* type which is 64-bit on a
compiler for a 64-bit CPU.


 
>I've used languages with 64 bit integers on 8 bit systems:
>why should the operating system or the CPU determine what the language
>does,

They don't determine what the languages does, they do determine what the
compiler does.  If efficiency matters, the CPU will influence the size,
if the interaction with other parts of the system matters, the OS will
influence the size.  How many implementations using 33-bit integers have
you seen?

>beyond the K&R suggestion of "typically reflecting the natural
>size of integers on the host machine"?

There's similar wording in the standard itself:

    A ``plain'' int object has the natural size suggested by the
    architecture of the execution environment...

But I agree that this really doesn't impose any requirement on the
implementation.  The architecture may suggest different "natural" sizes
to different implementors.

>In the case of Alpha, it may have 64 bit registers, but it has natural
>32 bit and 64 bit datatypes. Is one more "natural" than the other?

Is it "natural" to have no *standard* 64-bit integral type on a compiler
for a CPU with 64-bit registers?  Yet, this is the case for Alpha NT and
OpenVMS compilers :-)

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Porting Experiences (was Ada and Pascal etc ) Lawrence Kirby 11/5/97 12:00 AM

In article <345F97...@gsg.eds.com> nos...@gsg.eds.com "Seymour J." writes:

>Lawrence Kirby wrote:
>>
>> The portability implications of this are small or non-existent (there may
>> be performace implications in rare circumstances, and issues relating to
>> data sizes and external data formats). As ever the C language is designed

>> with the assumption that the programmer knows what he is doing. The use
>> of ranges implies that you know beforehand what those ranges will be.
>> In C you follow a set of rules:
>>
>> 1. If the range is contained within -32767 to 32767 then you use int
>>
>> 2. If the range is contained within -2147483647 to 2147483647 then you
>>    use long.
>>
>> 3. If you want to minimise space usage (such as for array elements or
>>    structure members) and the range is contained within -32767 to 32767 then

>>    you can use short. For -127 to 127 you can use signed char.
>>
>> 4. The unsigned types have larger positive ranges if your range is
>>    non-negative. Notably unsigned char typically corresponds to the
>>    notion of "byte" in most languages.
>
>Those rules only apply if you are going from one 32-bit machine to
>another; they have nothing to do with the definition of C itself and are
>inapplicable when you have to move between different word sizes.

Please take a look at the ISO C standard before making bold statements
such as this. These limits are laid in stone within the standard, for your
reference in section 5.2.4.2.1. Code following these guidelines is guaranteed
to work on *any* conforming C compiler with *any* word size. You don't
get more portable that that within the boundaries of a single language.

>The C standard makes the size of an int implimentation dependent,

Yes, it is implementatio-defined but with firm minimum limits, exactly
as stated above.

>and on
>16-bit machines it is normally 16.

True.

>On 64-bit machines int is usually 64,
>and if you want 32 you specify short.

That's an unwarranted assumption which will cause code to be non-portable
so if you want to write portable code you don't make it.

>Now, admittedly this will change with the new standard, but as long as
>it is still a draft it has nothing to do with the current language.

You need to take a look at what the standard for the current language
actually says.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Porting Experiences (was Ada and Pascal etc ) Dann Corbit 11/5/97 12:00 AM

Chris Brand wrote in message <3460CF...@ccgate.hac.com>...
[snip]

>So, Lawrance Kirby claims that -2147483647 to 2147483647 will fit in a
>long, while you claim that you can only rely on -2^31+1 to 2^31-1.
2^31 =  2147483648
-2^31+1 = -2147483647
2^31 - 1 =  2147483647

You get a question mark
?

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Ron Natalie 11/5/97 12:00 AM

nos...@spam.com wrote:

> You can emulate 32-bit mode in DIGITAL UNIX.

Not really.  The only thing you can really do is fix the
linking so that nothing is used in the address space greater
than 2**32.  While there is a compilation mode that lets you
turn on 32 bit pointers entirely, you have to be very careful
to disable it when communicating with the system libraries as
DEC doesn't provide 32 bit versions of these.

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/5/97 12:00 AM

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>
           nos...@spam.com  writes:

>k...@helios.crest.nt.com (Kaz Kylheku) writes:
>
>>
>> In article <345F49A2...@aom.ericsson.se>,
>> Ted Lyngmo  <qhs...@aom.ericsson.se> wrote:
>> >Bob Horvath wrote:
>> >>
>> >> Hmmmm.  How big is an int?
>> >
>> >As I've understood it, an int has two legal sizes. A short has only one,
>>
>> You haven't understood it.
>>
>> A short is large enough to represent numbers in the range -32767 to
>> 32767. An int is also large enough to represent numbers in the
>> same range. A long can represent numbers in the range -2147483647
>> to +2147483647.
>
>Nor have you.

Strange, the requirements that Kaz has specified above are the requirements
stated in the standard. Given that everything he stated is correct in
what way did he misunderstand anything? Maybe you would be happier if
"in the range" was replaced by "in at least the range". That makes it
a bit clearer but doesn't change the meaning.

>The definitions are as follows.
>
>short <= int <= long
>short < long
>short > char

They may be your definitions but they aren't the definitions in the ANSI/ISO
standard. Firstly you have to define what your comparisons refer to. The
standard says nothing about the relative sizes of the types (in terms of
space taken up) except that sizeof(char) is 1 and everything else is a
multiple of that. The standard talks in terms of ranges and subranges. In
the sequence signed char, short, int, long each type earlier in the list
can represent a range of values that is a subrange of the types later on.
Given your table refers to ranges and <= is a "subrange" operator then
the first line is correct but incomplete and the other 2 are incorrect.
The correct representation is:

signed char <= short <= int <= long

Note that this allows all types to have the same range and this does
occur in practice (e.g. some C compilers for 32 bit DSPs do this).

In addition to this each type is specified as having a minimum range of
values that it must be able to represent, which Kaz correctly stated above.
In summary:

signed char:    -127 to 127
short:          -32767 to 32767
int:            -32767 to 32767
long:           -2147483647 to 2147483647

There are also corresponding unsigned types which have minimum ranges:

unsigned char:  0 to 255
unsigned short: 0 to 65535
unsigned int:   0 to 65535
unsigned long:  0 to 4294967295

There is also char which the implementation is allowed to specify as having
either the same range as signed char or the same as unsigned char.

>If your system does not conform to this, it isn't ISO (I thinhk it was ISO)
>compliant.

I have a copy of the standard in front of me. Do you? If so have a look at
sections 5.2.4.2.1 and 6.1.2.5.

>What you stated above is true for (I would assume) all 32bit systems. It
>will not necessarily hold for 64 bit or 128 bit systems.

It holds for all conforming C implementations.

>I even had one person in the past try and tell me that when Intel went to
>64bits, that M$ was going to have:
>
>  short = 2 bytes
>  long  = 4 bytes
>  int   = 8 bytes

That would be possible but then the int would have to have unused bits
("holes", which the standard permits), which makes it rather pointless.
int isn't allowed to represent a greater range than long.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/5/97 12:00 AM

In article <3460A7BB...@hso.link.com>,

Samuel T. Harris <s_ha...@hso.link.com> wrote:
>Reading the arguments between Kaz and others, I'm struck
>with the realization that Kaz is missing a significant
>point. As long as application code is not concerned
>with the representation of variables, Kaz is correct
>in his statements that a few simple guidelines insure
>good type choices for portable C code. What Kaz has
>failed to consider, but has been state by others, is
>that sometimes the representation of the type IS
>important to the application, or at least to the
>context in which the application is running.

Then the application is not portable, by definition.  A portable program is one
which is not concerned with the representation of a type.

>The classic example here is a 32-bit integer. While
>application usually are only concerned witht he RANGE
>supported by the type (and Kaz's guidelines do insure
>a proper choice of type) the context in which the

Those are not only my guidelines, but have been reiterated by other comp.lang.c
regulars. They are also reflected in the comp.lang.c FAQ.

>app is running may force the use of a 32-bit integer,
>especially when interfacing to hardware, COTS libraries,

Interfacing to hardware is outside of the domain of a strictly conforming
C program.  A pure C language program communicates with the environment
only through streams.

There are ways, using C, to conform to external storage layouts in maximally
portable ways which do not depend on the representation of types other
than the type unsigned char.

>or in a distributed environment where heterogenous
>architectures must interface with each other. These

I have programmed in such circumstances and managed to remain strictly
conforming. Interfacing heterogeneous architectures can be solved by
identifying a canonical external representation format and then writing
maximally portable routines which encode data items to and from that
format. In my experience, only floating point representations represent
any significant difficulties in this area.

>are common examples of the context forcing a representation.
>C does not support forcing the representation in a
>portable way. Ada does. The need for such cannot
>be simply dismissed because the need is real.

But C allows you to manipulate individual bytes, and therein lies the
secret.

>In fact, Ada provides me facilities to exactly map
>the representation of a record right down to the
>location and size of each field to conform to the
>requirements of memory-mapped hardware registers.

This is also possible with C in a portable way. It is not that convenient, of
course, but we are discussing portability, rather than convenience.

>This is very powerful and convenient. I can even

I couldn't agree more, but please stick to the topic which is portability.

>So, I can't say to Kaz that he is wrong, because
>he is not, as far as he goes. What I do say to Kaz
>is "You have only pricked the tip of the portability
>iceberg." Portability involves much more than guaranteeing

That's because I was only asked to scratch the surface, because
the subject that arose was the choice of integral types to suit
particular requirements. Now we are on the topic of conforming
to external storage formats, which is something else. You haven't
requested a discussion of this topic before.

Conforming to external data layout can be done in a highly portable way in C.
It can also be done in non-portable ways which are usually faster.  

Instead of useless talk, why don't we try the following game: you describe the
storage layout, and I will demonstrate a maximally portable C example which can
communicate with that layout. I will entertain you as long as you wish.

Perhaps you will emerge out of this better armed for situations in which
you have to use C rather than some other preferred tool such as Ada.

>products with custom code. C simply does not have the
>language features to support any but the most
>rudimentary porting requirements of single-machine,
>black-box applications that run by themselves or
>with others in a strictly homogeneous environment
>all of which are built with a strictly compatible
>set of tools.

That depends on what you mean by language features. If you mean that C
doesn't have language features that are *specifically* designed to help you in
this area, then you are right.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/5/97 12:00 AM

In article <3460CF...@ccgate.hac.com>,
Chris Brand  <cbr...@ccgate.hac.com> wrote:

>Do I get a lollipop, or are you wrong ?

Incidentally, I only offered the lollipop to one named Shmuel Metz, so you can
find all the Kirby errors you want, but you ain't getting no candy from me.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Stevens 11/5/97 12:00 AM

On 30 Oct 1997 13:13:54 -0800, Kaz Kylheku <k...@helios.crest.nt.com> wrote:
>Telecommunication management software is large and complex, but not safety
>critical,

"HELLO!!??? 911??!!  Damn, the software controlling the switch crashed
again!" ;->

>and quasi-real-time at best. Shut-down software for a nuclear reactor
>may be less complex, but requires much more verification.

But in the end, it is the programmer and the quality assurance procedures
that make the difference, not language choice.

John S.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Stevens 11/5/97 12:00 AM

On 30 Oct 1997 11:50:05 -0800, Kaz Kylheku <k...@helios.crest.nt.com> wrote:
>No. C is perceived as being portable. Those who perceive C++ as portable
>are naive or mistaken.

If you use the entire language, you are correct, it isn't very portable.

But, if you stick with the standard stuff, there isn't much to worry
about.

>C++ is not a standardized language, unlike Ada 83 or Ada 95, so you would
>expect to have porting problems with it.

You might, but so far, I haven't had any problems with the *language*.

John S.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Stevens 11/5/97 12:00 AM

On Fri, 31 Oct 1997, Alan E & Carmel J Brain <aeb...@dynamite.com.au> wrote:
>While I agree with most of your post, I must take issue here. C and C++
>are perceived as being portable. Inasmuch as there are almost no major
>computers which don't have a C or C++ compiler, this is true. And that's
>a big, big selling point.
>
>However....
>
>C and C++ compilers differ by so much that porting is often a Nightmare.
>Before I get flamed, I'd like to talk to people who've actually ported
>code cross-platform.

Speaking (err, that is, writing! ;->).

I have written code specifically designed to be ported across platforms.

Note that most of the results of the GNU project have been ported across
platforms as well, and lately the results have been quite good.

The limiting factor in portability is almost always OS or library issues,
not incompatibilities in the language itself.

>In my own, albeit limited experience, the problems
>I've had with any C or C++ port are greater than all the problems I've
>had with Ada crossplatform put together!

Well, considering I was unable to port an Ada program to two of the five
platforms I was targeting, while I was able to port a C program to all five,
I'd have to say that C is infinitely more portable.

YMMV, and all that.

>If you have an Ada compiler

That *IF*, being the gotcha.

Has anybody ever successfully used Ada on a Linux box?

>Now C++ on the other hand, written using CodeWarrior 10 on a Mac, ported
>to CodeWarrior 10 on an IBM... or even MVC++ 4 vs MVC++ 5... or worse
>still CodeWarrior 9 on a Mac to CodeWarrior 10 on a Mac to MVC++ 5 on an
>IBM... In 15,000 LOCs of C++ how many would you reasonably expect to
>have to be changed? (yes, these were actual examples too)  

Note your choice of compiler.  This has a lot to do with it.

Now, using GCC. . .

John S.

Porting Experiences (was Ada and Pascal etc ) Alan E & Carmel J Brain 11/6/97 12:00 AM

Kaz Kylheku wrote:
>
> In article <3460A7BB...@hso.link.com>,
> Samuel T. Harris <s_ha...@hso.link.com> wrote:
> >Reading the arguments between Kaz and others, I'm struck
> >with the realization that Kaz is missing a significant
> >point. As long as application code is not concerned
> >with the representation of variables, Kaz is correct
> >in his statements that a few simple guidelines insure
> >good type choices for portable C code. What Kaz has
> >failed to consider, but has been state by others, is
> >that sometimes the representation of the type IS
> >important to the application, or at least to the
> >context in which the application is running.
>
> Then the application is not portable, by definition.  A portable program is one
> which is not concerned with the representation of a type.

I most strongly disagree. A very, very typical counterexample, found in
many, many systems is an I/O handler. For this, there is a standard
protocol
defined at some level, stating the bit representation of the telegrams.

Consider a telegram containing (in a representation-free sense):
A telegram type, which is between 0 and 255;
A value, which is between 0 and 20000
A 10-character string
6 status flags

This is implemented in the specification of the interface as:
Bytes 0     Telegram type
Bytes 1     Bytes of which the 6 MSBs are the status flags
Bytes 2-4   unused
Bytes 5-7   The value up to 20000
Bytes 8-17  The character string in ANSI 8-bit, no terminator
Bytes 18-19 Unused

All boxes on the bus must have a piece of code that can "decode" this
telegram. In C, using different C compilers, sure you need #ifdefs and
all sorts of other things. In Ada, even Ada-83, the same code on
different
CPUs with different compilers is guarenteed to use the same
representation,
if you use the representation clauses provided with the language.

For example:
type TelegramKindType is ( Conflict, Priority);
for TelegramKindType use ( Conflict => 16#FF, Priority => 2#10101010);
for TelegramKindType'size use 8; -- 8 bits exactly, no more, no less
 
type TelegramType is
record
  TheKind : TelgramKindType;
etc etc etc

and

for TelegramType use
record at mod 8        -- align it to some very portable word boundary
  TheKind at 0 range 0..7;
etc etc etc

The point is that the _exact same_ chunk of code is used in _every_
machine.
Now if that's not portable, what is?

> Interfacing to hardware is outside of the domain of a strictly conforming
> C program.  A pure C language program communicates with the environment
> only through streams.

Sounds as if Ada's more powerful here -->  :) <----

> I have programmed in such circumstances and managed to remain strictly
> conforming. Interfacing heterogeneous architectures can be solved by
> identifying a canonical external representation format and then writing
> maximally portable routines which encode data items to and from that
> format. In my experience, only floating point representations represent
> any significant difficulties in this area.

I agree, obviously you'll recognise the Ada example I gave above. In
Ada,
the problem's actually worse: in most cases, the language allows
complete
portability, you get used to it. But then along comes a problem where
the
communications telegram has IEEE floats, and the machine you're on only
has
DEC (or other) floats. In which case you have to write some more code.

BTW this is an actual example, I headed the team doing the I/O over a
VME
bus (Many MB/sec) between a KAV (DEC) card and an i860 card. Under
pressure
from management (execution time was crucial) an assembler Float
converter was written
by an Assembler guru. After 2 weeks, a C program was written, that was
actually faster, and worked (unlike the assembler).

Of course later, I then wrote an Ada conversion routine, that due to an
excellent
compiler, was faster still, but that's another matter.

> >In fact, Ada provides me facilities to exactly map
> >the representation of a record right down to the
> >location and size of each field to conform to the
> >requirements of memory-mapped hardware registers.
>
> This is also possible with C in a portable way. It is not that convenient, of
> course, but we are discussing portability, rather than convenience.

> Conforming to external data layout can be done in a highly portable way in C.


> It can also be done in non-portable ways which are usually faster.
>
> Instead of useless talk, why don't we try the following game: you describe the
> storage layout, and I will demonstrate a maximally portable C example which can
> communicate with that layout. I will entertain you as long as you wish.
>
> Perhaps you will emerge out of this better armed for situations in which
> you have to use C rather than some other preferred tool such as Ada.

YES PLEASE. Any help from anyone is always welcome. So much to learn,
and only one lifetime, *SIGH*

OK, I would like the following:

1st(0th) byte contains telegram type. This has legal values of FF,FE,and
00.
If the value is FF, then bytes 4-7 contain an IEEE floating point
between
-1.7666 e6 and 2.34 e12. Byte 3 contains an enumeration type, which has
the values Red,Green, Yellow, corresponding to 01, 10, and FF (hex).
If the value is FE, bytes 1-3 contain a binary angle (fixed point),
first 13
bits before the binary point. Bytes 4-11 contain a packed ANSI 7-bit
string.
If the value is 00, then the rest is "don't care".

The reading in must check that all values are correct. The floating
point
will be decoded into the form of mantissa, sign, exponent etc.

This is a nice, simple one. I'll get into the really polymorphic records
later.

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

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Peter Seebach 11/6/97 12:00 AM

In article <63r2sv$rgm$1...@helios.crest.nt.com>,

Kaz Kylheku <k...@helios.crest.nt.com> wrote:
>But it cannot be a conforming hosted implementation, as I pointed out
>in the other article, because the getc() and putc() functions require
>the int type to represent everything in the range of 0 to UCHAR_MAX,
>plus the extra value EOF. It therefore follows that a hosted implementation
>requires the additional requirement:

>    char < int

>This sort of thing would be good subject matter for a C-language version of
>Trivial Pursuit.

I don't think anything is broken by an implementation which has unsigned
char values which are negative when converted to int.

Typically, such implementations would only return smallish positive
values, or EOF, from getchar(), so it doesn't matter...

(Hmm.  I hadn't thought about ungetc, though; I'll bring that up at
the next meeting, if I remember.)

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) jimmaure...@worldnet.att.net 11/6/97 12:00 AM

Kaz Kylheku <k...@helios.crest.nt.com> wrote in article
> No. What I stated is in the C standard, so it's true for all conforming
> implementations. It defines the minimum ranges that all arithmetic types
must
> have. I wasn't making any claim about the relative sizes of the integral
types,
> just repeating the minimum range requirements.

This is still an interesting answer to the initial question.  What you have
is not
a definition of the size of an int, only a definition of its smallest
possible size.
So, how big is it, exactly?  You have quoted the C standard which in effect
says that an int is larger than a bread-box, and even describes the size of
a bread-box.  From this I can logically, and I believe correctly, assume
that
a 64 bit int is every bit as conforming as a 32 bit int.

The claim has been made that this produces completely portable code.  This
claim can be supported only if the programmer is prevented from using any
int value which cannot be represented by a 32 bit int.  Thus, if a system
of
hardware and compiler uses a 64 bit int, only the first 32 bits can ever be

used.  If more than the first 32 bits are used the program, although using
a
conforming compiler, will be completely non-portable to a system using a
32 bit int.

What does the C standard say about the behavior of an int at the margin of
its ranges?  Does 1 + INT_MAX always result in INT_MIN?  How about when
using an unsigned int?  Does 1 + UINT_MAX always result in 0?  If not, then
what is the portable definition of the behavior of an int at its range
limits?
Without a well defined set of such conditions no C program could be
considered portable for its entire range of int values.

Even with such a set of well defined rules, how many C programmers test
addition, for instance, to determine that X + 1 is greater than X?  Failure
to
perform such a test can clearly lead to catastrophic behavior at the limits
of
the range of an int.  Your program will then be entirely portable and
completely
incorrect.  Such portability is not a comfort to me.  I would rather
sacrifice a
little portablity for the elimination of such an error.
 
Fortunately, with Ada I do not need to sacrifice either.  By explicitly
specifying
the range of a type I get completely portable results.  I also get
automatic
range checking  including the raising of the exception Constraint_Error if
a
range boundary is violated.  I can handle this exception in a
non-catastrophic
manner without coding in a test at every addition.  Thus I can ensure
program
correctness even under the violation of type range boundaries.  This too is
entirely portable.

Jim Rogers
Colorado Springs, Colorado

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Oliver Batchelor 11/6/97 12:00 AM


Gary A. Wiltshire <70523...@compuserve.com> wrote in article
<345a060f...@news.albany.net>...
> nospam@nospam (John Black) wrote:
>
> >ADA and Pascal are two of the most useless inventions Man has ever
> >wasted space on this planet with.  These languages are hard to learn,
> >have zero applications, and people who only know these languages can
> >only find jobs at Taco Bell!  Smart programmers spend their time
> >learning only C, C++, and Java in that order.
>
> Does your daddy know that you're using his computer?
>
> BTW, you're ugly and your mommy dresses you funny.
>
>    --- Gary Wiltshire
>


Shut up

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Boyd Roberts 11/6/97 12:00 AM

In article <danpop.8...@news.cern.ch>, Dan...@cern.ch (Dan Pop) writes:
>Is it "natural" to have no *standard* 64-bit integral type on a compiler
>for a CPU with 64-bit registers?  Yet, this is the case for Alpha NT and
>OpenVMS compilers :-)

Sad, but true.  They got it completely wrong.

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: g...@t-1net.com

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Richard Kenner 11/6/97 12:00 AM

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me> nos...@spam.com writes:
>I even had one person in the past try and tell me that when Intel went to
>64bits, that M$ was going to have:
>
>  short = 2 bytes
>  long  = 4 bytes
>  int   = 8 bytes

This was Sun's original choice for their 64 bit systems, but I think
later decided against it.

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) R S Haigh 11/6/97 12:00 AM

In article <878763...@genesis.demon.co.uk>, fr...@genesis.demon.co.uk (Lawrence Kirby) writes:

> >I even had one person in the past try and tell me that when Intel went to
> >64bits, that M$ was going to have:
> >
> >  short = 2 bytes
> >  long  = 4 bytes
> >  int   = 8 bytes
>
> That would be possible but then the int would have to have unused bits
> ("holes", which the standard permits), which makes it rather pointless.
> int isn't allowed to represent a greater range than long.

Not altogether pointless.  The right time to use int is when
you want a range of +-32767, but you want to store the value in
the machine word size rather than the space-efficient size (short).
That's just what this supports.  Any other scheme frustrates what
was presumably the programmer's intention in choosing int.

--


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/6/97 12:00 AM

In article <63r2sv$rgm$1...@helios.crest.nt.com>
           k...@helios.crest.nt.com "Kaz Kylheku" writes:

>In article <63qkp9$bqr$3...@darla.visi.com>,
>Peter Seebach <se...@plethora.net> wrote:
>>In article <w0b4t5r428o.fsf@mah21awm.i-have-a-mis
>configured-system-so-shoot-me>,
>> <nos...@spam.com> wrote:
>>>Nor have you. The definitions are as follows.
>>
>>>short <= int <= long
>>>short < long
>>>short > char
>>
>>No.  Short is not required to be any smaller than long, nor any larger
>>than char.  A system where all four types are 64-bits is conforming.
>
>But it cannot be a conforming hosted implementation, as I pointed out
>in the other article, because the getc() and putc() functions require
>the int type to represent everything in the range of 0 to UCHAR_MAX,
>plus the extra value EOF.

getc() and putc() return EOF if the operation fails. However I can find
no guarantee that EOF is distinct from a valid character value returned
by one of these functions, so I disagree that int has to be greater than
char (specifically that INT_MAX >= UCHAR_MAX). However things are
unpleasant if that isn't the case.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Kaz Kylheku 11/6/97 12:00 AM

In article <01bcea71$74603f40$5e20430c@Rogers>,

James S. Rogers <jimmaure...@worldnet.att.net> wrote:
>Kaz Kylheku <k...@helios.crest.nt.com> wrote in article
>> No. What I stated is in the C standard, so it's true for all conforming
>> implementations. It defines the minimum ranges that all arithmetic types
>must
>> have. I wasn't making any claim about the relative sizes of the integral
>types,
>> just repeating the minimum range requirements.
>
>This is still an interesting answer to the initial question.  What you have
>is not
>a definition of the size of an int, only a definition of its smallest
>possible size.
>So, how big is it, exactly?  You have quoted the C standard which in effect

I don't know! How tall is a tree? ;)

>says that an int is larger than a bread-box, and even describes the size of
>a bread-box.  From this I can logically, and I believe correctly, assume
>that
>a 64 bit int is every bit as conforming as a 32 bit int.

Yes.

>The claim has been made that this produces completely portable code.  This
>claim can be supported only if the programmer is prevented from using any
>int value which cannot be represented by a 32 bit int.  Thus, if a system
>of

That is correct.

>hardware and compiler uses a 64 bit int, only the first 32 bits can ever be
>
>used.  If more than the first 32 bits are used the program, although using
>a

That is true. C89 is effectively a 32 bit language, as far as writing maximally
portable programs goes.

The C9X language will have support for larger integers.

>conforming compiler, will be completely non-portable to a system using a
>32 bit int.

>What does the C standard say about the behavior of an int at the margin of
>its ranges?  Does 1 + INT_MAX always result in INT_MIN?  How about when

Absolutely not! INT_MAX + 1 is an overflow which results in---guess
what---undefined behavior.

>using an unsigned int?  Does 1 + UINT_MAX always result in 0?  If not, then

Only the unsigned types have wrapping properties, thus 1 + UINT_MAX produces
zero, (UINT_MAX is always a Mersenne number).

To simulate modulo 65536 arithmetic in a portable way, you would use the
unsigned int type, and logically AND your results with 65535. If you
don't, you get modulo whatever the implementation gives you.

>what is the portable definition of the behavior of an int at its range
>limits?

If you try to compute an int value that tries to violate the limits, the
behavior is no longer well defined. On two's complement systems, wrapping
occurs. But this is not defined by the language. Correctly written programs
avoid such an error.


 
>Without a well defined set of such conditions no C program could be
>considered portable for its entire range of int values.
>
>Even with such a set of well defined rules, how many C programmers test
>addition, for instance, to determine that X + 1 is greater than X?  Failure

I do not know how many, but I do. In non trivial programs, I use the assert()
facility to detect such errors, ensuring that the preconditions to an operation
are satisfied.

>to
>perform such a test can clearly lead to catastrophic behavior at the limits
>of
>the range of an int.  Your program will then be entirely portable and

Come on, use your imagination. You do not have to perform the test

    assert (x + 1 <= INT_MAX)

in order to satisfy the condition that x is be less than INT_MAX!

You rewrite the test by moving the 1 to the other side of the equation:

    assert (x <= INT_MAX - 1)

In general, the abstract algebraic pre-condition assertions that are written
in the design of a program cannot be directly translated into program
statements because they themselves may violate the constraints of the machine's
arithmetic. However, that doesn't mean that the machine can't be used to test
for these conditions. The tests just have to be rewritten in less
straightforward ways to avoid the overflow.

For example, how would you test whether the sum a + b is within the
range [INT_MAX,INT_MIN], without ever producing an intermediate result that
falls outside of this range?

The solution is to divide into cases. If a and b have opposite sign, then
the result clearly cannot violate the bounds, so no check is required. If a and
b are both negative, then you only need to check that their sum is not below
INT_MIN.  The remaining case, a and b are both positive, is checked against
INT_MAX. The last two cases are rewritten to avoid overflow, of course.

Thus:

    int a, b;

    /*...*/

    if (a > 0 && b > 0) {
        assert(a <= INT_MAX - b);
    } else if (b < 0 && a < 0) {
        assert(a >= INT_MIN - b);
    }

    c = a + b;

This could be written as one big assertion in one line so that it does
not distract the reader of the program.

It's nice to have range-checking built into the language; however, this
does not give you coverage of all conditions, such as loop invariants
or generally andy relationships among variables that are not expressed in the
data declarations.

I think it's better to learn assertive programming first, and then go to a
language that can do many of the tedious checks for you.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Kaz Kylheku 11/6/97 12:00 AM

In article <63rasf$1ug$1...@darla.visi.com>,

Peter Seebach <se...@plethora.net> wrote:
>In article <63r2sv$rgm$1...@helios.crest.nt.com>,
>Kaz Kylheku <k...@helios.crest.nt.com> wrote:
>>But it cannot be a conforming hosted implementation, as I pointed out
>>in the other article, because the getc() and putc() functions require
>>the int type to represent everything in the range of 0 to UCHAR_MAX,
>>plus the extra value EOF. It therefore follows that a hosted implementation
>>requires the additional requirement:
>
>>    char < int
>
>>This sort of thing would be good subject matter for a C-language version of
>>Trivial Pursuit.
>
>I don't think anything is broken by an implementation which has unsigned
>char values which are negative when converted to int.
>
>Typically, such implementations would only return smallish positive
>values, or EOF, from getchar(), so it doesn't matter...

But what if all the negative values are required to represent data, leaving
no room for EOF? This is the case if an int is one byte wide. The int
is N bits wide and has to represent 2^N different byte values. That
leaves no possible room for the representation of EOF.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Morris M. Keesan 11/6/97 12:00 AM

On 5 Nov 1997 16:27:11 -0800, k...@helios.crest.nt.com (Kaz Kylheku)
wrote:
>In article <63qkp9$bqr$3...@darla.visi.com>,
>Peter Seebach <se...@plethora.net> wrote:
...

>>No.  Short is not required to be any smaller than long, nor any larger
>>than char.  A system where all four types are 64-bits is conforming.
>
>But it cannot be a conforming hosted implementation, as I pointed out
>in the other article, because the getc() and putc() functions require
>the int type to represent everything in the range of 0 to UCHAR_MAX,
>plus the extra value EOF. It therefore follows that a hosted implementation
>requires the additional requirement:
>
>    char < int

Here's where the problem of using this poorly-defined '<' notation comes
in.  If the < is interpreted to mean "has a smaller range of values
than", then the above is correct.  But I maintain that a conforming
hosted implementation can exist where sizeof(char) == sizeof(int), as
long as UCHAR_MAX < UINT_MAX.  E.g., I believe the following would be
conforming:

#define EOF (-1)
#define CHAR_BITS 64
#define UCHAR_MAX 0x7fffffffffffffff
#define SCHAR_MAX UCHAR_MAX
#define UINT_MAX  0xffffffffffffffff

where sizeof(int) == sizeof(char)
      sizeof(long) == sizeof(int)

--
Morris M. Keesan -- mke...@kenan.com
Kenan Systems Corporation

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Peter Seebach 11/6/97 12:00 AM

In article <63snhv$i18$1...@helios.crest.nt.com>,

Kaz Kylheku <k...@helios.crest.nt.com> wrote:
>But what if all the negative values are required to represent data, leaving
>no room for EOF? This is the case if an int is one byte wide. The int
>is N bits wide and has to represent 2^N different byte values. That
>leaves no possible room for the representation of EOF.

I'm not sure.  My guess is that the implementor is SOL.  Hmm.  Actually,
no, the user is.

If you look at the wording on WEOF, it doesn't have to be outside the
range of wchar_t, or anything like that - it just has to not be the
same as anything in the extended character set.  (Oops, silly me, I just
looked in the C9X draft.)  However, there's no restrictions on EOF, except
that it's negative... So, it's perfectly OK for anything not in the basic
character set to be equivalent to EOF, and arguably, on a system with
unsigned chars as large as ints, it's okay for anything but null bytes
to be equivalent to EOF.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Stevens 11/6/97 12:00 AM

On Thu, 30 Oct 1997 17:11:26 -0600, Scott Baierl <bai...@schneider.com> wrote:
>
>Smart programmers spend their time learning programming languages that help
>them solve the real-world problems in their particular application domain.

Umm. . . no.  Smart programmers live, learn, and grow up to be sofware
engineers.  Software engineers live, learn, and grow up to be system
architects.  System architects live, learn, and grow up to be Computer
Scientists.

The constant in all this is to move from the concrete, to ever more
abstraction, to higher levels of complexity, and to greater numbers of
relationships and levels of relationship nesting.

A programmer applies his knowledge of C to write a sorting algorithm
for integers using a cook book algorithm.

A software engineer queries his architect, develops designs that match
the system architechture, can be maintained, are of good quality and
can be easily and effectively tested.  And then he probably helps
program.

An architect surveys his customers business area, looks at the current set
of problems to be solved, and the tasks that need doing, matches this
information against both mature and newer art to design a system that
can be used to solve immediate problems, streamline communications between
hitherto separate or even antagonistic sub-systems, provide business
level control and support, constrain, and assist in the adaption of that
system to unexpected events or changes.  And then he probably helps do some
of the engineering and coding.

A Computer scientist is capable of all of the above, including the
addition of questions of morality and societal impact, as well as
being able to produce new art to solve problems that have not yet become
part of existing business systems.

Analogy:  The architect is the guy standing at the top of the hill.  He
surveys this hill, decides that the inhabitants of this hill are
wasting time and energy by growing to much food, and that this is occuring
because to much of this food is being wasted.

He decides that what is needed is: a monetary system to make it easier to
track and control the flow of food, a communications system to allow the
inhabitants to organize the flow of food from places where it can be produced
to places where it cannot be, and a system of roads to do the actual
transportion of the food to different parts of the hill.

One of the engineers gets the task of solving part of the transportation
problem by being asked to design the necesary bridge to get across a
particularly troublesome ravine.  The architect tells the engineer
to make the bridge out of wood, a minimum of two lanes wide, and capable
of supporting up to x number of tons.

The engineer decides what kind of bridge would be easiest/best to build
to cross this particular ravine: suspension, trestle, etc., and draws up
the specific plans taking into account good engineering practice (water
sealing the wood, designing a safety factor (x tons + 30%, for example)
adding on whatever state-of-the art traffic flow control options are
needed, and available, and putting up signs that specify the weight limit
of the bridge.

The programmers are the guys carrying the planks, swinging hammers, drilling
holes and sawing wood.  The keep a weather eye on each plank, making sure
that it has no flaws, is of good quality, and properly sealed.  They also
make best effort to ensure that the holes drilled are correct in size and
placement, that the pieces are cut to best fit, etc.

All the while this is going on, the Scientist is also standing on top of
the hill, but instead of looking down at the hill beneath his feet, he is
looking out over the sea that surrounds the island this hill sits on,
dreaming of ways (flying, anyone?) to get from this hill, to another hill
on the next island.

Which is why arguing about which language is best is probably outside
the scope of most of our area of responsibility.  Most of us here are
not architects, or even engineers.

>I know Pascal, C, C++, COBOL, Fortran, Java, Basic and several variants of
>Assembler.  None of them is difficult to learn.  Each language has its
>strong and weak points.  I happen to think that C++ is probably the most
>versatile language of the bunch, which is why I use it more than the others.

Me, I think that combining languages gives you much more versatility.

John S.

ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! John Stevens 11/6/97 12:00 AM

On Thu, 30 Oct 1997, Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
>>   2. Pascal and Ada (which is often called a highly enriched Pascal)
>> weren't designed as application development vehicles - whereas C/C++
>> were.
>
>Wrong on both counts. Ada was designed for applications development, and
>C was designed to be easily compilable on a small machine.

Actually, wrong again.  C was designed originally as a systems programming
tool (ie, "let's use C to write an OS").  Ada in its first incarnation
was designed primarily for use in writing embedded systems.

The one huge advantage C++ has over Ada, is that C++ is at least
semi-object oriented.  Ada isn't.

>> Pascal was invented as a teaching tool for structured and module
>> problem solving, to show and overcome the faults of weakly typed and
>> inherently undisciplined coding languages of the past (e.g. COBOL,
>> ForTran, BASIC, assembler, etc.).  
>
>Actually, ALGOL 60 had already done that.

But poorly.  Pascal was better.

>Correct, no one but business, education and government uses it.

As someone who has had a quite unreasonable amount of governmental
experience, I can assure you that a great deal of C and C++ are
used in governmental systems.

John S.

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Kaz Kylheku 11/6/97 12:00 AM

In article <878820...@genesis.demon.co.uk>,

Lawrence Kirby <fr...@genesis.demon.co.uk> wrote:
>In article <63r2sv$rgm$1...@helios.crest.nt.com>
>           k...@helios.crest.nt.com "Kaz Kylheku" writes:
>>But it cannot be a conforming hosted implementation, as I pointed out
>>in the other article, because the getc() and putc() functions require
>>the int type to represent everything in the range of 0 to UCHAR_MAX,
>>plus the extra value EOF.
>
>getc() and putc() return EOF if the operation fails. However I can find
>no guarantee that EOF is distinct from a valid character value returned

But EOF indicates end of input or an error condition. If you see EOF
without such a condition, what does that mean?

>by one of these functions, so I disagree that int has to be greater than
>char (specifically that INT_MAX >= UCHAR_MAX). However things are
>unpleasant if that isn't the case.

I forgot that you can check feof() and ferror(), which will resolve the
ambiguity if EOF clashes.

    unsigned char byte;

    switch (ch = getc(stream)) {
    /*...*/
    case EOF:
        if (feof(stream) || ferror(stream)) {
            /* handle */
        } else {
            byte = EOF;                
        }
    /*...*/
    }

However, I doubt that very many programs actually do this.

Is a strictly conforming program required to deal with the possibility
that EOF might not actually be an indicator of neither an error, nor
the end of input?

Could Schildt be right after all? ;)


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting Experiences (was Ada and Pascal etc ) Paul Campbell 11/6/97 12:00 AM

Alan E & Carmel J Brain wrote:

>
> This is implemented in the specification of the interface as:
> Bytes 0     Telegram type
> Bytes 1     Bytes of which the 6 MSBs are the status flags
> Bytes 2-4   unused
> Bytes 5-7   The value up to 20000

Byte ordering for integral types varies across machines so
you must have stuck lucy for this to have worked.

Paul C.
UK.

ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! Samuel Tardieu 11/6/97 12:00 AM

>>>>> "John" == John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> writes:

John> The one huge advantage C++ has over Ada, is that C++ is at least
John> semi-object oriented.  Ada isn't.

Looks like you're unaware of the '95 revision of the Ada language...

  Sam
--
Samuel Tardieu -- s...@ada.eu.org

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 11/6/97 12:00 AM

In article <slrn6620l9....@samoyed.ftc.nrcs.usda.gov>,

John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> wrote:
>On 30 Oct 1997 13:13:54 -0800, Kaz Kylheku <k...@helios.crest.nt.com> wrote:
>>Telecommunication management software is large and complex, but not safety
>>critical,
>
>"HELLO!!??? 911??!!  Damn, the software controlling the switch crashed
>again!" ;->

Embedded software which controls switches is distinct from TMN. TMN typically
runs on workstations and gives operators a map with blinking lights which
enables them to identify crises on the network and take action. The software
works essentially by monitoring the network elements for traffic reports and
alarms, and it not only identifies acute crises but can provide statistics
which can assist with planning future network expansion. That's sort of the
general thing that I would understand as ``telecommunication network
management''.

If network management fails, your call to 911 might not go through as a result
of the failure of the telco to identify and correct network problems such as
congestion or out of service trunks, or some failure in the signalling network,
etc, not as a direct result of the failure of the software.

>>and quasi-real-time at best. Shut-down software for a nuclear reactor
>>may be less complex, but requires much more verification.
>
>But in the end, it is the programmer and the quality assurance procedures
>that make the difference, not language choice.

If there is such thing as THE difference rather than a whole bunch of
smaller differences. :) The question is the extent to which the language
choice plays a role.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 11/6/97 12:00 AM

In article <slrn66258f....@samoyed.ftc.nrcs.usda.gov>,

John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> wrote:
>On Thu, 30 Oct 1997 17:11:26 -0600, Scott Baierl <bai...@schneider.com> wrote:
>>
>>Smart programmers spend their time learning programming languages that help
>>them solve the real-world problems in their particular application domain.
>
>Umm. . . no.  Smart programmers live, learn, and grow up to be sofware
>engineers.  Software engineers live, learn, and grow up to be system
>architects.  System architects live, learn, and grow up to be Computer
>Scientists.

And computer scientists have children who become hackers... :)

>Which is why arguing about which language is best is probably outside
>the scope of most of our area of responsibility.  Most of us here are
>not architects, or even engineers.

Which is why we see arguments like ``but that doesn't matter because I
would never make that sort of error in my program''. :)


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 11/6/97 12:00 AM

In article <slrn66211n....@samoyed.ftc.nrcs.usda.gov>,
John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> wrote:

>Well, considering I was unable to port an Ada program to two of the five
>platforms I was targeting, while I was able to port a C program to all five,
>I'd have to say that C is infinitely more portable.

No, you would have to say that C was 5/3 times as portable in your scenario. :)

>YMMV, and all that.
>
>>If you have an Ada compiler
>
>That *IF*, being the gotcha.
>
>Has anybody ever successfully used Ada on a Linux box?

I have used GNAT under Linux. It works.

Mind you, the first Ada program I tried to write was so bad, that the compiler
core dumped.

I was lightly amused, since it's written in Ada which is purported to prevent
such errors.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Steve Ropa 11/6/97 12:00 AM

On 6 Nov 1997, Kaz Kylheku wrote:

> In article <slrn6620l9....@samoyed.ftc.nrcs.usda.gov>,
> John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> wrote:
> >On 30 Oct 1997 13:13:54 -0800, Kaz Kylheku <k...@helios.crest.nt.com> wrote:
> >>Telecommunication management software is large and complex, but not safety
> >>critical,
> >
> >"HELLO!!??? 911??!!  Damn, the software controlling the switch crashed
> >again!" ;->
>
> Embedded software which controls switches is distinct from TMN. TMN typically
> runs on workstations and gives operators a map with blinking lights which
> enables them to identify crises on the network and take action. The software
> works essentially by monitoring the network elements for traffic reports and
> alarms, and it not only identifies acute crises but can provide statistics
> which can assist with planning future network expansion. That's sort of the
> general thing that I would understand as ``telecommunication network
> management''.
>
Actually, I need to point out that all alarms(fiber cut, huge BER, etc)
are reported to the NMS.  In one system we did, that meant over 10,000
alarms per second, and yes that becomes safety critical.  And actually the
software is not just meant for monitoring.  It will also take some of the
actions necessary to correct these alarms(emergency cutover, cross
connect, etc.)

> If network management fails, your call to 911 might not go through as a result
> of the failure of the telco to identify and correct network problems such as
> congestion or out of service trunks, or some failure in the signalling network,
> etc, not as a direct result of the failure of the software.
>
If some guy accidentally slices my fiber(self healing rings
notwithstanding) and I don't react to it by rerouting the traffic, the 911
call does not go through, and people die.

> >>and quasi-real-time at best. Shut-down software for a nuclear reactor
> >>may be less complex, but requires much more verification.
> >
I of course would not argue with that.  My point is that there are lots of
mission critical applications, and just because it may not seem that way
at first glance, if the customer feels it is...it is.  By the way, I have
worked with several SONET switches, and their embedded software is in C++!
I am not claiming that all, or even most switches are C++, just some of
the ones I worked with.  And yes, they are currently in the field.

> >But in the end, it is the programmer and the quality assurance procedures
> >that make the difference, not language choice.
>
> If there is such thing as THE difference rather than a whole bunch of
> smaller differences. :) The question is the extent to which the language
> choice plays a role.

The ability of the programmer to chose the right language for his/her
problem domain cetainly plays a role.  I think yoiu are right though,
there are really a lot of small roles that make up a good programmer.


Steve


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/6/97 12:00 AM

In <63r2sv$rgm$1...@helios.crest.nt.com> k...@helios.crest.nt.com (Kaz Kylheku) writes:

>In article <63qkp9$bqr$3...@darla.visi.com>,
>Peter Seebach <se...@plethora.net> wrote:
>>
>>No.  Short is not required to be any smaller than long, nor any larger
>>than char.  A system where all four types are 64-bits is conforming.
>
>But it cannot be a conforming hosted implementation, as I pointed out
>in the other article, because the getc() and putc() functions require
>the int type to represent everything in the range of 0 to UCHAR_MAX,
>plus the extra value EOF. It therefore follows that a hosted implementation
>requires the additional requirement:
>
>    char < int

How did you get the idea that EOF must be an "extra value"?  The standard
only requires it to be negative, not to be different from ANY value
returned by a successful call to getc().

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! David Weller 11/6/97 12:00 AM

#define TROLLBAIT(Newsgroups trimmed because I hate Pascal and Java is a fad.)

In article <slrn664qpv....@samoyed.ftc.nrcs.usda.gov>,
John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> wrote:


>On 06 Nov 1997 20:48:26 +0100, Samuel Tardieu <s...@ada.eu.org> wrote:
>>>>>>> "John" == John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> writes:
>>John> The one huge advantage C++ has over Ada, is that C++ is at least
>>John> semi-object oriented.  Ada isn't.
>>Looks like you're unaware of the '95 revision of the Ada language...
>
>I've looked at the new standard.
>
>I do not consider Ada to be an object oriented programming language.
>
Uh-oh...you're not one of those "OO purists", are you?  Those arguments
are red herrings at best...I think your point is made more explicit
in your next sentence...

>Note that you write OO *programs* in almost any language.  I've done
>OO programs in C.  But to be an OO programming language, it isn't
>sufficient to hack in some neat new stuff.
>
Hack?  Hmm...that implies a complete lack of engineering effort, or
a poor "kludge" into a given language.  Perhaps you can compare how
Ada's OO features are a hack compared to, say, C++ templates? (Yes, it's
a troll of sorts, but my point is that I don't think you don't posess
enough experience in both languages to discuss the merits or detractions
of both Ada's OO support or C++ template support...in which case, your
original post should just be retracted and you should say, "Sorry, I
was talking out of my ass...I'll be more careful next time")

>I may, in fact, be impossible to create anything other than a semi-OO
>language, or at best, a Hybrid OO language, with out starting from
>a blank slate.

A plausible argument...spoken language suffers from the same predicament,
but we don't collectively speak Esperanto, Loglan, or (God be praised)
Solresol.  Smalltalkers are quite fond of defending their language is
"pure", but "purity" is an elusive quality.  Perhaps if you defined
"Pure", "Hybrid", and "Hacked" categories of languages, we could
begin to find a common ground for discourse (Hint: You can't do it.  I'm
trolling again :-)

Let's just end this thread by recapping:
1) You didn't know what you were talking about in your original post.
2) You were corrected by a reader
3) You revised your comments by making vacuous statements (Defense By
Hand-Waving).
4) You caught me in a peckish mood and I posted a followup instead
of deleting the thread like a good Netizen.  Hopefully everybody
will NOT follow my example :-)

Alas, most REALLY long threads are started this way...I have a feeling
this will be no exception.

 


Porting Experiences (was Ada and Pascal etc ) Marin David Condic, 561.796.8997, M/S 731-96 11/6/97 12:00 AM

Lawrence Kirby <fr...@GENESIS.DEMON.CO.UK> writes:
>The portability implications of this are small or non-existent (there may
>be performace implications in rare circumstances, and issues relating to
>data sizes and external data formats). As ever the C language is designed
>with the assumption that the programmer knows what he is doing. The use
>of ranges implies that you know beforehand what those ranges will be.
>In C you follow a set of rules:
>
    I think you missed a very important point and one that has trashed
    many attempted ports in my experience.

    While the rules you cite do guarantee a minimum accuracy and
    intelligent use thereof certainly does help things, what do you do
    about all the representation issues? Technically, that integer you
    specify as needing a minimum of 16 bits could get represented with
    32 bits. Suppose that it is used in an I/O record to a data file?
    Now you're incompatible with all the data files built by another
    version which allocated only 16 bits. Or suppose it is passed as a
    parameter to an OS routine or routine written in another language
    or a routine written in C but compiled with a different compiler?

    There are *many* occasions where the internal representation of a
    data item is *critical* to the success of a system. Hence not
    having the ability to explicitly state what sort of representation
    is required can hurt portability. I don't see why C can't be
    modified in some subsequent standard to let the programmer dictate
    that a given number be represented a certain way, so I don't think
    it is the end of the world. But as things stand now, this is a
    weakness in the language that hurts portability and if something
    *does* successfully port without changes, it happens more by
    accident than by design.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  COND...@PWFL.COM
===============================================================================
    "Some people say a front-engine car handles best. Some people say
    a rear-engine car handles best. I say a rented car handles best."
        --  P. J. O'Rourke
===============================================================================

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! William & Melissa Thornton 11/6/97 12:00 AM

This is a multi-part message in MIME format.
--------------2C06438E1EDAEBDA78A851A2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

VERY WELL SAID!

--
                ______________________________
               |                              |
               |  __________________________  |
               |  |########################|  |
               |  |########################|  |
               |  |########################|  |
               |  |#####             ######|  |
               |  |#####    press    ######|  |
               |  |#####   any key   ######|  |
               |  |#####             ######|  |
               |  |########################|  |
               |  |########################|  |
               |  |########################|  |
               |                        []    |
               |_____________     ____________|
                \_____|=+=|( _____ )|=+=|____/
                ____________|_____|__________
            _.-" -=-=-=-=-=-=-=-=-=-=-=-=-=- "-._
          ,"__ =-=-=-this is the any key-=-=-= __",
          |_  _________________________________  _|
            \___________________________________/
--------------2C06438E1EDAEBDA78A851A2
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Thornton, William & Melissa
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             William & Melissa Thornton
n:              Thornton;William & Melissa
adr:            103A Paisley Court;;;Bozeman;Montana;59715-7321;USA
email;internet: thor...@avicom.net
tel;home:       406-586-9166
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------2C06438E1EDAEBDA78A851A2--

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) nos...@nospam.com 11/6/97 12:00 AM

I'm not going to argue this until I can find the document where I read
what I posted. I accept that I might be wrong, or perhaps that the
document was outdated/incorrect.

When/if I find it, I'll post the reference.

/Mike

ADA SUCKS, C/C++/JAVA RULES!!!! John Stevens 11/6/97 12:00 AM

On Sat, 01 Nov 1997 12:51:53 -0600, Charles R. Lyttle <lyt...@flash.net> wrote:
>NOSPAM_...@sm.luth.se wrote:
>[nsippage]
>
>If low up-front cost is the ruling factor, then
>C++ under some MS operating system is about the only thing available.

I beg to differ.  C/C++ on Linux/FreeBSD/NetBSD is a much better choice,
especially is low up-front cost is the ruling factor. . . ;->

>Be
>flexible, learn more than one language, and do software engineering instead of
>"programming".

Sort of like what I tell my students: learning C++ doesn't make you an
object oriented programmer.  Learning the OOP paradigm, however, will
make it childishly simple to write in whatever OOPL you choose for the
current project.  It becomes a simple matter of translation from design to
language specific syntax, at that point.

John S.

Porting Experiences (was Ada and Pascal etc ) Lawrence Kirby 11/6/97 12:00 AM

In article <346106...@gsg.eds.com> nos...@gsg.eds.com "Seymour J." writes:

>Craig Franck wrote:
>>
>> C is no less portable because of this. You may have a case if you
>> state that, perhaps, in this particular aspect of constructing
>> portable programs, Ada is more efficient. You can define your basic
>> types and have the compiler figure it all out. That may make for
>> more optimal code generation. But optimal code generation is not
>> the main goal of portable software. If the code runs half as fast
>> as a native assembler coded routine done by some asm guru whose
>> been pounding away at it for a week, you should be happy with your
>> tools.
>
>It's not just an efficiency issue. As an example, if I have to process
>data from the outside world, there is no portable way to declare them in
>C.

Certainly there is, you may have to do slightly more work explicitly. In
C you can treat any byte format as a sequence of unsigned chars. There's
plenty of portable C code around to deal with, for example, stadnard file
formats such as GIF and ZIP.

>As to the comparison with assembler, there are two problems with it.
>First, the alternative under discussion was Ada, and that's more
>maintainable than C, not less.

I won't argue eihter way there. You may be right to some degree, but the
point is that C isn't as unmaintainable as you seem to make out.

>Second, if you are using a modern
>assembler with a decent macro processor, the assembler code is likely to
>be more maintainable than C code as well (yes, I know that it won't be
>as tight as hand coded one-for-one, but that doesn't bother me.)

However that is an absurd statement. There has beena large trend of moving
from assembly to C (embdeed systems development is a good example) precisely
because the latter is more maintainable. Macros help but they aren't a
universal panacea. If macros are so good how often do you use them in Ada?

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/6/97 12:00 AM

In article <34623D...@dynamite.com.au>,
Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>YES PLEASE. Any help from anyone is always welcome. So much to learn,
>and only one lifetime, *SIGH*
>
>OK, I would like the following:
>
>1st(0th) byte contains telegram type. This has legal values of FF,FE,and 00.
>If the value is FF, then bytes 4-7 contain an IEEE floating point between
>-1.7666 e6 and 2.34 e12. Byte 3 contains an enumeration type, which has the
>values Red,Green, Yellow, corresponding to 01, 10, and FF (hex).  If the value
>is FE, bytes 1-3 contain a binary angle (fixed point), first 13 bits before
>the binary point. Bytes 4-11 contain a packed ANSI 7-bit string.  If the value
>is 00, then the rest is "don't care".
>
>The reading in must check that all values are correct. The floating point will
>be decoded into the form of mantissa, sign, exponent etc.
>
>This is a nice, simple one. I'll get into the really polymorphic records
>later.
>
>Over 2 U.

Okay, first of all we make the assumption that the octets in this datagram are
mapped to bytes in the C execution environment, which need not be octets.  This
is an issue which has to do with how the data are communicated to the execution
environment of the C program. For example, on an IBM mainframe that has 9 bit
bytes, data brought in from the 8 bit world are not chopped into 9 bit units,
but rather their octets are mapped to individual 9 bit bytes which then
have the values 0 to 255 (if interpreted as unsigned char).

The IEEE floating point handling is probably going to be a little shaky, but I
will do my best.

I haven't fully tested this (due to boredom), so let me know if I missed a
requirement, or botched something up.

I also have only implemented the decoding of the telegram, not encoding.

/*------------------------------------------------------------------------*/

    #include <stddef.h>        /* for size_t        */
    #include <math.h>        /* for ldexp()        */

    /*
     * First, we declare some C data type that _internally_ represents the
     * telegram/datagram.
     */

    typedef enum { red = 0x01, green = 0x10, yellow = 0xff } telegram_color;

    typedef struct {
        int type;
        double number;
        unsigned long angle;
        telegram_color color;
        char string[10];
    } telegram;

    int telegram_decode(telegram *tel, unsigned char *buf);
    double ieee_single_decode(unsigned char *buf);
    unsigned long fixed_24_decode(unsigned char *buf);
    void packed_string_decode(unsigned char *dest, unsigned char *src, size_t);

    /*
     * Then we write a routine which decodes that packet from a buffer of
     * bytes, which we assume contains a complete telegram.  We return 0 if
     * there is something wrong with the telegram's contents, 1 if the decoding
     * is successful.  We assume that the buffer has been prepared such that
     * all bytes are in the range 0 to 255 even if unsigned char has a larger
     * range.
     */

    int telegram_decode(telegram *tel, unsigned char *buf)
    {
        switch (tel->type = buf[0]) {
        case 0xFF:        /* legal values */
            tel->number = ieee_single_decode(buf + 4);
            if (tel->number < -1.7666E6 || tel->number > 2.34E12)
                return 0;
            tel->color = buf[3];
            if (tel->color!=red && tel->color!=green && tel->color!=yellow)
                return 0;
            break;
        case 0xFE:
            tel->angle = fixed_24_decode(buf + 1);
            packed_string_decode(tel->string, buf + 4, 8);
            tel->string[9] = 0;
            break;
        case 0x00:
            break;
        default:        /* or exit */
            return 0;
        }

        return 1;
    }
 
    /*
     * decode an IEEE single precision number, assumed to be stored
     * in big endian, broken into individual octets.
     * An IEEE 754 single precision number consists of a sign bit,
     * eight bits of binary exponent biased by adding 127, and
     * 23 bits of mantissa with an implicit 1 stripped away.
     * We try to convert this to a value of type double.
     */

    double ieee_single_decode(unsigned char *buf)
    {
        int sign, exponent;
        unsigned long mantissa;
        double mantdouble, result;


        /*
         * extract the sign bit as an int valued 1 or 0
         * representing negative and positive, respectively.
         */

        sign = ((buf[0] & 0x80) != 0);

        /*
         * extract the exponent as a negative integer
         */

        exponent = ((buf[0] & 0x7f) << 1 | (buf[1] >> 7)) - 127;

        /*
         * extract the mantissa as a 24 bit integer, with the implicit
         * 1 put back in explicitly
         */

        mantissa = (1UL << 23) | (unsigned long) (buf[1] & 0x7f) << 16;
        mantissa |= (unsigned) (buf[2] << 8) | buf[3];

        /*
         * compute the mantissa as a floating point number in the
         * range [0,1)
         */

        mantdouble = (double) mantissa / (1UL << 23);


        /*
         * compute mantdouble * 2**exponent using the standard function.
         */

        result = ldexp(mantdouble, exponent);

        /*
         * factor in the sign and return the result
         */

        return (sign) ? -result : result;
    }

    /*
     * extract a 24 bit fixed point number from three
     * octets. For now, this is just represented as a
     * scaled, unsigned integer, so this operation
     * is trivial.
     */

    unsigned long fixed_24_decode(unsigned char *buf)
    {
        return (unsigned long) buf[0] << 16 | (unsigned) buf[1] << 8 | buf[2];
    }

    /*
     * Decode a 7 bit string packet into eight bits
     * We basically loop over groups of 7 bytes (or 56 bits)
     * since 56 is the least common multiple of 8 and 7.
     * Then handle the remainder of the data which may be
     * less than a full 56 bit block.
     *
     * Parameter n is the number of octets of the input packet,
     * NOT the number of 7 bit characters to be extracted.
     *
     * There are more efficient ways to code this to defeat
     * assumptions of aliasing that the compiler has to make.
     */

    void packed_string_decode(unsigned char *dest, unsigned char *src, size_t n)
    {
        while (n >= 7) {
            dest[0] =                        src[0] >> 1;
            dest[1] = (src[0] & 0x01) << 6 | src[1] >> 2;
            dest[2] = (src[1] & 0x03) << 5 | src[2] >> 3;
            dest[3] = (src[2] & 0x07) << 4 | src[3] >> 4;
            dest[4] = (src[3] & 0x0f) << 3 | src[4] >> 5;
            dest[5] = (src[4] & 0x1f) << 2 | src[5] >> 6;
            dest[6] = (src[5] & 0x3f) << 1 | src[6] >> 7;
            dest[7] =  src[6] & 0x7f;

            dest += 8;
            src += 7;
            n -= 7;
        }

        /* note the reversal of the order of the above dest[] assignments in
           the cases below */

        switch (n) {
        case 6:
            dest[5] = (src[4] & 0x1f) << 2 | src[5] >> 6;
        case 5:
            dest[4] = (src[3] & 0x0f) << 3 | src[4] >> 5;
        case 4:
            dest[3] = (src[2] & 0x07) << 4 | src[3] >> 4;
        case 3:
            dest[2] = (src[1] & 0x03) << 5 | src[2] >> 3;
        case 2:
            dest[1] = (src[0] & 0x01) << 6 | src[1] >> 2;
        case 1:
            dest[0] =  src[0] >> 1;
        case 0:
            break;
        }
    }


/*------------------------------------------------------------------------*/

Here is an example of a packed six-bit data encoding routine which has been
aggressively coded to save the compiler from making pessimistic aliasing
assumptions. Here, the variables x and y are used as temporary values
which eliminate redundant loads from the source array, so that the bare minimum
number of pointer dereference operations is performed. In principle,
the same sort of technique can be applied to packed_string_decode().

    size_t sixbit_encode(unsigned char *dest, unsigned char *src, size_t size)
    {
        size_t out = 0;
        unsigned x, y;

        while (size > 2) {
            *dest++  = (x = *src++)  >> 2;
            *dest++  = (x & 3)       << 4  | (y = *src++) >> 4;
            *dest++  = (y & 15)      << 2  | (x = *src++) >> 6;
            *dest++  =  x & 63;

            size -= 3;
            out += 4;
        }

        switch (size) {
        case 2:
            *dest++  = (x = *src++)  >> 2;
            *dest++  = (x & 3)       << 4  | (y = *src) >> 4;
            *dest++  = (y & 15)      << 2;
            return out + 3;
        case 1:
            *dest++  = (x = *src++)  >> 2;
            *dest++  = (x & 3)       << 4;
            out += 2;
        default:
            return out;
        }
    }

Oh, and to dispel any myth that assembly language is easier to maintain than C,
here is a hand-coded 80x86 equivalent:


                .file        "sixbit-i386.s"

ALIGN                = 16

arg1                = 4
arg2                = 8
arg3                = 12

                .text

rcsid:                .ascii        "$Id: sixbit-i386.s,v 1.1 1997/07/26 18:35:35 kaz Exp $"

#
#  ... snip ...
#

                .globl        sixbit_encode
sixbit_encode:
                pushl        %edi
                pushl        %esi
                pushl         %ebx
                movl        arg1+12(%esp), %edi
                movl        arg2+12(%esp), %esi
                movl        arg3+12(%esp), %ecx
                xorl        %edx, %edx
                cld

                cmpl        $2, %ecx
                je        encode_two
                jb        encode_one

                .align        ALIGN

encode_threes:
                lodsw        (%esi), %ax
                movb        %al, %bh
                andb        $3, %bh
                shrb        $2, %al
                shlb        $4, %bh
                movb        %ah, %bl
                shrb        $4, %ah
                orb        %bh, %ah
                shll        $16, %eax
                andb        $15, %bl
                lodsb        (%esi), %al
                shlb        $2, %bl        
                movb        %al, %bh
                shrb        $6, %al        
                orb        %bl, %al
                movb        %bh, %ah
                andb        $63, %ah
                roll        $16, %eax
                stosl        %eax, (%edi)

                addl        $4, %edx
                subl        $3, %ecx
                cmp        $2, %ecx
                ja        encode_threes
                jb        encode_one

encode_two:        
                lodsw        (%esi), %ax
                movb        %al, %bh
                shrb        $2, %al        
                andb        $3, %bh        
                shlb        $4, %bh

                movb        %ah, %bl
                shrb        $4, %ah        
                orb        %bh, %ah
                stosw        %ax, (%edi)

                andb        $15, %bl
                shlb        $2, %bl        
                movb        %bl, (%edi)

                addl        $3, %edx
                movl        %edx, %eax

                popl        %ebx
                popl        %esi
                popl        %edi
                ret

encode_one:        
                testl        %ecx, %ecx
                je        encode_done

                lodsb        (%esi), %al
                movb        %al, %ah
                shrb        $2, %al        
                andb        $3, %ah
                shlb        $4, %ah        
                movw        %ax, (%edi)

                addl        $2, %edx

encode_done:
                movl        %edx, %eax
                popl        %ebx
                popl        %esi
                popl        %edi
                ret

--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! Charles R. Lyttle 11/6/97 12:00 AM

John Stevens wrote:

> On 06 Nov 1997 20:48:26 +0100, Samuel Tardieu <s...@ada.eu.org> wrote:
> >>>>>> "John" == John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> writes:
> >
> >John> The one huge advantage C++ has over Ada, is that C++ is at least
> >John> semi-object oriented.  Ada isn't.
> >
> >Looks like you're unaware of the '95 revision of the Ada language...
>
> I've looked at the new standard.
>
> My Ada specific programming experience was with the previous standard
> release.

>
> I do not consider Ada to be an object oriented programming language.
>
> Note that you write OO *programs* in almost any language.  I've done
> OO programs in C.  But to be an OO programming language, it isn't
> sufficient to hack in some neat new stuff.
>
> I may, in fact, be impossible to create anything other than a semi-OO
> language, or at best, a Hybrid OO language, with out starting from
> a blank slate.
>
> John S.

Ada was not an OO language. It was Object Based. Quiet a difference and the
difference was deliberate. Many of the OO constructs make any big appliation
"brittle" and reduce safety. I am not fully convienced that all the Ada95
changes were a good idea, but they do make it more Object Oriented and it is
still a lot better than C++. Have you noticed that as time goes by, Ada looks
more like C++ and C++ looks more like Ada? I mean Templates for pity sake.

--

Russ Lyttle

email : lyt...@mail.flash.net


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Peter Mayne 11/6/97 12:00 AM

On Wed, 5 Nov 1997 16:24:51 GMT, Dan...@cern.ch (Dan Pop) wrote:

>In <345f9c32....@mrnews.mro.dec.com> Peter...@digital.com (Peter Mayne) writes:
>
>>I'd say both of these statements are wrong. It depends on the
>>compiler.
>
>But the compiler itself is influenced by the CPU and the OS

I agree. But it is still the compiler designer that makes the choice,
even if that choice is influenced by the OS/CPU.

>>In the case of Alpha, it may have 64 bit registers, but it has natural
>>32 bit and 64 bit datatypes. Is one more "natural" than the other?
>
>Is it "natural" to have no *standard* 64-bit integral type on a compiler
>for a CPU with 64-bit registers?  Yet, this is the case for Alpha NT and
>OpenVMS compilers :-)

In these cases, yes. The compiler designer presumably thought that
since these operating systems also run on 32 bit CPUs which have no
natural 64 bit type, making long or int a 64 bit type would needlessly
complicate things when moving between platforms. Presumably, the
compiler designer was influenced not by the CPU the compiler runs on,
but by the compatibility requirements with a different CPU.

PJDM
Digital Equipment Corporation (Australia), Canberra, ACT
-------------------------------------------------------------------------------
These are my opinions, and have nothing to do with Digital.
This was edited by a wheelbarrow full of walruses.

Porting Experiences (was Ada and Pascal etc ) Craig Franck 11/7/97 12:00 AM

"Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>Craig Franck wrote:
>>
>> C is no less portable because of this. You may have a case if you
>> state that, perhaps, in this particular aspect of constructing
>> portable programs, Ada is more efficient. You can define your basic
>> types and have the compiler figure it all out. That may make for
>> more optimal code generation. But optimal code generation is not
>> the main goal of portable software. If the code runs half as fast
>> as a native assembler coded routine done by some asm guru whose
>> been pounding away at it for a week, you should be happy with your
>> tools.
>
>It's not just an efficiency issue. As an example, if I have to process
>data from the outside world, there is no portable way to declare them in
>C.

Sure there is; C programmers do it all the time.

>As to the comparison with assembler, there are two problems with it.
>First, the alternative under discussion was Ada, and that's more
>maintainable than C, not less.

I think well written code in C or Ada is just about equally maintain-
able by competent programmers in their respective languages.

>Second, if you are using a modern
>assembler with a decent macro processor, the assembler code is likely to
>be more maintainable than C code as well

That's silly. (You been hanging out with SN?)

>(yes, I know that it won't be
>as tight as hand coded one-for-one, but that doesn't bother me.)

By the time you have a macro assembler as maintainable as C, you
would have implemented a compiler. At which point using it would
be silly, because C is more portable.

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! John Stevens 11/7/97 12:00 AM

On 06 Nov 1997 20:48:26 +0100, Samuel Tardieu <s...@ada.eu.org> wrote:
>>>>>> "John" == John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> writes:
>
>John> The one huge advantage C++ has over Ada, is that C++ is at least
>John> semi-object oriented.  Ada isn't.
>
>Looks like you're unaware of the '95 revision of the Ada language...

I've looked at the new standard.

My Ada specific programming experience was with the previous standard
release.

I do not consider Ada to be an object oriented programming language.

Note that you write OO *programs* in almost any language.  I've done
OO programs in C.  But to be an OO programming language, it isn't
sufficient to hack in some neat new stuff.

I may, in fact, be impossible to create anything other than a semi-OO
language, or at best, a Hybrid OO language, with out starting from
a blank slate.

John S.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Craig Franck 11/7/97 12:00 AM

k...@helios.crest.nt.com (Kaz Kylheku) wrote:
>In article <slrn6620l9....@samoyed.ftc.nrcs.usda.gov>,
>John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> wrote:
>>On 30 Oct 1997 13:13:54 -0800, Kaz Kylheku <k...@helios.crest.nt.com> wrote:
>>>Telecommunication management software is large and complex, but not safety
>>>critical,
>>
>>"HELLO!!??? 911??!!  Damn, the software controlling the switch crashed
>>again!" ;->

>If network management fails, your call to 911 might not go through as a result


>of the failure of the telco to identify and correct network problems such as
>congestion or out of service trunks, or some failure in the signalling network,
>etc, not as a direct result of the failure of the software.

It's true the vast majority of telco failures are hardware faults, but
that van der Linden fellow detailed an instance when a bug in a C program
(something to do with a switch statement) caused AT&T's long distance
network to become completely unstable, like it had never done before.

You are correct it's up to the software to deal gracefully with resource
starvation and that normally comes from a hardware failure. And when was
the last time you heard an all circuits busy tone sequence?

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Boyd Roberts 11/7/97 12:00 AM

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>, nos...@spam.com writes:
>
>I even had one person in the past try and tell me that when Intel went to
>64bits, that M$ was going to have:
>
>  short = 2 bytes
>  long  = 4 bytes
>  int   = 8 bytes
>

The original intention of 'int' was to give you a signed machine word.

On a 64 bit machine it makes perfect sense to have a 64 bit int.

It should have been done:

    short 16 (bits)
    int   64
    long  32
    vlong 64

Yes you really do need a new vlong type.  Plan 9 has one.

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: g...@t-1net.com

Porting Experiences (was Ada and Pascal etc ) Boyd Roberts 11/7/97 12:00 AM

>In article <346106...@gsg.eds.com> nos...@gsg.eds.com "Seymour J." writes:
>Second, if you are using a modern
>assembler with a decent macro processor, the assembler code is likely to
>be more maintainable than C code as well (yes, I know that it won't be
>as tight as hand coded one-for-one, but that doesn't bother me.)

Third, if you are using a plugboard with a decent diagram the wiring
is likely be more maintainable than assembler as well (yes, I know that
it won't be a total rats-nest as hand plugged one-for-one, but that
doesn't bother me).

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: g...@t-1net.com

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Ole-Hjalmar Kristensen FOU.TD/DELAB 11/7/97 12:00 AM

nos...@spam.com writes:

> k...@helios.crest.nt.com (Kaz Kylheku) writes:
>
> >
> > In article <345F49A2...@aom.ericsson.se>,
> > Ted Lyngmo  <qhs...@aom.ericsson.se> wrote:
> > >Bob Horvath wrote:
> > >>
> > >> Hmmmm.  How big is an int?
> > >
> > >As I've understood it, an int has two legal sizes. A short has only one,
> >
> > You haven't understood it.
> >
> > A short is large enough to represent numbers in the range -32767 to
> > 32767. An int is also large enough to represent numbers in the
> > same range. A long can represent numbers in the range -2147483647
> > to +2147483647.
>
> Nor have you. The definitions are as follows.
>
> short <= int <= long
> short < long
> short > char
>

Yes, but it is also explicitly stated that
"The values below are acceptable minimum magnitudes; larger values may
be used.

...
INT_MAX         +32767
INT_MIN         -32767
LONG_MAX        +2147483647L
LONG_MIN        -2147483647L
...
SHRT_MAX         +32767
SHRT_MIN         -32767
"

So what you say used to be true, but isn't any more.

> If your system does not conform to this, it isn't ISO (I thinhk it was ISO)
> compliant.
>
> What you stated above is true for (I would assume) all 32bit systems. It
> will not necessarily hold for 64 bit or 128 bit systems.
>

It holds for all systems, else it's not standard C.


 
> I even had one person in the past try and tell me that when Intel went to
> 64bits, that M$ was going to have:
>
>   short = 2 bytes
>   long  = 4 bytes
>   int   = 8 bytes
>
> <rofl>
>
> /Mike


Porting Experiences (was Ada and Pascal etc ) Boyd Roberts 11/7/97 12:00 AM

In article <63p2g1$vnt$1...@helios.crest.nt.com>, k...@helios.crest.nt.com (Kaz Kylheku) writes:
>No C programmer who has a clue about portable coding would specify short
>to get a 32 bit type---unless he was worried about using the smallest possible
>type which fits, thus minimizing resource usage!
>

Well they would if they were coding for the Ariane 5.

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: g...@t-1net.com

ADA SUCKS, C/C++/JAVA RULES!!!! Boyd Roberts 11/7/97 12:00 AM

In article <slrn6622r0....@samoyed.ftc.nrcs.usda.gov>, jste...@samoyed.ftc.nrcs.usda.gov (John Stevens) writes:
>Sort of like what I tell my students: learning C++ doesn't make you an
>object oriented programmer.  Learning the OOP paradigm, however, will
>make it childishly simple to write in whatever OOPL you choose for the
>current project.  It becomes a simple matter of translation from design to
>language specific syntax, at that point.

Simple matter of syntax?  You are living in a dream world.

Say the design calls for a feature the language does not have?

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: g...@t-1net.com

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/7/97 12:00 AM

In <63t1j9$md8$1...@helios.crest.nt.com> k...@helios.crest.nt.com (Kaz Kylheku) writes:

>I forgot that you can check feof() and ferror(), which will resolve the
>ambiguity if EOF clashes.
>
>    unsigned char byte;
>
>    switch (ch = getc(stream)) {
>    /*...*/
>    case EOF:
>        if (feof(stream) || ferror(stream)) {
>            /* handle */
>        } else {
>            byte = EOF;                
>        }
>    /*...*/
>    }
>
>However, I doubt that very many programs actually do this.

Few programs are intended to be portable to such platforms.  The main
reason being that all the implementations with sizeof(int) == 1 that I
know of are freestanding.  But someone who wants to write maximally
portable code had to do the error checking as shown above.

>Is a strictly conforming program required to deal with the possibility
>that EOF might not actually be an indicator of neither an error, nor
>the end of input?

Can a strictly conforming program perform *any* kind of I/O?  You cannot
predict the behaviour of the system from the text of the standard.  Part
of the definition of "strictly conforming program" says:

    It shall not produce output dependent on any unspecified, undefined, or
    implementation-defined behavior...

It is unspecified (or maybe implementation-defined) when an I/O operation
fails and if that failure affects the behaviour of your program...

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Paul F. Pearson 11/7/97 12:00 AM

In article <danpop.8...@news.cern.ch>, Dan...@cern.ch (Dan Pop) wrote:
>In <63se05$bgu$1...@news.nyu.edu> ken...@lab.ultra.nyu.edu (Richard Kenner)
> writes:
>
>>In article
> <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>

> nos...@spam.com writes:
>>>I even had one person in the past try and tell me that when Intel went to
>>>64bits, that M$ was going to have:
>>>
>>>  short = 2 bytes
>>>  long  = 4 bytes
>>>  int   = 8 bytes
>>
>>This was Sun's original choice for their 64 bit systems, but I think
>>later decided against it.
>
>Such a choice simply CANNOT work with the C's promotion rules, unless
>the implementation makes INT_MAX no larger than LONG_MAX, which would
>result in wasting 4 bytes of the int objects.

Am I remembering correctly that ANSI C states the the sizeof(short) must
tbe the sizeof (char)?

--
Paul F. Pearson - ppea...@dynal.com or ppea...@hiwaay.net
http://fly.hiwaay.net/~ppearson/
"Lord heal our land. Father heal our land. Hear our cry and turn our nation
back to You" - Heal Our Land, _Magnify The Lord_ (Integrity Music)

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/7/97 12:00 AM

Craig Franck wrote:
>
> "Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
> >Craig Franck wrote:
>
> >Second, if you are using a modern
> >assembler with a decent macro processor, the assembler code is likely to
> >be more maintainable than C code as well
>
> That's silly. (You been hanging out with SN?)

It's not silly, it's true. "Saying "that's silly" instead of presenting
your ervidence, if any, is what's silly.  And I have no idea who SN is.

> >(yes, I know that it won't be
> >as tight as hand coded one-for-one, but that doesn't bother me.)
>
> By the time you have a macro assembler as maintainable as C, you
> would have implemented a compiler. At which point using it would
> be silly, because C is more portable.

Trying to pur words in my mouth is what's silly here; I never claimed
that the assembler code was portable, just more maintainable.

--

                        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 spam...@library.lspace.org

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/7/97 12:00 AM

In <63toc4$b...@sun001.spd.dsccc.com> jmcc...@sun1307.spd.dsccc.com (Mike McCarty) writes:

>In article <danpop.8...@news.cern.ch>, Dan Pop <Dan...@cern.ch> wrote:
>)In <63r2sv$rgm$1...@helios.crest.nt.com> k...@helios.crest.nt.com (Kaz Kylheku) writes:
>)
>)>In article <63qkp9$bqr$3...@darla.visi.com>,
>)>Peter Seebach <se...@plethora.net> wrote:
>)>>
>)>>No.  Short is not required to be any smaller than long, nor any larger
>)>>than char.  A system where all four types are 64-bits is conforming.
>)>
>)>But it cannot be a conforming hosted implementation, as I pointed out
>)>in the other article, because the getc() and putc() functions require
>)>the int type to represent everything in the range of 0 to UCHAR_MAX,
>)>plus the extra value EOF. It therefore follows that a hosted implementation
>)>requires the additional requirement:
>)>
>)>    char < int
>)
>)How did you get the idea that EOF must be an "extra value"?  The standard
>)only requires it to be negative, not to be different from ANY value
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>)returned by a successful call to getc().
>
>It's true that EOF does not have to be an "extra value". However, it
>-is- required to be -negative-.

Exactly what I wrote above, so I can't see your point here.

>Further, there seems to be an implicit
>requirement that an int can represent any value which an "unsigned char"
>can represent (see 7.3). If one takes the wording
>
>        In all cases the argument is an int, the value of which shall be
>        representable as an unsigned char or shall equal the value of
>        the macro EOF.
>
>as meaning that the values representable as unsigned char is a subset of
>the values representable as an int, then I think that it follows that
>it is a -proper- subset.

Your interpretation is plain wrong.  This paragraph says that the int
argument passed to the function shall be representable as un unsigned
char and nothing more.  An implementation with sizeof(int) == 1 definitely
satisfies this requirement.

>That would seem to imply that sizeof int > sizeof char.

Nope.

More relevant to the discussion are the integral promotions:

    A char, a short int, or an int bit-field, or their signed or
    unsigned varieties, or an object that has enumeration type, may be
    used in an expression wherever an int or unsigned int may be used.  If
    an int can represent all values of the original type, the value is
    converted to an int; otherwise it is converted to an unsigned int.

The wording here definitely provides support for the situation when an
unsigned char cannot be represented as a signed int, right?

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/7/97 12:00 AM

Boyd Roberts wrote:
>
> >In article <346106...@gsg.eds.com> nos...@gsg.eds.com "Seymour J." writes:
> >Second, if you are using a modern
> >assembler with a decent macro processor, the assembler code is likely to
> >be more maintainable than C code as well (yes, I know that it won't be
> >as tight as hand coded one-for-one, but that doesn't bother me.)
>
> Third, if you are using a plugboard with a decent diagram the wiring
> is likely be more maintainable than assembler as well (yes, I know that
> it won't be a total rats-nest as hand plugged one-for-one, but that
> doesn't bother me).

ROTF,LMAO!

Have you evere wired a plug board? Have you written any macros using a
powerfull macro assembler? I go back to the plugboard days, and even
with good documentation (which means a *lot* more than a diagram)
they're not easy to change. Even one-for-one assembler code is more
maintainable than a plug board.

As to rats'-nests, the worst rats' nests that I've seen have been BAIC
and C programs.

--

                        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 spam...@library.lspace.org

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Robert Dewar 11/7/97 12:00 AM

John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> wrote:

>Well, considering I was unable to port an Ada program to two of the five
>platforms I was targeting, while I was able to port a C program to all five,
>I'd have to say that C is infinitely more portable.

No, you would have to say that C was 5/3 times as portable in your scenario. :)

>YMMV, and all that.
>
>>If you have an Ada compiler
>
>That *IF*, being the gotcha.
>
>Has anybody ever successfully used Ada on a Linux box?


Robert Dewar replies

Since you are clearly unaware of what Ada compilers are available, it is
quite possible that your failure to successfully port Ada to some of your
platforms was simply a matter of not finding out how it could be done.
Yes, of course people have used Ada on a Linux box. As you can easily
discover if you look just a little bit, GNAT is fully implemented and
fully validated on Linux, as well as a dozen other platforms. We have a
number of commercially supported customers using Linux.

You can incidentally immediately discover that GNAT is fully implemented
on Linux by accessinfg the official list of validated Ada compilers. Any
Ada programmer should be aware of how to do this, since this is all publicly
available information.

The implementation of Ada 95 on Linux, like all other implementations of
GNAT supported by Ada Core Technologies, is a 100% full implementation of
the core language and all the annexes. We regard it as particularly
significant, since it means that GNAT + GNU + Linux form a 100% free
software solution in the Ada 95 area.

There are many reasons for difficulties in porting programs in any
languages:

  o incompetent use of the language
  o legitimate implementation dependent features
  o inadequacies in compilers
  o fundamental portability flaws in the language design

In the case of Ada, with the set of implementations available today, there
are very few portability problems if any that can be attributed to the
last two reasons. Incompetent programmers can of course write non-portable
code in any language. In particular, to write portable code you MUST be
aware of the defining standard, it is not good enough to informally knows
what happens to work with your compiler.

One real advantage of Ada over C is that Ada programmers tend to be at
least somewhat familiar with the Ada standard, and can be expected to
have a copy available, at least for reference purposes. The C standard
is very much less well known among C programmers (you only have to look
at some of the idiotic statements posted about C in the sizeof(int)
discussion to see how many C programmers have strange ideas about C).
Alternatively ask a roomful of Ada programmers how many have a copy of
the standard available to them and routinely reference it. You will
get essentially 100% yes response. Now ask the same question to a
roomfull of C programmers.

One reason for the difference is that the Ada standard has always been
completely freely available electronically, without copyright problems,
and inexpensive printed copies have also been available. The Ada community
fought hard to achieve this (at one point the ISO standardization was in
the balance over a resulting copyright controversy). Many other language
standards have not been so fortunate. I don't know the current situation
(I know that Ada has inspired other standards groups to try to liberate
their standards), but certainly earlier, the ANSI C standard was relatively
unavailable, and expensive.

Another reason is the culture and circumstances. People tend to have learned
C informally, and figure they know it without need to reference a standard.
Indeed I often meet C programmers who don't really know what the ANSI
standard for C *is*, let alone having a copy of it that they have read.
In the Ada world, everyone knows about the Ada standard, and is very aware
that knowing the standard and following it carefully is the key to writing
portable code.

Robert Dewar
Ada Core Technologies

P.S. Of course I am quite aware that substantive technical arguments can
be made regarding the superior portability of Ada over C from a language
point of view, but those arguments are well covered, and familiar. I wanted
to focus on a rather different aspect of portability, which is the role of
programmer attitude and knowledge.


ADA SUCKS, C/C++/JAVA RULES!!!! Kaz Kylheku 11/7/97 12:00 AM

In article <63usl7$hqo$7...@route1.mdrf.france3.fr>,

Boyd Roberts <bo...@france3.fr> wrote:
>In article <slrn6622r0....@samoyed.ftc.nrcs.usda.gov>, jste...@samoyed.ftc.nrcs.usda.gov (John Stevens) writes:
>>Sort of like what I tell my students: learning C++ doesn't make you an
>>object oriented programmer.  Learning the OOP paradigm, however, will
>>make it childishly simple to write in whatever OOPL you choose for the
>>current project.  It becomes a simple matter of translation from design to
>>language specific syntax, at that point.
>
>Simple matter of syntax?  You are living in a dream world.
>
>Say the design calls for a feature the language does not have?

It then could be that the design contains inappropriate implementation details
rather than focusing on abstractions and their relationships.

Or it could be that the language simply does genuinely lack a way to express
these abstractions and relationships: e.g.  your detailed design calls for
multiple inheritance and you don't have it in the language.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting Experiences (was Ada and Pascal etc ) Peter Seebach 11/7/97 12:00 AM

In article <346384...@gsg.eds.com>,

Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
>As to rats'-nests, the worst rats' nests that I've seen have been BAIC
>and C programs.

The all time worst rats' nest I've ever seen goes to a program that you
could *claim* was C++, but honestly, at my most hostile to the language,
I wouldn't blame it on C++.

It was written by FORTRAN programmers.

The "List" class had one, and only one, virtual function; it was
called "Draw".  The only thing which implemented it was four or five
levels down an inheritance tree, and used it to draw only one kind
of object, with a large set of assumptions about which displays were
available to draw in.  Luckily, it was only called in these cases,
at least, by intent.

That wasn't the worst, it was just one of the most memorable pieces.

I had a lot of fun staring at that code and wondering what posessed
these people to do what they did.  It was pretty crazy.

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Porting Experiences (was Ada and Pascal etc ) Samuel T. Harris 11/7/97 12:00 AM

Before I begin a point-to-point response, I must say
it is refreshing to read a response devoid of ego. I applaud
you and others who are glad to entertain considered discussions
filled with details and facts on the comparative merits.
I also salute your willingness to provide complete C code
supporting your position.

Kaz Kylheku wrote:
>
> In article <3460A7BB...@hso.link.com>,
> Samuel T. Harris <s_ha...@hso.link.com> wrote:
> >Reading the arguments between Kaz and others, I'm struck
> >with the realization that Kaz is missing a significant
> >point. As long as application code is not concerned
> >with the representation of variables, Kaz is correct
> >in his statements that a few simple guidelines insure
> >good type choices for portable C code. What Kaz has
> >failed to consider, but has been state by others, is
> >that sometimes the representation of the type IS
> >important to the application, or at least to the
> >context in which the application is running.
>
> Then the application is not portable, by definition.  A portable program is one
> which is not concerned with the representation of a type.

I don't agree. Portability is the ability to compile an run the
same source in several environments. Type representation is not
a application attribute which determines portability.

IMHO a portable program is one which has to run or has potential
to run on heterogenous platforms. By platform I mean the combination
of hardware, operating system, and compiler. Restrictions on
type selection are usually imposed on the context and many times
that context requires the program to satisfy those restrictions
in a portable way because the context spans many platforms.
In such contexts, applications do need to be concerned with
the representation of type AND still be portable. In such
domains, language choice for the project must recognize the
merits of candidate languages and their facilties which support
satisfying these needs. I recognize that the need for distributed
computing involving heterogenous platforms is on the rise. This
means that application domains which did not care about
type representation are now having to consider such issues given
the need/want to run such almost anywhere.

>
> >The classic example here is a 32-bit integer. While
> >application usually are only concerned witht he RANGE
> >supported by the type (and Kaz's guidelines do insure
> >a proper choice of type) the context in which the
>
> Those are not only my guidelines, but have been reiterated by other comp.lang.c
> regulars. They are also reflected in the comp.lang.c FAQ.

As you say. A good thing recognized by the C establishment as a good
thing.

>
> >app is running may force the use of a 32-bit integer,
> >especially when interfacing to hardware, COTS libraries,
>
> Interfacing to hardware is outside of the domain of a strictly conforming
> C program.  A pure C language program communicates with the environment
> only through streams.
>

This handicaps C for use in embedded systems.

> There are ways, using C, to conform to external storage layouts in maximally
> portable ways which do not depend on the representation of types other
> than the type unsigned char.

Which, as you detail below, involve conversion routines since the
native C types cannot be used on the storage layouts. While this
is a solution, it does have an execution cost (calling the conversion
routines). This is not to say that Ada is maximally efficient
when using representation clauses. There are times when a specified
record layout causes the compiler to emit inefficient code simply
because the required layout is not "natural" to the platform. Such
situations usually are the result of doing simulation work on
hardware other than the intended target. More on that later.

>
> >or in a distributed environment where heterogenous
> >architectures must interface with each other. These
>
> I have programmed in such circumstances and managed to remain strictly
> conforming. Interfacing heterogeneous architectures can be solved by
> identifying a canonical external representation format and then writing
> maximally portable routines which encode data items to and from that
> format. In my experience, only floating point representations represent
> any significant difficulties in this area.

That summarizes my experiences as well. Its just that with Ada, I can
dispense with the conversion/encoding routines when the format lends
itself to direct manipulation. I can't do that with C.

>
> >are common examples of the context forcing a representation.
> >C does not support forcing the representation in a
> >portable way. Ada does. The need for such cannot
> >be simply dismissed because the need is real.
>
> But C allows you to manipulate individual bytes, and therein lies the
> secret.

I can manipulate individual bytes with Ada, but I don't have to
in order to achieve portable code in a context requiring specific type
representations, so I don't.

>
> >In fact, Ada provides me facilities to exactly map
> >the representation of a record right down to the
> >location and size of each field to conform to the
> >requirements of memory-mapped hardware registers.
>
> This is also possible with C in a portable way. It is not that convenient, of
> course, but we are discussing portability, rather than convenience.
>
> >This is very powerful and convenient. I can even
>
> I couldn't agree more, but please stick to the topic which is portability.

This whole thread is about compiling and running the same source
on heterogenous environments. This is on topic and has been
all along.

>
> >So, I can't say to Kaz that he is wrong, because
> >he is not, as far as he goes. What I do say to Kaz
> >is "You have only pricked the tip of the portability
> >iceberg." Portability involves much more than guaranteeing
>
> That's because I was only asked to scratch the surface, because
> the subject that arose was the choice of integral types to suit
> particular requirements. Now we are on the topic of conforming
> to external storage formats, which is something else. You haven't
> requested a discussion of this topic before.

We'll, this was brought up in prior messages leading up to this
thread. Perhaps you missed that aspect but we are both on the
same track now. No matter, I see you have a complete grasp on
the situation now discussed.

>
> Conforming to external data layout can be done in a highly portable way in C.
> It can also be done in non-portable ways which are usually faster.
>
> Instead of useless talk, why don't we try the following game: you describe the
> storage layout, and I will demonstrate a maximally portable C example which can
> communicate with that layout. I will entertain you as long as you wish.
>
> Perhaps you will emerge out of this better armed for situations in which
> you have to use C rather than some other preferred tool such as Ada.

Been there, done that in C.
Been there, still doing that in Ada, and with much less hassle.

Subsequent messages on this thread have gone through this exercise
so I'll refer to them instead of duplicating the effort (or asking
your to duplicate). Your solution, both described in abstract above
and in implementation detail in other messages involves conversions
between an artificial intermediate representation which bears no
resemblence to the required types into and out of a C structure
which only resembles the required items but do not conform to the
specifications of the type. With these three components (the
intermediary
type, the abstract type, and the conversion routines) you do solve
the problem is communications were involved. I note the amount of
code required to support this architecture (conversion routines).
I also note the three separate maintenance areas involved.
The target type specifies range, size, and layout. Size is maintained
in the intermediary type. Range is maintained in the abstract type
(at least as well as C can support it). And layout is maintained
in the conversion routines.

The same situation in Ada dispenses with the conversion routines
(and the associated execution cost AND life-cycle maintenance)
by building the structures to the exacting specifications of the
context. Hence the code remains portable and simple. I submit that
your solution, while it can work, is not simple. My maintenance
is localized to a groups of type declarations and representation
clauses, all of which read very naturally compared to the type
specification itself.

To reimplement your solution in Ada, I simply declare a base
type sans representation clauses and declare derived types
from the base type and apply the necessary representation
clauses for the various type specifications I required.
This allows the compiler to use a most efficient layout
for the base (which I can manipulate as the abstract type).
I can then use simple Ada type conversions (without writting
a single line of supporting code) to convert from one layout
to another. In fact, my current project has a group which
passes hardware data around. We have the actual hardware
to deal with, and a hardware simulator produced by a third
part to deal with. Unfortunately, then don't used exactly
the same layout (how the third party got away with that
snafu is beyond me). We employ the method I have describe
and presto, no hassel and no worries.

I also submit that your solution does not support singleton access
to the fields. Your solution works when the goal is communications.
I get a packet, access and manipulate, and possible resent the packet.
Your solution does not work when the structure must reside on top of
a memory-mapped hardware location. In general, I CANNOT decode the whole
packet at once NOR can I decode the entire packet when I'm done. Some
hardware interfaces are sensitive to not only what I place in memory,
but if I place anything in memory. Bit splillage and extra access are
not allowed. Again, the Ada allows me to not only layout the type as
required, but also overlay the variable where it needs to be. Because
the type naturally maps to the desired representation, I can read/write
only the fields I need as the situation required. I invite you to extend
your solution to support singleton read/write access to each field of
the
structure. I know it can be done, but how much more code do you have to
write,
how many more points of maintenance are introduced, how much more
execution
penaly do is incured, how much more risk of failure is involved.

>
> >products with custom code. C simply does not have the
> >language features to support any but the most
> >rudimentary porting requirements of single-machine,
> >black-box applications that run by themselves or
> >with others in a strictly homogeneous environment
> >all of which are built with a strictly compatible
> >set of tools.
>
> That depends on what you mean by language features. If you mean that C
> doesn't have language features that are *specifically* designed to help you in
> this area, then you are right.

Which has been my point all along. Portability has little to do
with the needs of the application and everything to do with the
needs of the context. The context demands the code run in several
environment. This means portability of source code. It is becoming
increasing common for the context to also demand that code support
a particular type representation. At the risk of
repeating myself, portable code which cannot support specific
type representations is only portable in single-machine, black-box
applications that run by themselves _or_ with others in a strictly
homogenous (type consistent) environment all of which are built
with a strictly compatible (type consistent) set of tools. I submit
that those days are rapidly ending.

Even in the world of embedded and dedicated system, which are
traditionally written for a single target architecture, those days
are ending. More and more development of such system are preceeded
or are in parallel to efforts to simulate the system either for training
or verification. Reuse of code across all three areas is desirable to
cut costs. Usually, the training environment is vastly different from
the target environment and for verification, both environment must talk
to each other. Hence, the "real" code must conform to the target's
representation of things and the "fake" code (for training/simulation)
must also conform especially when used with "real" hardware for
verification.
Such situations are becoming more the norm than the exception
so any discussion of portability, which enables reuse, must
consider portable specification of contextually determined
type representations.

Finally, on the "real" target, I can ill-aford the extra time
and risk of using conversion routines due to the real-world
time response/latency requirements. Given the frequency such
conversion take place, the "fake" target also can ill-aford
conversion routines because the simulator is doing so many other
things to support training and verification that I quickly run out
of CPU horsepower no matter how big my computers. Bigger computers
just mean bigger simulations, not more resources for supporting
activities.

--
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!"

ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! John Stevens 11/7/97 12:00 AM

On Thu, 06 Nov 1997 21:18:55 -0600, Charles R. Lyttle <lyt...@flash.net> wrote:
>John Stevens wrote:
>> I may, in fact, be impossible to create anything other than a semi-OO
>> language, or at best, a Hybrid OO language, with out starting from
>> a blank slate.
>>
>> John S.
>
>Ada was not an OO language. It was Object Based. Quiet a difference and the
>difference was deliberate.

Why so?

>Many of the OO constructs make any big appliation
>"brittle" and reduce safety.

How so?

>I am not fully convienced that all the Ada95
>changes were a good idea, but they do make it more Object Oriented and it is
>still a lot better than C++.

If Ada is the language best suited to producing portable, sold, safe
programs, and OO constructs make an application brittle, then why
would the new standard include them?

Seems like they lost track of their purpose.

>Have you noticed that as time goes by, Ada looks
>more like C++ and C++ looks more like Ada? I mean Templates for pity sake.

Templates.  Fagh!  This is something I never use.

To allow portability to the greatest number of compilers, I try never to
use stuff that sits to close to the "edge", if you know what I mean.

John S.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Kaz Kylheku 11/7/97 12:00 AM

In article <dewar.878897750@merv>, Robert Dewar <de...@merv.cs.nyu.edu> wrote:

>One real advantage of Ada over C is that Ada programmers tend to be at
>least somewhat familiar with the Ada standard, and can be expected to
>have a copy available, at least for reference purposes. The C standard
>is very much less well known among C programmers (you only have to look
>at some of the idiotic statements posted about C in the sizeof(int)
>discussion to see how many C programmers have strange ideas about C).
>Alternatively ask a roomful of Ada programmers how many have a copy of
>the standard available to them and routinely reference it. You will
>get essentially 100% yes response. Now ask the same question to a
>roomfull of C programmers.

I find this to also be true. And not only that, but some C programmers have
a definitely negative reaction against standards, an attitude with is
easily summarised as ``I've hacked this far without the ISO junk,
nobody is going to tell me what value main() should return.'' Or: ``I know how
my compiler works inside and out so don't tell me a[i] = i++ is incorrect!''

>(I know that Ada has inspired other standards groups to try to liberate
>their standards), but certainly earlier, the ANSI C standard was relatively
>unavailable, and expensive.

Nevertheless, there is no excuse that a C programmer can have for not being
familiar with at least the contents of the K&R2 text. Many are not.

Also, let's not forget another reason that you haven't mentioned: a flood
of incorrect textbooks produced about C. Popularity has its drawbacks.

Even though the standard was reproduced (save for a missing page or two: the twit
for instance forgot the page which tells you that footnotes, examples and
annexes aren't part of the text of the standard) in a relatively inexpensive
textbook known as _The Annotated ANSI C Standard_, due to the author's inane
annotations, the book has probably done more damage than good.

>Another reason is the culture and circumstances. People tend to have learned
>C informally, and figure they know it without need to reference a standard.
>Indeed I often meet C programmers who don't really know what the ANSI
>standard for C *is*, let alone having a copy of it that they have read.

* Sigh *

>P.S. Of course I am quite aware that substantive technical arguments can
>be made regarding the superior portability of Ada over C from a language
>point of view, but those arguments are well covered, and familiar. I wanted
>to focus on a rather different aspect of portability, which is the role of
>programmer attitude and knowledge.

This is probably far more significant. C can allow all that wonderful
portability, but it's no good unless the programmer understands it
and gets it right.

--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Mike McCarty 11/7/97 12:00 AM

In article <danpop.8...@news.cern.ch>, Dan Pop <Dan...@cern.ch> wrote:
)In <63r2sv$rgm$1...@helios.crest.nt.com> k...@helios.crest.nt.com (Kaz Kylheku) writes:
)
)>In article <63qkp9$bqr$3...@darla.visi.com>,
)>Peter Seebach <se...@plethora.net> wrote:
)>>
)>>No.  Short is not required to be any smaller than long, nor any larger
)>>than char.  A system where all four types are 64-bits is conforming.
)>
)>But it cannot be a conforming hosted implementation, as I pointed out
)>in the other article, because the getc() and putc() functions require
)>the int type to represent everything in the range of 0 to UCHAR_MAX,
)>plus the extra value EOF. It therefore follows that a hosted implementation
)>requires the additional requirement:
)>
)>    char < int
)
)How did you get the idea that EOF must be an "extra value"?  The standard
)only requires it to be negative, not to be different from ANY value
)returned by a successful call to getc().

It's true that EOF does not have to be an "extra value". However, it
-is- required to be -negative-. Further, there seems to be an implicit

requirement that an int can represent any value which an "unsigned char"
can represent (see 7.3). If one takes the wording

        In all cases the argument is an int, the value of which shall be
        representable as an unsigned char or shall equal the value of
        the macro EOF.

as meaning that the values representable as unsigned char is a subset of
the values representable as an int, then I think that it follows that
it is a -proper- subset. That would seem to imply that sizeof int >
sizeof char.

Mike
--
----
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for DSC.         <- They make me say that.

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Peter Seebach 11/7/97 12:00 AM

In article <63toc4$b...@sun001.spd.dsccc.com>,

Mike McCarty <jmcc...@sun1307.spd.dsccc.com> wrote:
>It's true that EOF does not have to be an "extra value". However, it
>-is- required to be -negative-. Further, there seems to be an implicit
>requirement that an int can represent any value which an "unsigned char"
>can represent (see 7.3). If one takes the wording

>        In all cases the argument is an int, the value of which shall be
>        representable as an unsigned char or shall equal the value of
>        the macro EOF.

>as meaning that the values representable as unsigned char is a subset of
>the values representable as an int, then I think that it follows that
>it is a -proper- subset. That would seem to imply that sizeof int >
>sizeof char.

I don't see it requiring that.  I see it requiring that the arguments
thus described must be in the subset of values representable both in int
and in unsigned char, or EOF, but I don't see anything ruling out values
representable in unsigned char which cannot be used as arguments for
these functions.  :)

-s
--
se...@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! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Larry Elmore 11/7/97 12:00 AM

John Stevens wrote in message ...
>On Fri, 31 Oct 1997, Alan E & Carmel J Brain <aeb...@dynamite.com.au>
wrote:
>>While I agree with most of your post, I must take issue here. C and C++
>>are perceived as being portable. Inasmuch as there are almost no major
>>computers which don't have a C or C++ compiler, this is true. And that's
>>a big, big selling point.
>>
>>However....
>>
>>C and C++ compilers differ by so much that porting is often a Nightmare.
>>Before I get flamed, I'd like to talk to people who've actually ported
>>code cross-platform.
>
>Speaking (err, that is, writing! ;->).
>
>I have written code specifically designed to be ported across platforms.
>
>Note that most of the results of the GNU project have been ported across
>platforms as well, and lately the results have been quite good.

Well, when it's _designed_ that way from the beginning, that makes a
tremendous difference. When it's got to be done for some prize piece of work
that _wasn't_ written that way, but someone wants to port anyway, that's
something else entirely...

>The limiting factor in portability is almost always OS or library issues,
>not incompatibilities in the language itself.


How can you say that about C++, a language in evolution with different
compiler vendors supporting different features at different times?

>>In my own, albeit limited experience, the problems
>>I've had with any C or C++ port are greater than all the problems I've
>>had with Ada crossplatform put together!


>
>Well, considering I was unable to port an Ada program to two of the five
>platforms I was targeting, while I was able to port a C program to all
five,
>I'd have to say that C is infinitely more portable.

Or you understand C a lot better than you do Ada...

>YMMV, and all that.
>
>>If you have an Ada compiler
>
>That *IF*, being the gotcha.
>
>Has anybody ever successfully used Ada on a Linux box?


Yes, for quite some time now. From Linux 1.2.13 and GNAT 3.05 to Linux
2.0.31 and GNAT 3.10p (including recompiling GNAT for my system). And what I
do at home on my P90 compiles and runs identically on Win95 PCs, a  DEC
Alpha running OSF1 v 4.0, and another older Alpha running VMS (all using
GNAT, from 3.07 to 3.09). Of course, no GUI involved, but that's a whole
different can of worms.

>>Now C++ on the other hand, written using CodeWarrior 10 on a Mac, ported
>>to CodeWarrior 10 on an IBM... or even MVC++ 4 vs MVC++ 5... or worse
>>still CodeWarrior 9 on a Mac to CodeWarrior 10 on a Mac to MVC++ 5 on an
>>IBM... In 15,000 LOCs of C++ how many would you reasonably expect to
>>have to be changed? (yes, these were actual examples too)
>
>Note your choice of compiler.  This has a lot to do with it.
>
>Now, using GCC. . .

Do you always have control of what compiler you get to (have to) use?
Besides, "porting" a program can just as easily mean moving it from one
vendor's compiler to another on the same machine and OS because someone
higher up decided it would be "better", as it can mean moving it to
different machines and OSs.

Larry

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/7/97 12:00 AM

In <63se05$bgu$1...@news.nyu.edu> ken...@lab.ultra.nyu.edu (Richard Kenner) writes:

>In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me> nos...@spam.com writes:
>>I even had one person in the past try and tell me that when Intel went to
>>64bits, that M$ was going to have:
>>
>>  short = 2 bytes
>>  long  = 4 bytes
>>  int   = 8 bytes
>
>This was Sun's original choice for their 64 bit systems, but I think
>later decided against it.

Such a choice simply CANNOT work with the C's promotion rules, unless
the implementation makes INT_MAX no larger than LONG_MAX, which would
result in wasting 4 bytes of the int objects.

Dan


--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Gary A. Wiltshire 11/7/97 12:00 AM

"Oliver Batchelor" <ba...@netaccess.co.nz> wrote:
.....
>Shut up
.....


Yes, Ma'am!


   --- Gary Wiltshire

Porting Experiences (was Ada and Pascal etc ) Craig Franck 11/8/97 12:00 AM

"Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>Craig Franck wrote:
>>
>> "Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>> >Craig Franck wrote:
>>
>> >Second, if you are using a modern
>> >assembler with a decent macro processor, the assembler code is likely to
>> >be more maintainable than C code as well
>>
>> That's silly. (You been hanging out with SN?)
>
>It's not silly, it's true. "Saying "that's silly" instead of presenting
>your ervidence, if any, is what's silly.  

What evidence do you want? Saying a modern assembler with a decent
macro processor is likely to produce code that is more maintainable
than C is simply false. If someone came to me and said they wanted
to do a project in Microsoft's latest incarnation of MASM, rather
than C, because that would make the project more maintainable, I
would question their competence. [Not wanting to put words in your
mouth: you may replace MASM with any other macro assembler.]

>And I have no idea who SN is.

Scott Nudds (aka assembly boy, and a lot worse) of PASM fame.

>> >(yes, I know that it won't be
>> >as tight as hand coded one-for-one, but that doesn't bother me.)
>>
>> By the time you have a macro assembler as maintainable as C, you
>> would have implemented a compiler. At which point using it would
>> be silly, because C is more portable.
>
>Trying to pur words in my mouth is what's silly here; I never claimed
>that the assembler code was portable, just more maintainable.

Show me a macro assembler that's more maintainable than C. (I
currently have MASM 6.1 and several hundred megabytes of C and
asm code on my system that proves you wrong.)

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


ADA SUCKS, C/C++/JAVA RULES!!!! Charles R. Lyttle 11/8/97 12:00 AM

Charles W. Johnson wrote:

> On Sun, 2 Nov 1997 17:23:51 -0500, David A. Frantz proclaimed that:
>
> [snip]
>
> > I would agree that to achieve low up front cost a microsoft platform would
> > have to be chosen.   But C++ has as many problems there as anywhere else why
> > not choose Visual Basic for a Win * platform.
>
> [snip]
>
> There are several reasons why I do not consider VB to be an acceptable
> development platform. To list a few:
>
> 1) The language is in no way standardized; those new language "features"
> that M$ proclaims with every release are only new hacks to a language
> that in so little resembles standard BASIC that it can easily be argued
> that it is only called BASIC for marketting purposes.
>
> 2) VB inherits a freeform nature from BASIC that unsuitable for
> writing large, maintainable projects. Last I checked VB does not even
> require you to declare variables and their types (although Option
> Explicit allows you to require this on a module-by-module
> basis). While it has a (very) primitive exception handling mechanism
> (ON ERROR), said is little more than an advanced GOSUB. So ad
> infinitum.
>
> 3) Unless I am mistaken, VB does not support the concept of pointers
> or variable references, so it fails to even be capable of expressing
> basic dynamic data structures which are covered in a second year
> Fundamentals of Computer Science course.
>
> There are many, many options available compilers for Wintel platforms,
> and if you are willing to put aside market monoliths like C++, I would
> suggest that there are many solutions available which are far superior
> to VB.
>
> --
> [Charles W. Johnson <cw...@eskimo.com> - http://www.eskimo.com/~cwj2]
> |    Heathen@Undernet (there is a Heathen@Dalnet. I am not he.)    |
> |<BriceW:#atheism> Is this where you gfo instaed of Church?!       |
> [                 My opinions are mine alone. Duh.                 ]

 In the "quick and dirty" realm, I have seen some pretty good VB programs. I
think plain ol' basic Basic would have been just as functional for this class of
programs, but...
VB has its niche, if it stays there.

--

Russ Lyttle

email : lyt...@mail.flash.net


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Luis Espinal 11/8/97 12:00 AM

> >Having learned C before Ada, I too found Ada overy picky -- at first.
> >However, after writing several thousand lines of code, I came to
appreciate
I agree.

> Is suspect that the difference has partly to do with the level of
diagnosis.  A
> beginner in C or C++ is lulled into a sense that he or she is writing a
correct
> program just because the compiler accepts it.
Again, I agree; I see a lot of that around campus. I found myself trapped
on that "false sense" until I wrote a program in TC that did not behave as
expected when recompiled with VC 4.0 and that did not compile at all under
Unix.

> >But the *biggest* reason C is in such demand?  Inertia.  
Again, I agree. That same reason makes COBOL one of the, if not the most
used languages. Does that means that C and COBOL are somewhat alike:)?
Scary, isn't it:)?


ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! Charles R. Lyttle 11/8/97 12:00 AM

John Stevens wrote:

> On Thu, 06 Nov 1997 21:18:55 -0600, Charles R. Lyttle <lyt...@flash.net> wrote:
> >John Stevens wrote:
> >> I may, in fact, be impossible to create anything other than a semi-OO
> >> language, or at best, a Hybrid OO language, with out starting from
> >> a blank slate.
> >>
> >> John S.
> >
> >Ada was not an OO language. It was Object Based. Quiet a difference and the
> >difference was deliberate.
>
> Why so?
>

Ada used objects to collect code and data into a single component. It did not
support inheritance. The OO purist insisted that you could not call a language
Object Oriented unless it supported all the latest features of every individual
theory of what constituted OO. No two theorist seemed to agree as to what OO meant,
so Ada proponents adopted the term Object Based which prevents a lot of argument.

> >Many of the OO constructs make any big appliation
> >"brittle" and reduce safety.
>
> How so?
>

With multiple inheritance, for example, a change in a line of code can propagate
side effects through out a system. Because of the complex cross connections that
exist with multiple inheritance, it is can be nearly impossible to maintain a
system over time. Fixing a bug in one class by modifying an ancestor class can
induce new bugs in decedent classes way out in left field.

> >I am not fully convienced that all the Ada95
> >changes were a good idea, but they do make it more Object Oriented and it is
> >still a lot better than C++.
>
> If Ada is the language best suited to producing portable, sold, safe
> programs, and OO constructs make an application brittle, then why
> would the new standard include them?
>
> Seems like they lost track of their purpose.
>

   I think so.

> >Have you noticed that as time goes by, Ada looks
> >more like C++ and C++ looks more like Ada? I mean Templates for pity sake.
>
> Templates.  Fagh!  This is something I never use.
>

IMHO, the template concept is a good idea. They correspond approximately to the Ada
generics. It is just the C++ implementation that sucks.

> To allow portability to the greatest number of compilers, I try never to
> use stuff that sits to close to the "edge", if you know what I mean.
>
> John S.

 The old proverb was "Be not the first to discard the old, nor the last to accept
the new." There is a balance to becoming a stick-in-the-mud and chasing the latest
hype into never-never land.

--

Russ Lyttle

email : lyt...@mail.flash.net


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/8/97 12:00 AM

In <ucyY0f5...@newstoo.hiwaay.net> ppea...@nospam.hiwaay.net (Paul F. Pearson) writes:

>Am I remembering correctly that ANSI C states the the sizeof(short) must
>tbe the sizeof (char)?

ANSI C makes no statement whatsoever about sizeof(short).  The ONLY type
on whose size the standard imposes a restriction is char.  The standard
guarantees that sizeof(char) == 1.  

It is theoretically possible to have an implementation with
sizeof(long) < sizeof(int) < sizeof(short), but even on that
implementation you must have SHRT_MAX <= INT_MAX <= LONG_MAX (otherwise
the integral promotion rules would stop working), so the types short and
int would make a very inefficient use of their allocated space.

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

ADA and Pascal work, C,C++, and Java are the only lheadaches you need!! Mark Wilden 11/8/97 12:00 AM

Charles R. Lyttle wrote:
>
> Ada used objects to collect code and data into a single component. It did not
> support inheritance. The OO purist insisted that you could not call a language
> Object Oriented unless it supported all the latest features of every individual
> theory of what constituted OO.

Inheritance is hardly a late-breaking feature. Far from being part of
any "individual theory," inheritance is part of every definition of OOP
I've read in the standard texts.

> No two theorist seemed to agree as to what OO meant,

That may be true, but they do agree it includes inheritance.

> With multiple inheritance, for example, a change in a line of code can propagate
> side effects through out a system. Because of the complex cross connections that
> exist with multiple inheritance, it is can be nearly impossible to maintain a
> system over time. Fixing a bug in one class by modifying an ancestor class can
> induce new bugs in decedent classes way out in left field.

This has nothing to do with multiple inheritance. It's a feature of
inheritance in general. The converse is also true: fixing a bug in an
ancestor class fixes bugs in all descendants. I guess the question to
ask oneself before using inheritance is "Do I create more bugs than I
fix?". :)

ADA SUCKS, C/C++/JAVA RULES!!!! Charles W. Johnson 11/8/97 12:00 AM
ADA ,Pascal, and Basic ROCK! C,C++, and Java are nothing you need!! John Rickard 11/8/97 12:00 AM

--
--
Remove .DONTSPAMME from my
email address to send me REAL email.
--

John Stevens <jste...@samoyed.ftc.nrcs.usda.gov> wrote in article
<slrn667938....@samoyed.ftc.nrcs.usda.gov>...
: On Thu, 06 Nov 1997 21:18:55 -0600, Charles R. Lyttle:

Porting Experiences (was Ada and Pascal etc ) Kaz Kylheku 11/8/97 12:00 AM

In article <640ena$1...@mtinsc04.worldnet.att.net>,

Craig Franck  <clfr...@worldnet.att.net> wrote:
>Show me a macro assembler that's more maintainable than C. (I
>currently have MASM 6.1 and several hundred megabytes of C and
>asm code on my system that proves you wrong.)

You forgot to mention that 90% of the assembly won't even assemble.

Heh heh.


--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
        -- Blair P. Houghton

Porting Experiences (was Ada and Pascal etc ) Vesa Karvonen 11/8/97 12:00 AM

Kaz Kylheku wrote:
> In article <640ena$1...@mtinsc04.worldnet.att.net>,
> Craig Franck  <clfr...@worldnet.att.net> wrote:
> >Show me a macro assembler that's more maintainable than C. (I
> >currently have MASM 6.1 and several hundred megabytes of C and
> >asm code on my system that proves you wrong.)
>
> You forgot to mention that 90% of the assembly won't even assemble.

He also forgot to mention that 90% of C programs invoke undefined
behaviour.

> Heh heh.

Ditto.

--
<-->
  Vesa Karvonen                |   If I were speaking for my
  Housemarque Games, Inc.      |   employer, you would not be
  http://www.housemarque.com   |   reading this...

Porting (was ADA and Pascal etc) Simon Wright 11/9/97 12:00 AM

se...@plethora.net (Peter Seebach) writes:

> In article <x7v90v5...@pogner.demon.co.uk>,
> Simon Wright  <si...@pogner.demon.co.uk> wrote:
> >How does the C++ style localise scope? With the exception of variables
> >declared in "for" loops, the scope's from the point of declaration to
> >the end of the current block, not so?
>
> Of course not!  How could anyone be so *stupid* as to think that
> the clear explanation in the ARM is correct?  C++ being a very stable
> language, and well designed at all times, the scope of the variable
> is the for loop; it goes out of scope after the for loop's statement.

I think you're accusing me of something I didn't say!

  {
    // code with no access to j
    int j = 4;
    // code that can access j
    for (int k = 3; k < 5; k++) {
      // code that can access j and k
    }
    // code that can access j *but not k*
  }
  // j no longer accessible

and my point was that "code that can access j *but not k*" is as long
as a piece of string ..

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

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Peter Mayne 11/9/97 12:00 AM

On 6 Nov 1997 10:33:31 GMT, bo...@france3.fr (Boyd Roberts) wrote:

>In article <danpop.8...@news.cern.ch>, Dan...@cern.ch (Dan Pop) writes:
>>Is it "natural" to have no *standard* 64-bit integral type on a compiler
>>for a CPU with 64-bit registers?  Yet, this is the case for Alpha NT and
>>OpenVMS compilers :-)
>
>Sad, but true.  They got it completely wrong.

Why?

PJDM
Digital Equipment Corporation (Australia), Canberra, ACT
-------------------------------------------------------------------------------
These are my opinions, and have nothing to do with Digital.
This was edited by a wheelbarrow full of walruses.

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/9/97 12:00 AM

In article <3461ee56.265363281@news> mke...@kenan.com "Morris M. Keesan" writes:

...

>#define EOF (-1)
>#define CHAR_BITS 64
>#define UCHAR_MAX 0x7fffffffffffffff

The problem here is that you can't have holes in an unsigned char. So if
CHAR_BIT is 64 then UCHAR_MAX must be 0xffffffffffffffff

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Porting Experiences (was Ada and Pascal etc ) Dennis Weldy 11/9/97 12:00 AM

Go check DejaNews. Restrict yourself to the comp.lang.asm.x86, comp.lang.c,
and comp.lng.c++ newsgroups. Look for messages by "Scott Nudds".

Really a quite unique induhvidual.

Dennis
Shmuel (Seymour J.) Metz wrote in message <346382...@gsg.eds.com>...


>Craig Franck wrote:
>>
>> "Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>> >Craig Franck wrote:
>>
>> >Second, if you are using a modern
>> >assembler with a decent macro processor, the assembler code is likely to
>> >be more maintainable than C code as well
>>
>> That's silly. (You been hanging out with SN?)
>
>It's not silly, it's true. "Saying "that's silly" instead of presenting
>your ervidence, if any, is what's silly.  And I have no idea who SN is.

>
>> >(yes, I know that it won't be
>> >as tight as hand coded one-for-one, but that doesn't bother me.)
>>
>> By the time you have a macro assembler as maintainable as C, you
>> would have implemented a compiler. At which point using it would
>> be silly, because C is more portable.
>
>Trying to pur words in my mouth is what's silly here; I never claimed
>that the assembler code was portable, just more maintainable.
>
>--
>
>                        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 spam...@library.lspace.org

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/9/97 12:00 AM

In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:

...

>It is theoretically possible to have an implementation with
>sizeof(long) < sizeof(int) < sizeof(short), but even on that
>implementation you must have SHRT_MAX <= INT_MAX <= LONG_MAX (otherwise
>the integral promotion rules would stop working), so the types short and
>int would make a very inefficient use of their allocated space.

More directly it violates 6.1.2.5:

"There are four signed integer types, designated as signed char, short int,
 int and long int

 ...

 ...In the list of signed integer types above, the range of values of each
 type is a subrange of the values of the next type in the list"

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/9/97 12:00 AM

In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:

...

>>Is a strictly conforming program required to deal with the possibility
>>that EOF might not actually be an indicator of neither an error, nor
>>the end of input?
>
>Can a strictly conforming program perform *any* kind of I/O?

Yes.

> You cannot
>predict the behaviour of the system from the text of the standard.

Yes you can, however that behaviour depends on input from the environment.
Error returns from I/O functions constitute a form of input from the
environment.

> Part
>of the definition of "strictly conforming program" says:
>
>    It shall not produce output dependent on any unspecified, undefined, or
>    implementation-defined behavior...

However that doesn't mean that a strictly conforming program has to produce
the same output every time you run it. If that were true a program which
wrote output derived from rand() could not be strictly conforming (and it
can).

>It is unspecified (or maybe implementation-defined) when an I/O operation
>fails and if that failure affects the behaviour of your program...

No, it isn't. The standard states explicitly all cases of unspecified and
implementation-defined behaviour, these terms are very specific.
Only undefined behaviour can result from a lack of definition, and even
then only from a *total* lack of definition (or there is a defect in the
standard). getc() (for example) has no unspecified and no
implementation-defined behaviour (*). It only has undefined behaviour where
its argument is not a valid pointer to a stream. What it actually does in
any particular circumstance will depend on input from the environment,
and that includes whether it generates an end-of-file or error indication.

* - there are various forms of implementation-defined behaviour specified
generally for files and streams, e.g. in section 7.9.2 and 7.9.3. You may
have a valid argument relating to those but that needs to be argued on a
case by case basis, I'm referring above to getc() specifically as defined
in section 7.9.7.5.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


ADA SUCKS, C/C++/JAVA RULES!!!! Charles W. Kann 11/10/97 12:00 AM

Boyd Roberts (bo...@france3.fr) wrote:
: In article <slrn6622r0....@samoyed.ftc.nrcs.usda.gov>, jste...@samoyed.ftc.nrcs.usda.gov (John Stevens) writes:
: >Sort of like what I tell my students: learning C++ doesn't make you an
: >object oriented programmer.  Learning the OOP paradigm, however, will
: >make it childishly simple to write in whatever OOPL you choose for the
: >current project.  It becomes a simple matter of translation from design to
: >language specific syntax, at that point.

: Simple matter of syntax?  You are living in a dream world.

: Say the design calls for a feature the language does not have?

This is too true.  Many authors now advocate "designing to an interface",
for example Design Patterns by Gamma, et al, or any of the recent books
by Coad and Mayfield.  It can be done in C++, it is just clunky.  But
because Ada made the decision that there is never a reason to use
multiple inheritence, I have never been able to figure out a way to
write general purpose programs which use an interface like construct.
I would love to hear if someone has (and Generics don't count.  They
are backwards and non-dynamic.  And neither does the stupid "alias
type" field in a record which is advocated by AdaMagic.  Talk about
a KLUDGE, it was never even checked when I used it).

Many researchers believe that language greatly influences how programmers
generate code, even when things can be done one of several languages.  There
are papers by Thomas Green, Simon Davis, Rachael Belamy, David Gilmore,
and more that show, for simple programs and constructs, that the type type
of program developed depends on the language.  And I am personally convinced
that if you need to change your best model of your program to
match the language, you will nearly always end up with a less good program.

That said, I believe you should learn many programming languages and
ways to develop a program so you have many more ways to view a program,
and more tools to use when implementing it.  Which is my argument for
teaching Ada, Java, C++, Eiffel, Prolog, and LISP (minimally) in any
real Computer Science curriculum.

My 2 cents worth.

--
chuck kann
ck...@seas.gwu.edu

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/10/97 12:00 AM

Craig Franck wrote:
 
> What evidence do you want? Saying a modern assembler with a decent
> macro processor is likely to produce code that is more maintainable
> than C is simply false.

ROTF,LMAO. It's the code produced by the programmer that is at issue,
not what is generated by the compiler. If you are in the habbit of
changing the output of your compiler in order to "save recompilation"
time, then it is past time for you to move into the 20th century.

> If someone came to me and said they wanted
> to do a project in Microsoft's latest incarnation of MASM, rather
> than C, because that would make the project more maintainable, I
> would question their competence. [Not wanting to put words in your
> mouth: you may replace MASM with any other macro assembler.]

If the only macro assembler that you know is MASM, then I question your
competence to address the issue.

> Show me a macro assembler that's more maintainable than C. (I
> currently have MASM 6.1 and several hundred megabytes of C and
> asm code on my system that proves you wrong.)

It proves nothing but the limitations of your background. It's not so
much that C and MASM is all you know, it's that you don't understand
that not all assemblers are the same and that not all programs in the
same language are the same. I'm willing to take your word for it the the
code you wrote in MASM is unmaintainable, but that says nothing about
code written by others or about code written for other asemblers.

--

                        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 spam...@library.lspace.org

ADA SUCKS, C/C++/JAVA RULES!!!! Jon S Anthony 11/10/97 12:00 AM

ck...@seas.gwu.edu (Charles W. Kann) writes:

> because Ada made the decision that there is never a reason to use
> multiple inheritence,

Actually, all that was decided was there was no reasonably agreed upon
definition of how MI works in all the various OOLs that have it.  This
led to a decision to provide building blocks to allow the programmer
to build whatever version he thought was "correct".

Personally, I think MI is a complete goof wrt any modeling effort and
"should" be avoided if at all possible.  In some implementation
vehicles you can't avoid it as it is the only multi-view combinator
you have.


> I have never been able to figure out a way to write general purpose
> programs which use an interface like construct.

Such as?  By far the most common use of MI is as a kludge to implement
mixin behavior.  You get this cleanly and simply in Ada95 with SI and
generic mixins.


> I would love to hear if someone has (and Generics don't count.  They

Yes, of course.  Please feel free to give a case where MI as
implemented in C++ (from the NG list I assume you think C++ is it as
Java does not have MI either) is really necessary.

If you want something that is really useful, you might better think
along the lines of multiple dispatch and generic functions ala' CLOS.


> are backwards and non-dynamic.  And neither does the stupid "alias
> type" field in a record which is advocated by AdaMagic.  Talk about
> a KLUDGE, it was never even checked when I used it).

This is really a _view_ capability.  IMO, views are far more
expressive and consistent than MI.  You can say that the mechanism
provided for this is "nutsy boltsy", but it is not a kludge per se.
Shrug.


> Many researchers believe that language greatly influences how programmers
...

Right.

> that if you need to change your best model of your program to match
> the language, you will nearly always end up with a less good
> program.

More or less agree.


> That said, I believe you should learn many programming languages and
> ways to develop a program so you have many more ways to view a program,
> and more tools to use when implementing it.  Which is my argument for
> teaching Ada, Java, C++, Eiffel, Prolog, and LISP (minimally) in any
> real Computer Science curriculum.

My only "disagreement" here would be the "minimally" tag on Lisp.
While it has problems like anything else, IMO it is by far the most
expressive and flexible of all those listed.

/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

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/10/97 12:00 AM

In <873814...@genesis.demon.co.uk> fr...@genesis.demon.co.uk (Lawrence Kirby) writes:

>The problem here is that you can't have holes in an unsigned char.

Chapter and verse, please.

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/10/97 12:00 AM

In <873814...@genesis.demon.co.uk> fr...@genesis.demon.co.uk (Lawrence Kirby) writes:

>In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:
>
>>Can a strictly conforming program perform *any* kind of I/O?
>
>Yes.

Please provide an example.

>> Part
>>of the definition of "strictly conforming program" says:
>>
>>    It shall not produce output dependent on any unspecified, undefined, or
>>    implementation-defined behavior...
>
>However that doesn't mean that a strictly conforming program has to produce
>the same output every time you run it. If that were true a program which
>wrote output derived from rand() could not be strictly conforming (and it
>can).

Nope, it cannot.  The behaviour of rand() is unspecified.  Also code using
floating point arithmetic or most of the functions from <math.h> cannot
be strictly conforming.

>>It is unspecified (or maybe implementation-defined) when an I/O operation
>>fails and if that failure affects the behaviour of your program...
>
>No, it isn't. The standard states explicitly all cases of unspecified and
>implementation-defined behaviour, these terms are very specific.
>Only undefined behaviour can result from a lack of definition, and even
>then only from a *total* lack of definition (or there is a defect in the
>standard). getc() (for example) has no unspecified and no
>implementation-defined behaviour (*).

You missed the point.  It is undefined when the well defined conditions
that lead to the failure of a stdio function occur.  But the behaviour of
the program depends on the occurence of these conditions.

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/10/97 12:00 AM

Dennis Weldy wrote:
>
> Go check DejaNews. Restrict yourself to the comp.lang.asm.x86, comp.lang.c,
> and comp.lng.c++ newsgroups. Look for messages by "Scott Nudds".

Thanks; I found a lot of posts from him in scientific news groups, but
all that I found in the comp.* hierarchy were messages about him. There
seem to be a lot of messages making catty remarks about him, but very
little background on what he did to provoke them. OTOH, with 1540 hits
there was no way that I could read all of them :-(

BTW, did something happen to him recently? I saw some references to him
in the past tense, but didn't see an obit.

--

                        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 spam...@library.lspace.org

Porting Experiences (was Ada and Pascal etc ) Dennis Weldy 11/10/97 12:00 AM

He pretty much disappeared. No idea if anything happened.

IMO, in the general case, the code produced with an HLL will be a bit more
maintaibale and easier to understand than equivalent Assembly. That said,
it's lso possible to write obscure, unmaintainable code in any language.
Straight Assembly will typically have one too busy looking at individual
pieces of bark, let alone being able to see a tree (or forest). That's not
to say that its not possible:-)

Further, if one is using assembly to get max speed, you'll use the
associated tools to do so. Using a "nonobvious" instruction sequence to
avoid pileline stalls, AGI locks, what have you.

At the HLL level, one usually doesn't have that. And y'can usually see
things at a bit higher level.
A bt easier to see whats going on as the amount of information per line of
code is typically higher.

Just my views. Counterexamples welcome :-)

Dennis

Shmuel (Seymour J.) Metz wrote in message <346782...@gsg.eds.com>...

Porting Experiences (was Ada and Pascal etc ) Craig Franck 11/11/97 12:00 AM

"Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>Craig Franck wrote:
>
>> What evidence do you want? Saying a modern assembler with a decent
>> macro processor is likely to produce code that is more maintainable
>> than C is simply false.
>
>ROTF,LMAO. It's the code produced by the programmer that is at issue,
>not what is generated by the compiler.

I meant the source code the programmer would produce using those
two tools. (I was a bit ambiguous with my phrasing.)

>If you are in the habbit of
>changing the output of your compiler in order to "save recompilation"
>time, then it is past time for you to move into the 20th century.

Why, were they doing that in the 19th century. :-)

>> If someone came to me and said they wanted
>> to do a project in Microsoft's latest incarnation of MASM, rather
>> than C, because that would make the project more maintainable, I
>> would question their competence. [Not wanting to put words in your
>> mouth: you may replace MASM with any other macro assembler.]
>
>If the only macro assembler that you know is MASM, then I question your
>competence to address the issue.

I like MASM.

>> Show me a macro assembler that's more maintainable than C. (I
>> currently have MASM 6.1 and several hundred megabytes of C and
>> asm code on my system that proves you wrong.)
>
>It proves nothing but the limitations of your background.

Then suggest a better macro assembler. Please, *do* enlighten.

>It's not so
>much that C and MASM is all you know, it's that you don't understand
>that not all assemblers are the same and that not all programs in the
>same language are the same.

Every one of those points you just made is false.

>I'm willing to take your word for it the the
>code you wrote in MASM is unmaintainable,

I never said it was unmaintainable; it's very good code. The code I
got from that Len Dorfman fellow and dozens of others is very good.

>but that says nothing about
>code written by others or about code written for other asemblers.

Only a very small fraction of the code on my system was written by
me. It would be helpful if you would post a small snippet (or e-mail
me with more) of macro assembler source code that you feel is more
maintainable than when coded in a HLL like C.

[If your reading comp.lang.c you can drop the .ada and .c++ groups.]

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


ADA SUCKS, C/C++/JAVA RULES!!!! Remove 'NOSPAM' to reply 11/11/97 12:00 AM

On 10 Nov 1997 19:05:30 -0500, Jon S Anthony <j...@synquiry.com> wrote:

:ck...@seas.gwu.edu (Charles W. Kann) writes:
:
:> because Ada made the decision that there is never a reason to use
:> multiple inheritence,
:
:Actually, all that was decided was there was no reasonably agreed upon
:definition of how MI works in all the various OOLs that have it.

:This
:led to a decision to provide building blocks to allow the programmer
:to build whatever version he thought was "correct".

But that's yet another definition of how "MI works".

Did the Ada designers shy away from choosing one particular module scheme
because "there was no reasonably agreed upon definition of how modules ought
to work"?  Ditto for exceptions.

Ans: no.  

:> I have never been able to figure out a way to write general purpose


:> programs which use an interface like construct.
:
:Such as?  By far the most common use of MI is as a kludge to implement
:mixin behavior.  You get this cleanly and simply in Ada95 with SI and
:generic mixins.

Explain the kludginess of of "mixins" done, say with Sather or Eiffel.

(what's a generic mixin?)

I think it's perfectly OK to admit most of the truth that there was no clean
way to do MI in a language which included most of Ada83 and its module
system as an intellectual base.

--
*        Matthew B. Kennel/Institute for Nonlinear Science, UCSD          
*
* According to California Assembly Bill 3320, it is now a criminal offense
* to solicit any goods or services by email to a CA resident without
* providing the business's legal name and complete street address.
*


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Dr E. Buxbaum 11/11/97 12:00 AM

John Stevens wrote:
> >If you have an Ada compiler
>
> That *IF*, being the gotcha.
> Has anybody ever successfully used Ada on a Linux box?

I have not worked with it personally, but there is the Gnu Ada compiler
(Gnat). So in theory you should be able to run Ada on any system which
is supported by Gnu software, including Linux.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Russ Lyttle 11/11/97 12:00 AM
I run gnat on Linux. Have for about 3 years. The first years were not
the best, but it works just fine now.

ADA SUCKS, C/C++/JAVA RULES!!!! Marc Wachowitz 11/11/97 12:00 AM

ken...@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) wrote:
> I think it's perfectly OK to admit most of the truth that there was no clean
> way to do MI in a language which included most of Ada83 and its module
> system as an intellectual base.

Nothing against admitting this in case it truly was the reason, but I
don't see why it would be true. In fact, off the top of my head I could
think of several different approaches to integrating MI - be it multiple
interface inheritance with single code inheritance, or full multiple
code inheritance - with "OO-less Ada95". Of course, different people's
interpretations of what "clean" means in our context vary considerably.

I wouldn't like to try and please a fanatic "OO-purist" (bad misnomer,
but established by a bad tradition) who will only accept something as
"clean OO" if it looks pretty much like his beloved programming language
(be that Self or Smalltalk or Eiffel or Common Lisp's object system or
whatever else), but given what I'd expect about someone who generally
likes Ada (particularly its emphasis on readability and explicitness
vs. ease/compactness of writing, and the freedom to chose among design
alternatives), I think it would have been possible to find something
consistent with these tendencies and workable in practice. Basically I'd
go for a delegation-like model, where overriding is only possible with
the routines marked as such, and the decision whether or not to override
something must be explicit, such that with every subtype there's a list
of all available methods; thus any new method in a supertype would trigger
the need in subtypes to consider whether that new method would be used as
provided, or redefined, or that particular subtyping ceases to make sense.
Another approach would be to establish messages as declarations in their
own right, not inherently associated with types, and then define subtyping
as relation on the set of handled messages, where again handlers would be
required to be explicit. This way one could avoid name clashes or repeated
inheritance, not having to make up complicated solutions for problems which
don't occur in the first place. The design space is really quite large,
much richer than only the more popular models of Java, C++ or Eiffel.

My impression is indeed that the Ada language-design tradition tends to
be conservative about inventing unconventional "big models" - like some
very unusual form of OO - but will rather provide well-established features
(perhaps combined in a way which was previously not common) and building
blocks - which can be used in lots of different situations - for a variety
of designs, and I have no reasons to doubt that the original description
why MI was left out is true.

-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>

ADA SUCKS, C/C++/JAVA RULES!!!! Charles W. Kann 11/11/97 12:00 AM

: :> I have never been able to figure out a way to write general purpose
: :> programs which use an interface like construct.
: :
: :Such as?  By far the most common use of MI is as a kludge to implement
: :mixin behavior.  You get this cleanly and simply in Ada95 with SI and
: :generic mixins.

When I posted this, I was talking about "interface".  Look it up in Java.
It isn't "mixins".  It is clean, dynamic, straight forward, and very easy
to understand.  "interface" was one of the best ideas in Java.  Everytime
I mention this to an Ada person, they always try to make it like "you can
do everything in Ada, so this has to be there".  The most common thing Ada
people tell me is to look at Generics.  I know Generics, and it has nothing
to do with the concept of an "interface".  It is: 1 - static, and
2 - backwards.  

If there is an easy way to create the equivalent of an "interface" in
Ada, I would love to see it.  It can be done (if you are careful) in C++,
or any language with Virtual functions, Abstract classes, AND multiple
inheritence.  I am not putting down Ada, but it isn't the answer to every
problem, and regardless of what some Ada advocates might say, Ada 95 made
(alot) of bad design decisions.  Protected types (the implementation, the
idea was great), object allocation, inheritence are just a few bad decisions.

--
chuck kann
ck...@seas.gwu.edu

ADA SUCKS, C/C++/JAVA RULES!!!! Jon S Anthony 11/11/97 12:00 AM

ck...@seas.gwu.edu (Charles W. Kann) writes:

> : :> I have never been able to figure out a way to write general purpose
> : :> programs which use an interface like construct.
> : :
> : :Such as?  By far the most common use of MI is as a kludge to implement
> : :mixin behavior.  You get this cleanly and simply in Ada95 with SI and
> : :generic mixins.
>
> When I posted this, I was talking about "interface".  Look it up in Java.

Yeah, I already know about Java interfaces.


> It isn't "mixins".  It is clean, dynamic, straight forward, and very
> easy to understand.  "interface" was one of the best ideas in Java.

OK, yeah, that sounds about right.


> The most common thing Ada people tell me is to look at Generics.  I
> know Generics, and it has nothing to do with the concept of an
> "interface".  It is: 1 - static, and 2 - backwards.

I think the real issue here is clarity.  You may have been intending
to talk about "interface" as in Java interface, but you didn't
communicate that.  At least not well enough for me to catch what you
meant to say.

 
> If there is an easy way to create the equivalent of an "interface" in
> Ada, I would love to see it.  It can be done (if you are careful) in C++,
> or any language with Virtual functions, Abstract classes, AND multiple

Well yes you can.  It seems odd that you would even suggest that you
"can't".  Is it _clean_?  Well, IMO not particularly.  For some
reasonable details see Tucker Taft's _Programming the Internet in Ada
95_:

http://www.inmet.com/~stt/adajava_paper/

This mapping technique is how one Ada=>Java implementation handles
Java interfaces - going in both directions.  The idiom is simplified
for the AdaJava user via a new interface (Ada sense) convention:
Java_Interface.  This let's the compiler do some of the rubbish you'd
have to do by hand if just using the idiom in out of the box Ada95.


> inheritence.  I am not putting down Ada, but it isn't the answer to
> every problem, and regardless of what some Ada advocates might say,

I have no problem putting Ada "down".  I've done it many times.  Just
be _clear_ about what the actual technical issues are _and_ make a
decent argument for it.  Don't just assert it.  Well, you can do that
to, just don't be surprised if no one pays much attention.

/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

ADA SUCKS, C/C++/JAVA RULES!!!! Brian Rogoff 11/11/97 12:00 AM

On 11 Nov 1997, Charles W. Kann wrote:
> When I posted this, I was talking about "interface".  Look it up in Java.
> It isn't "mixins".  It is clean, dynamic, straight forward, and very easy
> to understand.  "interface" was one of the best ideas in Java.  Everytime
> I mention this to an Ada person, they always try to make it like "you can
> do everything in Ada, so this has to be there".  The most common thing Ada
> people tell me is to look at Generics.  I know Generics, and it has nothing
> to do with the concept of an "interface".  It is: 1 - static, and
> 2 - backwards.  

        I have no idea in what sense you think (Ada) generics are
"backward", but they do not model the dynamic aspects of Java interfaces.
They can be used like ML signatures, but to do Java interfaces you have
to use the secret technique hidden away in the unavailable document, the
"Ada 95 Rationale", which can be found easily at www.adahome.com. If you
look at 4.6.3 you'll find exactly what you need.

>
> If there is an easy way to create the equivalent of an "interface" in
> Ada, I would love to see it.  It can be done (if you are careful) in C++,
> or any language with Virtual functions, Abstract classes, AND multiple
> inheritence.

        It certainly isn't as syntactically convenient as Java interfaces
(or Sather abstract types) but I find Ada's OO component usable, and its non-OO
facilities like hierarchical modules and powerful generics more than make
up for its conservative OO approach. All IMO, of course.

-- Brian


ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! John Stevens 11/12/97 12:00 AM

But as suggested, I've never gotten it to work under Linux.  If anybody
has, is the result "true" Ada (does the compiler compile any legal Ada
program) and if so, to what standard does it comply?

John S.

which languages suck Stanley R. Allen 11/12/97 12:00 AM

Larry Elmore wrote:
>
> GNAT is a validated Ada 95 compiler. I'm not at all sure, but I think it
> still might be the _only_ validated Ada 95 compiler available. Maybe that's
> changed recently, though.

There are over 80 validated Ada95 compilers (at last count), and
numerous others which correctly operate but do not have a validation
certificate.

But I believe that GNAT is the only validated one for Linux.

--
Stanley Allen
mailto:s_a...@hso.link.com

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/12/97 12:00 AM

Craig Franck wrote:
 
> I meant the source code the programmer would produce using those
> two tools. (I was a bit ambiguous with my phrasing.)

Well, if that's what you meant, I've got decades of experiences in a lot
of languages. The languages that have a good macro facility have an
dvantage for applications where you need to supply complicated initial
alues, since you can write a macro to automate the dirty work. Still
mportant, but less so, is the generation of conditional code based on
yntactical tests, e.g., number of arguments.

> Why, were they doing that in the 19th century. :-)

Hyerbole; sometimes I say "Before the fool, and I'm quite certain that
old man Noach wasn't building computers with that gopher wood. ;-)

> >If the only macro assembler that you know is MASM, then I question your
> >competence to address the issue.
>
> I like MASM.

It has its good points, but there are wide variations among assemblers,
and unless you've seen a number of them then you have no basis to
discuss
assemblers in general, only the ones that you've seen.

 
> Then suggest a better macro assembler. Please, *do* enlighten.

Well, the most widely available one is the IBM High Level Assembler
don't blame me; I didn't pick the name.)


 
> >It's not so
> >much that C and MASM is all you know, it's that you don't understand
> >that not all assemblers are the same and that not all programs in the
> >same language are the same.
>
> Every one of those points you just made is false.

Perhaps, but your message certainly suggested that you have a very
limited language background, and you haven't presented any reasons for
me to believe that it's wrong.

BTW, to answer a few last questions, I'm reading this on comp.lang.ada
and I don't have access to any of my old source code or that of my
colleagues. What's worse, there's stuff that I wouldn't be allowed to
post even if I had access. Yeah, I know that I'm not the only one with
that last problem :-( but I grew up in a culture of freely exchanging
code and miss it.

--

                        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 spam...@library.lspace.org

Porting Experiences (was Ada and Pascal etc ) Shmuel (Seymour J.) Metz 11/12/97 12:00 AM

Dennis Weldy wrote:
>
> He pretty much disappeared. No idea if anything happened.

Thanks.


 
> IMO, in the general case, the code produced with an HLL will be a bit more
> maintaibale and easier to understand than equivalent Assembly. That said,
> it's lso possible to write obscure, unmaintainable code in any language.

Don't I know it! My language of choice is PL/I, but I've seen some PL/I
code
that shouldn't happen to a dog. And yes, it takes a little bit more
thought
to write maintainable assembler code.

> Straight Assembly will typically have one too busy looking at individual
> pieces of bark, let alone being able to see a tree (or forest). That's not
> to say that its not possible:-)

Well, my assembler code makes heavy use of macros; I go for
maintainablity
and readability, even at the price of speed.

 
> Further, if one is using assembly to get max speed, you'll use the
> associated tools to do so. Using a "nonobvious" instruction sequence to
> avoid pileline stalls, AGI locks, what have you.

IMHO anyone who uses nonobvious instruction sequences is obligated to
comment
them adequately, even if that means writing a page or two of comments
for a
single instruction. Remeber that "hacker" derives form "hack", as in "He
doesn't play chess, he just hacks at it." I have nothing but contempt
for the
idea that deliberately obscure code is a good thing in a production
program.
If you do something subtle, document it!


 
> At the HLL level, one usually doesn't have that. And y'can usually see
> things at a bit higher level.

I've seen the same sort of code in HLL, and I have the same attitude for
them:
the programmer is obligated to do whatever it takes to make the code
understandable.

> A bt easier to see whats going on as the amount of information per line of
> code is typically higher.

Well, you said "typically", and I won't argue with that. I know a number
of
languages, and mix and match depending on what is available and on the
nature
of the application. Typically I only use assembler for things that are
awkward in other languages.

One common example is generation of initial values. The macro facilities
of HLA and PL/I make those languages much better for generating
complicated data
structures than the available alternatives.

--

                        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 spam...@library.lspace.org

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Samuel T. Harris 11/12/97 12:00 AM

Please clarify that last question as "to what standard does it comply?".

That last question is confusing. Accepted terminology implies
Ada means Ada 95 and Ada 83 is listed explicitly. Do you mean
the Ada 83 standard vs the Ada 95 standard? If so, that is a
valid point, but irrelevent to the previous question which
concerned GNAT on Linux which is an Ada 95 compiler. Although
it does have a Ada 83 compatibility switch, that does not make
it an Ada 83 compiler.

Do you mean which Ada 95 standard? There is only one Ada 95
standard. It does have some annexes which are optional and
"extend" the standard into specific application domains.
Again, GNAT supports all the annexes and Robert Dewar delights
in pointing this out frequently (and well deservedly so).

--
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!"

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Larry Elmore 11/12/97 12:00 AM

John Stevens wrote in message ...

>On Tue, 11 Nov 1997 11:42:42 -0800, Dr E. Buxbaum <EB...@le.ac.uk> wrote:
>>John Stevens wrote:

>>
>>> Has anybody ever successfully used Ada on a Linux box?
>>
>>I have not worked with it personally, but there is the Gnu Ada compiler
>>(Gnat). So in theory you should be able to run Ada on any system which
>>is supported by Gnu software, including Linux.
>
>But as suggested, I've never gotten it to work under Linux.  If anybody
>has, is the result "true" Ada (does the compiler compile any legal Ada
>program) and if so, to what standard does it comply?

Have you tried this recently? What kernel version of Linux? Did you have the
specified libc version or higher? You also need the proper version of ld and
make (that is to say, one of the latest versions) if you're going to build
GNAT from source. All of this is in the docs that come with GNAT.

If you have the proper setup, getting the binary distribution to run on
Linux is easy. Just unpack it and follow the directions. If you have files
in non-standard locations, that can present problems, though.

If you want to build GNAT from source, you still need to get and install the
binary distribution because GNAT is written in Ada 95 and one must have a
working Ada 95 compiler to compile the GNAT source. If megabytes of compiler
source code (in legal Ada 95) isn't a good test of whether a compiler
generates good code or not, I'm not sure what would be... :)  (BTW, the GNAT
source code can be quite educational to go through)

I built GNAT 3.10p from source using the 3.10p binary and it worked like a
charm once I figured out (with some help from this newsgroup) that one must
build and install an Ada-aware gcc (from patched gcc source code) 'C'
compiler, then use _that_ to build and install GNAT and 'C' and C++ and
whatever else you want to use that uses gcc as the back-end. The docs aren't
real explicit on that point, though it seems rather obvious in hindsight.

GNAT is a validated Ada 95 compiler. I'm not at all sure, but I think it
still might be the _only_ validated Ada 95 compiler available. Maybe that's
changed recently, though. There's some bugs, of course, but if you know of a
compiler of any language that is certified bug-free, I'd sure like to know
where to get it! :)

Larry

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Marc Wachowitz 11/12/97 12:00 AM

[Follow-up to comp.lang.ada]

jste...@samoyed.ftc.nrcs.usda.gov (John Stevens) wrote:
> But as suggested, I've never gotten it to work under Linux.  If anybody
> has, is the result "true" Ada (does the compiler compile any legal Ada
> program) and if so, to what standard does it comply?

GNAT compiles the complete language specified in the latest revision (1995)
of the ISO standard for Ada, including all the optional Annexes, and has
been formally validated on many platforms (I don't remember which ones).

In my experience (only in my free time at home), GNAT works very well.
The public binary distribution worked out of the box, but I also had no
problems at all recompiling it with itself (except the common gcc parts,
GNAT and its tools are written in Ada), on Linux/x86 version 2.0.11, with
recent library versions.

For information about GNAT see
http://www.gnat.com

For information about Ada in general (including the text of the standard) see
http://www.adahome.com

-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/13/97 12:00 AM

In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:

...

>Nope, it cannot.  The behaviour of rand() is unspecified.

Show me where the standard says that. If the standard doesn't say explicitly
that rand() has unspecified behaviour then it doesn't, as far as the
standard's meaning of the term "unspecified" is concerned. Annex G.1,
barring errors, lists all cases of unspecified behaviour in the standard.

>Also code using
>floating point arithmetic or most of the functions from <math.h> cannot
>be strictly conforming.

That is trickier since the output may depend on implementation-defined
defined aspects, notably the properties of the floating point types
specified in 5.2.4.2.2. 6.1.2.5 makes the representation of floating
point types unspecified but I don't see anything else about them that is.
However floating point is a mess, it is difficult to predict anything
for certain.

>>>It is unspecified (or maybe implementation-defined) when an I/O operation
>>>fails and if that failure affects the behaviour of your program...
>>
>>No, it isn't. The standard states explicitly all cases of unspecified and
>>implementation-defined behaviour, these terms are very specific.
>>Only undefined behaviour can result from a lack of definition, and even
>>then only from a *total* lack of definition (or there is a defect in the
>>standard). getc() (for example) has no unspecified and no
>>implementation-defined behaviour (*).
>
>You missed the point.

No, this is the point.

> It is undefined when the well defined conditions
>that lead to the failure of a stdio function occur.

Again, you are using your own definition of a term, not the standard's.
3.16 describes what undefined behaviour is and when it can occur. The
situation you describe doesn't fit that description.

Clause 4 says

"A strictly conforming program shall use only those features of the language
 and library specified in this International Standard. It shall not produce


 output dependent on any unspecified, undefined, or implementation-defined
 behavior, and shall not exceed any minimum implementation limit."

The question is: what defines what constitutes unspecified, undefined, or
implementation-defined behaviour?

The answer is: the standard does, in all three cases. 3.16 isn't a
carte blanche for lack of definition, it imposes specific requirements
for a construct to have undefined behaviour. Those requirements don't turn
out to depend on knowing (or not) what input is received from the
environment in any particular instance.

Simply knowing a program is strictly conforming does not mean you can
predict what it will output. However if you do know what input a
strictly conforming program receives you should be able to predict from
the standard alone what output it generates (although I'm not 100% sure of
that). From this perspective values returned by rand(), for example, are
input to the program. I'd agree with you however that it is best to leave
floating point out of this. :-)

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/13/97 12:00 AM

In article <879381...@genesis.demon.co.uk>
           fr...@genesis.demon.co.uk "Lawrence Kirby" writes:

...

>Simply knowing a program is strictly conforming does not mean you can
>predict what it will output. However if you do know what input a
>strictly conforming program receives you should be able to predict from
>the standard alone what output it generates (although I'm not 100% sure of
>that).

After sleeping on it it is fairly obvious that isn't true. You can't tell
what output a program produces if a file output operation generates an error.
Perhaps the most interesting case here is the automatic stream closing that
happens at normal program termination, where the program itself never gets
an indication that an error occurred. Nevertheless there's nothing in the
standard that stops a program being strictly conforming because of that.

This thread has been cross-posted to various non-C language newsgroups.
Certainly this particular discussion is very C specific with possibly
some relevance to C++. I'm therefore directing followups to comp.lang.c
and comp.lang.c++ only.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Boyd Roberts 11/13/97 12:00 AM

In article <879433...@genesis.demon.co.uk>, fr...@genesis.demon.co.uk (Lawrence Kirby) writes:
>In article <879381...@genesis.demon.co.uk>
>           fr...@genesis.demon.co.uk "Lawrence Kirby" writes:
>
>...
>
>>Simply knowing a program is strictly conforming does not mean you can
>>predict what it will output. However if you do know what input a
>>strictly conforming program receives you should be able to predict from
>>the standard alone what output it generates (although I'm not 100% sure of
>>that).
>
>After sleeping on it it is fairly obvious that isn't true.

Obviously, because you're talking about the halting problem.

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: j...@gte.net

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Jon S Anthony 11/13/97 12:00 AM

"Larry Elmore" <ljel...@montana.campus.mci.net> writes:

> GNAT is a validated Ada 95 compiler. I'm not at all sure, but I
> think it still might be the _only_ validated Ada 95 compiler
> available. Maybe that's changed recently, though.

Not for some time.  Actually the very first validated Ada95 compiler
was one from Intermetric's which used their nifty AdaMagic FE.

I think I saw somewhere that there were around 40 or so validated
compilers for Ada95 at this time.  Certainly ObjectAda from Aonix is
validated and includes the "big 4" annexes.

/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

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/13/97 12:00 AM

In <879381...@genesis.demon.co.uk> fr...@genesis.demon.co.uk (Lawrence Kirby) writes:

>In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:
>
>...
>
>>Nope, it cannot.  The behaviour of rand() is unspecified.
>
>Show me where the standard says that. If the standard doesn't say explicitly
>that rand() has unspecified behaviour then it doesn't, as far as the
>standard's meaning of the term "unspecified" is concerned. Annex G.1,
>barring errors, lists all cases of unspecified behaviour in the standard.

Show me where the standard specifies the behaviour of rand(), so that I
can predict the output of the following program without having to compile
and run it:

    #include <stdio.h>
    #incldue <stdlib.h>

    int main()
    {
        printf("%d\n", rand());
        return 0;
    }

If I can't do that, then the program is not strictly conforming.
Furthermore, even if I read the implementation's documentation, there is
still no guarantee that I can predict the output.

>>Also code using
>>floating point arithmetic or most of the functions from <math.h> cannot
>>be strictly conforming.
>
>That is trickier since the output may depend on implementation-defined
>defined aspects, notably the properties of the floating point types
>specified in 5.2.4.2.2. 6.1.2.5 makes the representation of floating
>point types unspecified but I don't see anything else about them that is.
>However floating point is a mess, it is difficult to predict anything
>for certain.

You can't even predict the result of 1.0 + 1.0 based on the text of the
standard.

>>>>It is unspecified (or maybe implementation-defined) when an I/O operation
>>>>fails and if that failure affects the behaviour of your program...
>>>
>>>No, it isn't. The standard states explicitly all cases of unspecified and
>>>implementation-defined behaviour, these terms are very specific.
>>>Only undefined behaviour can result from a lack of definition, and even
>>>then only from a *total* lack of definition (or there is a defect in the
>>>standard). getc() (for example) has no unspecified and no
>>>implementation-defined behaviour (*).
>>
>>You missed the point.
>
>No, this is the point.
>
>> It is undefined when the well defined conditions
>>that lead to the failure of a stdio function occur.
>
>Again, you are using your own definition of a term, not the standard's.
>3.16 describes what undefined behaviour is and when it can occur. The
>situation you describe doesn't fit that description.

Where did I used the term "undefined behaviour"???

>Simply knowing a program is strictly conforming does not mean you can
>predict what it will output.

Then, it is not strictly conforming.

>However if you do know what input a
>strictly conforming program receives you should be able to predict from
>the standard alone what output it generates (although I'm not 100% sure of
>that). From this perspective values returned by rand(), for example, are
>input to the program.

Chapter and verse, please.  According to ANSI Classic 1.2:

    1.2 SCOPE

       This Standard specifies:
    ...
     * the representation of input data to be processed by C programs;
    ...

So, if the values of rand are input to the program, the standard must
specify that.  As far as I can tell, rand() is not described in the
INPUT/OUTPUT section of the library :-)

The wording of the standard clearly suggests that ALL the program input
data come from streams, via the stdio functions (it doesn't even include
the getenv() function as a source of program input).  If you disagree,
please provide the relevant quotes.

>I'd agree with you however that it is best to leave
>floating point out of this. :-)

There is no conceptual difference between the way the standard deals with
floating point and with the rand/srand functions.  On the contrary, I'd say
that the description of the sin() function is more precise than that of
rand() (although not precise enough to allow predicting the result of a
sin() call).

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Porting Experiences (was Ada and Pascal etc ) Samuel T. Harris 11/13/97 12:00 AM

Steve Summit wrote:
>

snip a whole lot of stuff I can't argue with...

>
> And don't get me wrong: I do agree that, as bad an idea as it
> often is, the need to perform layout-constrained I/O can be very
> real.  If I were designing a language, I'd include features to
> make it more convenient.  But that's another story.
>
> > So, I can't say to Kaz that he is wrong, because he is not, as far as
> > he goes. What I do say to Kaz is "You have only pricked the tip of the
> > portability iceberg." Portability involves much more than guaranteeing...
>
> Well, it all depends on how you define "portability."  I've been
> a student of portability for a long time, and maybe I'm crazy or
> tilting at windmills off in left field, but I'd say that if you
> really care about portability, you need to define your data file
> formats portably, too.  If your data format is defined, either
> explicitly or implicitly, as containing fields such as "a 32-bit
> integer in the machine's byte order", then it's an inherently
> unportable format, and to describe a "portable" program for
> reading or writing this format is an oxymoron.
>
> Once you've defined a portable data file format, *then* you can
> start arguing about which language makes it more or less
> convenient, or more or less efficient, to read and write that
> format.  But defining "portability" as the ability to write code
> which reads and writes binary formats and which recompiles
> anywhere, and then criticizing a language which does not make
> this task maximally convenient, strikes me as erecting a bit of a
> strawman.
>
>                                         Steve Summit
>                                         s...@eskimo.com

Just to clarify. I agree completely that file format over which
I have control will be defined in a "portable" manner. However,
many times the context of the applications forces me to use
file formats, parameter types, etc. which are externally defined.
In the simulation world, they are usually defined to take advantage
of the idiosyncracies of target/embedded hardware which I have to
simulate/interface to with wholly incompatible hardware. In those
cases, I just don't have a choice.

I take an exception at the bit about "erecting a bit of a strawman".
Any language which is more convenient in a problem domain is a
superior choice over other, less convenient languages. "Language
wars" are not won or lost of singleton point such as our discussion
on portability (and the various flavors that involves) because
each projects have several of these problem domains with which
to deal. Each project has to take an aggregation of specific
considerations, each of which may or may not have a clear winner,
and decide what the primary language will be.

This sub-thread is about a particular problem domain. IMHO the
clear winner is Ada because of the convenience, lack of required
supported code, lower initial development, and lower maintenance.
But that only applies to this particular problem domain.
Add this comparison to your checklist and move on.

--
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!"

Porting Experiences (was Ada and Pascal etc ) Steve Summit 11/13/97 12:00 AM

In article <3460A7BB...@hso.link.com>,
Samuel T. Harris <s_ha...@hso.link.com> evidently wrote:
> Reading the arguments between Kaz and others, I'm struck with the
> realization that Kaz is missing a significant point. As long as
> application code is not concerned with the representation of
> variables, Kaz is correct in his statements that a few simple
> guidelines insure good type choices for portable C code. What Kaz has
> failed to consider, but has been state by others, is that sometimes
> the representation of the type IS important to the application...
> context in which the application is running...  While application
> usually are only concerned witht he RANGE supported by the type...
> the context in which the app is running may force the use of
> [some type], especially when interfacing to hardware, COTS libraries,
> or in a distributed environment where heterogenous architectures must
> interface with each other. These are common examples of the context
> forcing a representation.  C does not support forcing the
> representation in a portable way. Ada does. The need for such
> cannot be simply dismissed because the need is real.

The need is as real as you make it.  (But note also that to
suggest that a problem be solved by avoiding it is not dismissing
or ignoring the problem.)

It's no surprise that performing portable, "binary" I/O to an
externally-imposed storage layout is less convenient in C.
*Everything* is less convenient in C!  It's a relatively
low-level language, as high-level languages go, and it embodies a
cornerstone of the Unix philosophy, which is that it should not
go too far in helping you to do something, because to help you to
do it invariably involves constraining the way you'll do it.
C lets you do I/O however you want; the cost is that you have
to specify more of the details to get what you want.

Of course, you can try to come up with a higher-level scheme
which contains so much flexibility that it lets you do whatever
you want, but of course, there are potential costs here, too.
One is the specification and implementation cost, and another is
the learning curve cost on the part of the would-be programmer.
From what you say, it sounds like Ada does attempt to tackle this
problem, but we know that at least one of those costs has already
been exacted.  For the first several years of its existence as a
language, Ada managed to revive an old adage from the earliest
days of high-level languages: Ada compilers were (just as FORTRAN
compilers were once thought to be) nearly impossible programs to
write.

I think that every aspect of this discussion over the problems of
performing portable, "binary" I/O is wholly consistent with the
established fact that C is a low-level language which may make
you do more work up-front than do more ambitious languages.
C's enduring popularity in spite of this tradeoff suggests
strongly that it must have some compensating merits.

But I've lapsed into silly, defensive, language-war posturing,
which is just that: silly!  Use the right tool for the job!
If you have an absolute requirement to perform I/O in a
byte-for-byte way to conform with externally-imposed storage
layouts, fread() and fwrite() are not your tools.  Either write
your own low-level I/O routines (as Kaz has been suggesting all
along), or use preexisting libraries such as those for XDR, CDF,
or HDF, or use another language which either has I/O built in or
makes it easier to encapsulate your own.  Don't blame C or call
it a poor tool for not making it easier to perform this task;
blame yourself or your superiors for choosing a poor tool or a
poor strategy.

which languages suck Larry Elmore 11/13/97 12:00 AM

Stanley R. Allen wrote in message <346A50...@hso.link.com>...


Yes, that's what I meant (though _not_ what I posted, I see now! :) ).
Thanks!

Larry

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!! Craig Franck 11/14/97 12:00 AM

Jon S Anthony <j...@synquiry.com> wrote:
>"Larry Elmore" <ljel...@montana.campus.mci.net> writes:
>
>> GNAT is a validated Ada 95 compiler. I'm not at all sure, but I
>> think it still might be the _only_ validated Ada 95 compiler
>> available. Maybe that's changed recently, though.
>
>Not for some time.  Actually the very first validated Ada95 compiler
>was one from Intermetric's which used their nifty AdaMagic FE.
>
>I think I saw somewhere that there were around 40 or so validated
>compilers for Ada95 at this time.  Certainly ObjectAda from Aonix is
>validated and includes the "big 4" annexes.

There is a version of that compiler for Windows bundled with the book
"Ada 95 For C and C++ Programmers" by Simon Johnston, from Add-Wes.

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


Porting Experiences (was Ada and Pascal etc ) Craig Franck 11/14/97 12:00 AM

"Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> wrote:
>Craig Franck wrote:

>> Then suggest a better macro assembler. Please, *do* enlighten.
>
>Well, the most widely available one is the IBM High Level Assembler
>don't blame me; I didn't pick the name.)

I will see what I can find out about it.


 
>> >It's not so
>> >much that C and MASM is all you know, it's that you don't understand
>> >that not all assemblers are the same and that not all programs in the
>> >same language are the same.
>>
>> Every one of those points you just made is false.
>
>Perhaps, but your message certainly suggested that you have a very
>limited language background, and you haven't presented any reasons for
>me to believe that it's wrong.

I can only dispell so many assumptions a day! :-)

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Jos De Laender 11/14/97 12:00 AM

Boyd Roberts wrote:
>
> In article <879433...@genesis.demon.co.uk>, fr...@genesis.demon.co.uk (Lawrence Kirby) writes:
> >In article <879381...@genesis.demon.co.uk>
> >           fr...@genesis.demon.co.uk "Lawrence Kirby" writes:
> >
> >...
> >
> >>Simply knowing a program is strictly conforming does not mean you can
> >>predict what it will output. However if you do know what input a
> >>strictly conforming program receives you should be able to predict from
> >>the standard alone what output it generates (although I'm not 100% sure of
> >>that).
> >
> >After sleeping on it it is fairly obvious that isn't true.
>
> Obviously, because you're talking about the halting problem.
>

        Can someone explain this more to me. (Maybe including the
halting problem, which I forget since university,  and the relation
with this problem ?)

Many thanks !

**
**
**
**
**
**
**
**
**
**
**

which languages suck Robert Munck 11/14/97 12:00 AM

On Wed, 12 Nov 1997 18:56:06 -0600, "Stanley R. Allen"
<s_a...@hso.link.com> wrote:

>But I believe that GNAT is the only validated
>[Ada 95 compiler] for Linux.

Isn't there a Java interpreter for Linux? Given
that the Intermetrics AppletMagic compiler targets
the JVM, (and, of course, all implementions of
the Java VM are perfectly identical and all code
can be run on all of them), wouldn't that mean
that AppletMagic works on Linux?

Bob Munck
Mill Creek Systems LC


Porting Experiences (was Ada and Pascal etc ) Robert Munck 11/14/97 12:00 AM

On Wed, 12 Nov 1997 17:52:04 -0800, "Shmuel (Seymour J.) Metz"
<nos...@gsg.eds.com> wrote:

>
>Well, my assembler code makes heavy use of macros; I go for
>maintainablity and readability, even at the price of speed.

Does anyone doing assembler use IF...THEN and other
structured programming macros anymore? I wrote some
pretty complex macro definitions for IBM's Assembler F
about 30 years ago, and then wrote a post-processor
for the listing file that indented the code appropriately,
supressed the macro expansions for the structure
macros while leaving others intact, and did other
pretty-printing functions.  Harlan Mills borrowed
my definitions and publicized them.

Bob Munck
Mill Creek Systems LC


which languages suck Bjorn Vaggen Konestabo 11/14/97 12:00 AM

[Robert Munck]

| Isn't there a Java interpreter for Linux? Given

Yes. I think there's a link to it from www.javasoft.com,
somewhere under third-party ports of the JDK.

| that the Intermetrics AppletMagic compiler targets
| the JVM, (and, of course, all implementions of
| the Java VM are perfectly identical and all code
| can be run on all of them), wouldn't that mean
| that AppletMagic works on Linux?

If it's 100% Java, it should.

--
"I used rock'n'roll all night, and party every day. Then it was
  every other day. Now I'm lucky if I can find half an hour a week in
    which to get funky."      -- Homer J. Simpson.

which languages suck Russ Lyttle 11/14/97 12:00 AM
Yes there is. My version, however, seems to have some holes in it. I am
working to discover if they are my fault or Suns. Sun doesn't provide
the support for Linux that it should.

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Morris M. Keesan 11/14/97 12:00 AM

On Sun, 09 Nov 97 14:06:58 GMT, fr...@genesis.demon.co.uk (Lawrence
Kirby) wrote:
>In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:
>
>...
>
>>It is theoretically possible to have an implementation with
>>sizeof(long) < sizeof(int) < sizeof(short), but even on that
>>implementation you must have SHRT_MAX <= INT_MAX <= LONG_MAX (otherwise
>>the integral promotion rules would stop working), so the types short and
>>int would make a very inefficient use of their allocated space.
>
>More directly it violates 6.1.2.5:
>
>"There are four signed integer types, designated as signed char, short int,
> int and long int
>
> ...
>
> ...In the list of signed integer types above, the range of values of each
> type is a subrange of the values of the next type in the list"
>

If SHRT_MAX <= INT_MAX <= LONG_MAX and SHRT_MIN >= INT_MIN >= LONG_MIN,
how does sizeof(long) < sizeof(int) < sizeof(short) violate 6.1.2.5?
6.1.2.5 directly addresses the VALUE RANGES of the types, not their
sizes.
--
Morris M. Keesan -- mke...@kenan.com
Kenan Systems Corporation

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Christopher Green 11/15/97 12:00 AM

In article <346C4C...@sh.bel.alcatel.be>,

Jos De Laender  <jd...@sh.bel.alcatel.be> wrote:
>Boyd Roberts wrote:
>>
>> In article <879433...@genesis.demon.co.uk>, fr...@genesis.demon.co.uk (Lawrence Kirby) writes:
>> >In article <879381...@genesis.demon.co.uk>
>> >           fr...@genesis.demon.co.uk "Lawrence Kirby" writes:
>> >
>> >>Simply knowing a program is strictly conforming does not mean you can
>> >>predict what it will output. However if you do know what input a
>> >>strictly conforming program receives you should be able to predict from
>> >>the standard alone what output it generates (although I'm not 100% sure of
>> >>that).
>> >
>> >After sleeping on it it is fairly obvious that isn't true.
>>
>> Obviously, because you're talking about the halting problem.
>
>        Can someone explain this more to me. (Maybe including the
>halting problem, which I forget since university,  and the relation
>with this problem ?)
[snip]

Somewhat oversimplified, the Halting Problem is this:  Given a
programming environment that meets some rather minimal conditions
(able to emulate a universal Turing machine, I believe), it is
always possible to construct a program in that environment, such
that it is impossible to determine whether the program will ever
terminate.

I will conjecture, but will not attempt to prove, that most
useful programming language standards specify environments
that are sufficient for the premise of the Halting Problem.

If so, it is impossible to predict whether certain strictly con-
forming programs will terminate.  A fortiori, it is impossible to
predict the entire output of such a program, and it is impossible
to predict it solely from knowledge of any standard.

Chris Green                                  Email cgr...@atc.com
Advanced Technology Center                   Phone (714) 583-9119
22982 Mill Creek Drive                                   ext. 220
Laguna Hills, CA 92653                       Fax   (714) 583-9213

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/16/97 12:00 AM

In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:

>In <879381...@genesis.demon.co.uk> fr...@genesis.demon.co.uk (Lawrence Kirby)
> writes:
>
>>In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:
>>
>>...
>>
>>>Nope, it cannot.  The behaviour of rand() is unspecified.
>>
>>Show me where the standard says that. If the standard doesn't say explicitly
>>that rand() has unspecified behaviour then it doesn't, as far as the
>>standard's meaning of the term "unspecified" is concerned. Annex G.1,
>>barring errors, lists all cases of unspecified behaviour in the standard.
>
>Show me where the standard specifies the behaviour of rand(), so that I
>can predict the output of the following program without having to compile
>and run it:
>
>    #include <stdio.h>
>    #incldue <stdlib.h>
>
>    int main()
>    {
>        printf("%d\n", rand());
>        return 0;
>    }
>
>If I can't do that, then the program is not strictly conforming.

Sorry, you've lost me there. Where does the standard say that the output
of a program has to be predictable for it to be strictly conforming?
Clause 4 certaintly doesn't say anything like "A strictly conforming
program shall not produce output dependent on anything that is not
fully specified in this International Standard". What it says is:

"A strictly conforming shall use only those features of the language and


 library specified in this International Standard. It shall not produce
 output dependent on any unspecified, undefined, or implementation-defined
 behaviour, and shall not exceed any minimum implementation limit."

>Furthermore, even if I read the implementation's documentation, there is
>still no guarantee that I can predict the output.

True, but not relevant. There is a potential issue relating to the value
of RAND_MAX. If this was implementation-defined or unspecified then there
would be a reasonable argument that your example is not strictly comforming.
However I can't find anything in the standard that makes it either of these.

>>>Also code using
>>>floating point arithmetic or most of the functions from <math.h> cannot
>>>be strictly conforming.
>>
>>That is trickier since the output may depend on implementation-defined
>>defined aspects, notably the properties of the floating point types
>>specified in 5.2.4.2.2. 6.1.2.5 makes the representation of floating
>>point types unspecified but I don't see anything else about them that is.
>>However floating point is a mess, it is difficult to predict anything
>>for certain.
>
>You can't even predict the result of 1.0 + 1.0 based on the text of the
>standard.

But, again, predictability isn't a property that the standard ascribes to
a strictly conforming program. I'm not quite sure where this idea comes
from. Maybe it is a feeling that strict conformance gives maximal portability
and in some sense maximal portability suggests precisely reproducible
results. That is a false correspondance as far as the standard is
concerned.

(as an aside I think I could put forward a reasonable proof that 1.0 +
1.0 is predictable, but don't lose sight of the fact that it is the program
output, not individual calculations that is the measure of strict
conformance).

>>>>>It is unspecified (or maybe implementation-defined) when an I/O operation
>>>>>fails and if that failure affects the behaviour of your program...
>>>>
>>>>No, it isn't. The standard states explicitly all cases of unspecified and
>>>>implementation-defined behaviour, these terms are very specific.
>>>>Only undefined behaviour can result from a lack of definition, and even
>>>>then only from a *total* lack of definition (or there is a defect in the
>>>>standard). getc() (for example) has no unspecified and no
>>>>implementation-defined behaviour (*).
>>>
>>>You missed the point.
>>
>>No, this is the point.
>>
>>> It is undefined when the well defined conditions
>>>that lead to the failure of a stdio function occur.
>>
>>Again, you are using your own definition of a term, not the standard's.
>>3.16 describes what undefined behaviour is and when it can occur. The
>>situation you describe doesn't fit that description.
>
>Where did I used the term "undefined behaviour"???

I had to assume that otherwise what you wrote had no relevance to the
issue of strict conformance.

>>Simply knowing a program is strictly conforming does not mean you can
>>predict what it will output.
>
>Then, it is not strictly conforming.

They you have a different definition of what the term "strictly conforming"
means compared to the one I see in the standard. These are the full
requirements for strict conformance as I see them in the standard:

1. Each translation unit that makes up a program has valid syntax.

2. There are no constraint violations in the program.

3. The program must not exceed any minimum translation limit

4. The program must use only the features of the language and library
   specified in the standard (I include this since it is specified but it
   may not add anything not covered by the next 3 requirements, however
   it is perhaps what gives requirements 1 and 2 the force of strict
   conformance).

5. The program must not produce output dependent on implementation-defined
   behaviour. Note that implementation-defined behaviour only exists when
   there is an explicit requirement in the standard for the implementation
   to document the behaviour. (3.10)

6. The program must not produce output dependent on unspecified behaviour.
   Note that unspecified behaviour can only exist where it is stated
   explicitly in the standard. This is perhaps the most critical point:
   see the definition of unspecified behaviour in 3.17, particularly
   the word "explicitly").

7. The program must not produce output dependent on undefined behaviour.
   (3.16). The important point here is that while undefined behaviour
   can exist through a lack of definition, it must be a *total* lack
   of definition i.e. "for which this standard imposes *no* requirements"
   (my emphasis). While not normative Annex G is a good reference for
   this (as well as 5 and 6) with perhaps some further indication of
   intent.

There are separate requirements for conforming implementations but
these aren't an issue here. I assert that any program that meets the
7 requirements above is strictly conforming, since these are the
only requirements I can find in the standard.

>>However if you do know what input a
>>strictly conforming program receives you should be able to predict from
>>the standard alone what output it generates (although I'm not 100% sure of
>>that). From this perspective values returned by rand(), for example, are
>>input to the program.
>
>Chapter and verse, please.  According to ANSI Classic 1.2:
>
>    1.2 SCOPE
>
>       This Standard specifies:
>    ...
>     * the representation of input data to be processed by C programs;
>    ...
>
>So, if the values of rand are input to the program, the standard must
>specify that.  As far as I can tell, rand() is not described in the
>INPUT/OUTPUT section of the library :-)

Whether you choose to treat the values returned by rand() as input to the
program or not doesn't affect any of the 7 requirements above so we
shouldn't get stuck on this point. I think it is reasonable and useful to
consider it as input to the program.

>The wording of the standard clearly suggests that ALL the program input
>data come from streams, via the stdio functions (it doesn't even include
>the getenv() function as a source of program input).  If you disagree,
>please provide the relevant quotes.

OK, if you don't like the term "program input" we'll just have to think of
another that can cover file input, argv, errno, rand(), getenv(), time(),
clock(), localeconv(), system(NULL) and anything else I've overlooked.
Maybe something like "environment derived data".

>>I'd agree with you however that it is best to leave
>>floating point out of this. :-)
>
>There is no conceptual difference between the way the standard deals with
>floating point and with the rand/srand functions.  On the contrary, I'd say
>that the description of the sin() function is more precise than that of
>rand() (although not precise enough to allow predicting the result of a
>sin() call).

The question is whether output derived from sin() is dependent on
implementation-defined characteristics specified in 5.2.4.2.2. rand()
doesn't have such issues (unless I've missed something in the standard
relating to RAND_MAX).

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


English SUCKS, Chinese is the only language you need!! Davide Bionda 11/18/97 12:00 AM

>there are not more chinese speakers than english.
>if you have not relized it but the english language it the most
>widely used language as a standard. why? cause us americans want it
>that way ;)

Then you should try to learn it ;-)

English SUCKS, Chinese is the only language you need!! Timo Salmi 11/18/97 12:00 AM

In article <347142...@erdw.ethz.ch>,
Davide Bionda  <bio...@erdw.ethz.ch> wrote:
(Concerning the parody about
ADA and Pascal SUCK, C,C++, and Java are the only langauges you need!)
:>there are not more chinese speakers than english.

But, but ... the Americans want it that way.

   All the best, Timo  (aka Perfesser Pundit in news:rec.humor)

(Folloups to news:rec.humor _*ONLY*_)

....................................................................
Prof. Timo Salmi   Co-moderator of news:comp.archives.msdos.announce
Moderating at ftp:// & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance  ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/>  ; FIN-65101,  Finland

Spam foiling in effect.  My email filter autoresponder will return a
required email password to users not yet in the privileges database.

English SUCKS, Chinese is the only language you need!! Mark Wilden 11/18/97 12:00 AM

John Rickard wrote:
>
> why should I waste my time RE learning a language I have understood
> and spoke since around 1-3 years of age?

Three reasons:

1) "RE learning" requires a hyphen.

2) "spoke" should be "spoken."

3) In "around 1-3", "around" is redundant.

Hey, you asked. :)

English SUCKS, Chinese is the only language you need!! Billy Chambless 11/18/97 12:00 AM

In article <64sql2$k...@mtinsc04.worldnet.att.net>, "John Rickard" <saskan@worldnet.att.net.DONTSPAMME> writes:

|> why should I waste my time RE learning a language I have understood
|> and spoke since around 1-3 years of age?

You forgot to mention your SAT scores.

English SUCKS, Chinese is the only language you need!! Jean-Sebastien Payette 11/18/97 12:00 AM

John Rickard wrote in message <64sql2$k...@mtinsc04.worldnet.att.net>...


>why should I waste my time RE learning a language I have understood
>and spoke since around 1-3 years of age?


I've never learn english and I talk better than you.
Now about Pascal and C let me tell you that in some case (strings and file
manipulation, most object handling) Pascal is way better and I know both
language (unlike you!!)

English SUCKS, Chinese is the only language you need!! Dennis Weldy 11/18/97 12:00 AM

It is? Care to offer a bit of proof there?
Standard Pascal was, last I looked woefully lacking in file handling.
Strings were packed arrays of chars (much like C).

Now, perhaps y'mean Object Pascal, from Borland? Yes, that would be better
at handling objects "better" than C, since C doesn't directly support the OO
paradigm. Of course, if y'try to compare it to C++....then I would disagree
(and yes, I do know Object Pascal (BP 7.0)).

Dennis

Jean-Sebastien Payette wrote in message
<64suum$5oo$1...@weber.videotron.net>...

English SUCKS, Chinese is the only language you need!! Jean-Sebastien Payette 11/18/97 12:00 AM

Dennis Weldy wrote in message ...


>It is? Care to offer a bit of proof there?
>Standard Pascal was, last I looked woefully lacking in file handling.
>Strings were packed arrays of chars (much like C).
>
>Now, perhaps y'mean Object Pascal, from Borland? Yes, that would be better
>at handling objects "better" than C, since C doesn't directly support the
OO
>paradigm. Of course, if y'try to compare it to C++....then I would disagree
>(and yes, I do know Object Pascal (BP 7.0)).
>
>Dennis
>


Ok sorry I was talking about C++, I never really code in pure C.
I must agree that I was a little overhelm stating that object pascal was
better than C ( oups! C++) but not string manipulation. I hate string
manipulation in C++. Damn strdup() that make everything fall appart...
and file manipulation is file manipulation, you can't really tell appart any
of the two languages because the functions are nearly the same in both.And
btw, in pascal, you can have pointer to string (like in C) but they are more
easy to handle!

English SUCKS, Chinese is the only language you need!! John Rickard 11/18/97 12:00 AM

why should I waste my time RE learning a language I have understood
and spoke since around 1-3 years of age?
--
--
Remove .DONTSPAMME from my
email address to send me REAL email.
--

Davide Bionda <bio...@erdw.ethz.ch> wrote in article
<347142...@erdw.ethz.ch>...
: >there are not more chinese speakers than english.:

English SUCKS, Chinese is the only language you need!! Chieh Cheng 11/18/97 12:00 AM

>John Black wrote:
>>
>> ADA and Pascal are two of the most useless inventions Man has ever
>> wasted space on this planet with.  These languages are hard to learn,
>> have zero applications, and people who only know these languages can
>> only find jobs at Taco Bell!  Smart programmers spend their time
>> learning only C, C++, and Java in that order.

Obviously, you do not understand the benefits of learning a variety of
different computer languages. If you don't learn LISP, you will never
fully understand the capability and limitation of C and C++. If you
are, or were, a computer science student, I would have been ashamed of
your CS department.

CC
--
http://www.geocities.com/Area51/8145/
Up the mountain, down the slope.
Around the tree trunks, past the streams.

English SUCKS, Chinese is the only language you need!! Chieh Cheng 11/18/97 12:00 AM

For one thing, your grammer sucks. And learn to capitalize. Isn't
ironic when an American who learned English since he/she was born,
write English worse than people with other nationalities?

On 18 Nov 1997 19:34:58 GMT, "John Rickard"
<saskan@worldnet.att.net.DONTSPAMME> wrote:

>why should I waste my time RE learning a language I have understood
>and spoke since around 1-3 years of age?
>
>Davide Bionda <bio...@erdw.ethz.ch> wrote in article
><347142...@erdw.ethz.ch>...
>: >there are not more chinese speakers than english.
>: >if you have not relized it but the english language it the most
>: >widely used language as a standard. why? cause us americans want
>it
>: >that way ;)
>:
>: Then you should try to learn it ;-)
>:

CC


--
http://www.geocities.com/Area51/8145/
Up the mountain, down the slope.
Around the tree trunks, past the streams.

English SUCKS, Chinese is the only language you need!! JCore 11/18/97 12:00 AM

On 17 Nov 1997 23:57:47 GMT, "John Rickard"
<saskan@worldnet.att.net.DONTSPAMME> wrote:

>there are not more chinese speakers than english.
>if you have not relized it but the english language it the most
>widely used language as a standard. why? cause us americans want it
>that way ;)

Um, actually Chinese is the most widely spoken language in the world.
Sorry to have to be the American to break it to you.  Oh yeh, and I
agree with the original article too.

-JCore

English SUCKS, Chinese is the only language you need!! Dr E. Buxbaum 11/18/97 12:00 AM

Ingemar Ragnemalm wrote:

> Couldn't you at least flame Pascal and ADA in favor of
> something *interesting*, like Forth, Scheme or PDP-11
> assembler? Joining the majority to flame the minority,
> sheesh. Boring.

I always thought C WAS the PDP-11 macro assembler!

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/19/97 12:00 AM

In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:

>In <879713...@genesis.demon.co.uk> fr...@genesis.demon.co.uk (Lawrence Kirby) >writes:
>
># In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:
>#
># >In <879381...@genesis.demon.co.uk> fr...@genesis.demon.co.uk (Lawrence
> Kirby)
># > writes:
># >
># >>In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:># >>
># >>...
># >>
># >>>Nope, it cannot.  The behaviour of rand() is unspecified.
># >>
># >>Show me where the standard says that. If the standard doesn't say explicitly># >>that rand() has unspecified behaviour then it doesn't, as far as the
># >>standard's meaning of the term "unspecified" is concerned.
>
>Show me where the standard says that "unspecified behaviour" must be
>*explicitly* labeled as such.

"3.17  unspecified behaviour:  Behaviour, for a correct program construct
 and correct data, for which this International Standard explicitly imposes
 no requirements".

I might agree that the exact term "unspecified behaviour" may not be required
but 3.17 makes it clear that something can't have unspecified behaviour
implicitily, i.e. just because the behaviour wasn't specified in the
standard. IOW the standard has positively to make something unspecified.

># >> Annex G.1,
># >>barring errors, lists all cases of unspecified behaviour in the standard.
>
>Annex G.1 is not part of the standard.

Agreed, I think I made the point that I was just using Annex G as evidence
of intent.

># >Show me where the standard specifies the behaviour of rand(), so that I
># >can predict the output of the following program without having to compile
># >and run it:
># >
># >    #include <stdio.h>
># >    #incldue <stdlib.h>
># >
># >    int main()
># >    {
># >        printf("%d\n", rand());
># >        return 0;
># >    }
># >
># >If I can't do that, then the program is not strictly conforming.
>#
># Sorry, you've lost me there. Where does the standard say that the output
># of a program has to be predictable for it to be strictly conforming?
># Clause 4 certaintly doesn't say anything like "A strictly conforming
># program shall not produce output dependent on anything that is not
># fully specified in this International Standard". What it says is:
>#
># "A strictly conforming shall use only those features of the language and
>#  library specified in this International Standard. It shall not produce
>#  output dependent on any unspecified, undefined, or implementation-defined
>#  behaviour, and shall not exceed any minimum implementation limit."
>
>And the definition of "unspecified behaviour" is:
>
> * Unspecified behavior --- behavior, for a correct program construct
>   and correct data, for which the Standard imposes no requirements.

No, the wording is as I quoted above, at least in the ISO 9899-1990
standard.

>The above program seems to fit that quite well.

I can find no explicit statement of unspecified behaviour for the program.

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Lawrence Kirby 11/19/97 12:00 AM

In article <64fbr2$76k$1...@route1.mdrf.france3.fr>
           bo...@france3.fr "Boyd Roberts" writes:

>In article <879433...@genesis.demon.co.uk>, fr...@genesis.demon.co.uk


> (Lawrence Kirby) writes:
>>In article <879381...@genesis.demon.co.uk>
>>           fr...@genesis.demon.co.uk "Lawrence Kirby" writes:
>>
>>...

>>
>>>Simply knowing a program is strictly conforming does not mean you can
>>>predict what it will output. However if you do know what input a

>>>strictly conforming program receives you should be able to predict from
>>>the standard alone what output it generates (although I'm not 100% sure of
>>>that).
>>
>>After sleeping on it it is fairly obvious that isn't true.
>
>Obviously, because you're talking about the halting problem.

Seems to be the answer to everything. :-)

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Alan E & Carmel J Brain 11/19/97 12:00 AM

Many thanks to the posters on this thread. Ada programmers often feel,
if not persecuted, then uncomfortably isolated by the mainstream.

It's issues like this that make me feel thankful that I'm restricted to
only programming in C or C++.

On another matter, please continue: I've learnt a vast amount about C
from reading this thread, as I'm sure many lurkers have.
--
aeb...@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abr...@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

English SUCKS, Chinese is the only language you need!! t...@panix.com 11/19/97 12:00 AM

On 19 Nov 1997 00:54:55 GMT, "Cynthia & Bill" <cbt...@clark.net>
wrote:

>I won't get into the debate between English, Chinese, or any other natural
>language.
>
>However...
>I too know both C (and C++) and Pascal.  (As well as a lot of other comp
>langauges.)
>I prefer C/C++ simply because it is used by the majority (on PC's and Unix
>boxes.)
>I also know RPG and COBOL.
>On mainframes I opt for COBOL.
>On AS/400's, RPG is my langauge of choice.
>On PC's and Unix boxes, I use C.  (And I'm starting to use Java.)
>
>Except for undergraduate work, I have yet to find Pascal the langauge
>of choice of the majority on any platform.
Pascal is the prefered language for developers of games.  Also it is
easier to debug Pascal prorgams than C/C++ programs.
Also Pascal is now available with MMX  technology. Check it out at
www.tmt.com
>
>Viva la difference!  But I'll (personally) take C over Pascal any day.
>
>(BTW, in case you can't tell - I'm a white American.  If I were black
>I might have more empathy for the minority.  I'm not, so I don't.  :-)
>
>(BTW BTW - Jean-Sebastien your English is better than my French
>will ever be.  Congratulations on your bi-lingualality (at least.))
>
>Jean-Sebastien Payette <jeansp...@videotron.ca> wrote in article


><64suum$5oo$1...@weber.videotron.net>...
>>
>> John Rickard wrote in message <64sql2$k...@mtinsc04.worldnet.att.net>...
>> >why should I waste my time RE learning a language I have understood
>> >and spoke since around 1-3 years of age?
>>
>>
>> I've never learn english and I talk better than you.
>> Now about Pascal and C let me tell you that in some case (strings and
>file
>> manipulation, most object handling) Pascal is way better and I know both
>> language (unlike you!!)
>>
>>
>>


English SUCKS, Chinese is the only language you need!! Cynthia & Bill 11/19/97 12:00 AM

I won't get into the debate between English, Chinese, or any other natural
language.

However...
I too know both C (and C++) and Pascal.  (As well as a lot of other comp
langauges.)
I prefer C/C++ simply because it is used by the majority (on PC's and Unix
boxes.)
I also know RPG and COBOL.
On mainframes I opt for COBOL.
On AS/400's, RPG is my langauge of choice.
On PC's and Unix boxes, I use C.  (And I'm starting to use Java.)

Except for undergraduate work, I have yet to find Pascal the langauge
of choice of the majority on any platform.

Viva la difference!  But I'll (personally) take C over Pascal any day.

(BTW, in case you can't tell - I'm a white American.  If I were black
I might have more empathy for the minority.  I'm not, so I don't.  :-)

(BTW BTW - Jean-Sebastien your English is better than my French
will ever be.  Congratulations on your bi-lingualality (at least.))

Jean-Sebastien Payette <jeansp...@videotron.ca> wrote in article
<64suum$5oo$1...@weber.videotron.net>...
>

English SUCKS, Chinese is the only language you need!! John Rickard 11/19/97 12:00 AM

When I posted that message my grammar was proper.
--
--
Remove "spam" from my

email address to send me REAL email.
--

Chieh Cheng <chieh...@iname.com> wrote in article
<34720007....@serve.installshield.com>...
: For one thing, your grammer sucks. And learn to capitalize. Isn't:

English SUCKS, Chinese is the only language you need!! Les Hazlewood 11/19/97 12:00 AM


Their his know knead too no ow too right English  :-)

--
Ignore the anti-spamming address given above and sent any replies to:

Email : hazl...@aston.ac.uk
Tel   : +44 (0)121 359 3611 x 4271
Fax:  : +44 (0)121 333 6215
Smail : Dr L J Hazlewood, Department of Computer Science,
        Aston University, Aston Triangle, Birmingham B4 7ET,
        United Kingdom

English SUCKS, Chinese is the only language you need!! Gary A. Wiltshire 11/19/97 12:00 AM

chieh...@iname.com (Chieh Cheng) wrote:
.....

>For one thing, your grammer sucks. And learn to capitalize. Isn't
>ironic when an American who learned English since he/she was born,
>write English worse than people with other nationalities?
.....
I don't normally pick on people for their English errors, particularly
someone who's learned it as a second language.  Since you've seen fit
to do that, be advised that it is grammAr, not grammEr!  The second
sentence above is (at least) stylistically dubious.  The third is
plainly ungrammatical.  Let's lighten up a bit and criticize CONTENT
of posts -- there is a lot of meat there.

   --- Gary Wiltshire

English SUCKS, Chinese is the only language you need!! Dennis Weldy 11/19/97 12:00 AM

Have y'tried using the string class? Y'dont have to use strdup any longer.
:-)
Give it a shot. :-)
    #include <string>
    #include <ostream>

    main()
    {
        std::string Hello, World, HelloWorld ;
        std::string HW2 ;
        Hello = "Hello" ;
        World = "World" ;
        HelloWorld = Hello + " " + World + "!" ;

        cout << HelloWorld << endl ;
        HW2 = HelloWorld ;
        HelloWorld = "I like the string class" ;

        cout << HW2 << endl ;
        cout << HelloWorld << endl ;
    }

Dennis

Jean-Sebastien Payette wrote in message
<64tnjp$o0k$1...@weber.videotron.net>...

English SUCKS, Chinese is the only language you need!! Davide Bionda 11/19/97 12:00 AM

>hardly, I can prove rather easily that I can speak my language better
>than you.

Right, that's the point: YOUR language, not english.

Take care
Davide

English SUCKS, Chinese is the only language you need!! Mark Wilden 11/19/97 12:00 AM

t...@panix.com wrote:
>
> Pascal is the prefered language for developers of games.

As a professional games programmer (currently with Sierra/Dynamix), I
can tell you that statement is untrue.

English SUCKS, Chinese is the only language you need!! Jean-Sebastien Payette 11/19/97 12:00 AM

>I do not know C and do not intend to learn it.  I do know TP Dos, TP
>Win, QuickBasic, VB3, VB4, and Visual Dialogscript.  So if you want a


Whoa you know pascal, pascal, basic, basic and basic that's cool!

>Damn near any idiot can program.  But it takes a Genius to become
>successful at it.

Yes and it don't take a genius to know 2 languages in different version!

Oh yea btw I know TP4, TP5, TP6, TP7, C++, Djgpp, and I even done some
programming in pascal on my C64
BUT I DON'T TELL ANYONE ABOUT IT BECAUSE IT'S ONLY 2 LANGUAGES! not 8 ...

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Dan Pop 11/19/97 12:00 AM

In <879900...@genesis.demon.co.uk> fr...@genesis.demon.co.uk (Lawrence Kirby) writes:

# In article <danpop.8...@news.cern.ch> Dan...@cern.ch "Dan Pop" writes:
#
# >And the definition of "unspecified behaviour" is:
# >
# > * Unspecified behavior --- behavior, for a correct program construct
# >   and correct data, for which the Standard imposes no requirements.
#
# No, the wording is as I quoted above, at least in the ISO 9899-1990
# standard.

I was quoting from my copy of the draft.  I wasn't aware that this
changed in the final version.

Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

English SUCKS, Chinese is the only language you need!! Kaz Kylheku 11/19/97 12:00 AM

In article <64suum$5oo$1...@weber.videotron.net>,

Standard Pascal is better at file handling than standard C? Hmm...
In what way, pray tell?

Have the I/O facilities of _standard_ Pascal improved since Brian Kernighan
wrote that paper entitled ``Why Pascal is Not My Favorite Programming
Language?'' It's not sufficient for some particular _implementation_ of Pascal
to provide better I/O facilities, if they are not part of the generally
accepted language definition.

As far as strings go, Pascal's representation of strings as character arrays is
not all too different from the way it's done in C. I just remember it as
being less flexible. The last time I used Pascal, it was next to impossible
to handle dynamic strings.

If you are going to use a Pascal-like language, at least go to Modula 2 (or
even 3).

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Kaz Kylheku 11/19/97 12:00 AM

In article <3473B0...@dynamite.com.au>,

Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>Many thanks to the posters on this thread. Ada programmers often feel,
>if not persecuted, then uncomfortably isolated by the mainstream.

That's downright silly.

>It's issues like this that make me feel thankful that I'm restricted to
>only programming in C or C++.

Did you pause to think when you wrote this?

English SUCKS, Chinese is the only language you need!! Kaz Kylheku 11/19/97 12:00 AM

In article <64tnjp$o0k$1...@weber.videotron.net>,

Jean-Sebastien Payette <jeansp...@videotron.ca> wrote:
>
>Dennis Weldy wrote in message ...
>>It is? Care to offer a bit of proof there?
>>Standard Pascal was, last I looked woefully lacking in file handling.
>>Strings were packed arrays of chars (much like C).
>>
>>Now, perhaps y'mean Object Pascal, from Borland? Yes, that would be better
>>at handling objects "better" than C, since C doesn't directly support the
>OO
>>paradigm. Of course, if y'try to compare it to C++....then I would disagree
>>(and yes, I do know Object Pascal (BP 7.0)).
>>
>>Dennis
>>
>
>
>Ok sorry I was talking about C++, I never really code in pure C.
>I must agree that I was a little overhelm stating that object pascal was
>better than C ( oups! C++) but not string manipulation. I hate string
>manipulation in C++. Damn strdup() that make everything fall appart...

You are confusing implementations and languages again. The strdup() function
is not part of C. It's an extension that is found in some implementations.
I believe it has descended from the System V Interface Definition.

Nevertheless, it is sometimes useful in a C program to execute an operation
that has the semantics of strdup. What do you find wrong with it? You have a
string that is in some static or automatic buffer. This string must be
maintained for a duration that is longer than the lifetime of the buffer, or
because that buffer will be reused for subsequent I/O operations. You have
little choice but to copy the string to dynamically allocated storage.

I have no clue what you are complaining about. Such an operation might be
required in _any_ language which does not hide storage management details
from the programmer.

You talk as if you lack programming experience.

English SUCKS, Chinese is the only language you need!! Mike Smith 11/19/97 12:00 AM

John Rickard <saskan@worldnet.att.net.DONTSPAMME> wrote in article
<64sql2$k...@mtinsc04.worldnet.att.net>...

> why should I waste my time RE learning a language I have understood
> and spoke since around 1-3 years of age?
> --
> --

Re-read your last post.  Hopefully, the reason will become obvious.

--Mike Smith

English SUCKS, Chinese is the only language you need!! Mike Smith 11/19/97 12:00 AM

Ingemar Ragnemalm <ing...@lysator.liu.se> wrote in article
<34706...@lysator.liu.se>...
> Do you realize that Java is more related to Object Pascal
> than to C and even C++? You don't? Yes, I thought you wouldn't.
> Think about it.
>

Of course we do.  That's why it sucks so bad.  ;-)  ;-)  ;-)  <--I'm
putting a bunch here so you can see I'm *really* joking.

--Mike Smith

English SUCKS, Chinese is the only language you need!! Mike Smith 11/19/97 12:00 AM

John Rickard <saskan@spam.worldnet.spam.att.spam.net.spam> wrote in article
<64ursa$j...@bgtnsc03.worldnet.att.net>...

> When I posted that message my grammar was proper.
> --
> --
> Remove "spam" from my
> email address to send me REAL email.
> --

Here's the message in question:

>why should I waste my time RE learning a language
>I have understood and spoke since around 1-3 years
>of age?

Let's see.  "Why" should be capitalized.  "RE" is not a word.  "RE
learning" is also not a word.  "Re-learning", maybe?  "I have understood
and spoke since"... maybe you meant "have understood and spoken since"?
"Around 1-3 years" is redundant - and, in your case, maybe a little
optimistic?

Normally I don't stoop to the level of nitpicking grammar and/or syntax in
Usenet posts, but if you're going to throw stones, you should move out of
that glass house first.

--Mike Smith

--Mike Smith


English SUCKS, Chinese is the only language you need!! Matt Corey 11/19/97 12:00 AM


Dr E. Buxbaum wrote:

  C:  The power and functionality of assembly language with the
usability and readability of assembly language.  ;-)

I think Tcl is the only language that anyone will ever need!  I haven't
been able to do anything in any other language, so Tcl is the only real
language.  (Never mind the fact the the Tcl library is written in C.)

Also, it's Ada, not ADA.  That's the people who approve your
toothbrushes.  :-)

A programming language is a tool, just like a hammer.  A particular
language is suitable for certain problems and domains.  I have yet to
see anyone write an OS in Tcl or Awk.  Does this make them 'worthless'
languages?  C doesn't support Objects, C++ doesn't have multithreading
defined in the language, Ada is perfect - I mean Ada doesn't support the
concept of interfaces a la Java,  Java doesn't support multiple
inheritance directly,  and Object Pascal (Delphi) is not portable in any
way, shape, or form (pun intended).  I use all of these languages
extensively and they are all very good languages.  If I had to choose
one language to use exclusively, I would quit and go work on my '66
Skylark.  The analysis and design of a system and the skill of the
programmer is implementing this has more to do with software quality
than the language chosen.

Viva la difference.   (Frenglish)

Does anyone have a Mandarin chinese keyboard that I can borrow?

Matt


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Shmuel (Seymour J.) Metz 11/19/97 12:00 AM

Alan E & Carmel J Brain wrote:
>
> Many thanks to the posters on this thread. Ada programmers often feel,
> if not persecuted, then uncomfortably isolated by the mainstream.

Oddly enough, Ada isn't even my language of choice. But it has a lot
going for it, and I was raised to "Tell the truth and shame the Devil".
Hell, I've even stuck up for C when the facts warranted it!

> It's issues like this that make me feel thankful that I'm restricted to
> only programming in C or C++.

I've got a problem with that. The more languages you know, the better
you understand the issues. With only C and C++, your experience is way
to narrow to appreciate other languages.

Mind you, I don't expect that you will like all of the other languages,
but each has something to teach you. Even (bletch) COBOL.

--

                        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 spam...@library.lspace.org

English SUCKS, Chinese is the only language you need!! J. W. Rider 11/19/97 12:00 AM

On Wed, 19 Nov 97 17:38:09 GMT, ch...@but_i_dont_like_spam.org (Chuck
Adams) wrote:

>Incorrect, standard pascal strings have their length encoded in them and are a
>primitive type.  delphi allows both pascal strings and null-terminated c
>strings (not always interchangeable).

*Standard* pascal strings are constants only.

Borland's Turbo Pascal strings used the prefix length byte.

Delphi (v3) handles the TP-style string, the null-terminated c-style
string, but uses a reference model version of a "long" string as its
default.

English SUCKS, Chinese is the only language you need!! Mike Smith 11/19/97 12:00 AM

Dennis Weldy <nojun...@ever.com> wrote in article
<32nusbR...@news2.ingr.com>...
> Ok, jumping on the content of Chieh's post, if you'll note he merely
ASSUMES
> the idividual is American, when there are penty of other countries where
the
> original poster couldve learned English from 1-3 years of age. England,
> Ireland, Canada, Australia,.... all sorts of places :)

He has stated in other posts that he is American.  Judging from his command
of the language, I wish he wouldn't advertise that fact so loudly.  ;-)

--Mike Smith

English SUCKS, Chinese is the only language you need!! John Rickard 11/19/97 12:00 AM

dont get on my case for throwing stones. i didnt even start this
shit.
i am getting flamed to death because i missed the fucking - key.
Geez. if it is a crime then you all should be executed also.
Oh what I am not allowed to estimate my age when i began speaking
understandable words?
GET OFF MY BACK!
I dont critisize any of you for fucking up words in a NG post!
like i said in another message, I don't have shit to prove to you!
this is a newsgroup not a english class!
this is a newsgroup not a resume!
GROW UP AND STOP BITCHING AT ME FOR A SIMPLE TYPO.

--
--
Remove "spam" from my
email address to send me REAL email.
--

Mike Smith <kld_m...@earthlink.nospam.net> wrote in article
<01bcf51e$35e2a0c0$0200000a@kld_mcs>...
: John Rickard <saskan@spam.worldnet.spam.att.spam.net.spam> wrote in


article
: <64ursa$j...@bgtnsc03.worldnet.att.net>...
: > When I posted that message my grammar was proper.
: > --
: > --
: > Remove "spam" from my
: > email address to send me REAL email.
: > --
:
: Here's the message in question:
:
: >why should I waste my time Re learning a language

: >I have understood and spoke since around 1-3 years
: >of age?
:
: Let's see.  "Why" should be capitalized.  "RE" is not a word.  "RE
: learning" is also not a word.  "Re-learning", maybe?  "I have
understood
: and spoke since"... maybe you meant "have understood and spoken
since"?
: "Around 1-3 years" is redundant - and, in your case, maybe a little
: optimistic?
:
: Normally I don't stoop to the level of nitpicking grammar and/or
syntax in
: Usenet posts, but if you're going to throw stones, you should move
out of
: that glass house first.
:
: --Mike Smith
:
: --Mike Smith
:
:

English SUCKS, Chinese is the only language you need!! John Rickard 11/19/97 12:00 AM

did someone forget that just about every inch of the internet you are
on now is in english.
NOTE: i did not say all. i said just about every inch.

--
--
Remove "spam" from my
email address to send me REAL email.
--

Mike Smith <kld_m...@earthlink.nospam.net> wrote in article
<01bcf51b$abcea520$0200000a@kld_mcs>...
: JCore <jco...@juno.com> wrote in article
: <34710873...@news.linkonline.net>...
: > On 17 Nov 1997 23:57:47 GMT, "John Rickard"
: > <saskan@worldnet.att.net.DONTSPAMME> wrote:
: >
: > >there are not more chinese speakers than english.
: > >if you have not relized it but the english language it the most
: > >widely used language as a standard. why? cause us americans want
it
: > >that way ;)
: >
: > Um, actually Chinese is the most widely spoken language in the
world.
: > Sorry to have to be the American to break it to you.  Oh yeh, and
I
: > agree with the original article too.
:
: Define "widely".  There certainly are an awful lot of
Chinese-speakers in
: the world.  But English is spoken in countries on every continent
of the
: globe (except South America? - I mean national tongue, not that one
or more
: people speak it).  It seems certain that, among people who speak at
least
: two languages, more people speak English as a second language than
Chinese.
:  English is the language of choice for international organizations
and for
: other international standards, e.g. English is the chosen language
for
: pilots, air traffic controllers, etc.  One hears English-language
songs on
: European radio all the time, but one almost never hears
: non-English-language songs on American radio (I can't speak for
: Commonwealth nations).  I don't know about the exact numbers of
English vs.
: Chinese speakers (don't forget India - not exactly a small
country), but
: certainly English is more "widely" spoken than Chinese.
:
: Is that because "we" (yes I'm American as if that weren't obvious)
want it
: that way?  Maybe.  But I think the UK deserves at least some of the
: credit/blame.  ;-)
:
: --Mike Smith
:

Your english sucks, mine is better. Mike Smith 11/19/97 12:00 AM

John Rickard <saskan@spam.worldnet.spam.att.spam.net.spam> wrote in article
<64vl4h$3...@bgtnsc02.worldnet.att.net>...
> God you people act as if a message posted to a newsgroup has to be
> written like a fucking resume'!  You all need to grow the fuck up and
> get off my back about a few damn words.
> You act as if I was writing a formal letter to apply to microsoft or
> some shit.  
> THIS IS A NEWSGROUP NOT A RESUME!

If you're going to make comments about the language skills of other
posters, then it seems only fair that you demonstrate that you can comment
from a position of superiority on the subject.  So far, you have failed to
do so.

I think I reflect the general viewpoint (no hyphen ;-) when I say that,
normally, few of us would bother to nitpick (no hyphen ;-) grammar and
syntax in Usenet posts, but after some of your comments, you're just plain
begging for it.

--Mike Smith

English SUCKS, Chinese is the only language you need!! sys...@niuhep.physics.niu.edu 11/19/97 12:00 AM

"Mike Smith" <kld_m...@earthlink.nospam.net> writes:
>JCore <jco...@juno.com> wrote in article
><34710873...@news.linkonline.net>...
>> On 17 Nov 1997 23:57:47 GMT, "John Rickard"
>> <saskan@worldnet.att.net.DONTSPAMME> wrote:
>>
>> >there are not more chinese speakers than english.
>> >if you have not relized it but the english language it the most
>> >widely used language as a standard. why? cause us americans want it
>> >that way ;)
>>
>> Um, actually Chinese is the most widely spoken language in the world.
>> Sorry to have to be the American to break it to you.  Oh yeh, and I
>> agree with the original article too.
>
>Define "widely".  There certainly are an awful lot of Chinese-speakers in
>the world.  But English is spoken in countries on every continent of the
>globe (except South America? - I mean national tongue, not that one or more
>people speak it).  

>One hears English-language songs on


>European radio all the time, but one almost never hears
>non-English-language songs on American radio (I can't speak for
>Commonwealth nations).  

I think that speaks more to our insularity than anything else.

>I don't know about the exact numbers of English vs.
>Chinese speakers (don't forget India - not exactly a small country),

My info is that 4% of Indians speak and read English.  How many
speak but don't read it?  dunno.

>Is that because "we" (yes I'm American as if that weren't obvious) want it
>that way?  Maybe.  

I think it is pretty clearly yes.  We can debate whether this is
"ugly" and/or "understandable" some other time.

>But I think the UK deserves at least some of the credit/blame.  ;-)

The U.K. mostly takes credit for making it one of the languages of choice
in its former colonies.

Mor...@physics.niu.edu
Real Women change tires                        abuse@uu.net postm...@uu.net
Real Men change diapers                 secu...@uu.net

Your english sucks, mine is better. John Rickard 11/19/97 12:00 AM

God you people act as if a message posted to a newsgroup has to be
written like a fucking resume'!  You all need to grow the fuck up and
get off my back about a few damn words.
You act as if I was writing a formal letter to apply to microsoft or
some shit.  
THIS IS A NEWSGROUP NOT A RESUME!
--
--
Remove "spam" from my email address to send me REAL email.
--

Mike Smith <kld_m...@earthlink.nospam.net> wrote in article
<01bcf528$91a46ba0$0200000a@kld_mcs>...
: John Rickard <saskan@spam.worldnet.spam.att.spam.net.spam> wrote in
article
: <64vdi2$8...@bgtnsc02.worldnet.att.net>...
: > Yea thats right. MY language is "American" English.  not English.
: > --
: > --
: > Remove "spam" from my
: > email address to send me REAL email.
: > --
:
: No.  Your language, judging from your posts on this newsgroup, is
some
: degenerate form of English where grammar and syntax have been
"dumbed down"
: so that people such as yourself don't need to feel shame in
breaking the
: "rules", or lack thereof.
:
: --Mike Smith
:

English SUCKS, Chinese is the only language you need!! sys...@niuhep.physics.niu.edu 11/19/97 12:00 AM

k...@helios.crest.nt.com (Kaz Kylheku) writes:
>Mark Wilden  <Mark@mWilden.com> wrote:
>>John Rickard wrote:
 
>>> why should I waste my time RE learning a language I have understood

>>> and spoke since around 1-3 years of age?

>>Three reasons:

>>1) "RE learning" requires a hyphen.

>Incidentally, re-learning would actually be written relearning.

Maybe.  John wanted to emphasize "RE", so I think he should have
typed "RE-learning".  No hyphen would have been ok, clearly a space
is incorrect.

>>2) "spoke" should be "spoken."

>Touche. That could be a typo.

Probably, but since this was a response to a criticism based on the typos
made by John you would think he would be a bit more carefull.
(The criticism included a smilie and I do think was made in good humor,
something John seems to lack)

Robert

Mor...@physics.niu.edu
Real Women change tires                        abuse@uu.net postm...@uu.net
Real Men change diapers                 secu...@uu.net

English SUCKS, Chinese is the only language you need!! sys...@niuhep.physics.niu.edu 11/19/97 12:00 AM

"John Rickard" wrote:

>Davide Bionda <bio...@erdw.ethz.ch> wrote:
>>"John Rickard" wrote:

>why should I waste my time RE learning a language I have understood
>and spoke since around 1-3 years of age?

>>>there are not more chinese speakers than english.


>>>if you have not relized it but the english language it the most
>>>widely used language as a standard. why? cause us americans want
>>>it that way ;)

>>Then you should try to learn it ;-)
 
You know, when I first read this, I thought John was having a bit of fun
and was a bit taken aback by the responses he got, then I read his
reply to a comment from one of our French-Canadian collegues and I
started to understand...

================================================================================
"John Rickard" <saskan@spam.worldnet.spam.att.spam.net.spam>
>J-S Payette wrote:

>>I've never learn english and I talk better than you.
>^^^^^^^^^^^^^^^^^^^^^^^^^And you should so you can learn proper
>vocabulary skills.

Given the construction of the above sentence/phrase I wouldn't
be so quick to be critical of others' language abilities.
At least you're capitalizing.

>>Now about Pascal and C let me tell you that in some case (strings and file
>>manipulation, most object handling) Pascal is way better and I know both
>>language (unlike you!!)

>And how do you know what languages I know?

I don't know about languages, but given the amount of formatting I
had to do to make this message legible I would say you don't know
much about newsreaders.

>So if you want a fight about who knows more we can skip the whole
>programming aspect and take this a intelectual level and have a
>battle of the wits.  And I can promise you I will win.

<heh> I think that is best left without explicit comment :)

<no snip between the above paragraph and the below 7 lines>

>-
>Damn near any idiot can program.  But it takes a Genius to become
>successful at it.
>-

>hardly, I can prove rather easily that I can speak my language better
>than you. I mean I have only been speaking it since I have been able
>to speak.

Please go find a style book and look up continuity and making transitions.

>As for talking better than me... Try reading you message and tell me
>you don't talk like a 12 year old.

Try rereading your messages and understand that:
1) you can't take a joke,
2) your intuitive grammer sucks
3) some people might think your emotional age matches Jean's skills
        at his 2nd written/spoken language.

Chill,


Robert

Mor...@physics.niu.edu
Real Women change tires                        abuse@uu.net postm...@uu.net
Real Men change diapers                 secu...@uu.net

English SUCKS, Chinese is the only language you need!! Matt Corey 11/19/97 12:00 AM

The Java v. Ada v. C v. C++ v. Pascal v. Tcl v. Forth v. Scheme v. Eiffel v.
Sather v. Awk v. Perl v. Basic v. B v. CLOS  ( breath ) v. Flavors v. RPG v.
COBOL v. Fortran v. Clipper v. Modulax v. ObjectiveC v. PL/1 v. PLM v.
Assembler v. Rexx v. Smalltalk v. Python language war has now added English.
:-)


--
Matthew F. Corey    mco...@itsnet.com
Software Engineer
Rigaku USA/MSC  http://www.msc.com

English SUCKS, Chinese is the only language you need!! Mark Wilden 11/19/97 12:00 AM

Michael Rubenstein wrote:
>
> According to the World Almanac there are almost twice as many speakers
> of Mandarin (999 million) as of English (487 million).

What year was that? Those figures seem suspect. They mean that over 4.5
billion people speak neither language.

English SUCKS, Chinese is the only language you need!! John Rickard 11/19/97 12:00 AM

>I've never learn english and I talk better than you.
^^^^^^^^^^^^^^^^^^^^^^^^^And you should so you can learn proper
vocabulary skills.
>Now about Pascal and C let me tell you that in some case (strings
and file
>manipulation, most object handling) Pascal is way better and I know
both
>language (unlike you!!)
And how do you know what languages I know?  You don't know the first
thing about me other than I read this newsgroup.  For your infomation

I do not know C and do not intend to learn it.  I do know TP Dos, TP
Win, QuickBasic, VB3, VB4, and Visual Dialogscript.  So if you want a

fight about who knows more we can skip the whole programming aspect
and take this a intelectual level and have a battle of the wits.  And
I can promise you I will win.
-
Damn near any idiot can program.  But it takes a Genius to become
successful at it.
-
hardly, I can prove rather easily that I can speak my language better
than you. I mean I have only been speaking it since I have been able
to speak.
Your english sucks, mine is better. Larry Elmore 11/19/97 12:00 AM

John Rickard wrote in message <64vl4h$3...@bgtnsc02.worldnet.att.net>...

> > why should I waste my time RE learning a language I have understood
> > and spoke since around 1-3 years of age?

>: Your language, judging from your posts on this newsgroup, is


>some
>: degenerate form of English where grammar and syntax have been
>"dumbed down"
>: so that people such as yourself don't need to feel shame in
>breaking the
>: "rules", or lack thereof.


>God you people act as if a message posted to a newsgroup has to be
>written like a fucking resume'!  You all need to grow the fuck up and
>get off my back about a few damn words.
>You act as if I was writing a formal letter to apply to microsoft or
>some shit.
>THIS IS A NEWSGROUP NOT A RESUME!

I don't know what _you're_ complaining about! YOU ASKED A QUESTION (see
first line of post). Now you complain when people answer your question
_accurately_? If you don't want to know what's wrong with your English,
DON'T ASK!!!

>: > Yea thats right. MY language is "American" English.  not English.

Unfortunately, I've known a quite a few people for whom English is a second
language and who speak far better _American_ English than many Americans.
Some of them have never even been to America, either.

What _you_ call  "American" English is a disgrace. Sort of a white version
of "Ebonics" is my guess. "Ivonics", perhaps?

Larry

English SUCKS, Chinese is the only language you need!! Chieh Cheng 11/19/97 12:00 AM

On Wed, 19 Nov 1997 15:01:11 GMT, 70523...@compuserve.com (Gary A.
Wiltshire) wrote:

>chieh...@iname.com (Chieh Cheng) wrote:
>.....
>>For one thing, your grammer sucks. And learn to capitalize. Isn't
>>ironic when an American who learned English since he/she was born,
>>write English worse than people with other nationalities?
>.....
>I don't normally pick on people for their English errors, particularly
>someone who's learned it as a second language.  Since you've seen fit
>to do that, be advised that it is grammAr, not grammEr!  The second
>sentence above is (at least) stylistically dubious.  The third is
>plainly ungrammatical.  Let's lighten up a bit and criticize CONTENT
>of posts -- there is a lot of meat there.
>
>   --- Gary Wiltshire

You are absolutely right. I am not very good with English, but I was
speaking for other people who learned their second language must
better than I did. Otherwise, I would have compared him to myself. And
again, you're right. I'll chill out a bit.

CC
--
http://www.geocities.com/Area51/8145/
Up the mountain, down the slope.
Around the tree trunks, past the streams.

English SUCKS, Chinese is the only language you need!! Kaz Kylheku 11/19/97 12:00 AM

In article <64vpcn$n...@corn.cso.niu.edu>,
 <sys...@niuhep.physics.niu.edu> wrote:

>k...@helios.crest.nt.com (Kaz Kylheku) writes:
>>Touche. That could be a typo.
>
>Probably, but since this was a response to a criticism based on the typos
>made by John you would think he would be a bit more carefull.

Carefull? :) Is that a blunder or an instance of irony?

English SUCKS, Chinese is the only language you need!! John R. Reagan 11/19/97 12:00 AM

In article <YSQz$BJ98G...@news2.ingr.com>, "Dennis Weldy" <nojun...@ever.com> writes...


>Standard Pascal was, last I looked woefully lacking in file handling.
>Strings were packed arrays of chars (much like C).
>
>Now, perhaps y'mean Object Pascal, from Borland? Yes, that would be better
>at handling objects "better" than C, since C doesn't directly support the OO
>paradigm. Of course, if y'try to compare it to C++....then I would disagree
>(and yes, I do know Object Pascal (BP 7.0)).

I guess you haven't looked since 1989 then.  Extended Pascal added a
real STRING type and many file handling routines.

The committee also authored a object-oriented extensions in Pascal that
looks more like Java or Object Pascal on the Apple than TP or C++.

--
John Reagan
DEC Pascal Project Leader
Application Compilers and Environments
Digital Equipment Corporation
rea...@hiyall.enet.dec.com
Disclaimer:  The opinions and statements expressed by me are not
             necessarily those of Digital Equipment Corporation.
--

English SUCKS, Chinese is the only language you need!! Kaz Kylheku 11/19/97 12:00 AM

In article <347388...@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:

>Matt Corey wrote:
>>
>>   C:  The power and functionality of assembly language with the
>> usability and readability of assembly language.  ;-)
>
>That's on a good day; the C preprocessor has less power and
>functionality than any macro language I've used in decades. And some C

That's probably a good thing. The current preprocessor is abused enough as it
is.  Because it's not too complicated, one can reasonably wade through some
of the worst abuses.

TeX is a powerful macro language; ever try to debug those important ``include''
files that come with the distribution? Aaaaargh... The problem with macro
languages is that something can undergo so many confusing levels of expansion
that it becomes difficult, if not nearly impossible to understand what is going
on.

Consider that the compiler for Plan 9 C actually has a _simplified_ preprocessor
(with respect to the requirements of ANSI C).

>constructs are more arcane that assembler language.

Which ones? I would vote for the possibility of side effects causing undefined
behaviors unheard of in assembly language. That has more to do with the way
a construct is used. Still, to me that is the single worst aspect of the C language,
and one of the least poorly understood by the average joe who fancies himself
a programmer. It's amazing how often in comp.lang.c we get some buffoon who claims
that his compiler is incorrectly translating some expression that obviously violates
the rules with respect to side effects.

>> Also, it's Ada, not ADA.  That's the people who approve your
>> toothbrushes.  :-)
>
>Yes, but see below.
>
>> in Tcl or Awk.  
>
>Shouldn't that be AWK, since it's named after the authors?

Touche! :) And TCL is also an acronym, is in not? Tool Command Language or some
such thing.

English SUCKS, Chinese is the only language you need!! Chuck Adams 11/19/97 12:00 AM

In article <YSQz$BJ98G...@news2.ingr.com>, "Dennis Weldy" <nojun...@ever.com> wrote:
>It is? Care to offer a bit of proof there?
>Standard Pascal was, last I looked woefully lacking in file handling.
>Strings were packed arrays of chars (much like C).

Incorrect, standard pascal strings have their length encoded in them and are a

primitive type.  delphi allows both pascal strings and null-terminated c
strings (not always interchangeable).


English SUCKS, Chinese is the only language you need!! Dennis Weldy 11/19/97 12:00 AM

Ok, jumping on the content of Chieh's post, if you'll note he merely ASSUMES
the idividual is American, when there are penty of other countries where the
original poster couldve learned English from 1-3 years of age. England,
Ireland, Canada, Australia,.... all sorts of places :)

Dennis
Gary A. Wiltshire <70523...@compuserve.com> wrote in message
<3472e573...@news.albany.net>...


>chieh...@iname.com (Chieh Cheng) wrote:
>.....
>>For one thing, your grammer sucks. And learn to capitalize. Isn't
>>ironic when an American who learned English since he/she was born,
>>write English worse than people with other nationalities?
>.....
>I don't normally pick on people for their English errors, particularly
>someone who's learned it as a second language.  Since you've seen fit
>to do that, be advised that it is grammAr, not grammEr!  The second
>sentence above is (at least) stylistically dubious.  The third is
>plainly ungrammatical.  Let's lighten up a bit and criticize CONTENT
>of posts -- there is a lot of meat there.
>
>   --- Gary Wiltshire

English SUCKS, Chinese is the only language you need!! John Rickard 11/19/97 12:00 AM

Yea thats right. MY language is "American" English.  not English.
--
--
Remove "spam" from my
email address to send me REAL email.
--

Davide Bionda <bio...@erdw.ethz.ch> wrote in article
<347301...@erdw.ethz.ch>...
: >hardly, I can prove rather easily that I can speak my language
better
: >than you.
:
: Right, that's the point: YOUR language, not english.
:
: Take care
: Davide
:

English SUCKS, Chinese is the only language you need!! Kaz Kylheku 11/19/97 12:00 AM

In article <3471F184.7924@mWilden.com>, Mark Wilden  <Mark@mWilden.com> wrote:
>John Rickard wrote:
>>
>> why should I waste my time RE learning a language I have understood
>> and spoke since around 1-3 years of age?
>
>Three reasons:
>
>1) "RE learning" requires a hyphen.

Hyphens are not part of the language, they are just an orthographic convention.

If you disagree, then tell me what sound the hyphen makes in the pronounciation
of ``re-learning''? ;)

Incidentally, re-learning would actually be written relearning. Hyphenation is
only used when words are combined in an unusual way, particularly two nouns.
When a certain combination becomes commonplace, the hyphen disappears.
A hyphen need not be used to separate a prefix from a word.  Do you write
``re-generate'', ``un-happy'', or ``black-board'' instead of ``regenerate'',
``unhappy'' or ``blackboard''?

Of course, hackers are divided on this issue. You have the BlackBoard camp, and
the black_board camp. :)))

In English, nouns can be combined simply by juxtaposition to form compound
nouns. For example:

    ``law school entrance requirement examination result''

This combination could serve, in a sentence, in the place of a simple noun.

Since this combination is arbitrary, rather than an idiom that often appears in
the language, we do not write it using hyphens between the nouns. (But contrast
this to German, in whose writing system strings of nouns are commonly pasted
together without whitespace).

In the English, when two nouns tend to be commonly associated, people start
writing the hyphen. Eventually, when two words meld to the point that the
meaning of the sum is more than the combination of the meanings of the two
parts, the words are simply written together. In effect, a new word results. A
blackboard is more than just a board that is black.

>2) "spoke" should be "spoken."

Touche. That could be a typo. No native speaker of English would say ``I have
understood and (I have) spoke'' unless he or she happened to blunder. It's
awfully faulty parallelism. :)

- Kaz (an English speaker since the age of twelve).

English SUCKS, Chinese is the only language you need!! Shmuel (Seymour J.) Metz 11/19/97 12:00 AM

Chieh Cheng wrote:
 
> Obviously, you do not understand the benefits of learning a variety of
> different computer languages. If you don't learn LISP, you will never
> fully understand the capability and limitation of C and C++.

Oh, no! Please don't start a LISP versus Prolog debate!

--

                        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 spam...@library.lspace.org

English SUCKS, Chinese is the only language you need!! Mark Wilden 11/19/97 12:00 AM

Kaz Kylheku wrote:
>
> Hyphens are not part of the language, they are just an orthographic convention.

And what do you suppose "orthographic conventions" are part of, if not
the language? Are you saying there is no difference between "release"
and "re-lease"?

> If you disagree, then tell me what sound the hyphen makes in the pronounciation
> of ``re-learning''? ;)

Only if you tell me what sound the "p" makes in "ptarmigan." Sound is
just one component of language.

> Incidentally, re-learning would actually be written relearning. Hyphenation is
> only used when words are combined in an unusual way, particularly two nouns.

That's actually true, according to modern style. For example, I recently
won a battle over how to spell "multiplayer" in a manual, against those
who preferred to hyphenate it.

> When a certain combination becomes commonplace, the hyphen disappears.

The guy wrote "re learning." A hyphen could have been used, or it could
have been made one word, I agree.

English SUCKS, Chinese is the only language you need!! Shmuel (Seymour J.) Metz 11/19/97 12:00 AM

Dr E. Buxbaum wrote:

> I always thought C WAS the PDP-11 macro assembler!

No; in fact, C was original done on a more primitive machine, the PDP-7.
While the ++ and -- operators were clearly inspired by the equivalent
macine instructions, the C preprocessor has less expressive power than
the macro facility of any assembler that I am familiar with.

It might be fair to say that C is BCPL, although I would consider that
there were too many changes from BCPL to B to C for me to defend such a
claim.

--

                        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 spam...@library.lspace.org

English SUCKS, Chinese is the only language you need!! Mike Smith 11/19/97 12:00 AM

John Rickard <saskan@spam.worldnet.spam.att.spam.net.spam> wrote in article
<64vdi2$8...@bgtnsc02.worldnet.att.net>...
> Yea thats right. MY language is "American" English.  not English.
> --
> --
> Remove "spam" from my
> email address to send me REAL email.
> --

No.  Your language, judging from your posts on this newsgroup, is some


degenerate form of English where grammar and syntax have been "dumbed down"
so that people such as yourself don't need to feel shame in breaking the
"rules", or lack thereof.

--Mike Smith

English SUCKS, Chinese is the only language you need!! John Rickard 11/19/97 12:00 AM

They assumed I was american BECAUSE I mentioned the fact I was in I
beleive the 2nd post I made in my defense.

--
--
Remove "spam" from my
email address to send me REAL email.
--

Dennis Weldy <nojun...@ever.com> wrote in article
<32nusbR...@news2.ingr.com>...
: Ok, jumping on the content of Chieh's post, if you'll note he:
:
:

English SUCKS, Chinese is the only language you need!! Mike Smith 11/19/97 12:00 AM

JCore <jco...@juno.com> wrote in article
<34710873...@news.linkonline.net>...
> On 17 Nov 1997 23:57:47 GMT, "John Rickard"
> <saskan@worldnet.att.net.DONTSPAMME> wrote:
>
> >there are not more chinese speakers than english.
> >if you have not relized it but the english language it the most
> >widely used language as a standard. why? cause us americans want it
> >that way ;)
>
> Um, actually Chinese is the most widely spoken language in the world.
> Sorry to have to be the American to break it to you.  Oh yeh, and I
> agree with the original article too.

Define "widely".  There certainly are an awful lot of Chinese-speakers in
the world.  But English is spoken in countries on every continent of the
globe (except South America? - I mean national tongue, not that one or more
people speak it).  It seems certain that, among people who speak at least
two languages, more people speak English as a second language than Chinese.
 English is the language of choice for international organizations and for
other international standards, e.g. English is the chosen language for
pilots, air traffic controllers, etc.  One hears English-language songs on

European radio all the time, but one almost never hears
non-English-language songs on American radio (I can't speak for
Commonwealth nations).  I don't know about the exact numbers of English vs.
Chinese speakers (don't forget India - not exactly a small country), but

certainly English is more "widely" spoken than Chinese.

Is that because "we" (yes I'm American as if that weren't obvious) want it
that way?  Maybe.  But I think the UK deserves at least some of the
credit/blame.  ;-)

--Mike Smith

English SUCKS, Chinese is the only language you need!! Kaz Kylheku 11/19/97 12:00 AM

In article <347339...@gsg.eds.com>,

Shmuel (Seymour J.) Metz <nos...@gsg.eds.com> wrote:
>Dr E. Buxbaum wrote:
>
>> I always thought C WAS the PDP-11 macro assembler!
>
>No; in fact, C was original done on a more primitive machine, the PDP-7.

No it wasn't. The language that Ken Thompson developed for the PDP-7 was called
B.

C was developed by Dennis Ritchie using the PDP-11. There is a myth surrounding

>While the ++ and -- operators were clearly inspired by the equivalent
>macine instructions, the C preprocessor has less expressive power than
>the macro facility of any assembler that I am familiar with.

That is a myth which is false. The ++ and -- operators were in the B language
that was implemented on the PDP-7, which had no such instructions. They
are an invention of Ken Thompson alone.

The PDP-7 did actually have some auto-increment memory cells. While they may
have suggested to Ken the idea for these operators, they were not used in their
implementation.

C inherited its ++ and -- operators from B, and not from the PDP-11 instruction
set as the widespread myth would have it.

>It might be fair to say that C is BCPL, although I would consider that
>there were too many changes from BCPL to B to C for me to defend such a
>claim.

There are similarities between C and BCPL, but that can also be said of C and
<insert language name here>. One chief differece is that BCPL is not byte
oriented but cell oriented. Pointers are unscaled and reference cells, not
individual bytes. The meaning of a cell depends on the applied operation.
Individual bytes are packed into cells, and are referenced using special
operators that take into account the packing. This is quite different from C's
comprehensive type system, byte oriented nature, and pointers that
automatically scale (not to mention vast differences between the syntaxes).

English SUCKS, Chinese is the only language you need!! Michael Rubenstein 11/19/97 12:00 AM

On 19 Nov 1997 18:48:10 GMT, "Mike Smith"
<kld_m...@earthlink.nospam.net> wrote:

According to the World Almanac there are almost twice as many speakers


of Mandarin (999 million) as of English (487 million).

Michael M Rubenstein

English SUCKS, Chinese is the only language you need!! Shmuel (Seymour J.) Metz 11/19/97 12:00 AM

Matt Corey wrote:
>
>   C:  The power and functionality of assembly language with the
> usability and readability of assembly language.  ;-)

That's on a good day; the C preprocessor has less power and
functionality than any macro language I've used in decades. And some C
constructs are more arcane that assembler language.

OTOH, I remember defending a particualr C construct against the charge
that it was opaque and poor practice.

> Also, it's Ada, not ADA.  That's the people who approve your
> toothbrushes.  :-)

Yes, but see below.
 
> in Tcl or Awk.  

Shouldn't that be AWK, since it's named after the authors?

--

                        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 spam...@library.lspace.org

English SUCKS, Chinese is the only language you need!! Michael Rubenstein 11/20/97 12:00 AM

On Wed, 19 Nov 1997 16:04:15 -0800, Mark Wilden <Mark@mWilden.com>
wrote:

It's from the 1997 Almanac (from Microsoft Bookshelf) and the figures
are for mid 1996.

There are also 457 million speakers of Hindi and 401 million speakers
of Spanish.

These figures include non-native speaker.

Also, of course, I meant "over", not "almost."

Michael M Rubenstein

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Alan E & Carmel J Brain 11/20/97 12:00 AM

Kaz Kylheku wrote:

> Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
> >Many thanks to the posters on this thread. Ada programmers often feel,
> >if not persecuted, then uncomfortably isolated by the mainstream.
>
> That's downright silly.

I agree. But true.
 
> >It's issues like this that make me feel thankful that I'm restricted to
> >only programming in C or C++.
>
> Did you pause to think when you wrote this?

Actually no, it was a strong and immediate reaction.

On further thought and reflection... it's still my reaction. Whether it
was worth posting on a newsgroup is another matter. Maybe it is: if only
one C programmer has a go at Eiffel, or Modula-3, or (best IMHO) Ada-95
then it might give them ideas on how to improve C, or a descendent
(Java, anyone?). So the state-of-the-art might improve.

Language wars are a WOFTAM. Hard data has been collected on productivity
enhancements in various domains, showing that what language you use DOES
matter. Of course Beta being superior to VHS didn't help it.

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

Your english sucks, mine is better. John Rickard 11/20/97 12:00 AM

: syntax in Usenet posts, but after some of your comments, you're
just plain
: begging for it.
I was not begging for anything.
If all you assholes were not so quick to think up a smart ass reply
then we would not have this flaming problem.


English SUCKS, Chinese is the only language you need!! Boyd Roberts 11/20/97 12:00 AM

In article <3473723c....@nntp.ix.netcom.com>, mik...@ix.netcom.com (Michael Rubenstein) writes:
>According to the World Almanac there are almost twice as many speakers
>of Mandarin (999 million) as of English (487 million).
>

By the shear number of speakers, the Mandarin speakers are predominant.

However, the universally used language is, and will be, some varient of English.

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: fr...@ultramax.net

English SUCKS, Chinese is the only language you need!! Joseph Santaniello 11/20/97 12:00 AM

In article <650e6p$ahv$1...@darla.visi.com>, se...@plethora.net (Peter Seebach)
wrote:

>>>> of Mandarin (999 million) as of English (487 million).
>
>>It's from the 1997 Almanac (from Microsoft Bookshelf) and the figures
>>are for mid 1996.
>
>>These figures include non-native speaker.
>
>I have a hard time believing this one.  Just about all of the U.S.,
>most of Canada, all of the U.K., a third of Europe, and a large portion
>of Asia, speak English, at least as a second language.

487 sounds about right if you figure the poulations for the areas you
mention are "about" as follows: US 270M, Canada 29M, UK 58M, 1/3 Europe
150M, and half of Japan (optimistic) 70M, Australia 15M (?). Plus everybody
else in Asia who maybe speaks English still falls way below 999M for
Mandarin.

Joe

English SUCKS, Chinese is the only language you need!! Boyd Roberts 11/20/97 12:00 AM

In article <650e6p$ahv$1...@darla.visi.com>, se...@plethora.net (Peter Seebach) writes:
>
>English has a wide variety of consonant clusters, and happily adopts
>words from nearly any other language; this has been a great strength
>for it.
>

That is hardly an argument.  If you try hard enough you can do it
in any language.  Take French:

   CD   == cédé
   mail == mél

Yes, they are serious.

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: fr...@ultramax.net

English SUCKS, Chinese is the only language you need!! Christer Gustavsson 11/20/97 12:00 AM

"John Rickard" <saskan@spam.worldnet.spam.att.spam.net.spam> writes:
> did someone forget that just about every inch of the internet you are
> on now is in english.
> NOTE: i did not say all. i said just about every inch.

Ok, so on some of the centimeters there are other languages, right?
:-)

/Christer

English SUCKS, Chinese is the only language you need!! Mike Smith 11/20/97 12:00 AM

sys...@niuhep.physics.niu.edu wrote in article
<64vpua$n...@corn.cso.niu.edu>...

> >One hears English-language songs on
> >European radio all the time, but one almost never hears
> >non-English-language songs on American radio (I can't speak for
> >Commonwealth nations).  
>
> I think that speaks more to our insularity than anything else.

Maybe.  For myself, I can say I don't like European music very much because
of the musical content, not the language.  Europeans (except the British,
who invented it, and a couple of flukes from Germany, like the Scorpions)
don't know how to ROCK!  I mean, what was the last really good Swiss (or
Czech, or Danish, etc.) grunge band?  ;-)

--Mike Smith

English SUCKS, Chinese is the only language you need!! Mike Smith 11/20/97 12:00 AM

Kaz Kylheku <k...@helios.crest.nt.com> wrote in article
<650kf8$smt$1...@helios.crest.nt.com>...

> >> in Tcl or Awk.  
> >
> >Shouldn't that be AWK, since it's named after the authors?
>
> Touche! :) And TCL is also an acronym, is in not? Tool Command Language
or some
> such thing.

They're both acronyms, but I've seen them widely (couldn't help digging up
that word again ;-) used without capitalization.  Sort of like scuba, which
is an acronym, but is very often not capitalized.

--Mike Smith

English SUCKS, Chinese is the only language you need!! Mike Smith 11/20/97 12:00 AM

Michael Rubenstein <mik...@ix.netcom.com> wrote in article
<3473723c....@nntp.ix.netcom.com>...

>
> According to the World Almanac there are almost twice as many speakers
> of Mandarin (999 million) as of English (487 million).
>

I wouldn't doubt it.  (Though I suspect the English figure; there must be
over 300 million English speakers in North America alone, plus the UK,
Ireland, Australia, India, South Africa, Singapore, etc., etc. - not to
mention people in continental Europe who speak English as a second
language.)  But most of those billion Mandarin-speakers live in China.
Those half-billion English-speakers live all over the world, and their
(our) language is more pervasive in a variety of fields like international
organizations.  That's what I meant by "widely".

--Mike Smith

English SUCKS, Chinese is the only language you need!! Mike Smith 11/20/97 12:00 AM

Chieh Cheng <chieh...@iname.com> wrote in article
<3472f84b....@serve.installshield.com>...
> On Wed, 19 Nov 1997 15:01:11 GMT, 70523...@compuserve.com (Gary A.
>
> You are absolutely right. I am not very good with English, but I was
> speaking for other people who learned their second language must
> better than I did. Otherwise, I would have compared him to myself. And
> again, you're right. I'll chill out a bit.
>

This seems like pretty good English to me!  (One point off misspelling
"much", though.  ;-)

--Mike Smith

English SUCKS, Chinese is the only language you need!! Marin David Condic, 561.796.8997, M/S 731-96 11/20/97 12:00 AM

Matt Corey <mco...@ITSNET.COM> writes:
>The Java v. Ada v. C v. C++ v. Pascal v. Tcl v. Forth v. Scheme v. Eiffel v.
>Sather v. Awk v. Perl v. Basic v. B v. CLOS  ( breath ) v. Flavors v. RPG v.
>COBOL v. Fortran v. Clipper v. Modulax v. ObjectiveC v. PL/1 v. PLM v.
>Assembler v. Rexx v. Smalltalk v. Python language war has now added English.
>:-)
>
    This thread has certainly degenerated quite a bit to the point
    where it has become hopelessly silly. Maybe we should toss in yet
    one more programming language to debate? How about Befunge - the
    worlds first two dimensional programming language:

        http://www.cats-eye.com/cet/soft/lang/befunge/

    I was rather impressed by it ;-)

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  COND...@PWFL.COM
===============================================================================
    "Some people say a front-engine car handles best. Some people say
    a rear-engine car handles best. I say a rented car handles best."
        --  P. J. O'Rourke
===============================================================================

English SUCKS, Chinese is the only language you need!! John R. Reagan 11/20/97 12:00 AM

In article <3473407e...@lhc.nlm.nih.gov>, jw_r...@usa.net (J. W. Rider) writes...
>*Standard* pascal strings are constants only.
>
>Borland's Turbo Pascal strings used the prefix length byte.

Becareful of what you speak...

The Extended Pascal standard from 1989 added a variable-length STRING type
in addition to the traditional PACKED ARRAY OF CHAR fixed-string type.

Also note that the standard doesn't provide an implementation.  A compiler
is free to choose whatever implementation to provide the semantic behavior.
It could choose a prefix length byte, a prefix length word, a trailing
null, a quija board, etc.


--
John Reagan
DEC Pascal Project Leader
Application Compilers and Environments
Digital Equipment Corporation
rea...@hiyall.enet.dec.com
Disclaimer:  The opinions and statements expressed by me are not
             necessarily those of Digital Equipment Corporation.
--

English SUCKS, Chinese is the only language you need!! Craig Franck 11/20/97 12:00 AM

"Mike Smith" <kld_m...@earthlink.nospam.net> wrote:
>sys...@niuhep.physics.niu.edu wrote in article
><64vpua$n...@corn.cso.niu.edu>...
>> >One hears English-language songs on
>> >European radio all the time, but one almost never hears
>> >non-English-language songs on American radio (I can't speak for
>> >Commonwealth nations).  
>>
>> I think that speaks more to our insularity than anything else.
>
>Maybe.  For myself, I can say I don't like European music very much because
>of the musical content, not the language.  

Looking at the international charts in Billboard, I can recognize 8
out of the top 10 songs in some countries. September 12 Top 10 in
Sweden is topped by "Barbie Slut Girl" and then Puff Daddy, Coolio,
the "Men in Black" song, then finally two artists that seem local,
then back to that Mr. Biggy fellow, Mariah Carrey, Baby Face & Stevie
Wonder, and The Verve (apparently not the same as The Verve Pipe,
because the label is different). Oasis, Aqua, John Fogerty (I guess
swamp funk if popular there), Spice Girls, No Doubt, and Prodigy all
have Top 10 albums in Sweden.

>Europeans (except the British,
>who invented it, and a couple of flukes from Germany, like the Scorpions)
>don't know how to ROCK!  I mean, what was the last really good Swiss (or
>Czech, or Danish, etc.) grunge band?  ;-)

There will always be ABBA (sold more records than the Beatles, you
know). :-) wowowowoWaterloo...

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


English SUCKS, Chinese is the only language you need!! John Rickard 11/20/97 12:00 AM

 

English SUCKS, Chinese is the only language you need!! Mark Wilden 11/20/97 12:00 AM

Dan wrote:
>
> Most people in South Africa, India, and perhaps Singapore do not speak
> much or any English.

I don't know about Singapore, but I'm skeptical about the other two. In
fact, I was under the impression that English is the official language
of India, due to the number of indigenous dialects.

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Craig Franck 11/20/97 12:00 AM

Alan E & Carmel J Brain <aeb...@dynamite.com.au> wrote:
>Kaz Kylheku wrote:
>
>> Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>> >Many thanks to the posters on this thread. Ada programmers often feel,
>> >if not persecuted, then uncomfortably isolated by the mainstream.
>>
>> That's downright silly.
>
>I agree. But true.

I think it depends on the persons basic personality. Some among us
feel that the "average" Ada programmer is a highly skilled software
engineer while the "average" C programmer is a bit more lacking.

There was a post in which it was stated the most Ada programmers had
the language definition handy while most C programmers did not, and
C programmers where more likely to confuse the compiler docs with the
standard.

It is this elitest mentality that may put some people off; however,
claming you are persecuted and shunned solely because of your choice
of programming language is pushing it.

[A girl told me recently "guys don't like me because I'm smart!" I
seriously doubt that was the reason (more like lack of discretion).]

--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant


English SUCKS, Chinese is the only language you need!! sys...@niuhep.physics.niu.edu 11/20/97 12:00 AM

Mark Wilden <Mark@mWilden.com> writes:

>Joseph Santaniello wrote:
 
>> 487 sounds about right if you figure the poulations for the areas you
>> mention are "about" as follows: US 270M, Canada 29M, UK 58M, 1/3 Europe
>> 150M, and half of Japan (optimistic) 70M, Australia 15M (?). Plus everybody
>> else in Asia who maybe speaks English still falls way below 999M for
>> Mandarin.

>Although you left out Africa, I don't really have a problem with the
>fact that more people speak Mandarin than English. What I can't fathom
>is that the vast majority of the world (over 4.5 billion people) speak
>_neither_.

Don't tell me you swallowed that bilge about the global village?!? ;-)

Why don't most Americans (will somebody please come up with an accurate
and easy to use word denoting citizens of the U.S.A.) learn more than
one language?  They don't need too!

Most Africans and South Americans and a very large chunk of Asians
have no use for either Mandarin or English.  They speak their
native language plus one other tribal language and/or perhaps the
national language if it differs from their native tongue.

Peace,
Robert
Mor...@physics.niu.edu
Real Women change tires                        abuse@uu.net postm...@uu.net
Real Men change diapers                 secu...@uu.net

Your english sucks, mine is better. sys...@niuhep.physics.niu.edu 11/20/97 12:00 AM

"John Rickard" writes:
>: after some of your comments, you're just plain begging for it.

>I was not begging for anything.

In response to your typo ridden post claiming that English was the
most used language, somebody jokingly suggests you learn English.
You responded with a post full of typos and poor usage proclaiming
that you didn't need to "RE learn" English...

Let me give you some free advice that you apparently need, don't walk
in the woods during deer season wearing brown with a white hanky hanging
out of your back pocket.

>If all you assholes were not so quick to think up a smart ass reply
>then we would not have this flaming problem.

If you weren't so quick to take offense...

Mor...@physics.niu.edu
Real Women change tires                        abuse@uu.net postm...@uu.net
Real Men change diapers                 secu...@uu.net

English SUCKS, Chinese is the only language you need!! Wei Jing Guo 11/20/97 12:00 AM

when we talk about Chinese language, we include Mandarin, Cantonese,
Fujianese, and some other hundred dialects...

there are defintely more people who speak Chinese, but it is also a fact
that English is spoken in more countries...i don't why this argument
should be posted in newsgroups about computer languages...  ;)


G Moore (was Re: Your english sucks, mine is better.) Kaz Kylheku 11/20/97 12:00 AM

In article <34747E...@no_spam.ip.edu.com>,
Joe C  <Joseph...@ccm.jf.intel.com> wrote:
>John Rickard wrote:
>>
>> : syntax in Usenet posts, but after some of your comments, you're

>> just plain
>> : begging for it.
>> I was not begging for anything.
>> If all you assholes were not so quick to think up a smart ass reply
>> then we would not have this flaming problem.
>
>Okay...how do we know this is not G. Moore under a non de plume?
>
>Joe Cipale

Once, upon a midnight dreary, while I pondered, weak and weary
Over many a quaint posting from computer.folklore
While I nodded, nearly napping, suddenly I heard a rapping,
As if my box were bootstrapping, paging code into its core!
`Tis some kernel bug, I muttered, or some ``C code'' from G. Moore.
    It is that---and nothing more.

Ah, distinctly I remember, it was in the bleak September
And each separate union member cast its type on the same store
Eagerly, I wished the morrow; vainly I had sought to borrow
From alt.humor cease of sorrow---sorrow for the lost G. Moore
For that dull, dark dilettante whom his parents named G. Moore
    Nameless here---for evermore!

(I only remember two stanzas from The Raven, otherwise I would keep going.
The next one is about some purple curtains rustling or something like that :)

Your english sucks, mine is better. Dennis Weldy 11/20/97 12:00 AM

Well said.
Y'know, when I first read the original post, I thought it quite amusing :-)
Lordy, I'd no idea that it'd be taken this far.....

Dennis

Rob Eamon wrote in message <652aes$63a$1...@news01.micron.net>...
>John Rickard wrote in message <6517kv$n...@bgtnsc03.worldnet.att.net>...


>>: syntax in Usenet posts, but after some of your comments, you're
>>just plain
>>: begging for it.
>>I was not begging for anything.
>>If all you assholes were not so quick to think up a smart ass reply
>>then we would not have this flaming problem.
>>
>
>Let's see if I understand the thread to this point:
>
>1) Someone points out that Ada and Pascal are worthless
>because hardly anyone knows those languages. Further,
>they state that C, C++ and Java are the only languages
>worth learning, inferring that more people 'speak' those
>languages.
>
>2) Someone else points out that more people speak
>Chinese than English. Thus, following the logic of the original
>point, we should consider English worthless.
>
>3) John Rickard refutes the claim in point 2.
>
>4) Davide Bionda jokingly says John 'should try to
>learn' English, gently ribbing John about his lack of sentence
>structure, poor spelling and poor grammar.
>
>5) John responds to point 4 by asking:
>
>'why should I waste my time RE learning a language I have
>understood and spoke since around 1-3 years of age?'
>
>Again, John uses poor grammar and poor spelling.
>
>6) Jean-Sebastien Payette uses poor spelling and poor
>grammar to claim English language skills that are superior
>to John's.
>
>7) John challenges Jean-Sebastien to a battle of wits and
>claims intellectual superiority by misspelling 'intelectual' (sic).
>John accuses Jean-Sebastien of speaking like a 12 year old.
>
>8) Barbs are traded between John and others about how
>John uses poor grammar and spelling.
>
>9) John becomes angry and abusive. John thinks he is
>being unfairly singled out and is being flamed.
>
>John, you should have let this drop back at step 4. Bionda
>was joking. You only hurt your case in claiming intellectual
>superiority by posting poorly structured messages and
>using profanity.
>
>In other words, shut the fuck up. Each time you open your
>mouth, you damage any credibility you might have had.
>
>
>
>

English SUCKS, Chinese is the only language you need!! Larry Elmore 11/20/97 12:00 AM

Boyd Roberts wrote in message <651fpg$ngu$2...@route1.mdrf.france3.fr>...

>In article <650e6p$ahv$1...@darla.visi.com>, se...@plethora.net (Peter
Seebach) writes:
>>
>>English has a wide variety of consonant clusters, and happily adopts
>>words from nearly any other language; this has been a great strength
>>for it.
>>
>That is hardly an argument.  If you try hard enough you can do it
>in any language.  Take French:
>
>   CD   == cédé
>   mail == mél


The key words being "If you try hard enough..." That's a _long_ ways from
happily adopting anything that comes along that makes sense! Isn't it France
that's fighting a losing campaign to preserve the "purity" of the French
language from the "pollution" of foreign words and phrases? Kind of ironic
considering French is essentially a bastardization of Latin with some other
stuff mixed in...

>Yes, they are serious.

That's what makes it all the more comical to the rest of us...

Larry

English SUCKS, Chinese is the only language you need!! Peter Seebach 11/20/97 12:00 AM

In article <3475921d....@nntp.ix.netcom.com>,

Michael Rubenstein <mik...@ix.netcom.com> wrote:
>On Wed, 19 Nov 1997 16:04:15 -0800, Mark Wilden <Mark@mWilden.com>
>>> According to the World Almanac there are almost twice as many speakers
>>> of Mandarin (999 million) as of English (487 million).

>It's from the 1997 Almanac (from Microsoft Bookshelf) and the figures
>are for mid 1996.

>These figures include non-native speaker.

I have a hard time believing this one.  Just about all of the U.S.,


most of Canada, all of the U.K., a third of Europe, and a large portion
of Asia, speak English, at least as a second language.

(The 'third of Europe' is from a recent article in The Economist.)

Furthermore, I have a very hard time buying the number given for Mandarin;
the Chinese I met living at a university *mostly* spoke Mandarin, but I'd
say no more than half of the people we met who weren't studens or teachers
did...

Also, you have to look at the rate of growth; English has become a very
popular technical and trade language, and (at least in the EU), younger
people are much more likely to have a second language, and more than
half of them learn English.

English has a wide variety of consonant clusters, and happily adopts
words from nearly any other language; this has been a great strength
for it.

If this gets any more off topic, I shall expect to be clobbered by the
Narn Bat Squad.

-s
--
se...@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

English SUCKS, Chinese is the only language you need!! Boyd Roberts 11/20/97 12:00 AM

In article <650je4$s5p$1...@helios.crest.nt.com>, k...@helios.crest.nt.com (Kaz Kylheku) writes:
>In article <64vpcn$n...@corn.cso.niu.edu>,
> <sys...@niuhep.physics.niu.edu> wrote:
>>k...@helios.crest.nt.com (Kaz Kylheku) writes:
>>>Touche. That could be a typo.
>>
>>Probably, but since this was a response to a criticism based on the typos
>>made by John you would think he would be a bit more carefull.
>
>Carefull? :) Is that a blunder or an instance of irony?

Blunder.  It's written touché.

--
Boyd Roberts <bo...@france3.fr>                        UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point à la ligne, voilà quoi -- Jacques

SPAT: fr...@ultramax.net

English SUCKS, Chinese is the only language you need!! Justin Ng 11/20/97 12:00 AM

In-Reply-To: <64vs87$1...@corn.cso.niu.edu>


On 19 Nov 1997 sys...@niuhep.physics.niu.edu wrote:

> Date: 19 NOV 1997 23:20:39 GMT
> From: sys...@niuhep.physics.niu.edu
> Newgroups: comp.lang.ada, comp.lang.c, comp.lang.c++,
>     comp.lang.java.advocacy, comp.lang.pascal.ansi-iso,
>     comp.lang.pascal.misc
> Subject: Re: English SUCKS, Chinese is the only language you need!!
>
> "John Rickard" wrote:
> >Davide Bionda <bio...@erdw.ethz.ch> wrote:


> >>"John Rickard" wrote:
>
> >why should I waste my time RE learning a language I have understood
> >and spoke since around 1-3 years of age?

You sound as if you're left with no choice? Well....bear in mind,
the world is always changing, it's either you change the environment to
suit your needs or you change your needs to suit the environment. Well,
of course, you alway have a choice, no one is forcing you, you can
remain as it is as well.

> >>>there are not more chinese speakers than english.
> >>>if you have not relized it but the english language it the most
> >>>widely used language as a standard. why? cause us americans want
> >>>it that way ;)

I know both chinese and english, I can communicate using both language,
(in a versatile way?), so I can have more friends than you do huh?

> ================================================================================
> "John Rickard" <saskan@spam.worldnet.spam.att.spam.net.spam>
> >J-S Payette wrote:
>
> >>I've never learn english and I talk better than you.
> >^^^^^^^^^^^^^^^^^^^^^^^^^And you should so you can learn proper
> >vocabulary skills.
>
> Given the construction of the above sentence/phrase I wouldn't
> be so quick to be critical of others' language abilities.
> At least you're capitalizing.

He who knows does not speak, he who speaks does not know.

> >>Now about Pascal and C let me tell you that in some case (strings and file
> >>manipulation, most object handling) Pascal is way better and I know both
> >>language (unlike you!!)
>
> >And how do you know what languages I know?
>
> I don't know about languages, but given the amount of formatting I
> had to do to make this message legible I would say you don't know
> much about newsreaders.
>
> >So if you want a fight about who knows more we can skip the whole
> >programming aspect and take this a intelectual level and have a
> >battle of the wits.  And I can promise you I will win.

He who is ruled by men lives in sorrow, he who rules men lives in confusion.
I chose not to be in either position instead.

No one is a sure winner. Who knows, there are so many people around the
whole world, it's just that you never get a chance to meet them, not that
they don't exist in this world.

You are just asking for a loser that's all, I believe there will be people
who are kind enough to entertain your needs.

> >-
> >Damn near any idiot can program.  But it takes a Genius to become
> >successful at it.
> >-
> >hardly, I can prove rather easily that I can speak my language better
> >than you. I mean I have only been speaking it since I have been able
> >to speak.
>
> Please go find a style book and look up continuity and making transitions.
>
> >As for talking better than me... Try reading you message and tell me
> >you don't talk like a 12 year old.
>
> Try rereading your messages and understand that:
> 1) you can't take a joke,
> 2) your intuitive grammer sucks
> 3) some people might think your emotional age matches Jean's skills
>         at his 2nd written/spoken language.

Hehe...just add to the list above,
  4) you need someone to entertain you simply by losing to you
  5) you just can't afford to lose
  6) you know you don't deserve respect from others

--
Justin Ng

English SUCKS, Chinese is the only language you need!! Jerry Sams 11/21/97 12:00 AM

JCore wrote in message <34710873...@news.linkonline.net>...
>On 17 Nov 1997 23:57:47 GMT, "John Rickard"


><saskan@worldnet.att.net.DONTSPAMME> wrote:
>
>>there are not more chinese speakers than english.
>>if you have not relized it but the english language it the most
>>widely used language as a standard. why? cause us americans want it
>>that way ;)
>
>Um, actually Chinese is the most widely spoken language in the world.

%^$&&*)&^%**(^&**@  (Chinese for "say whhaaaaaaatt?)

Jerry

English SUCKS, Chinese is the only language you need!! Jerry Sams 11/21/97 12:00 AM

Jean-Sebastien Payette wrote in message
<64suum$5oo$1...@weber.videotron.net>...
>
>John Rickard wrote in message <64sql2$k...@mtinsc04.worldnet.att.net>...


>>why should I waste my time RE learning a language I have understood
>>and spoke since around 1-3 years of age?
>
>
>I've never learn english and I talk better than you.
>Now about Pascal and C let me tell you that in some case (strings and file
>manipulation, most object handling) Pascal is way better and I know both
>language (unlike you!!)


That's "I've never 'learned' english."  It's called the past tense *perfect*
when you spell it right; otherwise just the past tense.

Jerry

G Moore (was Re: Your english sucks, mine is better.) Robert S. White 11/21/97 12:00 AM

In article <652hme$lsa$1...@helios.crest.nt.com>, k...@helios.crest.nt.com says...

  <snipped marvelous The Raven paraphrased in C & usenet arcania - Bravo!>
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Alan E & Carmel J Brain 11/21/97 12:00 AM

Craig Franck wrote:

> It is this elitest mentality that may put some people off; however,
> claming you are persecuted and shunned solely because of your choice
> of programming language is pushing it.

I didn't mean me personally.. people shun me because of bad breath, not
because I program in Ada. (I 'spose I better include a :-) for the
humour impaired ).

No, I meant things like:

> I know the STC is dropping Ada tracks, but I was unpleasantly
> surprised to receive a call from a track coordinator yesterday telling
> me that a proposed repeat of my Tri-Ada'97 panel titled "Software
> Engineering Plan Reviews -- Better or Worse for Ada than the Mandate?"
> was requested to shorten the title to just "Software Engineering Plan
> Reviews."
...
> Then I asked if all submissions with "Ada" in the title were getting
> similar requests.  The track coordinator thought so.

Also:
(after the decision by Mr Page to no longer mandate Ada for the DoD)
> I was in the
> >office of the CEO of one well-known DoD
> >contractor recently who said, "Get with it
> >Richard. Ada is dead, dead, dead."  His
> >company has pulled out of the Ada
> >marketplace entirely.

Also:

>One Academic institution (not mine, thank God!)has bowed to student >demand, and CS1 is now going to be taught using C++ instead of Ada as a >first language.

Little things like that.

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


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Robert Dewar 11/21/97 12:00 AM

<<>One Academic institution (not mine, thank God!)has bowed to student >demand, an
d CS1 is now going to be taught using C++ instead of Ada as a >first language.
>>

The funny thing about this is that the students, who think they are following
the latest fad, have *just* missed the boat, no doubt by mid-semester they
will be complaining that they are not being taught Java.

Actually of course, the whole idea of students telling professors what to
teach has its amusing side :-)


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Ole-Hjalmar Kristensen FOU.TD/DELAB 11/21/97 12:00 AM

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

Actually, they do, and have always done. If you don't get any
students, you'll soon get the message.


How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Jon S Anthony 11/21/97 12:00 AM

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

> Actually of course, the whole idea of students telling professors what to
> teach has its amusing side :-)

I have some words for it, but "amusing" isn't among them.

/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

English SUCKS, Chinese is the only language you need!! Dennis Weldy 11/21/97 12:00 AM

Well, I didn't see it. Of course, the whole thread has gotten prety darned
silly.
I mean, the original post was a JOKE. :-)

<shrug>
Dennis

John Rickard wrote in message <64vdko$8...@bgtnsc02.worldnet.att.net>...
>They assumed I was american BECAUSE I mentioned the fact I was in I
>beleive the 2nd post I made in my defense.
>--
>--
>Remove "spam" from my
>email address to send me REAL email.
>--
>
>Dennis Weldy <nojun...@ever.com> wrote in article
><32nusbR...@news2.ingr.com>...
>: Ok, jumping on the content of Chieh's post, if you'll note he
>merely ASSUMES
>: the idividual is American, when there are penty of other countries
>where the
>: original poster couldve learned English from 1-3 years of age.
>England,
>: Ireland, Canada, Australia,.... all sorts of places :)
>:
>: Dennis
>: Gary A. Wiltshire <70523...@compuserve.com> wrote in message
>: <3472e573...@news.albany.net>...
>: >chieh...@iname.com (Chieh Cheng) wrote:
>: >.....
>: >>For one thing, your grammer sucks. And learn to capitalize. Isn't
>: >>ironic when an American who learned English since he/she was
>born,
>: >>write English worse than people with other nationalities?
>: >.....
>: >I don't normally pick on people for their English errors,
>particularly
>: >someone who's learned it as a second language.  Since you've seen
>fit
>: >to do that, be advised that it is grammAr, not grammEr!  The
>second
>: >sentence above is (at least) stylistically dubious.  The third is
>: >plainly ungrammatical.  Let's lighten up a bit and criticize
>CONTENT
>: >of posts -- there is a lot of meat there.
>: >
>: >   --- Gary Wiltshire
>:
>:
>:

English SUCKS, Chinese is the only language you need!! Dennis Weldy 11/21/97 12:00 AM

Shmuel (Seymour J.) Metz wrote in message <3474B3...@gsg.eds.com>...
>Kaz Kylheku wrote:
>
>> >constructs are more arcane that assembler language.
>>
>> Which ones?
>
>Well, I was thinking of the use of * both for defining pointers and for
>dereferencing them.

I've always thought htat made sense: the declaraction matches use.
Or do you object to using [] for the declaration of arrays, and for indexing
into the array as well? ;-)

Dennis

English SUCKS, Chinese is the only language you need!! David Weller 11/21/97 12:00 AM

In article <01bcf5c2$c4dfe7c0$0200000a@kld_mcs>,
Mike Smith <kld_m...@earthlink.nospam.net> wrote:
>Kaz Kylheku <k...@helios.crest.nt.com> wrote in article
><650kf8$smt$1...@helios.crest.nt.com>...
>>
>or some
>> such thing.
>
>They're both acronyms, but I've seen them widely (couldn't help digging up
>that word again ;-) used without capitalization.  Sort of like scuba, which
>is an acronym, but is very often not capitalized.
>
>--Mike Smith

And the opposite of Ada, which should never be written in all caps,
but often is by those that don't understand it's a proper name, not an
acronym (at least whilst speaking of programming languages).
--
RIVA Technologies: Eschewing Obfuscation through Manipulexity and Whipitupitude
Visual Applications and Simulation.  Also specializing in migrating projects
from Ada83 (Rational/Verdix/SunAda) to Ada95 (GNAT-family).

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Kaz Kylheku 11/21/97 12:00 AM

In article <347675...@dynamite.com.au>,

Alan E & Carmel J Brain  <aeb...@dynamite.com.au> wrote:
>Also:
>
>>One Academic institution (not mine, thank God!)has bowed to student >demand, and CS1 is now going to be taught using C++ instead of Ada as a >first language.
>
>Little things like that.

I've heard variants on that theme; CS departments bowing to ``industry
pressure'' (rather than student demand) to start teaching C++ instead of, say,
Modula 2, C, or what have you. Which is crap, because teaching a certain
langauge in schools perpetuates the industry's use of that language. If some
city's university taught Ada, more of the local software shops would use it,
because they could recruit programmers willing and able to work in Ada.

I'd really like to see schools use languages like Ada or Eiffel to teach
introductory programming. In particular, Eiffel, with its organized support for
assertions. As far as teaching fundamentals goes, this feature is far more
important than fancy type mechanisms, OO and whatnot, because it harmonizes
with the the fundamentals of writing correct programs. Students should learn
to decompose programs into modules with not only well-defined interfaces in
terms of semantics and type compatibility, well-defined in terms of contracts
between the service user and the service provider. And, of course, data
structures have to be understood not only as passive entities, but as entities
having a state that is governed by invariants that must be preserved after
each operation.

G Moore (was Re: Your english sucks, mine is better.) Kevin Davis Sr. 11/21/97 12:00 AM

EXCELLENT!

Kevin

English SUCKS, Chinese is the only language you need!! Joseph Santaniello 11/22/97 12:00 AM

In article <34746A05.49AA@mWilden.com>, Mark Wilden <Mark@mWilden.com>
wrote:

>Joseph Santaniello wrote:
>>
>> 487 sounds about right if you figure the poulations for the areas you
>> mention are "about" as follows: US 270M, Canada 29M, UK 58M, 1/3 Europe
>> 150M, and half of Japan (optimistic) 70M, Australia 15M (?). Plus
everybody
>> else in Asia who maybe speaks English still falls way below 999M for
>> Mandarin.
>
>Although you left out Africa, I don't really have a problem with the
>fact that more people speak Mandarin than English. What I can't fathom
>is that the vast majority of the world (over 4.5 billion people) speak
>_neither_.

This got me a little interested, so I checked around a little:

The thing is, the world is a really big place.

Here's a list of countries with populations over 20 million
that have significant numbers of non-English and non-Chinese
speakers. This list leaves out almost 100 countries with populations
less than 20 million. The countries below account for a little over
3 billion people. China has 1.2 billion. The world has 5.7 billion.
This leaves 1.5 billion. If we figure the average size of the 100
countries which are less than 20 million to be 10 million, we get
another 1 billion non-English speakers. This leaves about 500 million
English speakers. Which seems about right for the US, Canada, UK,
Australia, South Africa, Nigeria, Malaysia, and of course, Belize.

I'm no statistician, just somebody who can't sleep ;-) I got all
this info from the CIA World fact book at:

http://www.odci.gov/cia/publications/pubs.html

Joe

Afghanistan        23M
Algeria        30M
Argentina 35M
Bangladesh 123M
Brazil 162M
Burma 46M
Columbia 37M
Egypt 64M
Ethiopia 57M
France 58M
Germany 84M
India 952M
Indonesia 206M
Iran 66M
Iraq 21M
Italy 57M
Japan 125M
North Korea 24M
South Korea 45M
Mexico 96M
Morocco 30M
Pakistan 129M
Peru 25M
Poland 39M
Romania 22M
Russia 148M
Spain 39M
Sudan 32M
Turkey 62M
Ukraine 51M
Uzbekistan 23M
Venezuela 22M
Vietnam 74M

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Robert Dewar 11/22/97 12:00 AM

<<Actually, they do, and have always done. If you don't get any
students, you'll soon get the message.>>

That's not my experience. In my classes, I teach what my experience says
is the right thing to teach, I very seldom find students have a good idea
of what they need to learn!

P.S. I do not find that I have no students :-) on the contrary, my classes
seem pretty popular, so I am not sure there is a correlation there at all!


English SUCKS, Chinese is the only language you need!! Ncp268 11/22/97 12:00 AM

In article <01bcf51b$abcea520$0200000a@kld_mcs>, "Mike Smith"
<kld_m...@earthlink.nospam.net> writes:

>Is that because "we" (yes I'm American as if that weren't obvious) want it
>that way?  Maybe.  But I think the UK deserves at least some of the
>credit/blame.  ;-)

We (the UK) have become a third rate global power. Please dont kick us when we
are down.

**************************************************************************
********************
Remember Nina Mackay!
How many more???
**************************************************************************
*********************

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Alan E & Carmel J Brain 11/23/97 12:00 AM

Kaz Kylheku wrote:

> I've heard variants on that theme; CS departments bowing to ``industry
> pressure'' (rather than student demand) to start teaching C++ instead of, say,
> Modula 2, C, or what have you.

Seen it all before. Fortunately, when I was an Undergrad in 1976, Sydney
University continued to teach in Pascal, and didn't bow to demand for
COBOL instead.

> I'd really like to see schools use languages like Ada or Eiffel to teach
> introductory programming. In particular, Eiffel, with its organized support for
> assertions.

I'd prefer Ada over Eiffel, but this is one case where the argument
really is religious, and a mere matter of opinion. I'd certainly be
happy with Eiffel as a first language. As opposed to, say, Visual C++
5.0, Visual C++ 4.3, CodeWarrior 10 C++, Turbo C++ 2.0 (all of which are
about as different from each other as Ada-83 is from Ada-95 ).

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

Your english sucks, mine is better. Andrew Koenig 11/23/97 12:00 AM

In article <64vl4h$3...@bgtnsc02.worldnet.att.net>,
John Rickard <saskan@spam.worldnet.spam.att.spam.net.spam> wrote:

> God you people act as if a message posted to a newsgroup has to be
> written like a fucking resume'!  You all need to grow the fuck up and
> get off my back about a few damn words.
> You act as if I was writing a formal letter to apply to microsoft or
> some shit.  
> THIS IS A NEWSGROUP NOT A RESUME!

Well yes and no.  If I were looking for another job, I would
expect any prospective employer to look in, say, DejaNews to
see what I has posted on Usenet in the past.
--
                                --Andrew Koenig
                                  a...@research.att.com
                                  http://www.research.att.com/info/ark

Your english sucks, mine is better. Spaceman Spiff! 11/23/97 12:00 AM

Andrew Koenig wrote:
>
> In article <64vl4h$3...@bgtnsc02.worldnet.att.net>,
> John Rickard <saskan@spam.worldnet.spam.att.spam.net.spam> wrote:
> [ Very polite swearing snipped ]

> > THIS IS A NEWSGROUP NOT A RESUME!
>
> Well yes and no.  If I were looking for another job, I would
> expect any prospective employer to look in, say, DejaNews to
> see what I has posted on Usenet in the past.
> --
>                                 --Andrew Koenig
>                                   a...@research.att.com
>                                   http://www.research.att.com/info/ark

I find that an extremely libel action.  The internet is
a very easy place to pretent your someone else, just by
altering your identity in your mailer or newsreader.
I could very easily pretend I'm not "Scotty"...


--
                                --Andrew Koenig
                                  a...@research.att.com
                                  http://www.research.att.com/info/ark
:-)

Your english sucks, mine is better. John Winters 11/23/97 12:00 AM

In article <652aes$63a$1...@news01.micron.net>,
Rob Eamon <rre...@idahopower.bitmosphere.com> wrote:
[snip]

>3) John Rickard refutes the claim in point 2.

I don't think he refuted it, he just denied it.

John

[Follow-ups set since this is off-topic in all the groups it is posted to]

--
John Winters.  Wallingford, Oxon, England.

Want to buy Linux CDs cheaply in the UK?  Join the Linux Buyers' Consortium.
See <http://www.polo.demon.co.uk/lbc.html>

Your english sucks, mine is better. Robert Dewar 11/23/97 12:00 AM

Andy Koenig says

<<Well yes and no.  If I were looking for another job, I would
expect any prospective employer to look in, say, DejaNews to
see what I has posted on Usenet in the past.>>

Absolutely, I think this is standard practice at this stage. I also do
a search of this kind for any student applying for a job or for admission.
You can often find out quite a lot about peoploe by seeing what they have
said in public!


Your english sucks, mine is better. Andrew Koenig 11/23/97 12:00 AM

In article <347855...@flash.net>,
Spaceman Spiff! <csw...@flash.net> wrote:

> I find that an extremely libel action.  The internet is
> a very easy place to pretent your someone else, just by
> altering your identity in your mailer or newsreader.
> I could very easily pretend I'm not "Scotty"...

Well, that may be.  But

        1. If someone's postings are mostly sensible, with a small fraction
           of unaccountable nonsense, it is easy to figure out that something
           odd is going on, and try to learn what it might be.

        2. If you're going to forge postings from me, you'll have to do
           a better job than you did.  It will take a couple of days for
           me to know for sure, but I'm willing to bet that DejaNews will
           not misattribute this particular forgery.


--
                                --Andrew Koenig
                                  a...@research.att.com
                                  http://www.research.att.com/info/ark

Your english sucks, mine is better. bi...@jk.pst.com 11/23/97 12:00 AM

In article <dewar.880302894@merv>, de...@merv.cs.nyu.edu says...No you can't.  You are in their control and not the other way around.  
You are a reactionary to things people post perhaps to get a particular
effect.  A lot of the posts in newsgroups are simply lies and marketing
tactics (lies again).  Not everyone feels that this medium requires
honesty, integrity, ethics etc.  The internet on one hand is a sesspool.

bill

Your english sucks, mine is better. Richard Kenner 11/23/97 12:00 AM

In article <MPG.ee2636b1...@news.idt.net> bi...@jk.pst.com writes:
>In article <dewar.880302894@merv>, de...@merv.cs.nyu.edu says...
>> Andy Koenig says
>>
>> <<If I were looking for another job, I would expect any prospective
>> employer to look in, say, DejaNews to see what I had posted on Usenet

>> in the past.>>
>>
>> Absolutely, I think this is standard practice at this stage.
>> You can often find out quite a lot about peoploe by seeing what they have
>> said in public!
>>
>Not everyone feels that this medium requires honesty, integrity, ethics etc.

Precisely.  That's exactly why such a search is useful.  I, for one,
would never hire somebody who thought that there was *any* medium or
forum that did not require honesty, integrity, and ethics.

Your english sucks, mine is better. bi...@jk.pst.com 11/23/97 12:00 AM

In article <65ab3u$v07$1...@news.nyu.edu>, ken...@lab.ultra.nyu.edu says...Well then you don't fall into the category of capitalist either because
being dishonest and unethical is at the core of capitalistic "success".  
But then you were referring to _other_ people weren't you.  Your
marketing people (and managers) will inherently be dishonest and
unethical by definition of the way things really work.  You're still a
pup.  Or many preach, few practice what they preach.

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Richard A. O'Keefe 11/24/97 12:00 AM

Craig Franck <clfr...@worldnet.att.net> writes:
>There was a post in which it was stated the most Ada programmers had
>the language definition handy while most C programmers did not, and
>C programmers where more likely to confuse the compiler docs with the
>standard.

May I point out the obvious reason why this is true?
Ada programmers keep the LRM handy because they *can*;
the Ada standard is available *free* over the net.
So is the superb Ada Qulity and Style Guidelines.
No version of the C standard is, has been, or foreseeably
will be.  I am one of several people who have argued in
comp.std.c that the C9x standard, or at least the public review
drafts, _should_ be available free.

I cannot imagine any good C++ programmer who wouldn't want to have
the current draft of the C++ standard handy, and that _is_ available
over the net.

>It is this elitest mentality that may put some people off;

What's "elitist" about using the freely available documents?
Is there any good programmer for _any_ language who wouldn't
gladly keep the relevant standards available if s/he could
afford them?  The HTML standard is freely available, so good
HTML authors use it.  That's not elitist, that's just sense.
--
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

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Richard A. O'Keefe 11/24/97 12:00 AM

de...@merv.cs.nyu.edu (Robert Dewar) writes:
>The funny thing about this is that the students, who think they are following
>the latest fad, have *just* missed the boat, no doubt by mid-semester they
>will be complaining that they are not being taught Java.

>Actually of course, the whole idea of students telling professors what to
>teach has its amusing side :-)

I just heard today about the .stop, .suspend, and .resume methods on threads
being "deprecated" in Java now.  Why people want a language where things
like this get sorted out a couple of _years AFTER_ people were told this was
the new fashionable thing instead of a language where things like this were
hammered out in hundreds of pages of studies _before_ people had to use them
is beyond me.

--
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

English SUCKS, Chinese is the only language you need!! Richard A. O'Keefe 11/24/97 12:00 AM

"Dennis Weldy" <nojun...@ever.com> writes:

>It is? Care to offer a bit of proof there?
>Standard Pascal was, last I looked woefully lacking in file handling.
>Strings were packed arrays of chars (much like C).

Then you didn't look at the current standard, ISO 10206, also known as
ISO Pascal Extended.

A programmer who knows only one programming language
is like a would-be author who has only read one book.

--
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

English SUCKS, Chinese is the only language you need!! Richard A. O'Keefe 11/24/97 12:00 AM

"Shmuel (Seymour J.) Metz" <nos...@gsg.eds.com> writes:
>Oh, no! Please don't start a LISP versus Prolog debate!

Any competent Lisp programmer knows there is _something_ of value in Prolog,
and what's more, knows where to find a free Lisp embedding of Prolog for
when it's useful.  Any competent Prolog programmer knows there is much of
value in Lisp, and will look to it for ideas.  (Some of the ideas in my
Craft of Prolog were stolen from a paper by Boyer & Moore on how to map
Fortran to pure Lisp for their theorem prover.)

--
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

English SUCKS, Chinese is the only language you need!! Richard A. O'Keefe 11/24/97 12:00 AM

"Mike Smith" <kld_m...@earthlink.nospam.net> writes:
>Define "widely".  There certainly are an awful lot of Chinese-speakers in
>the world.  But English is spoken in countries on every continent of the
>globe (except South America? - I mean national tongue, not that one or more
>people speak it).

Hm.  I've lived in four different Anglophone countries, and all of them
had plenty of Chinese people living there.  If you count countries where
the official language is the same, Spanish is probably more `widely'
spoken than English.  But why count countries rather than people?  And
how `official' does it have to be?  Election papers in this state are
distributed in about 10 languages.

>One hears English-language songs on
>European radio all the time, but one almost never hears
>non-English-language songs on American radio (I can't speak for
>Commonwealth nations).

Well, that says a lot about America, but very little about English.
My two favourite TV channels here are the ABC (Australian Broadcasting
Corporation) and the SBS (Special Broadcasting Services).  The SBS shows
a lot of foreign films on SBS (with subtitles, thankfully; the number of
non-English languages I understand _well_ could be counted on the fingers
of one knee).  The Deutsche-Welle news is regularly shown in several
languages (and very good it is too), and there are plenty of radio
broadcasts in other languages, notably including Chinese.

>but certainly English is more "widely" spoken than Chinese.

For _some_ definitions of "widely", yes.
And for _some_ definitions of "spoken".
For example, I read COBOL fairly well, but almost never write it.
Do I count as a "speaker" of COBOL or not?
Does a Panamanian who _can_ speak English but seldom has occasion to
count as an English speaker or not?
Do you count the speakers of Kriol in this country, or Tok Pijin in PNG,
as "English" speakers or not?

All of this matters in this thread only because of the programming analogues.
On the evidence I've seen, the number of _fluent_ C "speakers" is vanishingly
small.  And then there are all the retread C programmers calling themselves
C++ programmers, without using that fluently either.

Once upon a time, the majority of human beings used stone tools.
Where would we be now, if we let 'the majority' tell us what tools to use?


--
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

Your english sucks, mine is better. Richard A. O'Keefe 11/24/97 12:00 AM

a...@research.att.com (Andrew Koenig) writes:
>Well yes and no.  If I were looking for another job, I would
>expect any prospective employer to look in, say, DejaNews to
>see what I has posted on Usenet in the past.

In fact I _did_ apply for another job this year,
which I was awarded and am very pleased about.
I deliberately drew their attention to some of my postings,
and they promised to look at them.

Note too that there is a project to capture _everything_ on the web;
it has been done once before, it was being done recently, and it will
be done again in the future.  This is no longer a transient medium.


--
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

English SUCKS, Chinese is the only language you need!! Richard A. O'Keefe 11/24/97 12:00 AM

jw_r...@usa.net (J. W. Rider) writes:
>*Standard* pascal strings are constants only.

No.  Standard Pascal (ISO 10206) has a string data type,
without the pathetic limitation to 255 bytes of some antiques.

I wish people would find out what the current state of a language is
before they flame it.  It's not as though ISO Pascal Extended came out
yesterday.


--
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

How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!)) Alan E & Carmel J Brain 11/24/97 12:00 AM

Shmuel (Seymour J.) Metz wrote:
>
> Alan E & Carmel J Brain wrote:

> > It's issues like this that make me feel thankful that I'm restricted to
> > only programming in C or C++.

Should be a "not" in between I'm and restricted. Rather changes the
sense of things....
 
> The more languages you know, the better
> you understand the issues. With only C and C++, your experience is way
> to narrow to appreciate other languages.

Concur.

> Mind you, I don't expect that you will like all of the other languages,
> but each has something to teach you. Even (bletch) COBOL.

Concur. Even APL. C++ certainly!

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

Your english sucks, mine is better. Richard Kenner 11/24/97 12:00 AM

In article <MPG.ee29e258...@news.idt.net> bi...@jk.pst.com writes:
>Well then you don't fall into the category of capitalist either because
>being dishonest and unethical is at the core of capitalistic "success".  
>But then you were referring to _other_ people weren't you.  Your
>marketing people (and managers) will inherently be dishonest and
>unethical by definition of the way things really work.

I would not hire marketting people or manager who were dishonest
either.  I don't challenge your claim that some companies do, but I
would not.  I find your attitude that it's not possible to do business
without being dishonest and unethical very disturbing.  I've certainly never
been involved in such companies and never will knowingly be.

Your english sucks, mine is better. Andrew Koenig 11/24/97 12:00 AM

In article <MPG.ee2636b1...@news.idt.net>,  <bi...@jk.pst.com> wrote:

> No you can't.  You are in their control and not the other way around.  
> You are a reactionary to things people post perhaps to get a particular
> effect.  A lot of the posts in newsgroups are simply lies and marketing
> tactics (lies again).  Not everyone feels that this medium requires
> honesty, integrity, ethics etc.  The internet on one hand is a sesspool.

You're quite right -- writings will not prove someone's honesty by themselves.
It's like black-box software testing -- it can never prove the absence of bugs.

On the other hand, black-box software testing can often reveal the
presence of bugs, and reading what people have written can often
reveal that there would be no point even in interviewing them if they
were to come looking for a job.


--
                                --Andrew Koenig
                                  a...@research.att.com
                                  http://www.research.att.com/info/ark

Your english sucks, mine is better. Dennis Weldy 11/24/97 12:00 AM

That's incorrect. One can still be a capitalist, and still have ethics,
honesty, and integrity.
They aren't mutually exclusive.

Dennis

bi...@jk.pst.com wrote in message ...

Your english sucks, mine is better. Me 11/24/97 12:00 AM


bi...@jk.pst.com wrote:

> Well then you don't fall into the category of capitalist either because
> being dishonest and unethical is at the core of capitalistic "success".
> But then you were referring to _other_ people weren't you.  Your
> marketing people (and managers) will inherently be dishonest and
> unethical by definition of the way things really work.  You're still a
> pup.  Or many preach, few practice what they preach.

What are you, some sort of freaking communist?  Honesty and integrity are
fundamental for capatalistic success!  A company will not maintain a customer base
if it is not fundamentally honest.  Is Sun's little benchmark fiasco going to go
unnoticed or unconsidered by their customers?  If you develop a good solid product,
it is unnecessary to decieve customers into buying it.  There was a time that a
company could get away with deception and dishonesty (kind of like the current
President.)  but with the information that is available on just about anything, it
is very difficult for one to get away with it today.  If you want to see the
biggest example of lack of honesty and ethics, go back to the Soviet Union where
you belong!  Oh, sorry it's not there anymore.

Matt 'Capitalist Pig' Corey

(preparing flame-retardent capitalist-pig dark suit and red tie).

Your english sucks, mine is better. Mark Wilden 11/24/97 12:00 AM

Richard Kenner wrote:
>
> I would not hire marketting people or manager who were dishonest
> either.

I won't comment on managers, but the entire goal of marketers is to be
dishonest. They're trying to make people buy stuff they don't want. It's
that simple.

Your english sucks, mine is better. Mark Wilden 11/24/97 12:00 AM

Me wrote:
>
> A company will not maintain a customer base
> if it is not fundamentally honest.  Is Sun's little benchmark fiasco going to go
> unnoticed or unconsidered by their customers?

Is Sun going to go out of business as a result? Are they going to be
squeaky clean now that they've been found out? Did Ford go out of
business after the Pinto thing?

Give me a break. Neither companies not politicians have to be
"fundamentally honest."

Porting Experiences (was Ada and Pascal etc ) Ralph Silverman 11/24/97 12:00 AM

Shmuel (Seymour J.) Metz (nos...@gsg.eds.com) wrote:
: Craig Franck wrote:
:  
: > I meant the source code the programmer would produce using those
: > two tools. (I was a bit ambiguous with my phrasing.)

: Well, if that's what you meant, I've got decades of experiences in a lot
: of languages. The languages that have a good macro facility have an
: dvantage for applications where you need to supply complicated initial
: alues, since you can write a macro to automate the dirty work. Still
: mportant, but less so, is the generation of conditional code based on
: yntactical tests, e.g., number of arguments.

: > Why, were they doing that in the 19th century. :-)

: Hyerbole; sometimes I say "Before the fool, and I'm quite certain that
: old man Noach wasn't building computers with that gopher wood. ;-)

: > >If the only macro assembler that you know is MASM, then I question your
: > >competence to address the issue.
: >
: > I like MASM.

: It has its good points, but there are wide variations among assemblers,
: and unless you've seen a number of them then you have no basis to
: discuss
: assemblers in general, only the ones that you've seen.
:  
: > Then suggest a better macro assembler. Please, *do* enlighten.

: Well, the most widely available one is the IBM High Level Assembler
: don't blame me; I didn't pick the name.)
:  
: > >It's not so
: > >much that C and MASM is all you know, it's that you don't understand
: > >that not all assemblers are the same and that not all programs in the
: > >same language are the same.
: >
: > Every one of those points you just made is false.

: Perhaps, but your message certainly suggested that you have a very
: limited language background, and you haven't presented any reasons for
: me to believe that it's wrong.

: BTW, to answer a few last questions, I'm reading this on comp.lang.ada
: and I don't have access to any of my old source code or that of my
: colleagues. What's worse, there's stuff that I wouldn't be allowed to
: post even if I had access. Yeah, I know that I'm not the only one with
: that last problem :-( but I grew up in a culture of freely exchanging
: code and miss it.

: --

:                         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 spam...@library.lspace.org


        very good macro facility is found
        with
                eric isaacson 's
                a86 d86
        ( pc assembler,  debugger )
        shareware
        ^^^^^^^^^
        ( widely available ... )
        ...

--

Ralph Silverman
z007...@bcfreenet.seflin.lib.fl.us


Your english sucks, mine is better. Matt Corey 11/24/97 12:00 AM


Me wrote:

> What are you, some sort of freaking communist?  Honesty and integrity are
> fundamental for capatalistic success!  A company will not maintain a customer base
> if it is not fundamentally honest.  Is Sun's little benchmark fiasco going to go
> unnoticed or unconsidered by their customers?  If you develop a good solid product,
> it is unnecessary to decieve customers into buying it.  There was a time that a
> company could get away with deception and dishonesty (kind of like the current
> President.)  but with the information that is available on just about anything, it
> is very difficult for one to get away with it today.  If you want to see the
> biggest example of lack of honesty and ethics, go back to the Soviet Union where
> you belong!  Oh, sorry it's not there anymore.
>
> Matt 'Capitalist Pig' Corey
>
> (preparing flame-retardent capitalist-pig dark suit and red tie).

  Just so no-one assumes that I am hiding behind a fake email address, i have changed
it back to what it is.

Matt 'Capitalist Pig' Corey


Your english sucks, mine is better. Peter Seebach 11/24/97 12:00 AM

In article <MPG.ee2636b1...@news.idt.net>,  <bi...@jk.pst.com> wrote:
>No you can't.  You are in their control and not the other way around.  
>You are a reactionary to things people post perhaps to get a particular
>effect.  A lot of the posts in newsgroups are simply lies and marketing
>tactics (lies again).  Not everyone feels that this medium requires
>honesty, integrity, ethics etc.  The internet on one hand is a sesspool.

While this may be true, I doubt anyone doing a comprehensive search of
what I've posted would have any trouble guessing whether or not I know
C.  :)

Similarly, if you looked at a bunch of Nutts postings, I doubt you'd
take him very seriously.

It's not authoritative; it's a good first approximation.

-s
--
se...@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

Your english sucks, mine is better. Peter Seebach 11/24/97 12:00 AM

In article <MPG.ee29e258...@news.idt.net>,  <bi...@jk.pst.com> wrote:
>Well then you don't fall into the category of capitalist either because
>being dishonest and unethical is at the core of capitalistic "success".  

Not intrinsically.  It is a good short-term strategy; it is a pathetic
long-term strategy.

Cheating doesn't scale well.

>Or many preach, few practice what they preach.

What a popular excuse that is!

-s
--
se...@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

Your english sucks, mine is better. Timo Salmi 11/24/97 12:00 AM

/english/:=:j

-From: ftp://garbo.uwasa.fi/pc/pd2/tspost17.zip information file
-Subject: Re: A kill file example

[Q: How to avoid on the Usent news hostile or boring posters,
incessant bickering and net abuse.]

Consider using KILL files. Here is information that just might be of
some interest.

--------------- clip clip clipety clip clip clip ----------------
# This is an example rn kill file ~/News/rec/humor/KILL
# By prof. Timo Salmi, Mon 3-Jun-96
#
# It discards unread all postings from me in news:rec.humor
# Easy to adapt to other newsgroups or other posters!
#
# ts@ is the first part of my email address.
# The modifier h means look through the headers of the articles.
# The command j means junk.
# The command = shows the subjects of the messages being discarded.
# The : is a command separator.
#
/^From: ts@/h:=:j
#
# Or to make it more specific
# /^From: ts@uwasa.fi/h:=:j
#
# Let's not stop here, but also discard all articles that have any
# reference to me anywhere in the message. Of course this might lead
# to an overkill (eg Timothy would be a trigger). A better choice
# of keys might be necessary / useful in actual practice.
#
/timo/a:=:j
/salmi/a:=:j
#
# After you have seen that your customization works, you might wish
# to leave out the subject lister := like this
# /salmi/a:j
#
# A tip adapted from the news:news.admin.net-abuse.misc FAQ
# If you wish to kill excessively crossposted articles, use e.g.
# /^Newsgroups: .*,.*,.*,.*,.*,.*,.*,/h:=:j
# This marks as killed articles crossposted to more than 7 newsgroups.
#
# For more information on kill files plese see e.g.
#  7280 Oct 21 1995 ftp://garbo.uwasa.fi/pc/doc-net/killfile.zip
#  killfile.zip rn newsreader KILL file FAQ from Leanne Phillips
#
---------------------- clip clip clip -----------------------------


Another useful system to know against abuse are the email filters.
They enable you to sort the incoming email and to avoid email you
don't want to have. If you are an elm user, try
  man filter
and
  which filter
to ascertain whether your system has a filter program.  If it does,
put a line like this into your ~/.forward file
  "| /usr/local/bin/filter -o ${HOME}/.elm/filter.errors"

Then create a ~/.elm/filter-rules file. If you wish to avoid, say,
my email, put the following line into it
  if (from = "t...@uwasa.fi") then delete
or more benevolently
  if (from = "listserv@") then save /your/full/path/MailFromListserv

Note that you should not put empty lines into the said files, but
you can make it more readable since comments are allowed. It you put
# (the hash) as the first character on the row, it will be deemed a
comment.

I am frequently asked by the similarly spam-targeted fellow users
about my spam foiling password method (on Unix). Since I cannot
answer these questions individually, I have made the information
available via WWW. You'll find it through my home page (see my
signature) by clicking the "no-spam" thumbnail image.

   All the best, Timo

....................................................................
Prof. Timo Salmi   Co-moderator of news:comp.archives.msdos.announce
Moderating at ftp:// & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance  ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/>  ; FIN-65101,  Finland

Spam foiling in effect.  My email filter autoresponder will return a
required email password to users not yet in the privileges database.

Your english sucks, mine is better. bi...@jk.pst.com 11/24/97 12:00 AM

In article <65bo2c$d9l$1...@news.nyu.edu>, ken...@lab.ultra.nyu.edu says...I've never worked for a company that was otherwise!  It's just human
nature I guess.  Someone in the fold will always be playing politics
trying to get the better of someone.  No matter how slight the instance,
it is ALWAYS there somewhere (the repository for the ill behaviour seems
to be middle management who may indeed be chartered with the task of
oppressing of personnel).  Usually where there is conflict, there is
reason for it.  Companies go to great lengths to look like they on the
right side even if they are not.  I'm not just referring to interactions
with customers, as it is more predominant in the company's dealings with
its employees that put them in the realm of the dishonest and unethical.

As for sales people: that false bonding they do to get business is
dishonest at best.  It's plastic people interacting and that leads to
major conflicts in society as a whole.  The way to prevent the large
social problems from happening is to prevent the small ones from
occuring.  Unfortunately, the "problem" is actually a vehicle and an
asset to many.

billg

Your english sucks, mine is better. bi...@jk.pst.com 11/24/97 12:00 AM

In article <EK5KM...@research.att.com>, a...@research.att.com says...That's my edge in hiring good people and getting them to enjoy their
stay.  I don't rely on external sources to determine the value of a
person.  I give them the option to move on from the past (instead of
requiring them to suppress their personalities).  You've already defined
the "us vs. them" mentality.  Your starting point is one of distrust and
therefore you have already limited the potential relationship severly.  
This is very fragile ground.  If you are not a believer in people, then
get ready for union negotiating because that is the outcome of
communication breakdown.

The minute you do that (question someone's integrity), you no longer have
a trusting relationship.  Actually, I find that most people with "a past"
usually have a reason for it that was beyond their control.  And yes that
reason may be misunderstanding of their needs and modes of operation (not
"playing the game" is supposedly a big black mark for some).  Many times
it is failure to follow false-leadership (the management game).  Show me
a "difficult" employee and I'll show you someone with capabilities beyond
the average and probably higher ethical standards--not to say these
people won't be tough on you when you break the unwritten rules.  You
just have to understand them.  Show me the non-game players, I want to
work with them!  10% of the pop.?  2%?  hmmm...

I understand that most will not be able to recognize people as they
really are and their potential value in their lifetimes though.  It is
indeed a gift!  Yes, if you want game-players and oppressors and people
who unethically manipulate, look for a history of rising through the
ranks of political (most large) companies.  To find the leaders, look for
those who didn't.  Oops!  I gave away a trade secret!

None of this or any other post was directed toward any particular person
or poster.  Certainly your leadership in your trade is unquestionable and
hopefully you will stay out of the politics as we (the productive side of
us) need non-political elements to learn from!

billg

Your english sucks, mine is better. bi...@jk.pst.com 11/24/97 12:00 AM

In article <lVNyJnO#8GA...@news2.ingr.com>, nojun...@ever.com says...

> That's incorrect. One can still be a capitalist, and still have ethics,
> honesty, and integrity.
> They aren't mutually exclusive.
>
> Dennis

In practice though, you'd be hard pressed to use a corporation (or
capitalist) as an example of any of those things.  Those that try to
practice those characteristics don't do as well and are regarded as "not
a good fit" for business.  They just don't worship money enough to do the
things that accumulate it (money, power) the best.  Ever heard this: "you
don't want to be a manager--you have values!"?.  

billg

Your english sucks, mine is better. bi...@jk.pst.com 11/24/97 12:00 AM

In article <3479B760.282B@mWilden.com>, Mark@mWilden.com says...Thank god someone else is able to see reality.

billg

Your english sucks, mine is better. Rob Eamon 11/24/97 12:00 AM

bi...@jk.pst.com wrote in message ...

Yowza! I don't think you'll get an agreement on this from a group
that tends to see things as 0's and 1's, black and white, right
and wrong. Shades of gray are hard to justify to the engineering
mindset.


Your english sucks, mine is better. Rob Eamon 11/24/97 12:00 AM

Me wrote in message <3479B4F1.D575BEFC@SomewhereElse.com>...
>
>
>bi...@jk.pst.com wrote:
>
[snip]

>
>What are you, some sort of freaking communist?  Honesty and integrity are
>fundamental for capatalistic success!

Actually, pure communism relies on honesty and integrity as well. The
problems with communism have usually arisen from a central power
that wields absolute power and authority. Hmmm. Sounds somewhat
like someone's federal government....  <g>

[Now, back to exploring Java instead of debating the characteristics
of various economic principles..]

Your english sucks, mine is better. bi...@jk.pst.com 11/24/97 12:00 AM

In article <65ctht$jbt$1...@news01.micron.net>,
rre...@idahopower.bitmosphere.com says...And hence, they get abused by those who "capitalize" via manipulation
within the grey area!  You're right.  That is key too.  Society needs a
turn around.  That "grey area" is where business (capitalism) mostly
resides.  It needs to move to the realm where there is "no question"
until the grey becomes a darker color.  Those already entrenched in the
ways aren't gonna like it though as it means a shift in the wealth.  (And
they have guns!).

billg

Your english sucks, mine is better. Matthew S. Whiting 11/24/97 12:00 AM

And simply wrong.  Marketers try to get people to want in the future
things they don't want today.  SALES people try to get people to buy
stuff they don't want.  There IS a difference.  FYI - I'm neither a
marketer nor a salesperson, just a lowly engineering manager.

Your english sucks, mine is better. Kaz Kylheku 11/24/97 12:00 AM

In article <65ctht$jbt$1...@news01.micron.net>,

Rob Eamon <rre...@idahopower.bitmosphere.com> wrote:
>Yowza! I don't think you'll get an agreement on this from a group
>that tends to see things as 0's and 1's, black and white, right
>and wrong. Shades of gray are hard to justify to the engineering
>mindset.

As long as you are willing to talk about a power of two number of gray
shades (such as 16, 32 or 64) you should be OK.

Your english sucks, mine is better. Larry Elmore 11/24/97 12:00 AM

bi...@jk.pst.com wrote in message ...
>In article <65ab3u$v07$1...@news.nyu.edu>, ken...@lab.ultra.nyu.edu says...
>> In article <MPG.ee2636b1...@news.idt.net> bi...@jk.pst.com
writes:
>> >In article <dewar.880302894@merv>, de...@merv.cs.nyu.edu says...
>> >> Andy Koenig says
>> >>
>> >> <<If I were looking for another job, I would expect any prospective
>> >> employer to look in, say, DejaNews to see what I had posted on Usenet
>> >> in the past.>>
>> >>
>> >> Absolutely, I think this is standard practice at this stage.
>> >> You can often find out quite a lot about peoploe by seeing what they
have
>> >> said in public!
>> >>
>> >Not everyone feels that this medium requires honesty, integrity, ethics
etc.
>>
>> Precisely.  That's exactly why such a search is useful.  I, for one,
>> would never hire somebody who thought that there was *any* medium or
>> forum that did not require honesty, integrity, and ethics.
>>
>Well then you don't fall into the category of capitalist either because
>being dishonest and unethical is at the core of capitalistic "success".
>But then you were referring to _other_ people weren't you.  Your
>marketing people (and managers) will inherently be dishonest and
>unethical by definition of the way things really work.  You're still a
>pup.  Or many preach, few practice what they preach.

This is a disturbing world-view, to say the least. It also goes against most
of my experiences with people and businesses, at least in America. I've had
personal experience with chronic lying and corruption in one of the Far
Eastern nations (_not_ Japan or one of the Little Dragons), and IMHO, it's
one of the most severe problems that keeps that nation mired in poverty. Who
wants to do business with liars and cheats? The same applies everywhere
else. A relatively high degree of personal honesty and integrity among the
general population is necessary for a healthy business climate. A company's
reputation is probably one of its most prized assets. If you get a
reputation for screwing over over customers and partners, not many are going
to deal with you and you'll likely go under.

I have to wonder if billg has read much of what life is/was like in the
various socialist "workers paradises" that either collapsed economically or
are desperately trying to convert to capitalism without the ruling class
giving up any real political power (an impossible task).

Larry

Your english sucks, mine is better. Larry Elmore 11/24/97 12:00 AM

bi...@jk.pst.com wrote in message ...
>In article <65bo2c$d9l$1...@news.nyu.edu>, ken...@lab.ultra.nyu.edu says...
>> In article <MPG.ee29e258...@news.idt.net> bi...@jk.pst.com
writes:
>> >Well then you don't fall into the category of capitalist either because
>> >being dishonest and unethical is at the core of capitalistic "success".
>> >But then you were referring to _other_ people weren't you.  Your
>> >marketing people (and managers) will inherently be dishonest and
>> >unethical by definition of the way things really work.
>>
>> I would not hire marketting people or manager who were dishonest
>> either.  I don't challenge your claim that some companies do, but I
>> would not.  I find your attitude that it's not possible to do business
>> without being dishonest and unethical very disturbing.  I've certainly
never
>> been involved in such companies and never will knowingly be.
>>
>I've never worked for a company that was otherwise!  It's just human
>nature I guess.  Someone in the fold will always be playing politics
>trying to get the better of someone.  No matter how slight the instance,
>it is ALWAYS there somewhere (the repository for the ill behaviour seems
>to be middle management who may indeed be chartered with the task of
>oppressing of personnel).  Usually where there is conflict, there is
>reason for it.  Companies go to great lengths to look like they on the
>right side even if they are not.  I'm not just referring to interactions
>with customers, as it is more predominant in the company's dealings with
>its employees that put them in the realm of the dishonest and unethical.


There's definitely something to this, however, I fail to see a causal
relationship with capitalism. This is merely describing very common human
behavior at any point and place in time one chooses to look at. Competition
is a basic fact of life -- for _all_ life, from viruses on up. I recently
saw a good show on the social life and dynamics of a pack of wolves, and
there's several on chimps. I didn't see anything much different there, and
you can't blame capitalism for chimpanzee deceit and jockeying for power and
position... Such behavior existed among humans since our earliest ancestors
(that could be called human), long before capitalism was around, and if
capitalism dies out (and it's certainly under heavy assault), those
behaviors will still be here.

These are behaviors that may work in the short run quite well, but not in
the long run. Impeccable honor and integrity are not absolutely required,
but a relatively high degree of it certainly is if one intends to run a
legitimate, long-term business.


There's a lot of stupid people out there, too, that can't see past the
short-term gain. In the long-run, they're hurting themselves and their
company. I've been at companies where they screwed the employees over, and
any of us that were any good would leave as soon as we found out what the
score was, and found another place to go to.
That's the really good thing about capitalism -- the companies either
changed their ways or went out of business (or are limping along on the
verge of going out of business) because their products are shoddy, and their
productivity low because most of their workforce is crap. Government
operations can go on for decades just like that, though, and the more
inefficient they get, the larger they get to try to compensate. Just look at
the state-run operations in just about any communist/socialist country of
today or the recent past...

Larry

>As for sales people: that false bonding they do to get business is
>dishonest at best.  It's plastic people interacting and that leads to
>major conflicts in society as a whole.  The way to prevent the large
>social problems from happening is to prevent the small ones from
>occuring.  Unfortunately, the "problem" is actually a vehicle and an
>asset to many.
>
>billg

Your english sucks, mine is better. Lawrence Kirby 11/24/97 12:00 AM

In article <65ckg3$9b7$3...@darla.visi.com>
           se...@plethora.net "Peter Seebach" writes:

>In article <MPG.ee2636b1...@news.idt.net>,  <bi...@jk.pst.com> wrote:
>>No you can't.  You are in their control and not the other way around.  
>>You are a reactionary to things people post perhaps to get a particular
>>effect.  A lot of the posts in newsgroups are simply lies and marketing
>>tactics (lies again).  Not everyone feels that this medium requires
>>honesty, integrity, ethics etc.  The internet on one hand is a sesspool.
>
>While this may be true, I doubt anyone doing a comprehensive search of
>what I've posted would have any trouble guessing whether or not I know
>C.  :)

If they were in any doubt you can always point them at the IAQ! :-)

--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------


Your english sucks, mine is better. bi...@jk.pst.com 11/24/97 12:00 AM

In article <65d7i8$j...@netra.montana.edu>, ljel...@montana.campus.mci.net
says...

>
> There's definitely something to this, however, I fail to see a causal
> relationship with capitalism. This is merely describing very common human
> behavior at any point and place in time one chooses to look at. Competition
> is a basic fact of life -- for _all_ life, from viruses on up. I recently
> saw a good show on the social life and dynamics of a pack of wolves, and
> there's several on chimps. I didn't see anything much different there, and
> you can't blame capitalism for chimpanzee deceit and jockeying for power and
> position... Such behavior existed among humans since our earliest ancestors
> (that could be called human), long before capitalism was around, and if
> capitalism dies out (and it's certainly under heavy assault), those
> behaviors will still be here.

Human nature is one thing, but to condone the ugly parts of it and to
even promote it (and capitalize because of it), given that we are now
"civilized" and "able to think and reason", is another.  Unbridled
capitalism is the petri dish for those oppressing and repressing crimes
against humanity not to mention blatant stealing.

>
> These are behaviors that may work in the short run quite well, but not in
> the long run. Impeccable honor and integrity are not absolutely required,
> but a relatively high degree of it certainly is if one intends to run a
> legitimate, long-term business.

> That's the really good thing about capitalism -- the companies either


> changed their ways or went out of business (or are limping along on the
> verge of going out of business) because their products are shoddy, and their
> productivity low because most of their workforce is crap.

That's not true most of the time as evidenced by the company's that win
via marketing as opposed to quality.  Case in point: MS.  They're
continually trying to stifle the little guy and lock their (unknowning)
customers into their products.  (aside: Sun has learned from MS's bad
example, so has Borland, to market deceptively and use technology as a
weapon of submission (dependency)).  Their philosophy is written all over
their products if you know how to read them.  Unfortunately, "there's one
born every minute".  Their ethics as a corporation are questionable at
BEST.  They are first on my list as forfeiture candidates.

billg

Your english sucks, mine is better. bi...@jk.pst.com 11/24/97 12:00 AM

In article <347a2ca1...@news.frontiernet.net>,
mich...@frontiernet.net says...

> Reality Check!
> What does this have to do with Pascal?

It's a _C++_ group so expect that things will be a bit "abstract". <G>

billg

Your english sucks, mine is better. Larry Elmore 11/24/97 12:00 AM

bi...@jk.pst.com wrote in message ...

>Human nature is one thing, but to condone the ugly parts of it and to


>even promote it (and capitalize because of it), given that we are now
>"civilized" and "able to think and reason", is another.  Unbridled
>capitalism is the petri dish for those oppressing and repressing crimes
>against humanity not to mention blatant stealing.


I must disagree here. Capitalism certainly doesn't condone any of that, let
alone encourage it. That sounds a whole lot more like the origins of most
European nobility (centuries before capitalism), not to mention the general
workings of the Roman Empire, among others. Capitalism has _reduced_ such
crimes to the degree that it has been implemented (which is not even close
to completely, anywhere in the world). It was capitalism that ended slavery,
not communism (just another form of slavery, else why border defenses to
keep the population from voting with their feet?).

>> These are behaviors that may work in the short run quite well, but not in
>> the long run. Impeccable honor and integrity are not absolutely required,
>> but a relatively high degree of it certainly is if one intends to run a
>> legitimate, long-term business.
>
>> T