Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Stevens]

On Tue, 11 Nov 1997 11:42:42 -0800, Dr E. Buxbaum <EB15@le.ac.uk> wrote:
>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.

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.

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

[John Black]

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.

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[John Bode]

In article <34557f2b.1934172@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.

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

[vonhend]

In <jfbode-ya023380002810972146390001@news.earthlink.net>, jfbode@nospam.mail.earthlink.net (John Bode) writes:
>In article <34557f2b.1934172@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

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

[Adam Beneschan]

nospam@nospam (John Black) writes:
 
 >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.

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)

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

[Shmuel (Seymour J.) Metz]

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

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[Steve Ropa]

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

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

[Charles R. Lyttle]

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

Steve Ropa wrote:

> 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

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 : lyttlec@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 : lyttlec@mail.flash.net</PRE>
&nbsp;</HTML>

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

Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Robert S. White]

In article <Pine.SUN.3.96.971028125423.20605D-100000@flatland.dimensional.com>, 
theropas@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

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Steve Ropa]

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

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Bob Horvath]

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.

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Bob Horvath]

David A. Frantz wrote:

> Bob Horvath wrote in message <345881C4.640998A4@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?

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[David A. Frantz]

Bob Horvath wrote in message <345946D5.CF3E77FB@horvath.com>...
>
>
>David A. Frantz wrote:
>
>> Bob Horvath wrote in message <345881C4.640998A4@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

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Steve Ropa]

On Thu, 30 Oct 1997, Bob Horvath wrote:

> 
> 
> David A. Frantz wrote:
> 
> > Bob Horvath wrote in message <345881C4.640998A4@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

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Kenneth W. Sodemann]

Bob Horvath wrote in message <345946D5.CF3E77FB@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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Steve Ropa]

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.

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Larry Kilgallen]

In article <345881C4.640998A4@horvath.com>, Bob Horvath <bob@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

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Kaz Kylheku]

In article <1997Oct30.094442.1@eisner>,
Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
>In article <345881C4.640998A4@horvath.com>, Bob Horvath <bob@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

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Charles Hixson]

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 charleshixson@earthling.net
(510) 464-7733 or chixso@mtc.dst.ca.us

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Derek A Benner]

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

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Robert S. White]

In article <345881C4.640998A4@horvath.com>, bob@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

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Steve Ropa]

On 31 Oct 1997, Robert S. White wrote:

> In article <345881C4.640998A4@horvath.com>, bob@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!  :-)

Re: Current Ada strengths - was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Shmuel (Seymour J.) Metz]

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

Re: ADA work, C/C++/JAVA crashes!!!!

[Shmuel (Seymour J.) Metz]

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

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

[Kenneth W. Sodemann]

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[Kenneth W. Sodemann]

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[tbb03ar]

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

> John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
> forth...
> >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.
> 
> 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).  

Why? I'm using ObjectADA for Windows, and I feel quite good with it.

> 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 => kwsodema@avistainc.com
>     Web => http://www.pcii.net/~stuffel
>     Company_Web => http://www.avistainc.com);
> 
> 
> 
> 
> 

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

[Shayne Flint]

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        shayne@ainslie-software.com 
-- Ainslie Software Pty Limited    http://www.ainslie-software.com
--
--      ShapeDB, a database and form drawing add-on for Visio
------------------------------------------------------------------

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

[Dennis Weldy]

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 <3455D9B2.38F0@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        shayne@ainslie-software.com
>-- Ainslie Software Pty Limited    http://www.ainslie-software.com
>--
>--      ShapeDB, a database and form drawing add-on for Visio
>------------------------------------------------------------------

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

[Alan E & Carmel J Brain]

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

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

[CodeRed]

Alan E & Carmel J Brain wrote in message <34581F0D.533B@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 grivell@erols.com

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

[Alan Brain]

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.
aebrain@dynamite.com.au abrain@cs.adfa.oz.au

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

[John Black]

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.

ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Black]

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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[David A. Frantz]

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.1413708@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,
>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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Shombe Kroll]

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.1413708@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,

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Black]

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.

"Shombe Kroll" <Shombe@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.  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),

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Olof Oberg]

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

-- 
#############################################################
# millNO@SPAMludd.luth.se # http://pedgr571.sn.umu.se/~mill #
#############################################################

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Mike Copeland]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Nat Pryce]

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:  np2@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      |
+------------------------------------------+---------------------+

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Bode]

In article <636m6l$55t@bgtnsc01.worldnet.att.net>, "Shombe Kroll"
<Shombe@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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <jfbode-ya023380002910972057140001@news.earthlink.net>,
John Bode <jfbode@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Gary A. Wiltshire]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Richard A. O'Keefe]

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


"Shombe Kroll" <Shombe@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Black]

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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Mike Copeland]

   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.

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <MPG.ec1256665b68f1b98979d@news.primenet.com>,
Mike Copeland <mrcope@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

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[Shmuel (Seymour J.) Metz]

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

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[John Stevens]

On Thu, 30 Oct 1997, Shmuel (Seymour J.) Metz <nospam@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.

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[Samuel Tardieu]

>>>>> "John" == John Stevens <jstevens@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 -- sam@ada.eu.org

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[John Stevens]

On 06 Nov 1997 20:48:26 +0100, Samuel Tardieu <sam@ada.eu.org> wrote:
>>>>>> "John" == John Stevens <jstevens@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.

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[David Weller]

#define TROLLBAIT(Newsgroups trimmed because I hate Pascal and Java is a fad.)

In article <slrn664qpv.jh7.jstevens@samoyed.ftc.nrcs.usda.gov>,
John Stevens <jstevens@samoyed.ftc.nrcs.usda.gov> wrote:
>On 06 Nov 1997 20:48:26 +0100, Samuel Tardieu <sam@ada.eu.org> wrote:
>>>>>>> "John" == John Stevens <jstevens@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.

 

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[Charles R. Lyttle]

John Stevens wrote:

> On 06 Nov 1997 20:48:26 +0100, Samuel Tardieu <sam@ada.eu.org> wrote:
> >>>>>> "John" == John Stevens <jstevens@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 : lyttlec@mail.flash.net

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[John Stevens]

On Thu, 06 Nov 1997 21:18:55 -0600, Charles R. Lyttle <lyttlec@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.

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[Charles R. Lyttle]

John Stevens wrote:

> On Thu, 06 Nov 1997 21:18:55 -0600, Charles R. Lyttle <lyttlec@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 : lyttlec@mail.flash.net

Re: ADA and Pascal work, C,C++, and Java are the only lheadaches you need!!

[Mark Wilden]

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?". :)

Re: ADA ,Pascal, and Basic ROCK! C,C++, and Java are nothing you need!!

[John Rickard]

-- 
--
Remove .DONTSPAMME from my
email address to send me REAL email.
--

John Stevens <jstevens@samoyed.ftc.nrcs.usda.gov> wrote in article
<slrn667938.2ng.jstevens@samoyed.ftc.nrcs.usda.gov>...
: On Thu, 06 Nov 1997 21:18:55 -0600, Charles R. Lyttle
<lyttlec@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.
: 

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

[John Gluth]

In article <MPG.ec1256665b68f1b98979d@news.primenet.com> Mike Copeland,
mrcope@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...

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

[Bernard J. Girardot]

John Gluth wrote:
> 
> In article <MPG.ec1256665b68f1b98979d@news.primenet.com> Mike Copeland,
> mrcope@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!)

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

[Michael Stark]

John Gluth wrote:
> 
> In article <MPG.ec1256665b68f1b98979d@news.primenet.com> Mike Copeland,
> mrcope@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: mstark@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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[W. Wesley Groleau x4923]

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Al Christians]

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Jerry Sams]

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[John Rickard]

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?

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Jerry Sams]

In article <63d4d6$hfa@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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Shmuel (Seymour J.) Metz]

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Jerry Sams]

In article <345A37F1.29EA@gsg.eds.com>, nospam@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

Re: Yet another stupid language war (was: ... the only langu

[Jerry van Dijk]

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 | jdijk@acm.org

Re: Yet another stupid language war (was: ... the only languages you need!!)

[baddog]

I fully agree.  I feel that if the imbiciles need to fight over what
language is better, they need to find a place and time of their own to do
so.

This is one language that I know VERY well, and don't need others trying to
ruin the chances of someone else lerning this WONDERFUL language.

In the future, anyone who insists on arguing about the languages/techniques
on the newsgroups, try pulling your head(s) out of your ass(es), and
smelling the roses on your way into the shit pile.



Jerry Sams wrote in message <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
>

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Peter Seebach]

In article <3458D116.2D34@pseserv3.fw.hac.com>,
W. Wesley Groleau x4923 <wwgrol@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Bob Horvath]

Peter Seebach wrote:

> In article <3458D116.2D34@pseserv3.fw.hac.com>,
> W. Wesley Groleau x4923 <wwgrol@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?

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Peter Seebach]

In article <345947D2.D20EF8E9@horvath.com>,
Bob Horvath  <bob@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Pat Rogers]

Peter Seebach <seebs@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.  :)

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Peter Seebach]

In article <01bce627$82afbec0$400d6dce@my-pc.neosoft.com>,
Pat Rogers <progers@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Dr John Stockton]

In article <01bce627$82afbec0$400d6dce@my-pc.neosoft.com> of Fri, 31 Oct
1997 18:05:12 in comp.lang.pascal.ansi-iso, Pat Rogers <progers@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.    jrs@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)

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Simon Wright]

Dr John Stockton <jrs@merlyn.demon.co.uk> writes:

> In article <01bce627$82afbec0$400d6dce@my-pc.neosoft.com> of Fri, 31 Oct
> 1997 18:05:12 in comp.lang.pascal.ansi-iso, Pat Rogers <progers@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.wright@gecm.com
GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
Command & Information Systems Division           FAX: +44(0)1705-701800

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Robert Dewar]

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Simon Wright]

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

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

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.wright@gecm.com
GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
Command & Information Systems Division           FAX: +44(0)1705-701800

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Richard A. O'Keefe]

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


Dr John Stockton <jrs@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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Bob Horvath]

Peter Seebach wrote:

> In article <345947D2.D20EF8E9@horvath.com>,
> Bob Horvath  <bob@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.

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Peter Seebach]

In article <345AAAF5.199FEDD3@horvath.com>,
Bob Horvath  <bob@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

Bob Horvath <bob@horvath.com> writes:

> Peter Seebach wrote:
> 
> > In article <3458D116.2D34@pseserv3.fw.hac.com>,
> > W. Wesley Groleau x4923 <wwgrol@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?

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Bob Horvath]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> Bob Horvath <bob@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.

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Ed Falis]

Bob Horvath wrote in message <3459DA2C.14792107@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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Shmuel (Seymour J.) Metz]

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Shmuel (Seymour J.) Metz]

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Christopher Eltschka]

Bob Horvath wrote:

[...]

> Hmmmm.  How big is an int?

sizeof(int)

always.

:-)

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Ted Lyngmo]

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:qhslyng@aom.ericsson.se                  mailto:ted@lyncon.se

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Kaz Kylheku]

In article <345F49A2.5F5DC5A0@aom.ericsson.se>,
Ted Lyngmo  <qhslyng@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[nospam]

kaz@helios.crest.nt.com (Kaz Kylheku) writes:

> 
> In article <345F49A2.5F5DC5A0@aom.ericsson.se>,
> Ted Lyngmo  <qhslyng@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>
           nospam@spam.com  writes:

>kaz@helios.crest.nt.com (Kaz Kylheku) writes:
>
>> 
>> In article <345F49A2.5F5DC5A0@aom.ericsson.se>,
>> Ted Lyngmo  <qhslyng@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[R S Haigh]

In article <878763380snz@genesis.demon.co.uk>, fred@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.

-- 

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[nospam]

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Kaz Kylheku]

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>,
 <nospam@spam.com> wrote:
>kaz@helios.crest.nt.com (Kaz Kylheku) writes:
>
>> 
>> In article <345F49A2.5F5DC5A0@aom.ericsson.se>,
>> Ted Lyngmo  <qhslyng@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[James S. Rogers]

Kaz Kylheku <kaz@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Kaz Kylheku]

In article <01bcea71$74603f40$5e20430c@Rogers>,
James S. Rogers <jimmaureenrogers@worldnet.att.net> wrote:
>Kaz Kylheku <kaz@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Peter Seebach]

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>,
 <nospam@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Kaz Kylheku]

In article <63qkp9$bqr$3@darla.visi.com>,
Peter Seebach <seebs@plethora.net> wrote:
>In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>,
> <nospam@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <63r2sv$rgm$1@helios.crest.nt.com>
           kaz@helios.crest.nt.com "Kaz Kylheku" writes:

>In article <63qkp9$bqr$3@darla.visi.com>,
>Peter Seebach <seebs@plethora.net> wrote:
>>In article <w0b4t5r428o.fsf@mah21awm.i-have-a-mis
>configured-system-so-shoot-me>,
>> <nospam@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Kaz Kylheku]

In article <878820761snz@genesis.demon.co.uk>,
Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>In article <63r2sv$rgm$1@helios.crest.nt.com>
>           kaz@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

In <63t1j9$md8$1@helios.crest.nt.com> kaz@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <danpop.878913108@news.cern.ch> Dan.Pop@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

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

>In article <danpop.878913108@news.cern.ch> Dan.Pop@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <danpop.879204372@news.cern.ch> Dan.Pop@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <879381995snz@genesis.demon.co.uk>
           fred@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Boyd Roberts]

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


In article <879433137snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes:
>In article <879381995snz@genesis.demon.co.uk>
>           fred@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: jp@gte.net

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Jos De Laender]

Boyd Roberts wrote:
> 
> In article <879433137snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes:
> >In article <879381995snz@genesis.demon.co.uk>
> >           fred@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 !

**
**
**
**
**
**
**
**
**
**
**

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Christopher Green]

In article <346C4CED.2A84@sh.bel.alcatel.be>,
Jos De Laender  <jdla@sh.bel.alcatel.be> wrote:
>Boyd Roberts wrote:
>> 
>> In article <879433137snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes:
>> >In article <879381995snz@genesis.demon.co.uk>
>> >           fred@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 cgreen@atc.com
Advanced Technology Center                   Phone (714) 583-9119
22982 Mill Creek Drive                                   ext. 220
Laguna Hills, CA 92653                       Fax   (714) 583-9213

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <64fbr2$76k$1@route1.mdrf.france3.fr>
           boyd@france3.fr "Boyd Roberts" writes:

>In article <879433137snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk
> (Lawrence Kirby) writes:
>>In article <879381995snz@genesis.demon.co.uk>
>>           fred@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Alan E & Carmel J Brain]

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Shmuel (Seymour J.) Metz]

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Alan E & Carmel J Brain]

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!

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Kaz Kylheku]

In article <3473B088.3227@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@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?

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Alan E & Carmel J Brain]

Kaz Kylheku wrote:

> Alan E & Carmel J Brain  <aebrain@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.

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Craig Franck]

Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote:
>Kaz Kylheku wrote:
>
>> Alan E & Carmel J Brain  <aebrain@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Alan E & Carmel J Brain]

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. 

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Kaz Kylheku]

In article <34767515.5253@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@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.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Alan E & Carmel J Brain]

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

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Robert Dewar]

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

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

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

Actually, they do, and have always done. If you don't get any
students, you'll soon get the message.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Robert Dewar]

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Shmuel (Seymour J.) Metz]

Robert Dewar wrote:
 
> 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!

When I was in graduate school I knew a junior professor who got stuck
teaching a class called "Differential Equations for Engineers". They
wanted him to skip the Linear Algebra because "it wasn't relevant". Plus
ca change, pus c'est la meme chose! You seem to have gotten a better
grade of students in your classes.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Jon S Anthony]

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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Richard A. O'Keefe]

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


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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Rakesh Malhotra]

Alan E & Carmel J Brain wrote:
> 
> Craig Franck wrote:
[snip]
> 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 [snip]."
> ...
> > 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:
> 
>[snip]
> 
> Little things like that.
>
After reading the interesting postings on this thread for a while I felt
compelled to respond to the 3 items mentioned above.  It boggles my mind
why the CEO said what he did or why STC do not want to publicise Ada.

I have used Ada very successfully first on a big project in Australia
and more recently in the last 3 years on 2 more projects in the US.  All
projects are embedded, real time and were done by commercial companies
(no big budget defence contractor/aerospace) who could as easily have
chosen to do them in C or any other language.

And I have recently started on my next project and have (almost) decided
to chose Ada again. I did not come to this decision easily as I have
some doubts about Ada being around for the long run as also being able
to get Ada resources (people and tools).  

So, since I am familiar with C, C++ and some Java, I thought I would do
some investigation to see if I should choose Ada again or maybe move to
C, C++. I did this investigation in as impartial a manner as I could.  I
read a lot of very interesting papers and also a book called "Safer C:
Developing Software for High-Integrity and Safety Critical Systems". 

After reading all this stuff (specially the book) I came to the
conclusion that if I was to do everything that the book recommended I
should do to make C "good enough" (by the use of PC-Lint or other tools)
I may as well have used Ada and received all the other advantages that
that language gives me.  The reason for my wanting to make C "good
enough" is that I would rather have the compiler or PC-lint/other tools
pick up my errors than debug them at run time, as also to write well
engineered, readable, maintainable programs.

I do not want to repeat all the obvious advantages that Ada has (like
modularity(packages), readabilty etc),  however, in addition to these
Ada also gives me shorter time to market because I spend my time
debugging my application rather than silly programming errors like array
overflows or mis-pointed pointers etc.  Some of these features I can get
in C,C++ by using a program like PC-Lint with its "STRONG TYPING"
option; the use of PC-Lint and strong typing is recommended in the book
but I still cannot get all the other benefits that Ada brings to the
table. 

So inspite of what the CEO said or what STC is doing, till I have a
choice of language for my projects, I intend to continue using Ada.  One
of my few wishes are that Ada tools were cheaper (yes I know about GNAT)
and more were around.
--
Rakesh.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Rakesh Malhotra]

Alan E & Carmel J Brain wrote:
> 
> Craig Franck wrote:
[snip]
> 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 [snip]."
> ...
> > 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:
> 
>[snip]
> 
> Little things like that.
>
After reading the interesting postings on this thread for a while I felt
compelled to respond to the 3 items mentioned above.  It boggles my mind
why the CEO said what he did or why STC do not want to publicise Ada.

I have used Ada very successfully first on a big project in Australia
and more recently in the last 3 years on 2 more projects in the US.  All
projects are embedded, real time and were done by commercial companies
(no big budget defence contractor/aerospace) who could as easily have
chosen to do them in C or any other language.

And I have recently started on my next project and have (almost) decided
to chose Ada again. I did not come to this decision easily as I have
some doubts about Ada being around for the long run as also being able
to get Ada resources (people and tools).  

So, since I am familiar with C, C++ and some Java, I thought I would do
some investigation to see if I should choose Ada again or maybe move to
C, C++. I did this investigation in as impartial a manner as I could.  I
read a lot of very interesting papers and also a book called "Safer C:
Developing Software for High-Integrity and Safety Critical Systems". 

After reading all this stuff (specially the book) I came to the
conclusion that if I was to do everything that the book recommended I
should do to make C "good enough" (by the use of PC-Lint or other tools)
I may as well have used Ada and received all the other advantages that
that language gives me.  The reason for my wanting to make C "good
enough" is that I would rather have the compiler or PC-lint/other tools
pick up my errors than debug them at run time, as also to write well
engineered, readable, maintainable programs.

I do not want to repeat all the obvious advantages that Ada has (like
modularity(packages), readabilty etc),  however, in addition to these
Ada also gives me shorter time to market because I spend my time
debugging my application rather than silly programming errors like array
overflows or mis-pointed pointers etc.  Some of these features I can get
in C,C++ by using a program like PC-Lint with its "STRONG TYPING"
option; the use of PC-Lint and strong typing is recommended in the book
but I still cannot get all the other benefits that Ada brings to the
table. 

So inspite of what the CEO said or what STC is doing, till I have a
choice of language for my projects, I intend to continue using Ada.  One
of my few wishes are that Ada tools were cheaper (yes I know about GNAT)
and more were around.
--
Rakesh.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Richard A. O'Keefe]

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


Craig Franck <clfranck@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

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

>In article <danpop.879204372@news.cern.ch> Dan.Pop@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <danpop.879460135@news.cern.ch> Dan.Pop@cern.ch "Dan Pop" writes:

>In <879381995snz@genesis.demon.co.uk> fred@genesis.demon.co.uk (Lawrence Kirby)
> writes:
>
>>In article <danpop.879204372@news.cern.ch> Dan.Pop@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <danpop.879781536@news.cern.ch> Dan.Pop@cern.ch "Dan Pop" writes:

>In <879713346snz@genesis.demon.co.uk> fred@genesis.demon.co.uk (Lawrence Kirby) >writes:
>
># In article <danpop.879460135@news.cern.ch> Dan.Pop@cern.ch "Dan Pop" writes:
># 
># >In <879381995snz@genesis.demon.co.uk> fred@genesis.demon.co.uk (Lawrence
> Kirby)
># > writes:
># >
># >>In article <danpop.879204372@news.cern.ch> Dan.Pop@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

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

# In article <danpop.879781536@news.cern.ch> Dan.Pop@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Peter Seebach]

In article <63r2sv$rgm$1@helios.crest.nt.com>,
Kaz Kylheku <kaz@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Kaz Kylheku]

In article <63rasf$1ug$1@darla.visi.com>,
Peter Seebach <seebs@plethora.net> wrote:
>In article <63r2sv$rgm$1@helios.crest.nt.com>,
>Kaz Kylheku <kaz@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Peter Seebach]

In article <63snhv$i18$1@helios.crest.nt.com>,
Kaz Kylheku <kaz@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

In <63r2sv$rgm$1@helios.crest.nt.com> kaz@helios.crest.nt.com (Kaz Kylheku) writes:

>In article <63qkp9$bqr$3@darla.visi.com>,
>Peter Seebach <seebs@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Mike McCarty]

In article <danpop.878857889@news.cern.ch>, Dan Pop <Dan.Pop@cern.ch> wrote:
)In <63r2sv$rgm$1@helios.crest.nt.com> kaz@helios.crest.nt.com (Kaz Kylheku) writes:
)
)>In article <63qkp9$bqr$3@darla.visi.com>,
)>Peter Seebach <seebs@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.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

In <63toc4$baf@sun001.spd.dsccc.com> jmccarty@sun1307.spd.dsccc.com (Mike McCarty) writes:

>In article <danpop.878857889@news.cern.ch>, Dan Pop <Dan.Pop@cern.ch> wrote:
>)In <63r2sv$rgm$1@helios.crest.nt.com> kaz@helios.crest.nt.com (Kaz Kylheku) writes:
>)
>)>In article <63qkp9$bqr$3@darla.visi.com>,
>)>Peter Seebach <seebs@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Peter Seebach]

In article <63toc4$baf@sun001.spd.dsccc.com>,
Mike McCarty <jmccarty@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Morris M. Keesan]

On 5 Nov 1997 16:27:11 -0800, kaz@helios.crest.nt.com (Kaz Kylheku)
wrote:
>In article <63qkp9$bqr$3@darla.visi.com>,
>Peter Seebach <seebs@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 -- mkeesan@kenan.com
Kenan Systems Corporation

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <3461ee56.265363281@news> mkeesan@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

In <873814216snz@genesis.demon.co.uk> fred@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Richard Kenner]

In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me> nospam@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.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

In <63se05$bgu$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

>In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me> nospam@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Paul F. Pearson]

In article <danpop.878912679@news.cern.ch>, Dan.Pop@cern.ch (Dan Pop) wrote:
>In <63se05$bgu$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner)
> writes:
>
>>In article
> <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>
> nospam@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 - ppearson@dynal.com or ppearson@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)

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

In <ucyY0f568GA.71@newstoo.hiwaay.net> ppearson@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <danpop.879030933@news.cern.ch> Dan.Pop@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Morris M. Keesan]

On Sun, 09 Nov 97 14:06:58 GMT, fred@genesis.demon.co.uk (Lawrence
Kirby) wrote:
>In article <danpop.879030933@news.cern.ch> Dan.Pop@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 -- mkeesan@kenan.com
Kenan Systems Corporation

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Boyd Roberts]

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


In article <w0b4t5r428o.fsf@mah21awm.i-have-a-misconfigured-system-so-shoot-me>, nospam@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

nospam@spam.com writes:

> kaz@helios.crest.nt.com (Kaz Kylheku) writes:
> 
> > 
> > In article <345F49A2.5F5DC5A0@aom.ericsson.se>,
> > Ted Lyngmo  <qhslyng@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

Re: How big is an int?

[Richard Stamp]

In article <345F49A2.5F5DC5A0@aom.ericsson.se>,
Ted Lyngmo  <qhslyng@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Daniel Anderson]

In article <345F49A2.5F5DC5A0@aom.ericsson.se>, qhslyng@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.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Lawrence Kirby]

In article <345f4f9e.0@isc-newsserver.isc.rit.edu>
           dwa1844@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Peter Mayne]

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.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Ulric Eriksson]

In article <346a4ce9.154362161@pncnt.tecnomen.ie>,
Mark Burkley <mark@$tecnomen$.ie> wrote:
>Peter.Mayne@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?"

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[nospam]

Peter.Mayne@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Ron Natalie]

nospam@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.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Dan Pop]

In <345f9c32.752004296@mrnews.mro.dec.com> Peter.Mayne@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.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Boyd Roberts]

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


In article <danpop.878747091@news.cern.ch>, Dan.Pop@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Peter Mayne]

On 6 Nov 1997 10:33:31 GMT, boyd@france3.fr (Boyd Roberts) wrote:

>In article <danpop.878747091@news.cern.ch>, Dan.Pop@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.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Peter Mayne]

On Wed, 5 Nov 1997 16:24:51 GMT, Dan.Pop@cern.ch (Dan Pop) wrote:

>In <345f9c32.752004296@mrnews.mro.dec.com> Peter.Mayne@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.

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Corey Minyard]

mark@$tecnomen$.ie (Mark Burkley) writes:
> 
> dwa1844@rit.edu (Daniel Anderson) wrote:
> 
> >In article <345F49A2.5F5DC5A0@aom.ericsson.se>, qhslyng@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:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Marcelo Meira]

Daniel Anderson wrote:
> 
> In article <345F49A2.5F5DC5A0@aom.ericsson.se>, qhslyng@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

Re: How big is an int? (was: Yet another stupid language war (was: ... the only languages you need!!))

[Ron Natalie]

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.

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Timo Salmi]

/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 = "ts@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:ts@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.

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Dr E. Buxbaum]

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.

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Peter Seebach]

In article <345A50BE.74A9@le.ac.uk>, Dr E. Buxbaum <EB15@le.ac.uk> wrote:
>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.

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Richard Curzon]

On Thu, 30 Oct 1997 18:25:26 GMT, "W. Wesley Groleau x4923"
<wwgrol@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.  

regards,
Richard.

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Bob Horvath]

Richard Curzon wrote:

> On Thu, 30 Oct 1997 18:25:26 GMT, "W. Wesley Groleau x4923"
> <wwgrol@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.

?

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Russ]

Richard Curzon wrote:
> 
> On Thu, 30 Oct 1997 18:25:26 GMT, "W. Wesley Groleau x4923"
> <wwgrol@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.
> 
> regards,
> Richard.

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Ken Deboy]

Richard Curzon wrote:
> 
> On Thu, 30 Oct 1997 18:25:26 GMT, "W. Wesley Groleau x4923"
> <wwgrol@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.
> 
> regards,
> Richard. 
 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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Kaz Kylheku]

In article <345a880a.5334620@news.interlog.com>,
Richard Curzon <ssi@interNOSPAMlog.com> wrote:
>On Thu, 30 Oct 1997 18:25:26 GMT, "W. Wesley Groleau x4923"
><wwgrol@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.  

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

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Craig Franck]

kaz@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Yet another stupid language war (was: ... the only languages you need!!)

[John G. Volan]

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:  */ "johnv@ac3i.dseg.ti.com",
    /*homeEmail:  */ "johnvolan@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. :-) ");

Re: Yet another stupid language war (was: ... the only languages you need!!)

[Phosphor]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Alan E & Carmel J Brain]

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)  

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Jon S Anthony]

Alan E & Carmel J Brain <aebrain@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Craig Franck]

Jon S Anthony <jsa@synquiry.com> wrote:
>Alan E & Carmel J Brain <aebrain@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Jon S Anthony]

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

> Jon S Anthony <jsa@synquiry.com> wrote:
> >Alan E & Carmel J Brain <aebrain@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Lawrence Kirby]

In article <ufzpnpwt96.fsf@synquiry.com>  ** none **   writes:

>Craig Franck <clfranck@worldnet.att.net> writes:
>
>> Jon S Anthony <jsa@synquiry.com> wrote:
>> >Alan E & Carmel J Brain <aebrain@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Alan E & Carmel J Brain]

Jon S Anthony wrote:
> 
> Craig Franck <clfranck@worldnet.att.net> writes:
> 
> > Jon S Anthony <jsa@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.
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote:
>Jon S Anthony wrote:
>> 
>> Craig Franck <clfranck@worldnet.att.net> writes:
>> 
>> > Jon S Anthony <jsa@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Jon S Anthony]

Craig Franck <clfranck@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

Re: Porting Experiences (was Ada and Pascal etc )

[Alan E & Carmel J Brain]

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.

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

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <345E3ACD.A15@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@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

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <345F95D0.3984@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@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

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Boyd Roberts]

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


In article <63p0u1$uvm$1@helios.crest.nt.com>, kaz@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Lawrence Kirby]

In article <34610614.33AC@gsg.eds.com> nospam@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Boyd Roberts]

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


>In article <34610614.33AC@gsg.eds.com> nospam@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Boyd Roberts wrote:
> 
> >In article <34610614.33AC@gsg.eds.com> nospam@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 spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Peter Seebach]

In article <34638433.31EE@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

Craig Franck wrote:
> 
> "Shmuel (Seymour J.) Metz" <nospam@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 spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> wrote:
>Craig Franck wrote:
>> 
>> "Shmuel (Seymour J.) Metz" <nospam@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <640ena$1q8@mtinsc04.worldnet.att.net>,
Craig Franck  <clfranck@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

Re: Porting Experiences (was Ada and Pascal etc )

[Vesa Karvonen]

Kaz Kylheku wrote:
> In article <640ena$1q8@mtinsc04.worldnet.att.net>,
> Craig Franck  <clfranck@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...

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Ralph Silverman]

Shmuel (Seymour J.) Metz (nospam@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 spamtrap@library.lspace.org


	very good macro facility is found
	with
		eric isaacson 's
		a86 d86
	( pc assembler,  debugger )
	shareware
	^^^^^^^^^
	( widely available ... )
	...

--

Ralph Silverman
z007400b@bcfreenet.seflin.lib.fl.us

Re: Porting Experiences (was Ada and Pascal etc )

[Dennis Weldy]

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 <346382BD.25F8@gsg.eds.com>...
>Craig Franck wrote:
>>
>> "Shmuel (Seymour J.) Metz" <nospam@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 spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Dennis Weldy]

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 <3467828E.1059@gsg.eds.com>...
>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 spamtrap@library.lspace.org

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Robert Munck]

On Wed, 12 Nov 1997 17:52:04 -0800, "Shmuel (Seymour J.) Metz"
<nospam@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

Re: Porting Experiences (was Ada and Pascal etc )

[Pat Rogers]

Kaz Kylheku <kaz@helios.crest.nt.com> wrote in article
<63mcmm$r3s$1@helios.crest.nt.com>...
> In article <345E3ACD.A15@gsg.eds.com>,
> Shmuel (Seymour J.) Metz <nospam@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.)

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <01bce929$4a8cbe80$560b6dce@my-pc.neosoft.com>,
Pat Rogers <progers@acm.org> wrote:
>Kaz Kylheku <kaz@helios.crest.nt.com> wrote in article
><63mcmm$r3s$1@helios.crest.nt.com>...
>> In article <345E3ACD.A15@gsg.eds.com>,
>> Shmuel (Seymour J.) Metz <nospam@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

Re: Porting Experiences (was Ada and Pascal etc )

[Samuel T. Harris]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <3460A7BB.3CCD27DC@hso.link.com>,
Samuel T. Harris <s_harris@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

Re: Porting Experiences (was Ada and Pascal etc )

[Alan E & Carmel J Brain]

Kaz Kylheku wrote:
> 
> In article <3460A7BB.3CCD27DC@hso.link.com>,
> Samuel T. Harris <s_harris@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.
 
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <34623DA4.7EE5@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@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

Re: Porting Experiences (was Ada and Pascal etc )

[Paul Campbell]

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.

Re: Porting Experiences (was Ada and Pascal etc )

[Samuel T. Harris]

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.3CCD27DC@hso.link.com>,
> Samuel T. Harris <s_harris@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!"

Re: Porting Experiences (was Ada and Pascal etc )

[Steve Summit]

In article <3460A7BB.3CCD27DC@hso.link.com>,
Samuel T. Harris <s_harris@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.

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
					scs@eskimo.com

Re: Porting Experiences (was Ada and Pascal etc )

[Samuel T. Harris]

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
>                                         scs@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!"

Re: Porting Experiences (was Ada and Pascal etc )

[Lawrence Kirby]

In article <345E3ACD.A15@gsg.eds.com> nospam@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <345F9728.D61@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@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

Re: Porting Experiences (was Ada and Pascal etc )

[Chris Brand]

Kaz Kylheku wrote:
> 
> In article <345F9728.D61@gsg.eds.com>,
> Shmuel (Seymour J.) Metz <nospam@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 <nospam@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]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

Re: Porting Experiences (was Ada and Pascal etc )

[Dann Corbit]

Chris Brand wrote in message <3460CF02.3C99@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
?

Re: Porting Experiences (was Ada and Pascal etc )

[Lawrence Kirby]

In article <3460CF02.3C99@ccgate.hac.com>
           cbrand@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <3460CF02.3C99@ccgate.hac.com>,
Chris Brand  <cbrand@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

Re: Porting Experiences (was Ada and Pascal etc )

[Kaz Kylheku]

In article <3460CF02.3C99@ccgate.hac.com>,
Chris Brand  <cbrand@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

Re: Porting Experiences (was Ada and Pascal etc )

[Boyd Roberts]

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


In article <63p2g1$vnt$1@helios.crest.nt.com>, kaz@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

Re: Porting Experiences (was Ada and Pascal etc )

[James Youngman]

>>>>> "Shmuel" == Shmuel (Seymour J ) Metz <nospam@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.

Re: Porting Experiences (was Ada and Pascal etc )

[Steve Summit]

[followups trimmed slightly]

In article <345F9728.D61@gsg.eds.com>, nospam@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
					scs@eskimo.com

Re: Porting Experiences (was Ada and Pascal etc )

[Lawrence Kirby]

In article <345F9728.D61@gsg.eds.com> nospam@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Shmuel (Seymour J.) Metz]

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

Re: Porting Experiences (was Ada and Pascal etc )

[Craig Franck]

"Shmuel (Seymour J.) Metz" <nospam@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: Porting Experiences (was Ada and Pascal etc )

[Jon S Anthony]

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

> Jon S Anthony wrote:
> > 
> > Craig Franck <clfranck@worldnet.att.net> writes:
> > 
> > > Jon S Anthony <jsa@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

Re: Porting (was ADA and Pascal etc)

[Alan E & Carmel J Brain]

Craig Franck wrote:
> 
> Jon S Anthony <jsa@synquiry.com> wrote:
> >Alan E & Carmel J Brain <aebrain@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 :) }
-- 
aebrain@dynamite.com.au     <> <>    How doth the little Crocodile
| Alan & Carmel Brain|      xxxxx       Improve his shining tail?
| Canberra Australia |  xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM
 abrain@cs.adfa.oz.au  o OO*O^^^^O*OO o oo     oo oo     oo  
                    By pulling MAERKLIN Wagons, in 1/220 Scale

Re: Porting (was ADA and Pascal etc)

[Kaz Kylheku]

In article <345AB871.413A@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@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

Re: Porting (was ADA and Pascal etc)

[Shmuel (Seymour J.) Metz]

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

Re: Porting (was ADA and Pascal etc)

[Lawrence Kirby]

In article <63d5l4$tub$1@helios.crest.nt.com>
           kaz@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Porting (was ADA and Pascal etc)

[Simon Wright]

fred@genesis.demon.co.uk (Lawrence Kirby) writes:

> In article <63d5l4$tub$1@helios.crest.nt.com>
>            kaz@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.wright@gecm.com
GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
Command & Information Systems Division           FAX: +44(0)1705-701800

Re: Porting (was ADA and Pascal etc)

[Peter Seebach]

In article <x7v90v5y6k1.fsf@pogner.demon.co.uk>,
Simon Wright  <simon@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Porting (was ADA and Pascal etc)

[Simon Wright]

seebs@plethora.net (Peter Seebach) writes:

> In article <x7v90v5y6k1.fsf@pogner.demon.co.uk>,
> Simon Wright  <simon@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.wright@gecm.com
GEC-Marconi Radar & Defence Systems            Voice: +44(0)1705-701778
Command & Information Systems Division           FAX: +44(0)1705-701800

Re: Porting (was ADA and Pascal etc)

[Jon S Anthony]

fred@genesis.demon.co.uk (Lawrence Kirby) writes:

> In article <63d5l4$tub$1@helios.crest.nt.com>
>            kaz@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

Mixing declarations and statements (Re: Porting (was ADA and Pascal etc))

[�amonn McManus]

fred@genesis.demon.co.uk writes:
>            kaz@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

Re: Mixing declarations and statements (Re: Porting (was ADA and Pascal etc))

[Peter Seebach]

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


In article <swutch@kaa.gr.osf.org>,
�amonn McManus <emcmanus@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

s/w manual

[Nameir Ismeil]

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

Re: Mixing declarations and statements (Re: Porting (was ADA and Pascal etc))

[Charles Hixson]

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	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Mixing declarations and statements (Re: Porting (was ADA and Pascal etc))

[Kaz Kylheku]

In article <345F6265.A505E2FC@earthling.net>,
Charles Hixson  <charleshixson@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

Re: Mixing declarations and statements (Re: Porting (was ADA and Pascal etc))

[Peter Seebach]

In article <345F6265.A505E2FC@earthling.net>,
Charles Hixson  <charleshixson@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Mixing declarations and statements (Re: Porting (was ADA and Pascal etc))

[�amonn McManus]

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

Re: Porting (was ADA and Pascal etc)

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

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

> Craig Franck wrote:
> > 
> > Jon S Anthony <jsa@synquiry.com> wrote:
> > >Alan E & Carmel J Brain <aebrain@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>


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

Re: Porting (was ADA and Pascal etc)

[Alan E & Carmel J Brain]

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.

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

Re: Porting (was ADA and Pascal etc)

[Peter Seebach]

In article <345AB871.413A@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Porting (was ADA and Pascal etc)

[Matt Austern]

seebs@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.

Re: Porting (was ADA and Pascal etc)

[Peter Seebach]

In article <fxtbu05g48l.fsf@isolde.mti.sgi.com>,
Matt Austern  <austern@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: Porting (was ADA and Pascal etc)

[Jon S Anthony]

Matt Austern <austern@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

Re: Porting (was ADA and Pascal etc)

[Alan E & Carmel J Brain]

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

Re: Porting (was ADA and Pascal etc)

[Kaz Kylheku]

In article <fxtbu05g48l.fsf@isolde.mti.sgi.com>,
Matt Austern  <austern@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

Re: Porting (was ADA and Pascal etc)

[Alan E & Carmel J Brain]

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

Re: Porting (was ADA and Pascal etc)

[Peter Seebach]

In article <345BB0F9.1B7F@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Rud Merriam]

Jon S Anthony wrote in message ...
>Alan E & Carmel J Brain <aebrain@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <3459AC95.1D75@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Richard A. O'Keefe]

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


kaz@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 <3459AC95.1D75@dynamite.com.au>,
>Alan E & Carmel J Brain  <aebrain@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <63c3n8$nhp$1@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@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

Re: Portability: C, C++, Ada

[Alan E & Carmel J Brain]

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

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

Re: Portability: C, C++, Ada

[Peter Seebach]

In article <345BA52D.56F1@dynamite.com.au>,
Alan E & Carmel J Brain  <aebrain@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
-- 
seebs@plethora.net -- Speaking for myself.  No spam please.
Copyright 1997.  All rights reserved.  This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Stevens]

On 30 Oct 1997 11:50:05 -0800, Kaz Kylheku <kaz@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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Stevens]

On Fri, 31 Oct 1997, Alan E & Carmel J Brain <aebrain@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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <slrn66211n.91f.jstevens@samoyed.ftc.nrcs.usda.gov>,
John Stevens <jstevens@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Robert Dewar]

John Stevens <jstevens@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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <dewar.878897750@merv>, Robert Dewar <dewar@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Larry Elmore]

John Stevens wrote in message ...
>On Fri, 31 Oct 1997, Alan E & Carmel J Brain <aebrain@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Dr E. Buxbaum]

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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Russ Lyttle]

Dr E. Buxbaum wrote:
> 
> 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.
I run gnat on Linux. Have for about 3 years. The first years were not
the best, but it works just fine now.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Marc Wachowitz]

[Follow-up to comp.lang.ada]

jstevens@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 <mw@ipx2.rz.uni-mannheim.de>

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

[Dale Stanbrough]

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

Wasted words

[W. Wesley Groleau x4923]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Jon S Anthony]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <3456e71b.3833189@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Steve Ropa]

On 31 Oct 1997, Kaz Kylheku wrote:

> In article <3456e71b.3833189@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <345673af.1413708@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Rickard]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Xu Yifeng]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Scott Baierl]

Xu Yifeng wrote in message <3456A374.5BF2@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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Stevens]

On Thu, 30 Oct 1997 17:11:26 -0600, Scott Baierl <baierls@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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <slrn66258f.91f.jstevens@samoyed.ftc.nrcs.usda.gov>,
John Stevens <jstevens@samoyed.ftc.nrcs.usda.gov> wrote:
>On Thu, 30 Oct 1997 17:11:26 -0600, Scott Baierl <baierls@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[William & Melissa Thornton]

This is a multi-part message in MIME format.
--------------2C06438E1EDAEBDA78A851A2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

VERY WELL SAID!

John Stevens wrote:
>
> On Thu, 30 Oct 1997 17:11:26 -0600, Scott Baierl <baierls@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.

--
                ______________________________
               |                              |
               |  __________________________  |
               |  |########################|  |
               |  |########################|  |
               |  |########################|  |
               |  |#####             ######|  |
               |  |#####    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: thornton@avicom.net
tel;home:       406-586-9166
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


--------------2C06438E1EDAEBDA78A851A2--

Re: English SUCKS, Chinese is the only language you need!!

[Chieh Cheng]

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

Re: English SUCKS, Chinese is the only language you need!!

[Shmuel (Seymour J.) Metz]

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

Re: English SUCKS, Chinese is the only language you need!!

[Richard A. O'Keefe]

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


"Shmuel (Seymour J.) Metz" <nospam@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

Re: English SUCKS, Chinese is the only language you need!!

[Dr E. Buxbaum]

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!

Re: English SUCKS, Chinese is the only language you need!!

[Shmuel (Seymour J.) Metz]

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

Re: English SUCKS, Chinese is the only language you need!!

[Kaz Kylheku]

In article <34733969.13D5@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@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).

Re: English SUCKS, Chinese is the only language you need!!

[Matt Corey]

Dr E. Buxbaum wrote:

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

  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

Re: English SUCKS, Chinese is the only language you need!!

[Shmuel (Seymour J.) Metz]

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

Re: English SUCKS, Chinese is the only language you need!!

[Kaz Kylheku]

In article <34738872.783@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@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.

Re: English SUCKS, Chinese is the only language you need!!

[Mike Smith]

Kaz Kylheku <kaz@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

Re: English SUCKS, Chinese is the only language you need!!

[David Weller]

In article <01bcf5c2$c4dfe7c0$0200000a@kld_mcs>,
Mike Smith <kld_msmith@earthlink.nospam.net> wrote:
>Kaz Kylheku <kaz@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).

Re: English SUCKS, Chinese is the only language you need!!

[Dennis Weldy]

Shmuel (Seymour J.) Metz wrote in message <3474B3E4.67FA@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

Re: English SUCKS, Chinese is the only language you need!!

[Shmuel (Seymour J.) Metz]

Dennis Weldy wrote:

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

N, they don't; the order is different.

> Or do you object to using [] for the declaration of arrays, and for indexing
> into the array as well? ;-)

No, because there it's consistent.


-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

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

Re: English SUCKS, Chinese is the only language you need!!

[Dennis Weldy]

int * p = NULL ;

the * comes before the variable name. I've defined an int pointer

 p = new int ;
 *p = 10 ;

the * comes before the variable name. I'm using the int pointed to by p.

Have I missed something?

Dennis

Shmuel (Seymour J.) Metz wrote in message <3479FD07.2934@gsg.eds.com>...
>Dennis Weldy wrote:
>
>> >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.
>
>N, they don't; the order is different.
>
>> Or do you object to using [] for the declaration of arrays, and for
indexing
>> into the array as well? ;-)
>
>No, because there it's consistent.
>
>
>--
>
>                        Shmuel (Seymour J.) Metz
>                        Senior Software SE
>
>The values in from and reply-to are for the benefit of spammers:
>reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com,
>user smetz. Do not reply to spamtrap@library.lspace.org

Re: English SUCKS, Chinese is the only language you need!!

[Peter Seebach]

In article <3479FD07.2934@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@gsg.eds.com> wrote:
>N, they don't; the order is different.

Is not.  Well, not much.
	int *ip;
says, quite literally, that '*ip' is an integer.

If, later, you write '*ip', you are using integer type.

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

Re: English SUCKS, Chinese is the only language you need!!

[Martin M Dowie]

In article <34738872.783@gsg.eds.com>, "Shmuel (Seymour J.) Metz"
<nospam@gsg.eds.com> writes
>Yes, but see below.
> 
>> in Tcl or Awk.  
>
>Shouldn't that be AWK, since it's named after the authors?
>
I always thought it was AWKward ;-)

-- 
Martin M Dowie

Re: English SUCKS, Chinese is the only language you need!!

[Davide Bionda]

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

Re: English SUCKS, Chinese is the only language you need!!

[Timo Salmi]

In article <3471428A.6193@erdw.ethz.ch>,
Davide Bionda  <bionda@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.
:>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 ;-)

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:ts@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.

Re: English SUCKS, Chinese is the only language you need!!

[John Rickard]

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 <bionda@erdw.ethz.ch> wrote in article
<3471428A.6193@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 ;-)
: 

Re: English SUCKS, Chinese is the only language you need!!

[Jean-Sebastien Payette]

John Rickard wrote in message <64sql2$k0@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!!)

Re: English SUCKS, Chinese is the only language you need!!

[Dennis Weldy]

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>...
>
>John Rickard wrote in message <64sql2$k0@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!!)
>
>

Re: English SUCKS, Chinese is the only language you need!!

[Jean-Sebastien Payette]

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!

Re: English SUCKS, Chinese is the only language you need!!

[Kaz Kylheku]

In article <64tnjp$o0k$1@weber.videotron.net>,
Jean-Sebastien Payette <jeanspayette@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.

Re: English SUCKS, Chinese is the only language you need!!

[Dennis Weldy]

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

Re: English SUCKS, Chinese is the only language you need!!

[Chuck Adams]

In article <YSQz$BJ98GA.158@news2.ingr.com>, "Dennis Weldy" <nojunkmail@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).

Re: English SUCKS, Chinese is the only language you need!!

[J. W. Rider]

On Wed, 19 Nov 97 17:38:09 GMT, chuck@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.

Re: English SUCKS, Chinese is the only language you need!!

[Richard A. O'Keefe]

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


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

Re: English SUCKS, Chinese is the only language you need!!

[John Rickard]

>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.
As for talking better than me... Try reading you message and tell me
you don't talk like a 12 year old.

Re: English SUCKS, Chinese is the only language you need!!

[Jean-Sebastien Payette]

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

Re: English SUCKS, Chinese is the only language you need!!

[Davide Bionda]

>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

Re: English SUCKS, Chinese is the only language you need!!

[John Rickard]

Yea thats right. MY language is "American" English.  not English.
-- 
--
Remove "spam" from my
email address to send me REAL email.
--

Davide Bionda <bionda@erdw.ethz.ch> wrote in article
<347301BC.3AB7@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
: 

Re: English SUCKS, Chinese is the only language you need!!

[Mike Smith]

John Rickard <saskan@spam.worldnet.spam.att.spam.net.spam> wrote in article
<64vdi2$88b@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

Re: Your english sucks, mine is better.

[John Rickard]

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_msmith@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$88b@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
: 

Re: Your english sucks, mine is better.

[Larry Elmore]

John Rickard wrote in message <64vl4h$3qh@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

Re: Your english sucks, mine is better.

[system]

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

Morphis@physics.niu.edu
Real Women change tires			abuse@uu.net postmaster@uu.net
Real Men change diapers                 security@uu.net

Re: Your english sucks, mine is better.

[John Rickard]

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

Re: Your english sucks, mine is better.

[Dennis Weldy]

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$nfa@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.
>
>
>
>

Re: Your english sucks, mine is better.

[Andrew Koenig]

In article <64vl4h$3qh@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
				  ark@research.att.com
				  http://www.research.att.com/info/ark

Re: Your english sucks, mine is better.

[Spaceman Spiff!]

Andrew Koenig wrote:
> 
> In article <64vl4h$3qh@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
>                                   ark@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
                                  ark@research.att.com
                                  http://www.research.att.com/info/ark
:-)

Re: Your english sucks, mine is better.

[Andrew Koenig]

In article <34785536.4FCF@flash.net>,
Spaceman Spiff! <csweber@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
				  ark@research.att.com
				  http://www.research.att.com/info/ark

Re: Your english sucks, mine is better.

[Robert Dewar]

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!

Re: Your english sucks, mine is better.

[billg]

In article <dewar.880302894@merv>, dewar@merv.cs.nyu.edu says...
> 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!
> 
> 
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

Re: Your english sucks, mine is better.

[Richard Kenner]

In article <MPG.ee2636b141efc8b989781@news.idt.net> billg@jk.pst.com writes:
>In article <dewar.880302894@merv>, dewar@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.

Re: Your english sucks, mine is better.

[billg]

In article <65ab3u$v07$1@news.nyu.edu>, kenner@lab.ultra.nyu.edu says...
> In article <MPG.ee2636b141efc8b989781@news.idt.net> billg@jk.pst.com writes:
> >In article <dewar.880302894@merv>, dewar@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.

Re: Your english sucks, mine is better.

[Dennis Weldy]

That's incorrect. One can still be a capitalist, and still have ethics,
honesty, and integrity.
They aren't mutually exclusive.

Dennis

billg@jk.pst.com wrote in message ...
>In article <65ab3u$v07$1@news.nyu.edu>, kenner@lab.ultra.nyu.edu says...
>> In article <MPG.ee2636b141efc8b989781@news.idt.net> billg@jk.pst.com
writes:
>> >In article <dewar.880302894@merv>, dewar@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.

Re: Your english sucks, mine is better.

[billg]

In article <lVNyJnO#8GA.115@news2.ingr.com>, nojunkmail@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

Re: Your english sucks, mine is better.

[Rob Eamon]

billg@jk.pst.com wrote in message ...
>In article <lVNyJnO#8GA.115@news2.ingr.com>, nojunkmail@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

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.

Re: Your english sucks, mine is better.

[Kaz Kylheku]

In article <65ctht$jbt$1@news01.micron.net>,
Rob Eamon <rre2251@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.

Re: Your english sucks, mine is better.

[billg]

In article <65ctht$jbt$1@news01.micron.net>, 
rre2251@idahopower.bitmosphere.com says...
> billg@jk.pst.com wrote in message ...
> >In article <lVNyJnO#8GA.115@news2.ingr.com>, nojunkmail@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
> 
> 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.
> 
> 
> 
> 
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

Re: Your english sucks, mine is better.

[Me]

billg@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).

Re: Your english sucks, mine is better.

[Mark Wilden]

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

Re: Your english sucks, mine is better.

[Matt Corey]

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

Re: Your english sucks, mine is better.

[Timo Salmi]

/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 = "ts@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:ts@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.

Re: Your english sucks, mine is better.

[Rob Eamon]

Me wrote in message <3479B4F1.D575BEFC@SomewhereElse.com>...
>
>
>billg@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..]

Re: Your english sucks, mine is better.

[Leon Jones]

Me <Sparky@SomewhereElse.com> wrote in article
<3479B4F1.D575BEFC@SomewhereElse.com>...

> 
> billg@jk.pst.com wrote:

[snip previous content]

> What are you, some sort of freaking communist?  Honesty and integrity are
> fundamental for capatalistic success!  

Yeah, ask Bernie Eccleston, Al-Fayed and Robert Maxwell!!

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

Being dishonest and _getting caught_ being dishonest are two completely
different issues.  Your failure to distinguish between the two suggests a
fundamental nievety.  Either that or you view the world through rose tinted
specs.

> If you develop a good solid product,
> it is unnecessary to decieve customers into buying it.  

This just doesn't follow unless your's is the only company in a particular
market.  How often do you see advertisments along the lines of, "Well, it's
good but not as good as X/y's along the road.".  Someone's got to be lying
- they can't all be the best.  If there's so many great products, out there
in "Honest Corporate Land", that don't require advertising why so many
adverts?

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

I would like to know how you can substantiate your claims that the Soviet
Union was inherently more corrupt than other administrations.  Are you
suggesting that congress, (I assume you are american), is as pure as the
driven snow.  Infact America's attempts to cripple other countries into
conforming to it's elitist, arrogant definition of the ideal world amount
to nothing less than blackmail - an honest and commendable practice?  I
fear not!  The only thing that makes me more angry is the fact that our
current British administration continues to follow America like a sad, lost
puppy further feeding it's ambition to occupy the moral high ground and
preach to the rest of us.

Anyway this is going decidedly off topic but I invite further comment on my
e-mail address.  Believe me I could go on forever :-)

> Matt 'Capitalist Pig' Corey
> 
> (preparing flame-retardent capitalist-pig dark suit and red tie).
> 

leon.jones@lineone.net
Leon 

Re: Your english sucks, mine is better.

[Larry Elmore]

Leon Jones wrote in message <01bcf94a$43fbc1c0$LocalHost@default>...
>Me <Sparky@SomewhereElse.com> wrote in article
><3479B4F1.D575BEFC@SomewhereElse.com>...
>Being dishonest and _getting caught_ being dishonest are two completely
>different issues.  Your failure to distinguish between the two suggests a
>fundamental nievety.  Either that or you view the world through rose tinted
>specs.


If you've got a lot riding on it, only a fool would even take the _risk_ of
getting caught. The costs can be enormous. Witness Intel's attempt to keep
quiet about the Pentium math bug a while back. That just made things worse
for them.

>> If you develop a good solid product,
>> it is unnecessary to decieve customers into buying it.
>
>This just doesn't follow unless your's is the only company in a particular
>market.  How often do you see advertisments along the lines of, "Well, it's
>good but not as good as X/y's along the road.".  Someone's got to be lying
>- they can't all be the best.  If there's so many great products, out there
>in "Honest Corporate Land", that don't require advertising why so many
>adverts?

Obviously, there's some degree of lying involved with some (or a lot) of
advertising. But that's not capitalism's fault. Look at the communist
countries of a few years ago -- continuous, shameless advertising to their
own populations (i.e., propaganda). At least under capitalism, if the claims
exceed the reality very far, you can sue them for false advertising, that is
to say, fraud.

>> 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.
>
>I would like to know how you can substantiate your claims that the Soviet
>Union was inherently more corrupt than other administrations.  Are you
>suggesting that congress, (I assume you are american), is as pure as the
>driven snow.  Infact America's attempts to cripple other countries into
>conforming to it's elitist, arrogant definition of the ideal world amount
>to nothing less than blackmail - an honest and commendable practice?  I
>fear not!

I don't think the claim was made that Congress is all wonderful and shiny
clean. It certainly isn't. And America's practices overseas are largely
unknown to Americans at home, though that doesn't excuse the government and
the multinational corporations. They're very often anything but free-trade
and human-rights once you look below the surface.

>The only thing that makes me more angry is the fact that our
>current British administration continues to follow America like a sad, lost
>puppy further feeding it's ambition to occupy the moral high ground and
>preach to the rest of us.

More like America following along in Britain's tracks, several decades
behind. The British Empire was not exactly the nice guy on the block,
either, if one didn't toe the line...

>Anyway this is going decidedly off topic but I invite further comment on my
>e-mail address.  Believe me I could go on forever :-)

Should be interesting, then!

Larry

Re: Your english sucks, mine is better.

[billg]

In article <65dsjd$6gq@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> >This just doesn't follow unless your's is the only company in a particular
> >market.  How often do you see advertisments along the lines of, "Well, it's
> >good but not as good as X/y's along the road.".  Someone's got to be lying
> >- they can't all be the best.  If there's so many great products, out there
> >in "Honest Corporate Land", that don't require advertising why so many
> >adverts?
> 
> Obviously, there's some degree of lying involved with some (or a lot) of
> advertising. But that's not capitalism's fault. Look at the communist
> countries of a few years ago -- continuous, shameless advertising to their
> own populations (i.e., propaganda). At least under capitalism, if the claims
> exceed the reality very far, you can sue them for false advertising, that is
> to say, fraud.

There's nowhere near the amount of consumer protection that indicates 
ethical behaviour is the value.  The laws favor the capitalist over the 
consumer.  "Acceptable" levels of theft of income is condoned and 
facilitated.  Advertising context and marketing strategy need regulation.  
Companies that use ommission of known facts as a marketing method (as 
well as other unethical tactics/strategies) should not be allowed medium.  
Companies that minimize the use of consumer bandwidth to present their 
wares honestly should be.

billg 

Re: Your english sucks, mine is better.

[Larry Elmore]

billg@jk.pst.com wrote in message ...
>There's nowhere near the amount of consumer protection that indicates
>ethical behaviour is the value.  The laws favor the capitalist over the
>consumer.

Tell that to the companies sued over product liability and who lose millions
on ridiculous lawsuits. Like the lady who sued McDonald's because they
didn't have a warning label on their coffee cup from the drive-thru warning
that the coffee is hot and that it's dangerous to drive and try to drink hot
coffee at the same time. Well, duuhhhhh... She got millions for her
_stupidity_ when she sued (_after_ McDonald's had already paid all her
medical bills, etc.). There's a Superman costume that was out for this
Halloween where the manufacturers felt compelled to put a warning label on
the cape: "Warning: Wearing this cape does not enable the wearer to fly,"
because, sure as sh**, some kid would jump off the garage roof with it on,
the kid's moronic and/or greedy parents would sue, and likely as not, win
2.4 million dollars in punitive damages.

Besides, this kind of crap (false advertising, etc) has gone on ever since
any kind of trade went on, long before capitalism ever existed. Just because
capitalism hasn't eliminated it, the whole problem is capitalism's fault?
Get real. It's a problem of human nature, not capitalism. I don't know of
_any_ other system that has done any better, so why aren't you criticizing
them, too? You remind me of the "useful idiots" that were outraged by each
and every abuse in South Africa, and yet turned a blind eye to far worse
outrages in black-ruled African countries...

Larry

Larry

>"Acceptable" levels of theft of income is condoned and
>facilitated.  Advertising context and marketing strategy need regulation.
>Companies that use ommission of known facts as a marketing method (as
>well as other unethical tactics/strategies) should not be allowed medium.
>Companies that minimize the use of consumer bandwidth to present their
>wares honestly should be.

Re: Your english sucks, mine is better.

[billg]

In article <65patf$fma@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> billg@jk.pst.com wrote in message ...
> >There's nowhere near the amount of consumer protection that indicates
> >ethical behaviour is the value.  The laws favor the capitalist over the
> >consumer.
> 
> Tell that to the companies sued over product liability and who lose millions
> on ridiculous lawsuits. Like the lady who sued McDonald's because they
> didn't have a warning label on their coffee cup from the drive-thru warning
> that the coffee is hot and that it's dangerous to drive and try to drink hot
> coffee at the same time. Well, duuhhhhh... She got millions for her
> _stupidity_ when she sued (_after_ McDonald's had already paid all her
> medical bills, etc.). There's a Superman costume that was out for this
> Halloween where the manufacturers felt compelled to put a warning label on
> the cape: "Warning: Wearing this cape does not enable the wearer to fly,"
> because, sure as sh**, some kid would jump off the garage roof with it on,
> the kid's moronic and/or greedy parents would sue, and likely as not, win
> 2.4 million dollars in punitive damages.

All said, I think those judgements occur because it is realized that the 
business owners in general attain much of their money via the labor of 
others and should forfeit (give it to its rightful owners) some of it.  
<g>

> 
> Besides, this kind of crap (false advertising, etc) has gone on ever since
> any kind of trade went on, long before capitalism ever existed. Just because
> capitalism hasn't eliminated it, the whole problem is capitalism's fault?
> Get real. It's a problem of human nature, not capitalism. I don't know of
> _any_ other system that has done any better, so why aren't you criticizing
> them, too? You remind me of the "useful idiots" that were outraged by each
> and every abuse in South Africa, and yet turned a blind eye to far worse
> outrages in black-ruled African countries...

Well, at least I'm useful. :)

I don't have enough information on the the other systems and I don't have 
to live with them directly either.  Capitalistic behaviour is exploitive-
-and the more you are willing to (are able to) exploit (and extort) the 
more "successful" you will become.  The model is best exampled by the 
scenario where eastern slave-labor produces products for a garment 
company who then sells them at unheard of markups for the owner's 
benefit.  The mainstream (capitalistic company) is more subtle but those 
characteristics are always there.  The IT agency model is based on the 
same exploitive principles, and that one really hits home.

billg

Re: Your english sucks, mine is better.

[Larry Elmore]

Larry Elmore wrote in message <65s1u8$8kj@netra.montana.edu>...
billg@jk.pst.com wrote in message ...
>In article <65patf$fma@netra.montana.edu>,
>ljelmore@montana.campus.mci.net says...
>> billg@jk.pst.com wrote in message ...
>>
>All said, I think those judgements occur because it is realized that the
>business owners in general attain much of their money via the labor of
>others and should forfeit (give it to its rightful owners) some of it.

So morons who misuse products are "the rightful owners" of wealth?

>> Besides, this kind of crap (false advertising, etc) has gone on ever
since
>> any kind of trade went on, long before capitalism ever existed. Just
because
>> capitalism hasn't eliminated it, the whole problem is capitalism's fault?
>> Get real. It's a problem of human nature, not capitalism. I don't know of
>> _any_ other system that has done any better, so why aren't you
criticizing
>> them, too? You remind me of the "useful idiots" that were outraged by
each
>> and every abuse in South Africa, and yet turned a blind eye to far worse
>> outrages in black-ruled African countries...
>
>Well, at least I'm useful. :)

I meant to say "rightfully outraged" (re: South Africa). But it was stupid
to
get so upset _only_ about SA because it was whites vs. blacks when there was
_much_ worse black vs. black violence (tribe vs. tribe, actually) in a lot
of other
countries that was just _ignored_.

>I don't have enough information on the the other systems and I don't have
>to live with them directly either.

Well, you _should_ get to know them. You might find the alternatives to be
far worse than what you've got...

>Capitalistic behaviour is exploitive-
>-and the more you are willing to (are able to) exploit (and extort) the
>more "successful" you will become.  The model is best exampled by the
>scenario where eastern slave-labor produces products for a garment
>company who then sells them at unheard of markups for the owner's
>benefit.  The mainstream (capitalistic company) is more subtle but those
>characteristics are always there.  The IT agency model is based on the
>same exploitive principles, and that one really hits home.

This is just beautiful. The clothiers are more evil than the government that
enslaved the workers in the first place (and are making a tidy sum of money
themselves)...

Granted, I think the companies and countries doing business with such
countries are despicable. I will not buy anything that is made in certain
countries. There are some companies I will not buy anything from, no matter
where the product was made.

Larry

Re: Your english sucks, mine is better.

[billg]

In article <65s1u8$8kj@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> billg@jk.pst.com wrote in message ...
> >In article <65patf$fma@netra.montana.edu>,
> >ljelmore@montana.campus.mci.net says...
> >> billg@jk.pst.com wrote in message ...
> >>
> >All said, I think those judgements occur because it is realized that the
> >business owners in general attain much of their money via the labor of
> >others and should forfeit (give it to its rightful owners) some of it.
> 
> 
> So morons who misuse products are "the rightful owners" of wealth?

You missed it.  My point was that there is some recognition of the 
classification of society by those who have some control over the system 
and that that classification occurs because some choose to manipulate the 
system at the expense of others (in other words, behave unethically).  
The actual incident has no bearing then on the judgement but is made 
rather on more abstract (unwritten, grey) concepts to balance the scales 
a bit.

> I meant to say "rightfully outraged" (re: South Africa). But it was silly to
> get so upset about SA because it was whites vs. blacks when there was _much_
> worse black vs. black violence (tribe vs. tribe, actually) in a lot of other
> countries that was just _ignored_.

Perhaps the black vs. white battle was seen as based on a more trivial 
and baseless concept?  So what then do you see as "the other equally 
important issues" relating to what we are discussing?

> 
> >I don't have enough information on the the other systems and I don't have
> >to live with them directly either.
> 
> Well, you _should_ get to know them. You might find the alternatives to be
> far worse than what you've got...

I made no inference that would suggest replacing the current system with 
any other _existing_ system.

> 
> >Capitalistic behaviour is exploitive-
> >-and the more you are willing to (are able to) exploit (and extort) the
> >more "successful" you will become.  The model is best exampled by the
> >scenario where eastern slave-labor produces products for a garment
> >company who then sells them at unheard of markups for the owner's
> >benefit.  The mainstream (capitalistic company) is more subtle but those
> >characteristics are always there.  The IT agency model is based on the
> >same exploitive principles, and that one really hits home.
> 
> This is just beautiful. The clothiers are more evil than the government that
> enslaved the workers in the first place (and are making a tidy sum of money
> themselves)...

Stop making assumptions that imply we have potential high-level political 
(government) control.  The issue is the greedy capitalist who does have 
some control, by choosing his sources of production, chooses to exploit 
to make a buck and hopes no one will notice the crimes he is helping to 
proliferate.  He, the capitalist, in this instance, should be subject to 
forfeiture.  Not only after the fact when consumers boycott the products 
but also in retroactive enforcement: seizure of capital gained from the 
exploitation, and distribution of the funds to those who oppressively 
labored.

billg

Re: Your english sucks, mine is better.

[Larry Elmore]

Larry Elmore wrote in message <65dsjd$6gq@netra.montana.edu>...
>Leon Jones wrote in message <01bcf94a$43fbc1c0$LocalHost@default>...
>>Being dishonest and _getting caught_ being dishonest are two completely
>>different issues.  Your failure to distinguish between the two suggests a
>>fundamental nievety.  Either that or you view the world through rose
tinted
>>specs.
>
>If you've got a lot riding on it, only a fool would even take the _risk_ of


I'd like to apologize continuing this off-topic thread -- I'd meant to email
it, not post to the newsgroup. Oops...

Larry

Re: Your english sucks, mine is better.

[billg]

In article <65el45$cmd@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> Larry Elmore wrote in message <65dsjd$6gq@netra.montana.edu>...
> >Leon Jones wrote in message <01bcf94a$43fbc1c0$LocalHost@default>...
> >>Being dishonest and _getting caught_ being dishonest are two completely
> >>different issues.  Your failure to distinguish between the two suggests a
> >>fundamental nievety.  Either that or you view the world through rose
> tinted
> >>specs.
> >
> >If you've got a lot riding on it, only a fool would even take the _risk_ of
> 
> 
> I'd like to apologize continuing this off-topic thread -- I'd meant to email
> it, not post to the newsgroup. Oops...
> 
> Larry
> 
> 
> 
Afraid of riling the masses Larry? 

billg

Re: Your english sucks, mine is better.

[Craig Franck]

billg@jk.pst.com wrote:
>In article <65el45$cmd@netra.montana.edu>, 
>ljelmore@montana.campus.mci.net says...

>> I'd like to apologize continuing this off-topic thread -- I'd meant to email
>> it, not post to the newsgroup. Oops...
>> 
>> Larry
>> 
>Afraid of riling the masses Larry? 

Not in the way you mean. :-) You seem to have a lot of interesting
ideas; it's a shame your wasting them all by posting them into comp
groups. :-(

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

Re: Your english sucks, mine is better.

[billg]

In article <65g18t$t61@bgtnsc02.worldnet.att.net>, 
clfranck@worldnet.att.net says...
> billg@jk.pst.com wrote:
> >In article <65el45$cmd@netra.montana.edu>, 
> >ljelmore@montana.campus.mci.net says...
> 
> >> I'd like to apologize continuing this off-topic thread -- I'd meant to email
> >> it, not post to the newsgroup. Oops...
> >> 
> >> Larry
> >> 
> >Afraid of riling the masses Larry? 
> 
> Not in the way you mean. :-) You seem to have a lot of interesting
> ideas; it's a shame your wasting them all by posting them into comp
> groups. :-(

And I'm getting old and tired too. :-(

billg

Re: Your english sucks, mine is better.

[Peter Seebach]

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

Re: Your english sucks, mine is better.

[Larry Elmore]

billg@jk.pst.com wrote in message ...
>In article <65ab3u$v07$1@news.nyu.edu>, kenner@lab.ultra.nyu.edu says...
>> In article <MPG.ee2636b141efc8b989781@news.idt.net> billg@jk.pst.com
writes:
>> >In article <dewar.880302894@merv>, dewar@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

Re: Your english sucks, mine is better.

[billg]

In article <65d5pd$3e@netra.montana.edu>, ljelmore@montana.campus.mci.net 
says...
> 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 you sound like one of the "it's either black or white" people.  
Capitalism perfects dishonesty and unethical behaviour so that it is easy 
to get away with it (unseen, unclear or takes advantage of scale to wrong 
many just a little).  The devil is in the tactics (the grey areas of 
exploitation etc. for example).  Part of the thinking is that everybody 
is doing it so it is acceptable.  It is not.  That may be a rude 
awakening for some.  Someone illuded to the common practice of a business 
strategy that is unethical initially to "get ahead" and then play fair 
(or act like it).  To me that's a good case for forfeiture similar to 
illegal drug operations.  

It's not that capitalism is "bad", it's just that in practice it breeds 
wrong doing because it attracts those who are greedy and clever who take 
advantage.  It's the perfect crime.  Unfortunately, it's one against 
humanity.  

This way of thinking is met with opposition by many because they have 
large investments and stand to lose if the details of their unethical 
strategies and tactics (their "capitalist" success formula) become dinner 
table talk.  It's time to bring the taboo out of the closet.

billg

Re: Your english sucks, mine is better.

[Larry Elmore]

billg@jk.pst.com wrote in message ...
>In article <65d5pd$3e@netra.montana.edu>, ljelmore@montana.campus.mci.net
>says...
>> 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 you sound like one of the "it's either black or white" people.


That's because it _is_ either black or white, billg. Gray is nothing more
than a mixture of black and white. The shade of gray depends only on the
relative proportions of black and white. Any "gray" situation can be, with
enough insight and analysis, be reduced to spots of black and white that
_appear_ gray from a distance. On virtually any issue where there are two or
more sides, one will find both sides to be gray, usually one somewhat darker
gray than the other. That is to say, there's both black and white on both
sides. I'm not claiming that I can successully separate everything, but in
principle it can be done. If you can prove that it can't be done, I'd like
to see that.

>Capitalism perfects dishonesty and unethical behaviour so that it is easy
>to get away with it (unseen, unclear or takes advantage of scale to wrong
>many just a little).  The devil is in the tactics (the grey areas of
>exploitation etc. for example).  Part of the thinking is that everybody
>is doing it so it is acceptable.  It is not.  That may be a rude
>awakening for some.

So how is it any different than French feudalism? Roman imperialism? Russian
communism?

>Someone illuded to the common practice of a business
>strategy that is unethical initially to "get ahead" and then play fair
>(or act like it).  To me that's a good case for forfeiture similar to
>illegal drug operations.
>
>It's not that capitalism is "bad", it's just that in practice it breeds
>wrong doing because it attracts those who are greedy and clever who take
>advantage.  It's the perfect crime.  Unfortunately, it's one against
>humanity.

Name one system where that isn't equally true. Just name _one_ out of
history! In practice, it's human stupidity, ignorance and gullibility that
breed wrong doing because it attracts those who are greedy and clever who
take advantage...

>This way of thinking is met with opposition by many because they have
>large investments and stand to lose if the details of their unethical
>strategies and tactics (their "capitalist" success formula) become dinner
>table talk.  It's time to bring the taboo out of the closet.

What in the world do you mean by "out of the closet"? This bilge has been
circulating for centuries and is no "secret".  Wait. "Bilge".

That's it! billg = bilge! Oh criminy, this has been one long troll the whole
time! Or fortune has smiled upon the rest of us, oh billg, for giving you
such an appropriate and revealing username...

Larry

Re: Your english sucks, mine is better.

[billg]

In article <65pcjm$g32@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...

> >Larry you sound like one of the "it's either black or white" people.
> 
> 
> That's because it _is_ either black or white, billg. Gray is nothing more
> than a mixture of black and white. The shade of gray depends only on the
> relative proportions of black and white. Any "gray" situation can be, with
> enough insight and analysis, be reduced to spots of black and white that
> _appear_ gray from a distance. On virtually any issue where there are two or
> more sides, one will find both sides to be gray, usually one somewhat darker
> gray than the other. That is to say, there's both black and white on both
> sides. I'm not claiming that I can successully separate everything, but in
> principle it can be done. If you can prove that it can't be done, I'd like
> to see that.

But again the grey area is used as a means to exploit, for everyone is 
not inclined to examine things in such detail.  The grey area is what 
allows the negative aspects of capitalism to thrive.  Heard the saying 
"read between the lines"?

> 
> >Capitalism perfects dishonesty and unethical behaviour so that it is easy
> >to get away with it (unseen, unclear or takes advantage of scale to wrong
> >many just a little).  The devil is in the tactics (the grey areas of
> >exploitation etc. for example).  Part of the thinking is that everybody
> >is doing it so it is acceptable.  It is not.  That may be a rude
> >awakening for some.
> 
> So how is it any different than French feudalism? Roman imperialism? Russian
> communism?

I don't know.

billg

Re: Your english sucks, mine is better.

[Richard Kenner]

In article <MPG.ee29e258b7bed66989783@news.idt.net> billg@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.

Re: Your english sucks, mine is better.

[Mark Wilden]

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.

Re: Your english sucks, mine is better.

[billg]

In article <3479B760.282B@mWilden.com>, Mark@mWilden.com says...
> 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.
> 
Thank god someone else is able to see reality.

billg

Re: Your english sucks, mine is better.

[Matthew S. Whiting]

Mark Wilden wrote:
> 
> 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.

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.

Re: Your english sucks, mine is better.

[billg]

In article <65bo2c$d9l$1@news.nyu.edu>, kenner@lab.ultra.nyu.edu says...
> In article <MPG.ee29e258b7bed66989783@news.idt.net> billg@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.

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

Re: Your english sucks, mine is better.

[Larry Elmore]

billg@jk.pst.com wrote in message ...
>In article <65bo2c$d9l$1@news.nyu.edu>, kenner@lab.ultra.nyu.edu says...
>> In article <MPG.ee29e258b7bed66989783@news.idt.net> billg@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

Re: Your english sucks, mine is better.

[billg]

In article <65d7i8$jt@netra.montana.edu>, ljelmore@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

Re: Your english sucks, mine is better.

[Larry Elmore]

billg@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.
>
>> 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.

But the examples you cite (and there are much better ones in history) are
examples of attempts to restrict the free market -- anti-capitalist actions,
that is. Those are actions that cannot succeed in the long run without the
aid of government regulations and laws. Unfortunately, many such
anti-capitalist structures have been in place for many years, bought by the
big boys to secure their position by restricting competition. You seem to be
arguing that most people are too greedy and nasty to be trusted to run
companies and corporations (I'm not too hot on corporations either), so we
should what? Turn it all over to a government composed of other greedy,
nasty people? Unless you've got a way to filter them out? At least when the
greedheads/crooks screw up when they're running a company, that's all they
screw up -- the company and those in contact with it. When a government
screws up economically, the whole country and everyone in it is screwed. And
since government has a monopoly on the use of organized force, there's not
much one can do about it, either....

When you put politicians in charge of regulating buying and selling, the
very first things to be bought and sold are politicians....

Larry

Re: Your english sucks, mine is better.

[billg]

In article <65drlj$66g@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> 
> billg@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. 

Again, the definition is one thing, the implementation is another.  
Observe the results of a capitalistic enterprise at any large 
corporation.  Politics rule... everyone else is on 20, 30, 40 yr 
maintenance plans.  The ones on top are kings, the ones on bottom are 
peasants.  The social classification hierarchy is alive and well in big 
business.  Are the ultimate results good or not?  Your _response_ 
probably depends where you stand in the hierarchy, but the simple 
"knowing right from wrong" test may give a different answer.  The ones at 
the top are there (or stay there) because they have successfully "played" 
a large group of people into following them.  Most times these people are 
the manipulators (hence requiring all the corporate controls) and not 
true leaders.  Cat's out of the bag now for those trusting people that 
are the salt of the earth.

> It was capitalism that ended slavery,

Transformed (abstracted) it.

> But the examples you cite (and there are much better ones in history) are
> examples of attempts to restrict the free market -- anti-capitalist actions,
> that is. 

Wealth is being successfully accumulated this way in a capitalistic 
setting.  Period.  Capitalistic "success" is determined between the lines 
of the definition, has been and will continue to be.  Hence one must 
conclude that any original specification or intent is just a facade or 
was never meant to be taken seriously accept as a manipulation device.

> Those are actions that cannot succeed in the long run without the
> aid of government regulations and laws. Unfortunately, many such
> anti-capitalist structures have been in place for many years, bought by the
> big boys to secure their position by restricting competition. You seem to be
> arguing that most people are too greedy and nasty to be trusted to run
> companies and corporations (I'm not too hot on corporations either), so we
> should what? Turn it all over to a government composed of other greedy,
> nasty people? Unless you've got a way to filter them out? At least when the
> greedheads/crooks screw up when they're running a company, that's all they
> screw up -- the company and those in contact with it. When a government
> screws up economically, the whole country and everyone in it is screwed. And
> since government has a monopoly on the use of organized force, there's not
> much one can do about it, either....
> 
> When you put politicians in charge of regulating buying and selling, the
> very first things to be bought and sold are politicians....

A top down approach probably won't work because as we all know, 
corruption floats.  I know.. how about something like "for the people, by 
the people".  They won't like it.  They have guns. 

billg

Re: Your english sucks, mine is better.

[michael]

On Mon, 24 Nov 1997 17:54:41 -0700, "Larry Elmore"
<ljelmore@montana.campus.mci.net> wrote:

>billg@jk.pst.com wrote in message ...
>>In article <65bo2c$d9l$1@news.nyu.edu>, kenner@lab.ultra.nyu.edu says...
>>> In article <MPG.ee29e258b7bed66989783@news.idt.net> billg@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
>


Reality Check!
What does this have to do with Pascal?

Sheesh, i get a sound 'verbal' thrashing for asking a question
that someone else has already asked, yet you guys babble on and on
and on and on about this stupid thread and the good "Dr. S." says
nothing?  No comment from Timo?  

Re: Your english sucks, mine is better.

[billg]

In article <347a2ca1.2305668@news.frontiernet.net>, 
michaelb@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

Re: Your english sucks, mine is better.

[Paul Holden]

but is crossed posted to many other groups.

Re: Your english sucks, mine is better.

[Craig Franck]

billg@jk.pst.com wrote:

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

I don't think that's true in the general case. What I have seen a lot
of is the rosy spin they try to put on everthing. When your health
care benefits are no longer free, but require a contribution from the
employee, they say this is good because "it gives you more choices".
When they don't give pay raises this quarter it means the company is
taking steps to stay competitive and your job is more secure. These
things aren't exactly lies. [I have been directly lied to, but those
folks never seem to stay around very long.]

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

Re: Your english sucks, mine is better.

[Dennis Weldy]

billg@jk.pst.com wrote in message ...
>In article <65bo2c$d9l$1@news.nyu.edu>, kenner@lab.ultra.nyu.edu says...
>> In article <MPG.ee29e258b7bed66989783@news.idt.net> billg@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.
>
>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.

So we can blame racial difficulties, drugs, teen pregnacy and all that on
salesfolks? :-)
Hmm..I'll bet even Saddam Hussein was a salesman at some point.....:-)

>
>billg

Re: Your english sucks, mine is better.

[billg]

In article <s1o4tTg#8GA.145@news2.ingr.com>, nojunkmail@ever.com says...
> 
> So we can blame racial difficulties, drugs, teen pregnacy and all that on
> salesfolks? :-)
> Hmm..I'll bet even Saddam Hussein was a salesman at some point.....:-)

There always has to be an extremist in the bunch over-extrapolating.

billg

Re: Your english sucks, mine is better.

[Boyd Roberts]

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


In article <MPG.ee6332b1771bda798979e@news.idt.net>, billg@jk.pst.com writes:
>In article <s1o4tTg#8GA.145@news2.ingr.com>, nojunkmail@ever.com says...
>> 
>> So we can blame racial difficulties, drugs, teen pregnacy and all that on
>> salesfolks? :-)
>> Hmm..I'll bet even Saddam Hussein was a salesman at some point.....:-)
>
>There always has to be an extremist in the bunch over-extrapolating.
>

    ... the epistemological anarchist has no compunction to defend the most
    trite, or the most outrageous statement. ... he may use reason,
    emotion, ridicule, an `attitude of serious concern' and whatever other
    means have been invented by humans to get the better of their fellow
    men.  His favourite pastime is to confuse rationalists ...  There is no
    view, however `absurd' or `immoral', he refuses to consider or to act
    upon, and no method is regarded as indispensable.

    -Paul K Feyerabend "Against Method"

-- 
Boyd Roberts <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: qa@interbrix.com

Re: Your english sucks, mine is better.

[billg]

In article <65jhvv$h4s$5@route1.mdrf.france3.fr>, boyd@france3.fr says...

>     ... the epistemological anarchist has no compunction to defend the most
>     trite, or the most outrageous statement. ... he may use reason,
>     emotion, ridicule, an `attitude of serious concern' and whatever other
>     means have been invented by humans to get the better of their fellow
>     men.  His favourite pastime is to confuse rationalists ...  There is no
>     view, however `absurd' or `immoral', he refuses to consider or to act
>     upon, and no method is regarded as indispensable.
> 
>     -Paul K Feyerabend "Against Method"
> 

So now we have a start to the formal definition of unethical 
employers/managers?

billg

Re: Your english sucks, mine is better.

[Steven Read]

On Fri, 28 Nov 1997 16:52:51 -0600, billg@jk.pst.com wrote:

>In article <65jhvv$h4s$5@route1.mdrf.france3.fr>, boyd@france3.fr says...
>
>>     ... the epistemological anarchist has no compunction to defend the most
>>     trite, or the most outrageous statement. ... he may use reason,
>>     emotion, ridicule, an `attitude of serious concern' and whatever other
>>     means have been invented by humans to get the better of their fellow
>>     men.  His favourite pastime is to confuse rationalists ...  There is no
>>     view, however `absurd' or `immoral', he refuses to consider or to act
>>     upon, and no method is regarded as indispensable.
>> 
>>     -Paul K Feyerabend "Against Method"
>> 
>
>So now we have a start to the formal definition of unethical 
>employers/managers?
>
>billg


Have you ever thought about switching this subject over to 
the  _alt.bs.managment_   newsgroup?

Re: Your english sucks, mine is better.

[Peter Seebach]

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

Re: Your english sucks, mine is better.

[Lawrence Kirby]

In article <65ckg3$9b7$3@darla.visi.com>
           seebs@plethora.net "Peter Seebach" writes:

>In article <MPG.ee2636b141efc8b989781@news.idt.net>,  <billg@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 | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

Re: Your english sucks, mine is better.

[Andrew Koenig]

In article <MPG.ee2636b141efc8b989781@news.idt.net>,  <billg@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
				  ark@research.att.com
				  http://www.research.att.com/info/ark

Re: Your english sucks, mine is better.

[billg]

In article <EK5KMz.B41@research.att.com>, ark@research.att.com says...
> In article <MPG.ee2636b141efc8b989781@news.idt.net>,  <billg@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
> 				  ark@research.att.com
> 				  http://www.research.att.com/info/ark
> 
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

Re: Your english sucks, mine is better.

[Dennis Weldy]

billg@jk.pst.com wrote in message ...
>In article <EK5KMz.B41@research.att.com>, ark@research.att.com says...
>> In article <MPG.ee2636b141efc8b989781@news.idt.net>,  <billg@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
>>   ark@research.att.com
>>   http://www.research.att.com/info/ark
>>
>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.

Ah. So y'dont ask for references when hring someone, or about past job
performance, or even verify job history?

Sure, "one's past' should be able to be "lived down", depending on what it
is. :-) But....

It's for practical reasons:
    * if you hire someone, you'll have to spend time training them on the
project.
    * they'll have to work well witht he othrs in your group.
    * you'll be paying them.

Don't y'think its a responsible thing to do to verify what a prospective
employee says?
And yes, postings in technical newsgroups can be used as a measure. :-)
Even the non-technical stuff can give one a good idea of the persons
communication skills and how
one handles disagreements. Should it be the sole judge? Nah.

If y'hire someone, and they turn out to be "difficult" or a bad fit, or
doesnt get alog well with anyone in the org, eventually you;ll have to let
the person go...and that time & money wouldve been wasted. :-)

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

Maybe. Of course some "difficult" employees are just difficult. :-)
It's just as likely that difficult person was NOT "beyond the average" or
have higher ethical standards. Really, on what do you base your above
comments? :-)

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

Hmm..is it my job to try to understand how you really are, or your job to
show me how you really are? ;-)

Ah..so the leaders dont lead. How cunning!

Yeah, there are those who will backbite, oppress, unethically manipulate and
whatever else.
There are also those who will NOT do those things, and will rise on
achivement alone.
At least, thats what I've seen where I work.
If you wind up working for the former....I'd suggest looking for a new job.
:-)

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

Re: Your english sucks, mine is better.

[billg]

In article <tY$Doig#8GA.221@news2.ingr.com>, nojunkmail@ever.com says...
> Ah. So y'dont ask for references when hring someone, or about past job
> performance, or even verify job history?

No.

> 
> Sure, "one's past' should be able to be "lived down", depending on what it
> is. :-) But....
> 
> It's for practical reasons:
>     * if you hire someone, you'll have to spend time training them on the
> project.
>     * they'll have to work well witht he othrs in your group.
>     * you'll be paying them.
> 
> Don't y'think its a responsible thing to do to verify what a prospective
> employee says?

No.  If you can't tell whether a person is being honest or ask _that 
person_ more questions to verify, or give opportunity, then you should be 
one to hire people (I know, this is OPINION, YMMV).  The moment you 
"check up" on someone, you have broken a potential trusting relationship.  
Expect less than working toward common goals.

> And yes, postings in technical newsgroups can be used as a measure. :-)
> Even the non-technical stuff can give one a good idea of the persons
> communication skills and how
> one handles disagreements. Should it be the sole judge? Nah.
> 
> If y'hire someone, and they turn out to be "difficult" or a bad fit, or
> doesnt get alog well with anyone in the org, eventually you;ll have to let
> the person go...and that time & money wouldve been wasted. :-)

There are no bad employees, just bad managers.

> Maybe. Of course some "difficult" employees are just difficult. :-)

There are no bad employees, just bad managers.

> It's just as likely that difficult person was NOT "beyond the average" or
> have higher ethical standards. Really, on what do you base your above
> comments? :-)

OK, so I forgot to add that the person may be very ambitious.  That 
doesn't mean they are "difficult" or even that it is their fault for not 
"seeing" everything.  But you as "manager" have no excuse.  It is your 
fault.  Especially for not handling the situation appropriately by taking 
the all to often used "you're difficult, you're fired".  Perhaps, for 
instance, you "forgot" (conveniently forgot in order to play the odds 
that you would be able to excercise control over the individual or force 
him/her to follow you) to explain that your machine was such that people 
are only machine parts and their inherent worth is not valued. ;)

There are no bad employees, just bad managers.

> Hmm..is it my job to try to understand how you really are, or your job to
> show me how you really are? ;-)

Is it really that difficult for you?  Here you go: assume people are 
inherently "good".  That should get you started.

> 
> Ah..so the leaders dont lead. How cunning!

Less (no?) leaders get to the top within a company they don't own than 
those who cleverly play the game (game of manipulating the leaders!).

> 
> Yeah, there are those who will backbite, oppress, unethically manipulate and
> whatever else.

Ah, the typical "manager" in practice!  (Driven by constant denial and 
desire to be above others).

> There are also those who will NOT do those things, and will rise on
> achivement alone.
> At least, thats what I've seen where I work.
> If you wind up working for the former....I'd suggest looking for a new job.
> :-)

The former is in ample supply, the latter rare.

billg

Re: Your english sucks, mine is better.

[Peter Seebach]

In article <MPG.ee63d42d1ce4d798979f@news.idt.net>,  <billg@jk.pst.com> wrote:
>There are no bad employees, just bad managers.

I disagree, having met bad employees.  I will grant, I've met more bad
managers...

Still, I've met people who start by lying about what they can do, and
then try to cover up for it.  Now, you can blame part of this on the
manager not inspiring them, or firing them if they won't work, but the
employee is responsible for some of this too...

>Is it really that difficult for you?  Here you go: assume people are 
>inherently "good".  That should get you started.

It is a very good model.

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

Re: Your english sucks, mine is better.

[billg]

In article <65iclc$cms$5@darla.visi.com>, seebs@plethora.net says...
> In article <MPG.ee63d42d1ce4d798979f@news.idt.net>,  <billg@jk.pst.com> wrote:
> >There are no bad employees, just bad managers.
> 
> I disagree, having met bad employees.  I will grant, I've met more bad
> managers...
> 
> Still, I've met people who start by lying about what they can do, and
> then try to cover up for it.  Now, you can blame part of this on the
> manager not inspiring them, or firing them if they won't work, but the
> employee is responsible for some of this too...

My guess is the person was, in most instances, not lying but rather 
"believed" he/she could do it (shine; take a short term risk to realize 
longer term results, for example) given the opportunity.  Given enough 
time, I'll bet they could have too.  Other times visions of what is 
required, agreed to and what the potentials are, are seriously 
misinterpretted by one or both parties.  Nothing to resort to name 
calling or ill feelings about however.  It's just learning.  It takes a 
pretty "big" person to give someone real opportunity for achievement, 
self-worth etc.  Sometimes doing good may cost you something in the short 
term.  But in the fast-food age I realize this is idealistic.

billg

Re: Your english sucks, mine is better.

[Peter Seebach]

In article <MPG.ee905f464138d6c9897aa@news.idt.net>,  <billg@jk.pst.com> wrote:
>> Still, I've met people who start by lying about what they can do, and
>> then try to cover up for it.  Now, you can blame part of this on the
>> manager not inspiring them, or firing them if they won't work, but the
>> employee is responsible for some of this too...

>My guess is the person was, in most instances, not lying but rather 
>"believed" he/she could do it (shine; take a short term risk to realize 
>longer term results, for example) given the opportunity.

Nah.  I knew a guy who had never done any real programming, except for
small test programs in Fortran, who put several years of C on his
resume.  He freely admitted he couldn't program if you asked him - after
he got the job, and as long as a manager wasn't around.

>Given enough time, I'll bet they could have too.

After watching him for about two and a half years, I didn't think so.
This is a guy who spent *weeks* writing code to convert DD/MM/YY dates
to "November 25, 1997".  Not to mention that he decided to use YY after
1996.  I believe it took him six months to write a program which selected
file names and ran a conversion program.  He was simply *not a programmer*.
Whatever it is that makes programmers go, he didn't have it.

I think he would have been a fairly good tech writer.

>Other times visions of what is 
>required, agreed to and what the potentials are, are seriously 
>misinterpretted by one or both parties.  Nothing to resort to name 
>calling or ill feelings about however.  It's just learning.  It takes a 
>pretty "big" person to give someone real opportunity for achievement, 
>self-worth etc.  Sometimes doing good may cost you something in the short 
>term.  But in the fast-food age I realize this is idealistic.

I believe there are people who really just aren't getting any better.
I believe some of them will lie about this, because they'd rather have
jobs than not.

I've been in large companies, and I've seen sales reps say "well, I retire
in spring, and I'm going to get a pretty decent pension, so I'm not talking
to any customers any more.  Don't try to give me accounts, I'm not taking
any."  (After some study, they realized the company's firing procedure would
take longer than it would be before he retired and got the pension, so they
gave up and paid him to stay home for six months.)

Yeah, employers suck - but so do at least *some* employees.

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

Re: Your english sucks, mine is better.

[billg]

In article <65nhvg$q49$1@darla.visi.com>, seebs@plethora.net says...

>   He freely admitted he couldn't program if you asked him - after
> he got the job, and as long as a manager wasn't around.

Oops!  I've done that too to avoid being pushed into the techie crowd 
when my main goals/skills/direction are higher level business 
manangement.  C++ on a resume can really hurt the manager.  But your 
instance may be authentic.  I think to prove a point, some will give the 
exceptions as the examples, though.  

Really?  People would _lie_ to program?  Go figure! ;)

> 
> >Given enough time, I'll bet they could have too.
> 
> After watching him for about two and a half years, I didn't think so.
> This is a guy who spent *weeks* writing code to convert DD/MM/YY dates
> to "November 25, 1997".  Not to mention that he decided to use YY after
> 1996.  I believe it took him six months to write a program which selected
> file names and ran a conversion program.  He was simply *not a programmer*.
> Whatever it is that makes programmers go, he didn't have it.
> 
> I think he would have been a fairly good tech writer.

Or perhaps a designer.  I have found that good designers can program 
somewhat, but they are just not efficient enough at it (always looking 
for a better design?) to be on the assembly line.  Always check this 
capability first if the position is open or can use augmentation.

> I believe there are people who really just aren't getting any better.
> I believe some of them will lie about this, because they'd rather have
> jobs than not.

I've had developers who weren't anywhere near superstars also.  But they 
should be able to work too.  It takes all kinds.  Some just need more 
facilitation.  For the critical short-term project, I can see where there 
is a "fit" problem though.
 
> 
> I've been in large companies, and I've seen sales reps say "well, I retire
> in spring, and I'm going to get a pretty decent pension, so I'm not talking
> to any customers any more.  Don't try to give me accounts, I'm not taking
> any."  (After some study, they realized the company's firing procedure would
> take longer than it would be before he retired and got the pension, so they
> gave up and paid him to stay home for six months.)
> 
> Yeah, employers suck - but so do at least *some* employees.

Eventually I may encounter one too, then perhaps I will know.  Most are 
just products of their environment.  And god knows the IT industry is 
less than the moral or ethical high ground.

AP

Re: Your english sucks, mine is better.

[Larry Elmore]

billg@jk.pst.com wrote in message ...
>In article <65iclc$cms$5@darla.visi.com>, seebs@plethora.net says...
>> In article <MPG.ee63d42d1ce4d798979f@news.idt.net>,  <billg@jk.pst.com>
wrote:
>> >There are no bad employees, just bad managers.
>>
>> I disagree, having met bad employees.  I will grant, I've met more bad
>> managers...

I suspect that's because being a good manager requires a lot more of some
skills and personality traits than most employees need. Lord knows I've met
a _lot_ of people who have a difficult enough time keeping _themselves_
organized and coordinated with their coworkers, let alone trying to keep a
group of people working together productively and amicably.

>> Still, I've met people who start by lying about what they can do, and
>> then try to cover up for it.  Now, you can blame part of this on the
>> manager not inspiring them, or firing them if they won't work, but the
>> employee is responsible for some of this too...
>
>My guess is the person was, in most instances, not lying but rather
>"believed" he/she could do it (shine; take a short term risk to realize
>longer term results, for example) given the opportunity.  Given enough
>time, I'll bet they could have too.

Yeah, right. Many times, these are the same people who cheated in school to
get through with higher grades (or even to get through at all). You seem to
be under the persistent delusion that all incompetent, and/or dishonest,
and/or evil people end up as managers, CEO's and shareholders, while all
employees are at worst misunderstood angels. What a crock. I wonder just how
much real-world experience you have? As an employee in some real low-end
jobs, I've worked with some other employees who were scum of the earth.
People who lied, cheated, stole, pawned off as much work as possible on
their co-workers, etc., etc., ad nauseum.

> Other times visions of what is
>required, agreed to and what the potentials are, are seriously
>misinterpretted by one or both parties.  Nothing to resort to name
>calling or ill feelings about however.  It's just learning.  It takes a
>pretty "big" person to give someone real opportunity for achievement,
>self-worth etc.  Sometimes doing good may cost you something in the short
>term. <snip>

So you'd be willing to allow managers the chance to learn, and would be a
"big" person and allow them the opportunity for achievement, self-worth,
etc.? After all, there are no bad managers, just bad employees who can't see
the "big picture" and blame all their problems, including the fact that it
rained on their picnic, on bad management...

Get real. People are people, whether employee or manager or shareholder.
Some are bad, some are good, most are a bit of each.


Larry

Re: Your english sucks, mine is better.

[billg]

In article <65p7v8$f0j@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> billg@jk.pst.com wrote in message ...
> >In article <65iclc$cms$5@darla.visi.com>, seebs@plethora.net says...
> >> In article <MPG.ee63d42d1ce4d798979f@news.idt.net>,  <billg@jk.pst.com>
> wrote:
> >> >There are no bad employees, just bad managers.
> >>
> >> I disagree, having met bad employees.  I will grant, I've met more bad
> >> managers...
> 
> I suspect that's because being a good manager requires a lot more of some
> skills and personality traits than most employees need. Lord knows I've met
> a _lot_ of people who have a difficult enough time keeping _themselves_
> organized and coordinated with their coworkers, let alone trying to keep a
> group of people working together productively and amicably.

Are you making the assumption that "a good team member" is necessarily a 
requirement?  Being good at the details is not really the overriding 
requirement for being a manager.

> I wonder just how
> much real-world experience you have? 

I've made you defensive, sorry.  Give me someone who "knows" vs. someone 
with "experience" any day BTW.  The "experience" argument is usually used 
by those who would like to have control over another by some kind of 
mystical virtue and without having to prove themselves.

billg

Re: Your english sucks, mine is better.

[Larry Elmore]

billg@jk.pst.com wrote in message ...
>ljelmore@montana.campus.mci.net says...
>Are you making the assumption that "a good team member" is necessarily a
>requirement?

Only if you're going to be working as part of a team...

>Being good at the details is not really the overriding
>requirement for being a manager.

I never said that it was...

>> I wonder just how
>> much real-world experience you have?
>
>I've made you defensive, sorry.  Give me someone who "knows" vs. someone
>with "experience" any day BTW.  The "experience" argument is usually used
>by those who would like to have control over another by some kind of
>mystical virtue and without having to prove themselves.

Oops, sorry for having made _you_ defensive. What the hell do you think
"experience" _is_ if it isn't having proved oneself? _You're_ the one
arguing for some mystical virtue on the part of employees ("inherent worth")
and that there is no need for them to have proven themselves in a previous
job! If that isn't mystical, what is? It's kind of hard to have good, solid
experience without knowing what one is doing. Of course one has to have the
requisite knowledge, but _one_ good indicator of that is past job
experience.

Larry

Re: Your english sucks, mine is better.

[billg]

In article <65s24n$8mn@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> billg@jk.pst.com wrote in message ...
> >ljelmore@montana.campus.mci.net says...
> >Are you making the assumption that "a good team member" is necessarily a
> >requirement?
> 
> Only if you're going to be working as part of a team...
> 
> >Being good at the details is not really the overriding
> >requirement for being a manager.
> 
> I never said that it was...
> 
> >> I wonder just how
> >> much real-world experience you have?
> >
> >I've made you defensive, sorry.  Give me someone who "knows" vs. someone
> >with "experience" any day BTW.  The "experience" argument is usually used
> >by those who would like to have control over another by some kind of
> >mystical virtue and without having to prove themselves.
> 
> Oops, sorry for having made _you_ defensive. What the hell do you think
> "experience" _is_ if it isn't having proved oneself?

Experience (when used as an argument for qualification) = just hanging 
around with the right crowd for awhile and learning how to be a 
politician.  Experience (when used as an argument for qualification) = 
overpriced labor.  Give me someone who has learned the right things in 
the minimal amount of time any day.  It reminds me of the DBA that asked 
why I was the PM when she had 12 years of experience as a DBA.  Duh?

> _You're_ the one
> arguing for some mystical virtue on the part of employees ("inherent worth")
> and that there is no need for them to have proven themselves in a previous
> job!

If they know what they're talking about, they know what they're talking 
about.  The other 10% will be acquired in doing.  You over emphasize 
employment-based experience vs. learning based experience.  Employment-
based experience takes too long (too narrow, specific), the example above 
about the DBA applies.  If the employee isn't doing some learning on the 
job, my theory says that you over-hired and that there is a higher 
potential for conflict (since you are no longer providing the 
leadership).


> If that isn't mystical, what is? It's kind of hard to have good, solid
> experience without knowing what one is doing. Of course one has to have the
> requisite knowledge, but _one_ good indicator of that is past job
> experience.

Another example... Employee with "experience" is phenominal with RAD tool 
X, unfortunately he's not too useful anywhere else.  Employee who has 
"learned" knows where certain tasks fit in the project, has a big picture 
view, is capable of producing results beyond the task level, is a top-
down thinker...  If you need a temporary to do RAD-tool-X work, contract 
the "experienced" person.  If you need a long term alliance or partner, 
hire the one who knows something.

I know.. I'm being facetious.  But having seen so many "experienced" 
people less capable than well focused self-learners, I hesitate to 
generalize that "experience" is worth anything.  It may be, but usually 
someone is just trying to use years as an indicator instead of knowledge 
or capability gained.  Especially in IT where knowledge of yesterday's 
technology only has minimal usage today is experience "questionable".

billg ;)

Re: Your english sucks, mine is better.

[billg]

> >Someone illuded to the common practice of a business
> >strategy that is unethical initially to "get ahead" and then play fair
> >(or act like it).  To me that's a good case for forfeiture similar to
> >illegal drug operations.
> >
> >It's not that capitalism is "bad", it's just that in practice it breeds
> >wrong doing because it attracts those who are greedy and clever who take
> >advantage.  It's the perfect crime.  Unfortunately, it's one against
> >humanity.
> 
> Name one system where that isn't equally true. Just name _one_ out of
> history! In practice, it's human stupidity, ignorance and gullibility that
> breed wrong doing because it attracts those who are greedy and clever who
> take advantage...

No, no Larry.  Preying on the weak, the unfortunate, the unknowing is not 
a desireable characteristic.  It should be "bred out".

> 
> >This way of thinking is met with opposition by many because they have
> >large investments and stand to lose if the details of their unethical
> >strategies and tactics (their "capitalist" success formula) become dinner
> >table talk.  It's time to bring the taboo out of the closet.
> 
> What in the world do you mean by "out of the closet"? This bilge has been
> circulating for centuries and is no "secret".  Wait. "Bilge".
> 
> That's it! billg = bilge! Oh criminy, this has been one long troll the whole
> time! Or fortune has smiled upon the rest of us, oh billg, for giving you
> such an appropriate and revealing username...

Nah, you're over thinking.  To the masses, the strategies and tactics are 
successfully applied on every new generation.  It _is_ a secret 
especially perhaps at lower levels of econonic means and education and to 
the trusting young.  Human behaviour is one thing, creating institutional 
and organizational unwritten "policy" to act unethically on a larger 
scale for personal gain is a crime against humanity.  

billg

Re: Your english sucks, mine is better.

[Billy Chambless]

In article <MPG.eea5df9604a05979897b6@news.idt.net>, billg@jk.pst.com writes:
|> In article <65p7v8$f0j@netra.montana.edu>, 

|> ljelmore@montana.campus.mci.net says...
 
|> > I wonder just how
|> > much real-world experience you have? 
 
|> I've made you defensive, sorry.  Give me someone who "knows" vs. someone 
|> with "experience" any day BTW.  The "experience" argument is usually used 
|> by those who would like to have control over another by some kind of 
|> mystical virtue and without having to prove themselves.

Pass the syrup, somebody, the waffling's too dry.

Re: Your english sucks, mine is better.

[Wes Groleau]

> I've made you defensive, sorry.  Give me someone who "knows" vs. someone
> with "experience" any day BTW.  The "experience" argument is usually used
> by those who would like to have control over another by some kind of
> mystical virtue and without having to prove themselves.

Or by someone having experience when confronted by someone who obviously
doesn't have it.  How many people "knew" that larger objects fall faster
when Galileo* announced his "experience" that objects fall at the same
speed?

A man with experience is never at the mercy of a man with an argument.

* I heard that the story of Galileo dropping things from the 
tower of Pisa is a myth.  Anyone have _good_ evidence either way?

Re: Your english sucks, mine is better.

[wjanik]

> * I heard that the story of Galileo dropping things from the
> tower of Pisa is a myth.  Anyone have _good_ evidence either way?

While I don't have quotable PROOF on the tower of Pisa myth, I can offer
you this quotation from Steven Hawking's "A Brief History of Time"

"It is said that Galileo demonstrated that Aristotle's belief was false
by droping weights from the leaning tower of Pisa.  This story is almost
certainly untrue, but Galileo did do something equivalent: he rolled
balls of diferent weights down a smooth slope."

Again, while this isn't really "proof" that the Pisa story was a myth,
it does cast a little more doubt.

Re: Your english sucks, mine is better.

[billg]

In article <65p7v8$f0j@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> >My guess is the person was, in most instances, not lying but rather
> >"believed" he/she could do it (shine; take a short term risk to realize
> >longer term results, for example) given the opportunity.  Given enough
> >time, I'll bet they could have too.

> Yeah, right. Many times, these are the same people who cheated in school to
> get through with higher grades (or even to get through at all). You seem to
> be under the persistent delusion that all incompetent, and/or dishonest,
> and/or evil people end up as managers, CEO's and shareholders, while all
> employees are at worst misunderstood angels. What a crock.

In general, management is more corrupt and unethical in practice than it 
could be.  The problem stems from the fact that most people are not 
followers, so management science has found ways to manipulate people into 
doing things they would normally chose not to.  The foundation principles 
are flawed so that's why the reality sometimes rears its ugly head.  The 
only people that work well together are those that are "similar" (values, 
status etc).  People just don't want to have your way forced upon them.   
Many managers, protecting their ground (elite etc), accept that raping is 
an acceptable practice, though.

> I wonder just how
> much real-world experience you have? As an employee in some real low-end
> jobs, I've worked with some other employees who were scum of the earth.
> People who lied, cheated, stole, pawned off as much work as possible on
> their co-workers, etc., etc., ad nauseum.

Somehow they got the perception that those were the principles of 
survival.  And that there is no hope.   Who do you think gave them that 
way of thinking?  

> 
> > Other times visions of what is
> >required, agreed to and what the potentials are, are seriously
> >misinterpretted by one or both parties.  Nothing to resort to name
> >calling or ill feelings about however.  It's just learning.  It takes a
> >pretty "big" person to give someone real opportunity for achievement,
> >self-worth etc.  Sometimes doing good may cost you something in the short
> >term. <snip>
> 
> So you'd be willing to allow managers the chance to learn, and would be a
> "big" person and allow them the opportunity for achievement, self-worth,
> etc.? After all, there are no bad managers, just bad employees who can't see
> the "big picture" and blame all their problems, including the fact that it
> rained on their picnic, on bad management...

No, a bad manager-in-training has the potential to do too much damage and 
the damage is done _to_ people.  What works for technical activities 
doesn't apply to management.  Those that have to learn management are 
usually the ones who learn how to manipulate.  I don't believe one can be 
trained to be a good manager as they are born not made.  Of course, in 
reality now, the manipulative and deceptive manager is what is being 
solicited many times.  The one to do the dirty work for the officers.  
Management in practice (sigh) is more the unwritten oppressive science 
than anything else.  Management should be only applied when asked for or 
agreed upon otherwise it restricts freedom.

> 
> Get real. People are people, whether employee or manager or shareholder.
> Some are bad, some are good, most are a bit of each.

And all are just products of the environment.  An environment that you 
perhaps helped create and proliferate.  I'm dissappointed with people 
sometimes too.  But mostly with those who _knowingly_ chose wrong over 
right, I have a hard time forgiving those.

billg

Re: Your english sucks, mine is better.

[Mark Wilden]

billg@jk.pst.com wrote:
> 
> The moment you
> "check up" on someone, you have broken a potential trusting relationship.
> Expect less than working toward common goals.

The employer and employed are not working toward common goals. The
employer wants to get the best work out of the employee at the lowest
price. The employee wants to get the most money and benefits from the
employer, preferably without working too many 80 hour weeks.

These goals are opposed. The wonder of capitalism is that by each party
working as selfishly as possible, progress is achieved. It's not always
a pretty sight, though...

Re: Your english sucks, mine is better.

[Craig Franck]

Mark Wilden <Mark@mWilden.com> wrote:
>billg@jk.pst.com wrote:
>> 
>> The moment you
>> "check up" on someone, you have broken a potential trusting relationship.
>> Expect less than working toward common goals.
>
>The employer and employed are not working toward common goals. The
>employer wants to get the best work out of the employee at the lowest
>price. The employee wants to get the most money and benefits from the
>employer, preferably without working too many 80 hour weeks.
>
>These goals are opposed. The wonder of capitalism is that by each party
>working as selfishly as possible, progress is achieved. It's not always
>a pretty sight, though...

That's a pretty bleak picture! I really don't think it's the general
case at all. I think it is to the degree that the employer and the
employee manage to establish common goals and priorities that things
can be said to be working out well. [I have seen many disfunctional
work places -- almost "Lord Of The Flies" type situations -- but
your average work place is more of an exercise in daily frustration
and grappling with the meaninglessness of Western culture as a whole,
than it is a selfish persuit by either party.]

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

Re: Your english sucks, mine is better.

[Mark Wilden]

Craig Franck wrote:
> 
> Mark Wilden <Mark@mWilden.com> wrote:
> >
> >The employer and employed are not working toward common goals. The
> >employer wants to get the best work out of the employee at the lowest
> >price. The employee wants to get the most money and benefits from the
> >employer, preferably without working too many 80 hour weeks.
> >
> >These goals are opposed. The wonder of capitalism is that by each party
> >working as selfishly as possible, progress is achieved. It's not always
> >a pretty sight, though...
> 
> That's a pretty bleak picture! I really don't think it's the general
> case at all. I think it is to the degree that the employer and the
> employee manage to establish common goals and priorities that things
> can be said to be working out well.

Yes, they do have common goals: for one thing, to keep the company in
business. But people are employees and employers for one main reason: to
make money. I think it's a rare employee who truly thinks he's paid what
he's worth, and a rare employer who doesn't think the opposite.

Jobs (was: Re: Your english sucks, mine is better.

[Billy Chambless]

In article <347DEB34.1A90@mWilden.com>, Mark Wilden <Mark@mWilden.com> writes:
 
|> Yes, they do have common goals: for one thing, to keep the company in
|> business. But people are employees and employers for one main reason: to
|> make money.

Money is certainly *a* major reason that people are employess, but not
always *the* major reason. I've turned down job offers that would have
nearly doubled my salary, because my current jobs offer other satisfiers
that are more important to me.

|> I think it's a rare employee who truly thinks he's paid what
|> he's worth, and a rare employer who doesn't think the opposite.

I think in general this is true, but there are exceptions. There's at
least one guy who works for me who is worth a lot more than he's paid.
(Well, duh, this is a university!) Luckily for me, he likes working here
as much as I do!

Re: Jobs (was: Re: Your english sucks, mine is better.

[Amy Williams]

On 28 Nov 1997 16:31:52 GMT, billy@cast.msstate.edu (Billy Chambless)
wrote:
>|> I think it's a rare employee who truly thinks he's paid what
>|> he's worth, and a rare employer who doesn't think the opposite.
>
>I think in general this is true, but there are exceptions. There's at
>least one guy who works for me who is worth a lot more than he's paid.
>(Well, duh, this is a university!) Luckily for me, he likes working here
>as much as I do!

My first job ever was making a web page for a business.  Anyone a few
years older than I would have probably been paid 2 or 3 times as much
as I was for the exact same job, but I thought I was rich after I got
that pay check. :)

--
Amy Williams
epic@aros.net
http://www.aros.net/~epic/
Finger for PGP public key.

Employment ethics (was: Your english sucks, ....)

[Wes Groleau]

> >The employer and employed are not working toward common goals. The
> >employer wants to get the best work out of the employee at the lowest
> >price. The employee wants to get the most money and benefits from the
> >employer, preferably without working too many 80 hour weeks.

THIS employee (speaking) wants the satisfaction of creating or adding
something of quality to the world without losing contact with his wife
and children or seeing them hungry.  And I'm sure I'm not the only one!
And I also believe (or I'd be working somewhere else) that my employer
wants the former (for profit's sake) and the latter (to keep a good
employee from leaving).

Re: Employment ethics (was: Your english sucks, ....)

[Mark Wilden]

Wes Groleau wrote:
> 
> > >The employer and employed are not working toward common goals. The
> > >employer wants to get the best work out of the employee at the lowest
> > >price. The employee wants to get the most money and benefits from the
> > >employer, preferably without working too many 80 hour weeks.
> 
> THIS employee (speaking) wants the satisfaction of creating or adding
> something of quality to the world without losing contact with his wife
> and children or seeing them hungry.  And I'm sure I'm not the only one!
> And I also believe (or I'd be working somewhere else) that my employer
> wants the former (for profit's sake) and the latter (to keep a good
> employee from leaving).

True. However, you didn't address my message. Given a certain level of
(continued) performance from an employee, the employer wants to get that
for the lowest price. Given a certain level of (continued) performance,
the employee wants to receive the highest price. It's those goals that
are not common between employer and employed.

Re: Your english sucks, mine is better.

[Billy Chambless]

In article <347C92F0.152B@mWilden.com>, Mark Wilden <Mark@mWilden.com> writes:
|> billg@jk.pst.com wrote:
|> > 
|> > The moment you
|> > "check up" on someone, you have broken a potential trusting relationship.
|> > Expect less than working toward common goals.
 
|> The employer and employed are not working toward common goals. The
|> employer wants to get the best work out of the employee at the lowest
|> price. The employee wants to get the most money and benefits from the
|> employer, preferably without working too many 80 hour weeks.

|> These goals are opposed. The wonder of capitalism is that by each party
|> working as selfishly as possible, progress is achieved. It's not always
|> a pretty sight, though...

The goals don't have to be all that opposed. Enlightened managers realise
that happy, fulfilled employees are much more productive. Enlightened
employees realise that success for the company *can* mean success for
them. (of course, the more enlightened management is, the more "success
for the company" equates to "success for the employee".)

Enlightened selfishness often can lead to behaviour that seems
altruistic.


[ yuk. I have an urge to set followups to alt.philosophy.objectivism..]

Re: Your english sucks, mine is better.

[Mark Wilden]

Billy Chambless wrote:
> 
> The goals don't have to be all that opposed. Enlightened managers realise
> that happy, fulfilled employees are much more productive. Enlightened
> employees realise that success for the company *can* mean success for
> them. (of course, the more enlightened management is, the more "success
> for the company" equates to "success for the employee".)

There has to be a balance between employee wages and owner profits. To
at least some degree, if you increase one you must decrease the other.
Both want slices from the same pie.

Re: Your english sucks, mine is better.

[Spaceman Spiff!]

Mark Wilden wrote:
> 
> Billy Chambless wrote:
> >
> > The goals don't have to be all that opposed. Enlightened managers realise
> > that happy, fulfilled employees are much more productive. Enlightened
> > employees realise that success for the company *can* mean success for
> > them. (of course, the more enlightened management is, the more "success
> > for the company" equates to "success for the employee".)
> 
> There has to be a balance between employee wages and owner profits. To
> at least some degree, if you increase one you must decrease the other.
> Both want slices from the same pie.

Two things come to mind here:
1> Companies are usually not that concerned with employee wages, as
they are concerned with _Shareholder Return_  Now, look at the radical 
movements in the market, and you can see that it's mostly immediate 
gradification which control stock price.
High level Managers have developed a system to protect themselves
after short-sighted cuts have burned up any extra margins they
generate (which yeild the immediate gradification demand of the stock
market).  It's called the "Golden Parachute"

The last company I worked for used up 5 CEO's in 3 years, each time
one bailed out, they figured they needed to up the ante to get the next
one.  Guess where in the pie that money came from.
Now the company is gone.

2> The other thing is a quote from Dilbert:
"The companies woes are your fault, not managements. Do you realize 
 how much you could gain personally be making the company
 a success?"
"I'd get a nice plaque in a plastic frame"
"Yeah, I was hoping you didn't know"

-Scotty

Your boss sucks, mine is better (was: Your english sucks, mine is better.

[Billy Chambless]

In article <347DEBB2.5B6A@mWilden.com>, Mark Wilden <Mark@mWilden.com> writes:
|> Billy Chambless wrote:

|> > The goals don't have to be all that opposed. Enlightened managers realise
|> > that happy, fulfilled employees are much more productive. Enlightened
|> > employees realise that success for the company *can* mean success for
|> > them. (of course, the more enlightened management is, the more "success
|> > for the company" equates to "success for the employee".)
 
|> There has to be a balance between employee wages and owner profits. To
|> at least some degree, if you increase one you must decrease the other.
   ^^^^^^^^^^^^^^^^^^^^^

To at least some degree. But it's certainly not a simple matter of
dividing a finite amount of money.

|> Both want slices from the same pie.

A well-run company can give employees a stake in making the pie itself
bigger -- profit sharing, bounuses, stock options, yadda yadda. All this
varies depending on the size and type of the ogranization, but I think
the general principle is the same.

And there are other rewards in addition to money -- working environment,
autonomy, etc. My feeling at my job is usually that the better job I do,
the more I'll get of all the things I want.

Re: Your boss sucks, mine is better (was: Your english sucks, mine is better.

[Mark Wilden]

Billy Chambless wrote:
> 
> To at least some degree. But it's certainly not a simple matter of
> dividing a finite amount of money.

I believe it is, after you've given the employee enough to keep him
working productively.

> A well-run company can give employees a stake in making the pie itself
> bigger -- profit sharing, bounuses, stock options, yadda yadda. All this
> varies depending on the size and type of the ogranization, but I think
> the general principle is the same.

Of course, this "general principle" doesn't apply at all to the majority
of jobs in the world. Only those of us lucky enough to have relatively
rare talents can hope for profit-sharing (BTW, I think the fact that
"profit-sharing" is optional proves my point).

> My feeling at my job is usually that the better job I do,
> the more I'll get of all the things I want.

I'll bet your boss loves you. :) And you must work a _lot_ of 80 hour
weeks, because that makes you a more productive worker, hence doing "a
better job." The only thing is, there's more to life than work, and work
and play are themselves exclusive to a great extent.

Re: Your boss sucks, mine is better (was: Your english sucks, mine is better.

[Peter Seebach]

In article <347F25CE.2ABC@mWilden.com>, Mark Wilden  <Mark@mWilden.com> wrote:
>I'll bet your boss loves you. :) And you must work a _lot_ of 80 hour
>weeks, because that makes you a more productive worker, hence doing "a
>better job." The only thing is, there's more to life than work, and work
>and play are themselves exclusive to a great extent.

I dunno - a lot of the things I do for fun are ones I can get paid for.

80 hour work weeks are not especially productive; indeed, people who work
too many hours are less productive than people who work closer to 40.

I doubt most people can sustain productive brain-work for very long,
or do it most of the time without needing breaks.  Long ones.  :)

I knew a manager who thought the company was best served by people working
six days a week, 8-10 hours a day, or more, and was, himself, in at least
60 hours a week.  He sucked.  His employees struggled, they botched, they
didn't think clearly.  Weeks were wasted.

Horrible management philosophy.

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

Re: Your boss sucks, mine is better (was: Your english sucks, mine is better.

[Mark Wilden]

Peter Seebach wrote:
> 
> I dunno - a lot of the things I do for fun are ones I can get paid for.

That's true. Some of the funnest things I do in life are while I'm
working. But you have to admit that people in jobs like yours and mine
are _very_ lucky. Most people just tolerate, if not actually dislike
their jobs.

> 80 hour work weeks are not especially productive; indeed, people who work
> too many hours are less productive than people who work closer to 40.

I don't know what the precise cut-off point is. It's certainly less than
80 and certainly more than 40. And it's not even as cut and dried as
that. One 80 hour week, in isolation, can be more productive than two 40
hour weeks, because of the minimizing of overhead and having to refocus
on the task. On the other hand, four 80 hour weeks in a row may be only
as productive as four 60 hour weeks in a row.

But _in general_, I think it's fair to say that employees would like to
work less for the same pay and employers would like them to work more.

In my part of the industry, at least (games), 80 hour weeks at the end
of the development cycle are required. That's one reason I decided to
become a consultant--so I can avoid that kind of thing. For one thing,
working 80 hours/week in an office doesn't give me time to work on my
own projects, that are _really_ fun. :)

Re: Your boss sucks, mine is better (was: Your english sucks, mine is better.

[Shmuel (Seymour J.) Metz]

Peter Seebach wrote:
> 
> 80 hour work weeks are not especially productive; indeed, people who work
> too many hours are less productive than people who work closer to 40.

Even 60 hour weeks leave to burnout if sustained.
 
> I doubt most people can sustain productive brain-work for very long,
> or do it most of the time without needing breaks.  Long ones.  :)
> 
> I knew a manager who thought the company was best served by people working
> six days a week, 8-10 hours a day, or more, and was, himself, in at least
> 60 hours a week.  He sucked.  His employees struggled, they botched, they
> didn't think clearly.  Weeks were wasted.

Well, the worst wrecks I've seen were when management isn't forcing you
to work too many hours, but you want the project to succeed so badly
that it warps your judgement of what your own limits are. It's sobering
to find out that hard way that you aren't Superman :-(

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

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

Re: Your boss sucks, mine is better (was: Your english sucks, mine is better.

[Christian Bau]

In article <34835BC4.1B96@gsg.eds.com>, nospam@gsg.eds.com wrote:

> Peter Seebach wrote:
> > 
> > 80 hour work weeks are not especially productive; indeed, people who work
> > too many hours are less productive than people who work closer to 40.
> 
> Even 60 hour weeks leave to burnout if sustained.
>  
> > I doubt most people can sustain productive brain-work for very long,
> > or do it most of the time without needing breaks.  Long ones.  :)
> > 
> > I knew a manager who thought the company was best served by people working
> > six days a week, 8-10 hours a day, or more, and was, himself, in at least
> > 60 hours a week.  He sucked.  His employees struggled, they botched, they
> > didn't think clearly.  Weeks were wasted.
> 
> Well, the worst wrecks I've seen were when management isn't forcing you
> to work too many hours, but you want the project to succeed so badly
> that it warps your judgement of what your own limits are. It's sobering
> to find out that hard way that you aren't Superman :-(

From a book of the late Eysenck: It was found that people working 57 hours
a week were less productive than people working 42 hours a week. Not only
doing less work per hour, but doing absolutely less work. 

Another quote: "You can force people do be in the company more than 40
hours a week, but you cant force them to work more than 40 hours a week".

Re: Your boss sucks, mine is better (was: Your english sucks, mine is better.

[billg]

In article <65mrcg$fmu$1@NNTP.MsState.Edu>, billy@cast.msstate.edu 
says...

> A well-run company can give employees a stake in making the pie itself
> bigger -- profit sharing, bounuses, stock options, yadda yadda. All this
> varies depending on the size and type of the ogranization, but I think
> the general principle is the same.
> 
> And there are other rewards in addition to money -- working environment,
> autonomy, etc. My feeling at my job is usually that the better job I do,
> the more I'll get of all the things I want.
> 
All in all, face it: as an employee, you get the short end of the stick 
most times and throughout your life your time spent as an employee is 
spent giving up your life for someone else.  The more skilled you are, 
the worse the situation is.  Certainly many people need or just want to 
be just "adequately" compensated and taken care of.  But, especially in 
today's high-tech arena, most (many) would prefer to capitalize on their 
skills without limitations.  This is not possible with most employee 
agreements.  And there isn't an employer around that is going to "clue-
in" anyone.  

Hence we have capitalism as an unethical practice of manipulation as 
opposed to a process that leads to development of people, provides 
opportunity, makes the US strong etc.  A step in the right direction is 
to reduce the politicing and increase production; reward ethical 
behaviour and leadership and reject the opposites.  Many ways to approach 
the problem but the greedy enemy is formidable.  Best way of all.. just 
do it: be a good example.

billg

Re: Your english sucks, mine is better.

[Craig Franck]

Mark Wilden <Mark@mWilden.com> wrote:
>Billy Chambless wrote:
>> 
>> The goals don't have to be all that opposed. Enlightened managers realise
>> that happy, fulfilled employees are much more productive. Enlightened
>> employees realise that success for the company *can* mean success for
>> them. (of course, the more enlightened management is, the more "success
>> for the company" equates to "success for the employee".)
>
>There has to be a balance between employee wages and owner profits. To
>at least some degree, if you increase one you must decrease the other.
>Both want slices from the same pie.

But it's not necessarily a zero-sum game. Profit margins can rise
fast enough to satisfy owner's desire for profits and, at the same
time, allow them to share the wealth with the employees. This is
especially true when people are compensated with stock that later
goes through the roof. It is also true with bonus plans tied to
windfall profits. Some very talent intensive organizations consider
the signing and keeping of key people almost as an investment in
infrastructure.

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

Re: Your english sucks, mine is better.

[Mark Wilden]

Craig Franck wrote:
> 
> But it's not necessarily a zero-sum game.

No, I carefully avoided using that term. :)

However, there are _parts_ that are indeed zero-sum. Such a case is the
distribution of profits. You're selling everything you can make, you've
attracted and kept the best employees you can, your costs are as low as
you can make them--now you've got a certain sum of money: the profit.
Who gets it, the employees or the employers? Obviously, the employers
(more accurately, the owners).

> Profit margins can rise
> fast enough to satisfy owner's desire for profits

Are owners' desires for profits ever satisfied? :) My own desire for
salary certainly isn't.

> and, at the same
> time, allow them to share the wealth with the employees.

The _only_ reason they'd do that is to make sure they kept valuable
employees. They'll pay the absolute minimum necessary to do this. To do
otherwise would simply be philanthropy, and they'd probably go out of
business.

> This is
> especially true when people are compensated with stock that later
> goes through the roof.

As a beneficiary of such compensation, I understand that very well. But
where I made a paltry quarter of a million, the owners of the company
made much more.

> It is also true with bonus plans tied to
> windfall profits. Some very talent intensive organizations consider
> the signing and keeping of key people almost as an investment in
> infrastructure.

Absolutely. We're not talking slave labor, here. My point is simply that
it's the employer's job to reduce costs, other things being equal. After
a minimum point at which the employee is "satisfied," it's indeed
zero-sum: the more the employee gets, the less the owner gets.

Re: Your english sucks, mine is better.

[billg]

In article <347E4203.2A5E@mWilden.com>, Mark@mWilden.com says...
> However, there are _parts_ that are indeed zero-sum. Such a case is the
> distribution of profits. You're selling everything you can make, you've
> attracted and kept the best employees you can, your costs are as low as
> you can make them--now you've got a certain sum of money: the profit.
> Who gets it, the employees or the employers? Obviously, the employers
> (more accurately, the owners).

If the owners are the key people and not just administrators or 
investors, I can see the owners getting most of the profits.  However, in 
practice, owners simply siphon the fruits of others' labor.  The business 
simply operates as a tax collecting (for the owner) mechanism.

> As a beneficiary of such compensation, I understand that very well. But
> where I made a paltry quarter of a million, the owners of the company
> made much more.

Live and learn, your employers/managers are not your friends/family, they 
are the opposite (many times in practice).  Your case: you do the 
work, perhaps all of it, are the key to the windfall, they retire (or you 
support their lifestyle) but you get to go looking for another job.

> 
> My point is simply that
> it's the employer's job to reduce costs, other things being equal. 

This is an assumption that (when applied to human issues) proliferates 
abuse via greedy temptation.  The employee as a cost scenario leads to 
repressing (by the unethical) the employee so that he does feel 
adequately compensated; condescending attitude, devalueing skills etc.  
Read: cost reduction tactics for unethical employers; negotiation without 
concern for the individual.  It indeed seeks to compensate the employee 
for even less than his perceived value (screwing someone over 101), not 
too mention not paying for his actual value.

billg

Re: Your english sucks, mine is better.

[John Hannon]

Mark Wilden wrote:
> 
> Craig Franck wrote:
> >
snip
> 
> > Profit margins can rise
> > fast enough to satisfy owner's desire for profits
> 
> Are owners' desires for profits ever satisfied? :) My own desire for
> salary certainly isn't.
> 
> > and, at the same
> > time, allow them to share the wealth with the employees.
> 
> The _only_ reason they'd do that is to make sure they kept valuable
> employees. They'll pay the absolute minimum necessary to do this. To do
> otherwise would simply be philanthropy, and they'd probably go out of
> business.
> 
> > This is
> > especially true when people are compensated with stock that later
> > goes through the roof.
> 
> As a beneficiary of such compensation, I understand that very well. But
> where I made a paltry quarter of a million, the owners of the company
> made much more.
> 
> > It is also true with bonus plans tied to
> > windfall profits. Some very talent intensive organizations consider
> > the signing and keeping of key people almost as an investment in
> > infrastructure.
> 
> Absolutely. We're not talking slave labor, here. My point is simply that
> it's the employer's job to reduce costs, other things being equal. After
> a minimum point at which the employee is "satisfied," it's indeed
> zero-sum: the more the employee gets, the less the owner gets.

One situation not addressed in this is employee owned companies, such as
mine (Science Applications International Corporation.)  All stock is in
the hands of employees, so there are no owners other than us.  Decisions
that are good for the company are usually good for me, and vice versa.

John
-- 
John Hannon
Principal Systems Programmer
john.p.hannon@cpmx.saic.com
=============

Re: Your english sucks, mine is better.

[Mark Wilden]

John Hannon wrote:
> 
> One situation not addressed in this is employee owned companies, such as
> mine (Science Applications International Corporation.)  All stock is in
> the hands of employees, so there are no owners other than us.  Decisions
> that are good for the company are usually good for me, and vice versa.

But this is communism! How can the workers possibly know how to run
their own company? You _have_ to have investors and bosses, whose only
contribution is to decide what others should do, and how much profit
they themselves should reap for doing so!

:)

Re: Your english sucks, mine is better.

[Larry Elmore]

Mark Wilden wrote in message <347F2A17.5EDB@mWilden.com>...
>John Hannon wrote:
>>
>> One situation not addressed in this is employee owned companies, such as
>> mine (Science Applications International Corporation.)  All stock is in
>> the hands of employees, so there are no owners other than us.  Decisions
>> that are good for the company are usually good for me, and vice versa.
>
>But this is communism! How can the workers possibly know how to run
>their own company? You _have_ to have investors and bosses, whose only
>contribution is to decide what others should do, and how much profit
>they themselves should reap for doing so!
>
>:)

I never realized that was a requirement of capitalism! :) I'm so
disillusioned...

Seriously, though, if _I_ invested millions into starting up a business (if
I had the millions to invest, and was the sole proprietor), you're damned
right it's going to be run as I see fit to run it! I will hire people to do
specific jobs well, and if they can't or won't, then I'll find someone else
who will. If I'm too blind to take good suggestions, and make bad decisions,
alienate my employees to the point that all the good ones leave and I go out
of business, well, it was my money at risk, and my loss. If someone else
thinks they can do better, let them start their own business and risk their
own money. They have no business telling me what to do with mine. They're
free to do with theirs as they see fit. If they're successful, that's great!

Larry

Re: Your english sucks, mine is better.

[Mark Wilden]

Larry Elmore wrote:
> 
> Seriously, though, if _I_ invested millions into starting up a business (if
> I had the millions to invest, and was the sole proprietor), you're damned
> right it's going to be run as I see fit to run it!

Of course, one concomitant of this is the old adage "it takes money to
make money." Can there be much doubt that people who are born rich have
more influence on the rest of us than those who are born poor.?

Re: Your english sucks, mine is better.

[Larry Elmore]

Mark Wilden wrote in message <3480929A.5A37@mWilden.com>...
>Larry Elmore wrote:
>>
>> Seriously, though, if _I_ invested millions into starting up a business
(if
>> I had the millions to invest, and was the sole proprietor), you're damned
>> right it's going to be run as I see fit to run it!
>
>Of course, one concomitant of this is the old adage "it takes money to
>make money." Can there be much doubt that people who are born rich have
>more influence on the rest of us than those who are born poor.?

Of course. But that's just a fact of life. It's also true that those that
are born smart will _tend_ to have more influence on the rest of us than
those who are born stupid. Unless, of course, the stupid are born into
positions of power and prestige that they cannot ordinarily lose, such as
into the nobility of old. There used to be a saying in this country,
"Shirtsleeves to shirtsleeves in three generations." It's not quite like
that anymore. It's getting to be more like Europe with hereditary dynasties,
thanks to all the legal and tax protections the extremely rich have
purchased for themselves. David Rockefeller is a good example. If he'd been
born a century ago, he'd have lost his entire vast fortune long before he
reached his current age.

Larry

Re: Your english sucks, mine is better.

[Mark Wilden]

Larry Elmore wrote:
> 
> Of course. But that's just a fact of life.

Not necessarily. There's nothing biologically necessary about inheriting
wealth.

Re: Your english sucks, mine is better.

[Larry Elmore]

Mark Wilden wrote in message <3481D6F1.1E09@mWilden.com>...
>Larry Elmore wrote:
>>
>> Of course. But that's just a fact of life.
>
>Not necessarily. There's nothing biologically necessary about inheriting
>wealth.

Not _biologically_ necessary, but when have children _not_ inherited their
parents' wealth except where the government has decreed such, _and_ uses
force to ensure compliance? As I recall, the "Communist Manifesto" proposed
(where revolution was not a viable option) 10 measures that once
implemented, would lead to the creation of a communist state. #3 was the
abolition of all rights to inheritance. When you die, everything you own
reverts to the state (actually, the small group of elites in control of the
state). Luckily, the US has only partially implemented this despotic inroad
on private property rights, as well as 4 others. Unfortunately, it has
completely implemented #2 (a heavy, graduated income tax), and #5, creation
of a central banking system with sole control of the money supply.

Larry

Re: Your english sucks, mine is better.

[Mark Wilden]

Larry Elmore wrote:
> 
> Mark Wilden wrote in message <3481D6F1.1E09@mWilden.com>...
> >Larry Elmore wrote:
> >>
> >> Of course. But that's just a fact of life.
> >
> >Not necessarily. There's nothing biologically necessary about inheriting
> >wealth.
> 
> Not _biologically_ necessary, but when have children _not_ inherited their
> parents' wealth except where the government has decreed such, _and_ uses
> force to ensure compliance?

Where have people _not_ murdered one another except under those
circumstances? :) You sound like a libertarian, but most of us think
_some_ government is necessary.

(BTW, I would have trimmed comp.lang.ada from this post, but for a
delightful exchange with a member of that group who seemed to think he
owned it. I think he can use all the wisdom of mine he can get.)

Re: Your english sucks, mine is better.

[billg]

In article <65p8j0$f4l@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> Seriously, though, if _I_ invested millions into starting up a business (if
> I had the millions to invest, and was the sole proprietor), you're damned
> right it's going to be run as I see fit to run it! I will hire people to do
> specific jobs well, and if they can't or won't, then I'll find someone else
> who will. If I'm too blind to take good suggestions, and make bad decisions,
> alienate my employees to the point that all the good ones leave and I go out
> of business, well, it was my money at risk, and my loss. If someone else
> thinks they can do better, let them start their own business and risk their
> own money. They have no business telling me what to do with mine. They're
> free to do with theirs as they see fit. If they're successful, that's great!

That's all fine and good, Larry.  And if you are also a leader you will 
be successful.  I think one key is to hire people who care to learn from 
you, perhaps those younger that are on the same path.  

The problem other companies have is that they really have no business 
being in business as all they attempt to do is set up a "front" to get a 
piece (most of it) the pie hoping to extort from some unsuspecting 
leaders.  I liken our industry's behaviour (IT) to the zombies in "The 
Night of the Living Dead" that are fighting over another's entrails.  
It's sick and twisted.

billg

Re: Your english sucks, mine is better.

[Dennis Weldy]

Nah, its only communism if
a) someone forced 'em into emplyee ownership at gunpoint
b) the reward they receive for working hard is more work.

;-)

Dennis

Mark Wilden wrote in message <347F2A17.5EDB@mWilden.com>...
>John Hannon wrote:
>>
>> One situation not addressed in this is employee owned companies, such as
>> mine (Science Applications International Corporation.)  All stock is in
>> the hands of employees, so there are no owners other than us.  Decisions
>> that are good for the company are usually good for me, and vice versa.
>
>But this is communism! How can the workers possibly know how to run
>their own company? You _have_ to have investors and bosses, whose only
>contribution is to decide what others should do, and how much profit
>they themselves should reap for doing so!
>
>:)

Re: Your english sucks, mine is better.

[John Hannon]

Mark Wilden wrote:
> 
> John Hannon wrote:
> >
> > One situation not addressed in this is employee owned companies, such as
> > mine (Science Applications International Corporation.)  All stock is in
> > the hands of employees, so there are no owners other than us.  Decisions
> > that are good for the company are usually good for me, and vice versa.
> 
> But this is communism! How can the workers possibly know how to run
> their own company? You _have_ to have investors and bosses, whose only
> contribution is to decide what others should do, and how much profit
> they themselves should reap for doing so!
> 
> :)

Obviously you have found the reason for our lack of success in the 
marketplace :-)  I guess we'll have to go out and find some 
exploit^h^h^h^h^h^h^h bosses to make us a viable company!

John
-- 
John Hannon
Principal Systems Programmer
john.p.hannon@cpmx.saic.com
=============

Re: Your english sucks, mine is better.

[billg]

In article <347C92F0.152B@mWilden.com>, Mark@mWilden.com says...
> billg@jk.pst.com wrote:
> > 
> > The moment you
> > "check up" on someone, you have broken a potential trusting relationship.
> > Expect less than working toward common goals.
> 
> The employer and employed are not working toward common goals. The
> employer wants to get the best work out of the employee at the lowest
> price. The employee wants to get the most money and benefits from the
> employer, preferably without working too many 80 hour weeks.
> 
> These goals are opposed. The wonder of capitalism is that by each party
> working as selfishly as possible, progress is achieved. It's not always
> a pretty sight, though...
> 
I think this relationship is what will change in the future.  A more 
equal partnership and less classification of society that the current 
practice creates.

billg

Re: Your english sucks, mine is better.

[Larry Elmore]

billg@jk.pst.com wrote in message ...
>In article <tY$Doig#8GA.221@news2.ingr.com>, nojunkmail@ever.com says...
>> Don't y'think its a responsible thing to do to verify what a prospective
>> employee says?
>
>No.  If you can't tell whether a person is being honest or ask _that
>person_ more questions to verify, or give opportunity, then you should be
>one to hire people (I know, this is OPINION, YMMV).  The moment you
>"check up" on someone, you have broken a potential trusting relationship.
>Expect less than working toward common goals.


No wonder no managers live up to your specs -- you require god-like
omniscience (not to mention the patience of a saint). How can you tell
whether a person is a thief, let alone whether or not they'll get along with
other people you've already got working with you? As the man who thinks he
can't be fooled, you're the perfect mark for a good con man...

>> It's just as likely that difficult person was NOT "beyond the average" or
>> have higher ethical standards. Really, on what do you base your above
>> comments? :-)
>
>OK, so I forgot to add that the person may be very ambitious.  That
>doesn't mean they are "difficult" or even that it is their fault for not
>"seeing" everything.  But you as "manager" have no excuse.  It is your
>fault.  Especially for not handling the situation appropriately by taking
>the all to often used "you're difficult, you're fired".  Perhaps, for
>instance, you "forgot" (conveniently forgot in order to play the odds
>that you would be able to excercise control over the individual or force
>him/her to follow you) to explain that your machine was such that people
>are only machine parts and their inherent worth is not valued. ;)

How much work experience have you had? If you've had much, I'm beginning to
suspect that you've been fired multiple times, or at least strongly
encouraged to move on elsewhere. Either that, or this is a troll.

As an employee, I realize I'm being paid to do a certain job. If I don't do
what I'm hired to do, then why should they pay me??? That's the implicit
contract -- I agree to do X, they agree to compensate me with Y. It's a
mutual agreement -- no one is forced to accept a job. If you don't like it,
move on elsewhere or starve. It's not that much different than 10,000 years
ago -- certain things are required for survival. If you didn't want to do
them then (farming's too hard, hunting's too icky, or whatever), you
starved, or more likely, you became a primitive socialist -- those that did
work should share with you simply because you deserved it from your
"inherent worth" as a supposed human being (I'm here and I'm breathing, so
feed me!) -- and if they didn't share voluntarily, you and your other lazy
buddies took it by force. Quite frankly, I've known a _few_ people whose
only "inherent worth" I or anyone else could ever discover was as dog food.
Mostly they're in prison or became worm food and fertilizer.

If you hire a couple of guys to paint your house, what do you expect them to
do? If they ignore your directions, do things as they see fit, choose colors
you think are hideous, get into fights with your neighbors, etc., are _you_
going to pay them? Will you hire them the next time you need that job or
some other job done? Rememebr, there are no bad employees, only bad
managers... Hmmh?

Larry

Re: Your english sucks, mine is better.

[billg]

In article <65pa18$ffc@netra.montana.edu>, 
ljelmore@montana.campus.mci.net says...
> billg@jk.pst.com wrote in message ...
> >In article <tY$Doig#8GA.221@news2.ingr.com>, nojunkmail@ever.com says...
> >> Don't y'think its a responsible thing to do to verify what a prospective
> >> employee says?
> >
> >No.  If you can't tell whether a person is being honest or ask _that
> >person_ more questions to verify, or give opportunity, then you should be
> >one to hire people (I know, this is OPINION, YMMV).  The moment you
> >"check up" on someone, you have broken a potential trusting relationship.
> >Expect less than working toward common goals.
> 
> 
> No wonder no managers live up to your specs -- you require god-like
> omniscience (not to mention the patience of a saint). How can you tell
> whether a person is a thief, let alone whether or not they'll get along with
> other people you've already got working with you? As the man who thinks he
> can't be fooled, you're the perfect mark for a good con man...

The only reason there is so much emphasis on all the "controls" is to 
divert attention from the politics, exploitations etc that are occurring 
_to_ the potential employee.  Most trusting people (most people) are 
taken advantage of this way, as they could not comprehend using such 
behaviour.  If you just play the odds, chances are you will never come up 
with a bad-egg job seeker (assuming you are not just one of the 
extortionist companies).  If you do, chances are that you have caused it.  
Most manager-types are not "touchy feely" and request "just the facts" 
and cannot see beyond.  A little intuition goes a long way.  It's not 
learnable.  You either are or you're not.

> 
> >> It's just as likely that difficult person was NOT "beyond the average" or
> >> have higher ethical standards. Really, on what do you base your above
> >> comments? :-)
> >
> >OK, so I forgot to add that the person may be very ambitious.  That
> >doesn't mean they are "difficult" or even that it is their fault for not
> >"seeing" everything.  But you as "manager" have no excuse.  It is your
> >fault.  Especially for not handling the situation appropriately by taking
> >the all to often used "you're difficult, you're fired".  Perhaps, for
> >instance, you "forgot" (conveniently forgot in order to play the odds
> >that you would be able to excercise control over the individual or force
> >him/her to follow you) to explain that your machine was such that people
> >are only machine parts and their inherent worth is not valued. ;)
> 
> How much work experience have you had? If you've had much, I'm beginning to
> suspect that you've been fired multiple times, or at least strongly
> encouraged to move on elsewhere. Either that, or this is a troll.

At least 15 yrs.  4 at one co.  5 at another.  R&D, engineering, 
planning, hands-on mostly but a wealth of information on organizational 
practice and development gathered.  The rest in various (consulting) and 
also following my own pursuits.  Not just IT though.  But definitely 
related technically.  I don't get any big points for being the techie who 
wrote an OS or compiler over the weekend or anything.  My focus is 
management (generalist) in technical environments with the ultimate goal 
of growing a business.  The business is a lifelong dream and am pursuing 
that now.  I was fired once, but it was more of an agreement that because 
I wouldn't give up technology rights we were probably not a "good fit".  
How right they were!  (I feel so exposed now! Why did you ask me that. ;) 
).

> 
> As an employee, I realize I'm being paid to do a certain job. If I don't do
> what I'm hired to do, then why should they pay me??? That's the implicit
> contract -- I agree to do X, they agree to compensate me with Y. It's a
> mutual agreement -- no one is forced to accept a job. If you don't like it,
> move on elsewhere or starve. It's not that much different than 10,000 years
> ago -- certain things are required for survival.

I agree with the underlying theme here: that most employment should be 
viewed as temporary work until other means are available/possible and not 
"employer as your care taker looking out for your behalf".  It's not like 
marriage, it's more like dating.

> If you didn't want to do
> them then (farming's too hard, hunting's too icky, or whatever), you
> starved, or more likely, you became a primitive socialist -- those that did
> work should share with you simply because you deserved it from your
> "inherent worth" as a supposed human being (I'm here and I'm breathing, so
> feed me!) -- and if they didn't share voluntarily, you and your other lazy
> buddies took it by force. Quite frankly, I've known a _few_ people whose
> only "inherent worth" I or anyone else could ever discover was as dog food.
> Mostly they're in prison or became worm food and fertilizer.
> 
> If you hire a couple of guys to paint your house, what do you expect them to
> do? If they ignore your directions, do things as they see fit, choose colors
> you think are hideous, get into fights with your neighbors, etc., are _you_
> going to pay them? Will you hire them the next time you need that job or
> some other job done? Rememebr, there are no bad employees, only bad
> managers... Hmmh?

Exceptional case given again.  If you have encountered more than your 
share of exceptions, then it's time to look internally.

C'mon Larry you know very well that employment contracts are designed to 
be as good for the employer as possible.  Doing X and Y is fine if agreed 
to.  It's when the hidden clauses and implications are present that 
problems occur.  Those who are trying to be clever in exploiting and 
extorting deserve what they get.  To expect some kind of all-encompassing 
loyalty and sacrifice of all your intellectual possessions just because 
one agreed to do some work for another is silly.  Relationships are built 
over years and not in a few interviews.  Expecting employees to be slaves 
is the road to disaster.  The employer-employee pattern doesn't work.  
That's why we are seeing so many sell their wares as products and 
services: because the employer-employee scenario takes away freedom, 
exploits, extorts etc. and attracts those who are of that mentality to 
become "employers".  Good contracting will force the unscrupulous (sp?) 
to become more honest and be compensated for their own value and not for 
others'.

billg

Re: Your english sucks, mine is better.

[John English]

I'm trying to resist the temptation to join in this monster of a thread
-- argh! euck! it's no good! I can't help it!

Larry Elmore (ljelmore@montana.campus.mci.net) wrote:
: ... It's not that much different than 10,000 years
: ago -- certain things are required for survival. If you didn't want to do
: them then (farming's too hard, hunting's too icky, or whatever), you
: starved, or more likely, you became a primitive socialist -- those that did
: work should share with you simply because you deserved it from your
: "inherent worth" as a supposed human being (I'm here and I'm breathing, so
: feed me!) -- and if they didn't share voluntarily, you and your other lazy
: buddies took it by force ...

In the UK, these are no longer referred to as "primitive socialists";
they (and their lazy buddies) are called names like the Duke of X,
Lord Y and Prince Z. The ones who did the hunting, farming etc. are
known as "peasants" or "commoners".

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Your english sucks, mine is better.

[Larry Elmore]

John English wrote in message <65u2u8$a2u@saturn.brighton.ac.uk>...
>I'm trying to resist the temptation to join in this monster of a thread
>-- argh! euck! it's no good! I can't help it!
>
>Larry Elmore (ljelmore@montana.campus.mci.net) wrote:
>: ... It's not that much different than 10,000 years
>: ago -- certain things are required for survival. If you didn't want to do
>: them then (farming's too hard, hunting's too icky, or whatever), you
>: starved, or more likely, you became a primitive socialist -- those that
did
>: work should share with you simply because you deserved it from your
>: "inherent worth" as a supposed human being (I'm here and I'm breathing,
so
>: feed me!) -- and if they didn't share voluntarily, you and your other
lazy
>: buddies took it by force ...
>
>In the UK, these are no longer referred to as "primitive socialists";
>they (and their lazy buddies) are called names like the Duke of X,
>Lord Y and Prince Z. The ones who did the hunting, farming etc. are
>known as "peasants" or "commoners".


Exactly! Actually, the modern statists (socialists, communists, fascists,
etc.) seem to have the same goal in mind for themselves. "All animals are
created equal, but some animals are more equal than others..." (Napoleon the
Pig?)

This thread is also too long and hideous to continue and I'm retiring from
it... (I'll answer e-mail, though).

Larry

Re: Your english sucks, mine is better.

[Bob O]

On Mon, 1 Dec 1997 10:18:48, je@bton.ac.uk (John English) wrote:

> I'm trying to resist the temptation to join in this monster of a thread
> -- argh! euck! it's no good! I can't help it!
> 
> Larry Elmore (ljelmore@montana.campus.mci.net) wrote:
> : ... It's not that much different than 10,000 years
> : ago -- certain things are required for survival. If you didn't want to do
> : them then (farming's too hard, hunting's too icky, or whatever), you
> : starved, or more likely, you became a primitive socialist -- those that did
> : work should share with you simply because you deserved it from your
> : "inherent worth" as a supposed human being (I'm here and I'm breathing, so
> : feed me!) -- and if they didn't share voluntarily, you and your other lazy
> : buddies took it by force ...
> 
> In the UK, these are no longer referred to as "primitive socialists";
> they (and their lazy buddies) are called names like the Duke of X,
> Lord Y and Prince Z. The ones who did the hunting, farming etc. are
> known as "peasants" or "commoners".

That is because their great great great great great great great great great
great great great great great great great great great great great great 
great great great great great great great great great great great great 
great great Grandfather had a bigger axe.

Then sometime around the 13th Century (if my history memory serves me and I
am sure you can readily correct me if I am wrong) rather than having 
another axe contest, the guys with the next biggest axes signed an 
agreement that formalized the convention for following generations so the 
Big Axe guys could raise children without the need to learn how to use an 
axe. Then other than an occasional quick axing (I guess a few children 
decided to become proficient at the axe anyway) in order to make subtle 
realignments to the convention the foundations of the British system was 
formed.

Now it has generally been an effective system, however, if they had chosen 
to share the wealth a bit more, the United Kingdom would be a lot bigger 
than it is.  The lesson being is if you are into world domination you 
shouldn't be perceived as being too greedy.











Bob O - Computing for fun

News postings and job interviews (was: Re: Your english sucks, mine is better.

[Billy Chambless]

In article <tY$Doig#8GA.221@news2.ingr.com>, "Dennis Weldy" <nojunkmail@ever.com> writes:
|> 
|> billg@jk.pst.com wrote in message ...
|> >In article <EK5KMz.B41@research.att.com>, ark@research.att.com says...

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

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

|> It's for practical reasons:
|>     * if you hire someone, you'll have to spend time training them on the
|> project.
|>     * they'll have to work well witht he othrs in your group.
|>     * you'll be paying them.

...

|> And yes, postings in technical newsgroups can be used as a measure. :-)
|> Even the non-technical stuff can give one a good idea of the persons
|> communication skills and how one handles disagreements. 

Very often, in some of the newsgroups discussions, I'll imagine being in
a design meeting or code review with certain posters. Arrgghghh!

Your point about communications skills and disagreement is very well
taken. As ark pointed out, news posts won't tell you everything about a
person, but they might be useful in highlighting specific flaws, ones
that might be hard to find in an interview:

1. Does the person defend technical points from an emotional stance?
2. Do they take correction personally?
3. Do they tend to change the subject when they feel that they're
    "losing" an argument?

My experience has been that interaction between programmers can often be
ego-bruising, at least until one develops the proper attitude. People
who can't set their egos aside in order to get the job done can be very,
very difficult to work with. Sometimes these people do us a favor by
warning us about them through their netnews postings. ;)

Re: Your english sucks, mine is better.

[Richard A. O'Keefe]

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


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

Re: Your english sucks, mine is better.

[Matt Osborne]

I didn't take the time to read all of the messages but i would prefer that
if you are going to just critisize other people that you do it privately.

Re: Your english sucks, mine is better.

[ANDREAS LEITNER]

Andrew Koenig (ark@research.att.com) wrote:
: 
: 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.

Isn't it a poin,t that the subject of all this newsgroups has something to
do with sience. And even if this is not the case, posters would like the
readers to understand what they wrote (exactly). Therefore it is quite
usefull to use the language correct to make missunderstandings (that maybe
has flaming as consequence) as minimal as possible.

(Please dont flame me on my english, its not my mother langugage)


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

G Moore (was Re: Your english sucks, mine is better.)

[Kaz Kylheku]

In article <34747E35.79AE@no_spam.ip.edu.com>,
Joe C  <Joseph_Cipale@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 :)

Re: G Moore (was Re: Your english sucks, mine is better.)

[Robert S. White]

In article <652hme$lsa$1@helios.crest.nt.com>, kaz@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

Re: G Moore (was Re: Your english sucks, mine is better.)

[Kevin Davis Sr.]

EXCELLENT!

Kevin

Re: Your english sucks, mine is better.

[John Winters]

In article <652aes$63a$1@news01.micron.net>,
Rob Eamon <rre2251@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>

Re: English SUCKS, Chinese is the only language you need!!

[system]

"John Rickard" wrote:
>Davide Bionda <bionda@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

Morphis@physics.niu.edu
Real Women change tires			abuse@uu.net postmaster@uu.net
Real Men change diapers                 security@uu.net

Re: English SUCKS, Chinese is the only language you need!!

[Richard A. O'Keefe]

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


"Dennis Weldy" <nojunkmail@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

Re: English SUCKS, Chinese is the only language you need!!

[Cynthia & Bill]

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 <jeanspayette@videotron.ca> wrote in article
<64suum$5oo$1@weber.videotron.net>...
> 
> John Rickard wrote in message <64sql2$k0@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!!)
> 
> 
> 

Re: English SUCKS, Chinese is the only language you need!!

[tmt]

On 19 Nov 1997 00:54:55 GMT, "Cynthia & Bill" <cbt1213@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 <jeanspayette@videotron.ca> wrote in article
><64suum$5oo$1@weber.videotron.net>...
>> 
>> John Rickard wrote in message <64sql2$k0@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!!)
>> 
>> 
>> 

Re: English SUCKS, Chinese is the only language you need!!

[Mark Wilden]

tmt@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.

Re: English SUCKS, Chinese is the only language you need!!

[Ingemar Ragnemalm]

My God, what a thread. I thought that title said it all:

Don't kick the minority. First, it takes a coward to do so,
and second, you may find yourself in a minority one day yourself.
English vs chinese is just an example, if you only care about
numbers.

Personally I love being in minorities. It is more fun, as long as
they don't get extinct. Wouldn't it be boring if all people in the
world spoke american english, dressed in jeans, ate hamburgers,
drank Coke, programmed in C++ on Intel PC's with Windows, sang
country&western, ... (etc, etc)

Cynthia & Bill wrote:

> Viva la difference!

That's the spirit!

> But I'll (personally) take C over Pascal any day.

You have made a choice, and you know it is your personal choice.
Too many don't choose, they just follow the majority without
thinking, and never care to learn more than one thing.

All I ask more is that you also respect that others choose
different. And perhaps recognize that the other choices actually
have some advantages over your choice.

And now LET'S STOP FUSSING ABOUT THIS! Cut down the number of
newsgroups in every follow-up please!

/Ingemar

Re: English SUCKS, Chinese is the only language you need!!

[Danette & Murray Root]

On Fri, 28 Nov 1997 23:51:48 +0000, Ingemar Ragnemalm <ingemar@lysator.liu.se>
wrote in comp.lang.c:

=> My God, what a thread. I thought that title said it all:
=> 
=> Don't kick the minority. First, it takes a coward to do so,
=> and second, you may find yourself in a minority one day yourself.
=> English vs chinese is just an example, if you only care about
=> numbers.
=> 
=> Personally I love being in minorities. It is more fun, as long as
=> they don't get extinct. Wouldn't it be boring if all people in the
=> world spoke american english, dressed in jeans, ate hamburgers,
=> drank Coke, programmed in C++ on Intel PC's with Windows, sang
=> country&western, ... (etc, etc)
=> 
That's not boring - that's hell. I hate Coke and country&western, Hamburgers
are only good when I cook them. C++ is not as much fun as C and assembler.
Windows is a premature birth (3.x looked more like a still-born, but it was
revived), if it grows up it might be useful.
 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Be Different -
        THINK!

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

http://mroot.home.mindspring.com

Re: English SUCKS, Chinese is the only language you need!!

[Morgan Palaeo Associates]

Ingemar Ragnemalm <ingemar@lysator.liu.se> wrote:
^
| Personally I love being in minorities. It is more fun, as long as
| they don't get extinct. Wouldn't it be boring if all people in the
| world spoke american english, dressed in jeans, ate hamburgers,
| drank Coke, programmed in C++ on Intel PC's with Windows, sang
| country&western, ... (etc, etc)
v

AOL!

(On some global internet communities, 'AOL' is a code term for
'Me too!' or 'I agree!'.  It's not in terribly wide use, however,
hence this explanatory note.)

----------------------------------------------
Morgan Palaeo Associates
Palynological/Petroleum Geological Consultants

  Postal Address:   Box 161, Maitland, South Australia 5573
  Deliveries: 1 Shannon Tce, Maitland, South Australia 5573
  Phone: (08) 8832 2795
  Fax:   (08) 8832 2798

Re: English SUCKS, Chinese is the only language you need!!

[R.E.Donais]

morganpalaeo@peg.apc.org (Morgan Palaeo Associates) wrote:

>AOL!
>
>(On some global internet communities, 'AOL' is a code term for
>'Me too!' or 'I agree!'.  It's not in terribly wide use, however,
>hence this explanatory note.)
>

Its original meaning is America-on-line --- aol.com

The meaning you suggest originates with the numerous AOL members
who contribute little to a discussion and generally do nothing
more than quote articles and append -- 'Me too!' or 'I agree!'.

There's another meaning associated with this.  Kind of an
extension of the above explanation and a play on the first two
letters.  Can you guess what it is?  

I recommend you distance yourself from the acronym altogether.
;-)

    ...red

-- 
Support the anti-Spam amendment
  Join at http://www.cauce.org/

Re: English SUCKS, Chinese is the only language you need!!

[Matt Corey]

Ingemar Ragnemalm wrote:
<snip>

>   C++ on Intel PC's with Windows,  sang country&western,
> |
> ^^^^^^^^^^^^^^^^^^^^

Them's fightin' words!!  ;-)

Yes, this is another pointless post to a pointless thread.


Matt "Capitalist Redneck" Corey

Re: English SUCKS, Chinese is the only language you need!!

[Kaz Kylheku]

In article <64suum$5oo$1@weber.videotron.net>,
Jean-Sebastien Payette <jeanspayette@videotron.ca> wrote:
>
>John Rickard wrote in message <64sql2$k0@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!!)

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

Re: English SUCKS, Chinese is the only language you need!!

[Jerry Sams]

Jean-Sebastien Payette wrote in message
<64suum$5oo$1@weber.videotron.net>...
>
>John Rickard wrote in message <64sql2$k0@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

Re: English SUCKS, Chinese is the only language you need!!

[Billy Chambless]

In article <64sql2$k0@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.

Re: English SUCKS, Chinese is the only language you need!!

[Chieh Cheng]

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 <bionda@erdw.ethz.ch> wrote in article
><3471428A.6193@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.

Re: English SUCKS, Chinese is the only language you need!!

[John Rickard]

When I posted that message my grammar was proper.
-- 
--
Remove "spam" from my
email address to send me REAL email.
--

Chieh Cheng <chiehcheng@iname.com> wrote in article
<34720007.344948449@serve.installshield.com>...
: 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 <bionda@erdw.ethz.ch> wrote in article
: ><3471428A.6193@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.
: 

Re: English SUCKS, Chinese is the only language you need!!

[John Rickard]

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_msmith@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$jpu@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
: 
: 

Re: English SUCKS, Chinese is the only language you need!!

[Gary A. Wiltshire]

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

Re: English SUCKS, Chinese is the only language you need!!

[Chieh Cheng]

On Wed, 19 Nov 1997 15:01:11 GMT, 70523.3077@compuserve.com (Gary A.
Wiltshire) wrote:

>chiehcheng@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.

Re: English SUCKS, Chinese is the only language you need!!

[Mike Smith]

Chieh Cheng <chiehcheng@iname.com> wrote in article
<3472f84b.408504898@serve.installshield.com>...
> On Wed, 19 Nov 1997 15:01:11 GMT, 70523.3077@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

Re: English SUCKS, Chinese is the only language you need!!

[Dennis Weldy]

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.3077@compuserve.com> wrote in message
<3472e573.3440168@news.albany.net>...
>chiehcheng@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

Re: English SUCKS, Chinese is the only language you need!!

[John Rickard]

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 <nojunkmail@ever.com> wrote in article
<32nusbR98GA.70@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.3077@compuserve.com> wrote in message
: <3472e573.3440168@news.albany.net>...
: >chiehcheng@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
: 
: 
: 

Re: English SUCKS, Chinese is the only language you need!!

[Dennis Weldy]

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$88b@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 <nojunkmail@ever.com> wrote in article
><32nusbR98GA.70@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.3077@compuserve.com> wrote in message
>: <3472e573.3440168@news.albany.net>...
>: >chiehcheng@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
>:
>:
>:

Re: English SUCKS, Chinese is the only language you need!!

[Mark Wilden]

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. :)

Re: English SUCKS, Chinese is the only language you need!!

[Kaz Kylheku]

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

Re: English SUCKS, Chinese is the only language you need!!

[system]

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

Morphis@physics.niu.edu
Real Women change tires			abuse@uu.net postmaster@uu.net
Real Men change diapers                 security@uu.net

Re: English SUCKS, Chinese is the only language you need!!

[Matt Corey]

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    mcorey@itsnet.com
Software Engineer
Rigaku USA/MSC  http://www.msc.com

Re: English SUCKS, Chinese is the only language you need!!

[D. Ross]

Matt Corey wrote:
> 
> 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.

We should get Mr. Stroustrup to re-do English... and call it English++. 

Just think how efficient we'd all be if everything we said was
polymorphic, overloaded, object-oriented and templatized!

Only problem, it would take 10 minutes to think of (compile) a sentence
before we said it.

And everyone's speech center (compiler) would perpetually be one version
behind the Standard.


-- 
derekr@escape.ca
Derek Ross

Re: English SUCKS, Chinese is the only language you need!!

[Spaceman Spiff]

D. Ross wrote:
> 
> Matt Corey wrote:
> >
> > 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.
> 
> We should get Mr. Stroustrup to re-do English... and call it English++.
> 
> Just think how efficient we'd all be if everything we said was
> polymorphic, overloaded, object-oriented and templatized!

Oh yeah!  I'd just love to overload some nouns!
Having several potential meanings for gault would make life easier.

:-)

-Scotty

Re: English SUCKS, Chinese is the only language you need!!

[Mark Wilden]

D. Ross wrote:
> 
> Just think how efficient we'd all be if everything we said was
> polymorphic, overloaded, object-oriented and templatized!

Language is already all of those things. That's one reason why OOP is,
in general, a good way to program--it's closer to the way people think.

Re: English SUCKS, Chinese is the only language you need!!

[William Rapp]

In comp.lang.c Mark Wilden <Mark@mWilden.com> wrote:
: D. Ross wrote:
: > 
: > Just think how efficient we'd all be if everything we said was
: > polymorphic, overloaded, object-oriented and templatized!

: Language is already all of those things. That's one reason why OOP is,
: in general, a good way to program--it's closer to the way people think.

AND IF THEY NEVER LEARN TO WRITE REAL CODE (BECOME DEPENDANT), 
ARE LIMITED TO SOMEONE ELSES SQUARE PEG IN A ROUND HOLE.

-AS

Re: English SUCKS, Chinese is the only language you need!!

[Kaz Kylheku]

In article <64vpcn$ni7@corn.cso.niu.edu>,
 <system@niuhep.physics.niu.edu> wrote:
>kaz@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?

Re: English SUCKS, Chinese is the only language you need!!

[Boyd Roberts]

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


In article <650je4$s5p$1@helios.crest.nt.com>, kaz@helios.crest.nt.com (Kaz Kylheku) writes:
>In article <64vpcn$ni7@corn.cso.niu.edu>,
> <system@niuhep.physics.niu.edu> wrote:
>>kaz@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: fred@ultramax.net

Re: English SUCKS, Chinese is the only language you need!!

[michael j tobler]

This thread is started to suck, let's move on ...
--
blue skies
michael j. tobler,  mailto:mjtobler@ix.netcom.com

system@niuhep.physics.niu.edu wrote:

> kaz@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
>
> Morphis@physics.niu.edu
> Real Women change tires                 abuse@uu.net postmaster@uu.net
> Real Men change diapers                 security@uu.net

Re: English SUCKS, Chinese is the only language you need!!

[Mark Wilden]

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.

Re: English SUCKS, Chinese is the only language you need!!

[Jeffrey George]

This is a defunct thread which has, at this point, absolutely nothing to
do with ada, c, or c++, but I couldn't help but be intrigued enough to
respond to all the same newsgroups where it appeared. Here's my two
cents:

Mark Wilden wrote:
> 
> 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"?

I'm not sure I follow your logic here; are you saying that there must be
a difference between, "re-animate" and "reanimate", simply because they
are written differently? Surely you don't mean to suggest the converse,
that words which are pronounced and written identically must always have
the same meaning? It might be a shock to the pope to find that he was
periodically releasing a big, smelly, male animal, when all he meant to
do was make an official publication! Well fortunately for the pope, we
differentiate "bull" from "bull", and there is very little confusion.

Once an expression, like "re-activate", enters common usage, the hyphen
vanishes because the word "reactivate" is adopted as part of the common
vocabulary which no longer needs to be clarified by the visual breakdown
of its morphological components. In other words, from a historical
viewpoint, the hyphen is a temporary convenience used to facilitate the
entry of new words into the language's phonological writing system.

Jeff
-- 
----------------
Jeff George
jgeorge@texas.net
When all other means of communication fail, try words.

Re: English SUCKS, Chinese is the only language you need!!

[Mark Wilden]

Jeffrey George wrote:
> 
> I'm not sure I follow your logic here; are you saying that there must be
> a difference between, "re-animate" and "reanimate", simply because they
> are written differently?

No, there doesn't have to be a difference in all cases. In some case,s
though, there is a difference: re-lease and release, e.g.

At any rate, this began when someone used a space between "re" and
another word, and this is incorrect.

Re: English SUCKS, Chinese is the only language you need!!

[Denny]

On 19 Nov 1997 10:44:35 -0800, kaz@helios.crest.nt.com (Kaz Kylheku)
wrote:

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

No native speaker of English would make such a blunder?
Blunder implies unintentional.  Evidently you be forgetting about
Ebonics.  I be, you be, he be, we be, they be.  All correct and proper
in some circles.  ;-)

Re: English SUCKS, Chinese is the only language you need!!

[Les Hazlewood]

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.
> 
> 2) "spoke" should be "spoken."
> 
> 3) In "around 1-3", "around" is redundant.
> 
> Hey, you asked. :)


Their his know knead too no ow too right English  :-)

-- 
Ignore the anti-spamming address given above and sent any replies to:

Email : hazlewlj@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

Re: English SUCKS, Chinese is the only language you need!!

[Mike Smith]

John Rickard <saskan@worldnet.att.net.DONTSPAMME> wrote in article
<64sql2$k0@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

Re: English SUCKS, Chinese is the only language you need!!

[John R. Reagan]

In article <YSQz$BJ98GA.158@news2.ingr.com>, "Dennis Weldy" <nojunkmail@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
reagan@hiyall.enet.dec.com
Disclaimer:  The opinions and statements expressed by me are not
             necessarily those of Digital Equipment Corporation.
--

Re: English SUCKS, Chinese is the only language you need!!

[John R. Reagan]

In article <3473407e.17757163@lhc.nlm.nih.gov>, jw_rider@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
reagan@hiyall.enet.dec.com
Disclaimer:  The opinions and statements expressed by me are not
             necessarily those of Digital Equipment Corporation.
--

Re: English SUCKS, Chinese is the only language you need!!

[JCore]

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

Re: English SUCKS, Chinese is the only language you need!!

[Jerry Sams]

JCore wrote in message <34710873.4313003@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

Re: English SUCKS, Chinese is the only language you need!!

[system]

"Mike Smith" <kld_msmith@earthlink.nospam.net> writes:
>JCore <jcorez@juno.com> wrote in article
><34710873.4313003@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.

Morphis@physics.niu.edu
Real Women change tires			abuse@uu.net postmaster@uu.net
Real Men change diapers                 security@uu.net

Re: English SUCKS, Chinese is the only language you need!!

[Craig Franck]

"Mike Smith" <kld_msmith@earthlink.nospam.net> wrote:
>system@niuhep.physics.niu.edu wrote in article
><64vpua$ni7@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: English SUCKS, Chinese is the only language you need!!

[Michael Rubenstein]

On 19 Nov 1997 18:48:10 GMT, "Mike Smith"
<kld_msmith@earthlink.nospam.net> wrote:

>JCore <jcorez@juno.com> wrote in article
><34710873.4313003@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.  ;-)

According to the World Almanac there are almost twice as many speakers
of Mandarin (999 million) as of English (487 million).

Michael M Rubenstein

Re: English SUCKS, Chinese is the only language you need!!

[Mark Wilden]

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.

Re: English SUCKS, Chinese is the only language you need!!

[Michael Rubenstein]

On Wed, 19 Nov 1997 16:04:15 -0800, Mark Wilden <Mark@mWilden.com>
wrote:

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

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

Re: English SUCKS, Chinese is the only language you need!!

[Peter Seebach]

In article <3475921d.208410468@nntp.ix.netcom.com>,
Michael Rubenstein <miker3@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
-- 
seebs@plethora.net -- I am not speaking for my employer.  Copyright '97
All rights reserved.  This was not sent by my cat.  C and Unix wizard -
send mail for help, or send money for a consultation.  Visit my new ISP
<URL:http://www.plethora.net/> --- More Net, Less Spam!  Plethora . Net

Re: English SUCKS, Chinese is the only language you need!!

[Boyd Roberts]

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


In article <650e6p$ahv$1@darla.visi.com>, seebs@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: fred@ultramax.net

Re: English SUCKS, Chinese is the only language you need!!

[Larry Elmore]

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


Boyd Roberts wrote in message <651fpg$ngu$2@route1.mdrf.france3.fr>...
>In article <650e6p$ahv$1@darla.visi.com>, seebs@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

Re: English SUCKS, Chinese is the only language you need!!

[Joseph Santaniello]

In article <650e6p$ahv$1@darla.visi.com>, seebs@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 

Re: English SUCKS, Chinese is the only language you need!!

[system]

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
Morphis@physics.niu.edu
Real Women change tires			abuse@uu.net postmaster@uu.net
Real Men change diapers                 security@uu.net

Re: English SUCKS, Chinese is the only language you need!!

[Frans E. Boone]

system@niuhep.physics.niu.edu wrote:

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

No one needs to learn a second language. It is a matter of courtesy toadapt
yourself to your surroundings.
Most people however have trouble enough learning their own language.

--
Frans Boone

Re: English SUCKS, Chinese is the only language you need!!

[CERVANTES OJEDA, Jorge]

Frans E. Boone wrote:
> 
> system@niuhep.physics.niu.edu wrote:
> 
> > 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!
> 
> No one needs to learn a second language. It is a matter of courtesy toadapt
> yourself to your surroundings.

  It is NOT only courtesy. When you learn a second language you get also an
incredible ammount of CULTURE. :^)

  As for programming languages, The more languages you learn the more adaptable
you are for any change in your job. It is not only the knowledge of the 
languages itselves but the ability to understand other people's ideas and
improve them with your's.



> Most people however have trouble enough learning their own language.

Yes but you can allways learn in parallel YOUR language and another one.  8^l




  Jorge Cervantes (native Spanish speaker)
                  (learning French, German and, of course, English)

Re: English SUCKS, Chinese is the only language you need!!

[Peter Seebach]

In article <65h9r4$knu@btmpjg.god.bel.alcatel.be>,
CERVANTES OJEDA, Jorge <"JCER@BTMV74"@btma74.se.bel.alcatel.be> wrote:
>  It is NOT only courtesy. When you learn a second language you get also an
>incredible ammount of CULTURE. :^)

Indeed!  Most natural languages have assumptions about the nature of
the universe embedded in them, and different ones can express different
concepts more easily.

>  As for programming languages, The more languages you learn the more adaptable
>you are for any change in your job. It is not only the knowledge of the 
>languages itselves but the ability to understand other people's ideas and
>improve them with your's.

Indeed!

I didn't really make good use of switch in C until I had gotten used
to using 'case' in sh.

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

Re: English SUCKS, Chinese is the only language you need!!

[Kevin Edwards]

CERVANTES OJEDA, Jorge wrote:
> 
> Frans E. Boone wrote:
> >
> > system@niuhep.physics.niu.edu wrote:
> >
> > > 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!
> >
> > No one needs to learn a second language. It is a matter of courtesy toadapt
> > yourself to your surroundings.
> 
>   It is NOT only courtesy. When you learn a second language you get also an
> incredible ammount of CULTURE. :^)
> 

Consider a country like Luxembourg where the mother tongue
(Letzebergish) is spoken by about 250,000 people world wide.  Conducting
business (professional or private) almost certainly involves daily usage
of German, French and English.  Being multi-lingual there is certainly
not just courtesy , nor just culture, but real necessity.

As for communicating with a broad range of computer professionals, is it
really that much different?  The paradigms familiar to a COBOL
programmer are indeed different from those familiar to a C++
programmer.  Do I as a C++ programmer simply scowl and proclaim
technical superiority over my COBOL cohorts?  Considering that 70% of
the information age's data today is housed on IBM mainframes driven
primarily by COBOL programming, that is probably not a particularly
reasonable point of view, but I could choose to be closed minded about
it.

Re: English SUCKS, Chinese is the only language you need!!

[system]

"Frans E. Boone" <fboone@lucent.com> writes:
>system@niuhep.physics.niu.edu wrote:

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

>No one needs to learn a second language.

When you live within one day's travel of 2-5 different countries where
they speak different languages it is considered useful to learn more
than one language.

>Most people however have trouble enough learning their own language.

Most (all?) college-prep students in Germany know 3 languages by the time 
they graduate from H.S..  Scandinavia is much the same.  I know little
about other countries but I would be surprized if it were greatly different.
Morphis@physics.niu.edu
Real Women change tires			abuse@uu.net postmaster@uu.net
Real Men change diapers                 security@uu.net

Re: English SUCKS, Chinese is the only language you need!!

[Knochenhauer Bernd]

In article <65hm4g$3na@corn.cso.niu.edu>, system@niuhep.physics.niu.edu wrote:
>
>When you live within one day's travel of 2-5 different countries where
>they speak different languages it is considered useful to learn more
>than one language.

Not only then. It widens your view of the world around you.

>Most (all?) college-prep students in Germany know 3 languages by the time 
>they graduate from H.S..  

In theory: yes. Personally however, I almost successfully managed to
forget all the french I had to learn in school :) 

--
Bernd Knochenhauer
Dr.Materna GmbH Dortmund
--

Re: English SUCKS, Chinese is the only language you need!!

[Bob Bakh]

I personally prefer speaking Esperanto

Re: English SUCKS, Chinese is the only language you need!!

[macpar]

In article <65f14j$68$1@cronkite.sp.trw.com>,
  "Bob Bakh" <rbakh@mailsrv1.trw.com> wrote:
>
> I personally prefer speaking Esperanto

C^u vere?  Se vi preferas paroli esperante, kiel vi neniam efektive
faris
tion, anstatau nur prediki pri g^i al homoj, kiuj supozeble nek scipovas
g^in nek ec^ iomete interesig^as pri g^i?

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

Re: English SUCKS, Chinese is the only language you need!!

[Boyd Roberts]

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


In article <3473723c.200248081@nntp.ix.netcom.com>, miker3@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: fred@ultramax.net

Re: English SUCKS, Chinese is the only language you need!!

[Mark Wilden]

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.

Re: English SUCKS, Chinese is the only language you need!!

[Wei Jing Guo]

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...  ;)

Re: English SUCKS, Chinese is the only language you need!!

[John Rickard]

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_msmith@earthlink.nospam.net> wrote in article
<01bcf51b$abcea520$0200000a@kld_mcs>...
: JCore <jcorez@juno.com> wrote in article
: <34710873.4313003@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
: 

Re: English SUCKS, Chinese is the only language you need!!

[Christer Gustavsson]

"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

Re: English SUCKS, Chinese is the only language you need!!

[Ncp268]

In article <01bcf51b$abcea520$0200000a@kld_mcs>, "Mike Smith"
<kld_msmith@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???
**************************************************************************
*********************

Re: English SUCKS, Chinese is the only language you need!!

[Richard A. O'Keefe]

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


"Mike Smith" <kld_msmith@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

Re: English SUCKS, Chinese is the only language you need!!

[chasjt]

Mike Smith wrote:
> 
<snip>
 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). 
<snip>

Hell, you can't even speak for Texas.

Re: English SUCKS, Chinese is the only language you need!!

[John Rickard]

Re: English SUCKS, Chinese is the only language you need!!

[Mike Smith]

Ingemar Ragnemalm <ingemar@lysator.liu.se> wrote in article
<347067B8.46@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Timo Salmi]

In article <345673af.1413708@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:ts@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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Dr E. Buxbaum]

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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Steve Ropa]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <Pine.SUN.3.96.971030093508.12308F-100000@flatland.dimensional.com>,
Steve Ropa  <theropas@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[John Stevens]

On 30 Oct 1997 13:13:54 -0800, Kaz Kylheku <kaz@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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Kaz Kylheku]

In article <slrn6620l9.91f.jstevens@samoyed.ftc.nrcs.usda.gov>,
John Stevens <jstevens@samoyed.ftc.nrcs.usda.gov> wrote:
>On 30 Oct 1997 13:13:54 -0800, Kaz Kylheku <kaz@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Steve Ropa]

On 6 Nov 1997, Kaz Kylheku wrote:

> In article <slrn6620l9.91f.jstevens@samoyed.ftc.nrcs.usda.gov>,
> John Stevens <jstevens@samoyed.ftc.nrcs.usda.gov> wrote:
> >On 30 Oct 1997 13:13:54 -0800, Kaz Kylheku <kaz@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Craig Franck]

kaz@helios.crest.nt.com (Kaz Kylheku) wrote:
>In article <slrn6620l9.91f.jstevens@samoyed.ftc.nrcs.usda.gov>,
>John Stevens <jstevens@samoyed.ftc.nrcs.usda.gov> wrote:
>>On 30 Oct 1997 13:13:54 -0800, Kaz Kylheku <kaz@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[NOSPAM_f93-eaa]

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_f93-eaa@sm.luth.se 

Re: Ada, Pascal, Eiffel and others

[Alan Brain]

NOSPAM_f93-eaa@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.
> 
> 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.
aebrain@dynamite.com.au abrain@cs.adfa.oz.au

Re: Ada, Pascal, Eiffel and others

[NOSPAM_f93-eaa]

Alan Brain <abrain@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_f93-eaa@sm.luth.se 

Re: Ada, Pascal, Eiffel and others

[tmt]

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

>NOSPAM_f93-eaa@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.
>aebrain@dynamite.com.au abrain@cs.adfa.oz.au

Re: Ada, Pascal, Eiffel and others

[geldridg]

In article <3457F230.2C75@cs.adfa.oz.au>,
  Alan Brain <abrain@cs.adfa.oz.au> wrote:
>
> NOSPAM_f93-eaa@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:  geldridg@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

Re: Ada, Pascal, Eiffel and others

[Alan E & Carmel J Brain]

geldridg@progsoc.uts.edu.au wrote:

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Corey Barcus]

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
corey@simplersw.com

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Scott A. Moore]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Shmuel (Seymour J.) Metz]

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.

-- 

                        Shmuel (Seymour J.) Metz
                        Senior Software SE

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Scott A. Moore]

In article <345A5E44.5946@gsg.eds.com>, nospam@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]

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Shmuel (Seymour J.) Metz]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Timo Salmi]

In article <345A5E44.5946@gsg.eds.com>,
Shmuel (Seymour J.) Metz <nospam@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:ts@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.

Trolling...

[Jerry van Dijk]

In article <345673af.1413708@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 | jdijk@acm.org

Re: Trolling...

[Ron Thompson]

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.

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Gary A. Wiltshire]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Gary A. Wiltshire]

"Oliver Batchelor" <batch@netaccess.co.nz> wrote:
.....
>Shut up
.....


Yes, Ma'am!


   --- Gary Wiltshire

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Christopher Eltschka]

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

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

[John Bode]

In article <34566fe9.447229@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.

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

[Dann Corbit]

John Black wrote in message <34566fe9.447229@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

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

[Adam Beneschan]

"Dann Corbit" <dcorbit@solutionsiq.com> writes:
 >John Black wrote in message <34566fe9.447229@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

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

[BRIAN LANGENBERGER]

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?

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

[Philip Brashear]

In article <34566fe9.447229@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)

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

[Ed Muldoon]

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.

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

[Jon S Anthony]

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

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[BRIAN LANGENBERGER]

John Black (nospam@nospam) 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.

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. 

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

[Rob]

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

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

[Tucker Taft]

BRIAN LANGENBERGER (lang0104@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   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[JT (from Fritz)]

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.

Re: Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[David A. Frantz]

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.9C650F03@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.
>

Re: Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Phlip C Plumlee]

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

Re: Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Kaz Kylheku]

In article <3458072B.6A22E8FA@deltanet.com>,
Phlip C Plumlee  <tegan@deltanet.com> wrote:
>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...

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

Re: Nope! was Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[Alan E & Carmel J Brain]

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

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[Rob Eamon]

John Black wrote in message <34557f2b.1934172@news.mindspring.com>...
>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.

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.

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

[Kenneth W. Sodemann]

John Black, in message <34557f2b.1934172@news.mindspring.com> spewed
forth...
>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.

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 => kwsodema@avistainc.com
    Web => http://www.pcii.net/~stuffel
    Company_Web => http://www.avistainc.com);

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

[Ken Mays]

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?

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

[Charles R. Lyttle]

Ken Mays wrote:

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

 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 : lyttlec@mail.flash.net

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

[NOSPAM_f93-eaa]

Charles R. Lyttle <lyttlec@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_f93-eaa@sm.luth.se 

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

[Charles R. Lyttle]

NOSPAM_f93-eaa@sm.luth.se wrote:

> Charles R. Lyttle <lyttlec@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_f93-eaa@sm.luth.se

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 : lyttlec@mail.flash.net

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

[David A. Frantz]

Charles R. Lyttle wrote in message <345B7A48.F32E4924@flash.net>...
>NOSPAM_f93-eaa@sm.luth.se wrote:
>
>> Charles R. Lyttle <lyttlec@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_f93-eaa@sm.luth.se
>
>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 : lyttlec@mail.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

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

[Charles W. Johnson]

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 <cwj2@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.                 ]

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

[Charles R. Lyttle]

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 <cwj2@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 : lyttlec@mail.flash.net

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

[Nick Leaton]

Charles R. Lyttle wrote:
> 
> NOSPAM_f93-eaa@sm.luth.se wrote:
> 
> > Charles R. Lyttle <lyttlec@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_f93-eaa@sm.luth.se
> 
> 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".

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

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

[John Stevens]

On Sat, 01 Nov 1997 12:51:53 -0600, Charles R. Lyttle <lyttlec@flash.net> wrote:
>NOSPAM_f93-eaa@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.

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

[Boyd Roberts]

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


In article <slrn6622r0.91f.jstevens@samoyed.ftc.nrcs.usda.gov>, jstevens@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 <boyd@france3.fr>			UTM N 31 447109 5411310

En fin, bon, bref, si tu veux, point � la ligne, voil� quoi -- Jacques

SPAT: gpg@t-1net.com

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

[Kaz Kylheku]

In article <63usl7$hqo$7@route1.mdrf.france3.fr>,
Boyd Roberts <boyd@france3.fr> wrote:
>In article <slrn6622r0.91f.jstevens@samoyed.ftc.nrcs.usda.gov>, jstevens@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

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

[Charles W. Kann]

Boyd Roberts (boyd@france3.fr) wrote:
: In article <slrn6622r0.91f.jstevens@samoyed.ftc.nrcs.usda.gov>, jstevens@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
ckann@seas.gwu.edu

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

[Jon S Anthony]

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

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

[Matt Kennel (Remove 'NOSPAM' to reply)]

On 10 Nov 1997 19:05:30 -0500, Jon S Anthony <jsa@synquiry.com> wrote:
:ckann@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. 
*

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

[Charles W. Kann]

: :> 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
ckann@seas.gwu.edu

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

[Brian Rogoff]

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

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

[Jon S Anthony]

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

Flame bait count 146 (Re: ADA SUCKS, C/C++/JAVA RULES!!!!)

[Ken Garlington]

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!

Re: Flame bait count 146 (Re: ADA SUCKS, C/C++/JAVA RULES!!!!)

[Marcus Agrippa]

In article <345B9091.5D06@flash.net>, Ken.Garlington@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.


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

Re: Flame bait count 146 (Re: ADA SUCKS, C/C++/JAVA RULES!!!!)

[Carsten Engelmann]

Marcus Agrippa (president@whitehouse.gov) wrote:
: In article <345B9091.5D06@flash.net>, Ken.Garlington@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

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

[Supreme]

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 ?


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.

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

[Alan E & Carmel J Brain]

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

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

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

[Guest]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Samuel T. Harris]

John Stevens wrote:
> 
> On Tue, 11 Nov 1997 11:42:42 -0800, Dr E. Buxbaum <EB15@le.ac.uk> wrote:
> >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.
> 
> 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.

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Larry Elmore]

John Stevens wrote in message ...
>On Tue, 11 Nov 1997 11:42:42 -0800, Dr E. Buxbaum <EB15@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

Re: which languages suck

[Stanley R. Allen]

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_allen@hso.link.com

Re: which languages suck

[Larry Elmore]

Stanley R. Allen wrote in message <346A5026.794B@hso.link.com>...
>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.


Yes, that's what I meant (though _not_ what I posted, I see now! :) ).
Thanks!

Larry

Re: which languages suck

[Robert Munck]

On Wed, 12 Nov 1997 18:56:06 -0600, "Stanley R. Allen"
<s_allen@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

Re: which languages suck

[Russ Lyttle]

Robert Munck wrote:
> 
> On Wed, 12 Nov 1997 18:56:06 -0600, "Stanley R. Allen"
> <s_allen@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
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.

Re: which languages suck

[Bjorn Vaggen Konestabo]

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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Jon S Anthony]

"Larry Elmore" <ljelmore@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

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Craig Franck]

Jon S Anthony <jsa@synquiry.com> wrote:
>"Larry Elmore" <ljelmore@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
clfranck@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Marin David Condic, 561.796.8997, M/S 731-96]

John Black <nospam@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:  CONDICMA@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
===============================================================================

Re: ADA and Pascal SUCK, C,C++, and Java are the only languages you need!!

[Marin David Condic, 561.796.8997, M/S 731-96]

Mike Copeland <mrcope@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:  CONDICMA@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
===============================================================================