Re: INFO-ADA Digest - 1 Jan 1998 to 2 Jan 1998 - Special issue

Re: INFO-ADA Digest - 1 Jan 1998 to 2 Jan 1998 - Special issue

[DSCI-New Jersey]

This is the second request!  Please do not send any more messages to this
address.  You can forward them to Glenn Booker at the following address:
gbooker@acm.org

Thank you.

At 11:50 AM 1/2/98 -0600, you wrote:
>Date:     Fri, 2 Jan 1998 11:50:30 -0600
>Reply-To: Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
>Sender:   Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
>From:     Automatic digest processor <LISTSERV@LISTSERV.NODAK.EDU>
>Subject:  INFO-ADA Digest - 1 Jan 1998 to 2 Jan 1998 - Special issue
>To:       Recipients of INFO-ADA digests <INFO-ADA@LISTSERV.NODAK.EDU>
>
>There are 27 messages totalling 1010 lines in this issue.
>
>Topics in this special issue:
>
>  1. Which language pays most? Smalltalk, not C++ nor Java. (11)
>  2. Which language pays most -- C++ vs. Java? (4)
>  3. Variable-block memory managers bad in realtime (2)
>  4. gnat-3_10p1-nt and C++ ? (2)
>  5. We're hoping that 1998 will be your most prosperous year!
>  6. Ada - State of the art tools... lacking
>  7. GNAT/RTEMS
>  8. Which language pays most 17457 -- C++ vs. Java? (2)
>  9. Translation services
> 10. Help: Truncating Decimal Types
> 11. general-purpose vs. domain-specific programming languages
>Date:    Tue, 30 Dec 1997 19:04:04 -0500
>From:    Joshua Waxman <jwaxman@YMAIL.YU.EDU>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>On Tue, 30 Dec 1997, firewind wrote:
>
>> On Tue, 30 Dec 1997, Joshua Waxman wrote:
>>
>> > On Mon, 29 Dec 1997, Guillermo Schwarz wrote:
>> > > very poorlanguage. You can't know how many bits does an int have. Or if
>long
>> > > is actually bigger
>> > > than int.
>>
>> > You can't? How about sizeof(int) and if(sizeof(int) < sizeof(long))
>>
>> sizeof(int) gives the size in bytes, which you need to multiply by
>> CHAR_BIT to get the number of bits.
>>
>> > > You can't ask an structure how many fields does it have.
>> >
>> > True. But structures in C++ tend to have a constant number of fields, no?
>>
>> And I'm curious as to the usefulness of this, anyway. How can you use a
>> structure that you don't know the layout of?
>
>Well, if you had a Stack structure, which has a variable number of fields,
>you can still know the basic layout of it and thus use it, but it would be
>useful to know how many stack elements there are. C++, of course,
>might do this with a structure containing a linked list of constant sized
>elements, and in this case the size is known or can easily be determined.
>
>>
>> > > In C++ there is no way to handle overflow of integers.
>> >
>> > Check after each addition to see if you reversed signs, and act
>> > accordingly.
>>
>> What about unsigned arirthmetic? What if sign reversal is possible (but
>> not garunteed) in this expression, without any overflow?
>>
>
>He said integers, and int without any modifier is signed. I was talking in
>terms of addition, and when you add or multiply by positive numbers, I
>would expect the only way to change sign is with overflow. If a newgative
>number you are adding, sign change is possible, but then we wouldn't worry
>about overflow. Anyway, probably the best way to handle this is to make
>classes Integer, and UnsignedInteger, overload operators, and let the
>internals worry about checking for overflow conditions.

>By the way, it is spelled *guaranteed*.
>
>
>Josh Waxman
>
>> [-                               firewind
>-]
>> [-   email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work)
>-]
>> [-          "You're just jealous because the voices talk to -me-."
>-]
>> [-                   Have a good day, and enjoy your C.
>-]
>> [-          (on a crusade of grumpiness where grumpiness is due)
>-]
>>
>>
>>
>Date:    Tue, 30 Dec 1997 19:14:28 -0500
>From:    Joshua Waxman <jwaxman@YMAIL.YU.EDU>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>On 30 Dec 1997, Kaz Kylheku wrote:
>
>> In article <Pine.A41.3.95.971230143114.19568A-100000@acis.mc.yu.edu>,
>> Joshua Waxman  <jwaxman@ymail.yu.edu> wrote:
>> >> In C++ there is no way to handle overflow of integers.
>> >
>> >Check after each addition to see if you reversed signs, and act
>> >accordingly.
>>
>> That is absurd. Overflow invokes undefined behavior in C++. To check
>> for sign reversal, you would have to depend on a particular platform's
>> handling of overflow. On two's complement systems, overflow on addition or
>> subtraction can be detected by examining the most significant bit of the
>> result and those of the operands. This isn't true in general, however.
>>
>> It's possible to determine whether a given operation will occur by
>> writing a test expression (or assertion) which itself does not invoke
>> overflow.
>
>Oops! Thanks for pointing that out.
>
>By the way, does your later post indicate that Borland guarantees
>that overflow will wrap around?
>
>Also, clue me in on "undefined behavior." From the rest of your postr, I
>would call this "implementation dependant behavior."  What are the various
>degrees and meanings of evil things in C++?
>
>Josh Waxman
>Date:    Tue, 30 Dec 1997 19:16:57 -0500
>From:    Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>
>Kaz says
>
><<That is absurd. Overflow invokes undefined behavior in C++. To check
>for sign reversal, you would have to depend on a particular platform's
>handling of overflow. On two's complement systems, overflow on addition or
>subtraction can be detected by examining the most significant bit of the
>result and those of the operands. This isn't true in general, however.
>
>It's possible to determine whether a given operation will occur by
>writing a test expression (or assertion) which itself does not invoke
>overflow.
>>>
>
>
>Yes, it is possible, but gruesome, especially for multiplication. And rather
>silly, since at the hardware level it is typically easy to detect overflow.
>The lack of overflow detection in a language like C++ seems a clear and
>annoying ommission (actually I had been told this was fixed in the latest
>standard, but I guess that was false information). Anyway, the Ada approach
>makes far more sense than appealing to highly dubious assertions!
>Date:    Tue, 30 Dec 1997 17:12:33 -0800
>From:    Dann Corbit <dcorbit@SOLUTIONSIQ.COM>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>MIME-Version: 1.0

>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>Robert Dewar wrote in message ...
>>Kaz says
>>
>><<That is absurd. Overflow invokes undefined behavior in C++. To check
>>for sign reversal, you would have to depend on a particular platform's
>>handling of overflow. On two's complement systems, overflow on addition or
>>subtraction can be detected by examining the most significant bit of the
>>result and those of the operands. This isn't true in general, however.
>>
>>It's possible to determine whether a given operation will occur by
>>writing a test expression (or assertion) which itself does not invoke
>>overflow.
>>>>
>>
>>
>>Yes, it is possible, but gruesome, especially for multiplication. And rather
>>silly, since at the hardware level it is typically easy to detect overflow.
>>The lack of overflow detection in a language like C++ seems a clear and
>>annoying ommission (actually I had been told this was fixed in the latest
>>standard, but I guess that was false information). Anyway, the Ada approach
>>makes far more sense than appealing to highly dubious assertions!
>Now, with Ada we can simply declare precision, and I will agree this is very
>nice.  But we can make the same sort of decisions for other languages and use
>efficient fixed sizes or new types of our own design.  Instead of growing a
>bit at a time, we grow in jumps.  Now, if I declare a type of 60 bits of
>precision, am I guaranteed that it will never overflow?  Obviously, I still
>have to perform the same analysis that I would need for any other software
>system.  Getting exactly what you want is much easier, though.
>
>
>Exception handling is not perfect a solution either.  It is even better to
>engineer a solution where the types used never extend beyond the design
range.
>If there is any possibility that a counter of type short is not large enough,
>use long.  And if there is any chance that long is too small, use a larger
>type or invent one.  Same for float, double, long double.
>
>Exception handling for memory or disk problems makes excellent sense, since
>those are often limited resources of unknown quantity.  But integer overflow
>and the like is an indication of a serious flaw in the original physical
>design.
>
>If an exhaustive test of the domain is applied, using assert() is as good as
>any other method, and it has the added benefit of documenting the thinking of
>the software analyst very concisely.  However, with more than 5 bytes of data
>length in the domain, exhaustive testing is prohibitive.
>--
>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
>Date:    Tue, 30 Dec 1997 17:20:00 -0800
>From:    Dann Corbit <dcorbit@SOLUTIONSIQ.COM>
>Subject: Re: Which language pays most -- C++ vs. Java?
>MIME-Version: 1.0
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>arnie sherman wrote in message <34a991f0.2379476@news.diac.com>...
>>to return briefly to the original topic of this thread:

>>
>>i'm studying programing, including smalltalk (smalltalk express), &
>>would like to know not so much which language will pay the most, but
>>rather, which will be more likely to make me employable in the
>>shortest time (as an entry level programmer) ?
>Depends on what you want to do.
>
>>i am guessing c & c++,
>>even though i do find smalltalk to be a cleaner & more refined
>>programming environment.
>Once you have learned smalltalk, C++ will be fairly easy to learn (though
>templates will be something of a departure).  Once you know C++, C will be
>easy to learn.  Why not learn them all?  It's really not all that
difficult to
>pick up a new programming language.  Each language has strengths and
>weaknesses.  The more you know, the better you will be as a programmer.
>Besides that, each teaches some new concepts that you can carry over to your
>design skills.
>
>>additionally, i am primarilly interested in
>>graphics, i.e. multimedia, inteerface design, internet apps., etc.
>Sounds like C, C++, and Assembly to me, but I suspect that some of that goes
>on in most programming disciplines.
>
>>whenever i discuss web design w/ placement people they immediatly want
>>to know if i know java. i suspect this is a trendy thing, though also
>>reflecting some real possibilities for employment in the immediate
>>future.
>
>Why not learn Java too?  Go pick up a book from your local library.  In one
>day or so, you will know if you want to pursue it.
>
>Look through your local Sunday paper.  Find out what kind of work the
>programmers in those disciples do in your area.  If it sounds like something
>you would enjoy, focus on that target.
>--
>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
>Date:    Tue, 30 Dec 1997 20:35:19 -0500
>From:    Joe Gwinn <gwinn@RES.RAY.COM>
>Subject: Re: Variable-block memory managers bad in realtime
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>In article <ufk9cu7bjl.fsf@synquiry.com>, Jon S Anthony <jsa@synquiry.com>
>wrote:
>
>> gwinn@res.ray.com (Joe Gwinn) writes:
>>
>> > Waste lots of memory, actually.  Sometimes we don't have the memory
>> > to waste, or we would rather waste it on something else.  I don't
>> > know that these algorithms have guaranteed absolute upper bounds on
>> > response time, and absolute protection against fragmentation,
>> > together with the requisite efficiency.
>> >
>> > Fixed-block allocators waste no space, and have absolutely constant
>> > service time.
>>
>> What in the world are you talking about?  Fixed block allocators waste
>> space up the wazoo unless (of course) you _always_ require the _exact_
>> size they provide.
>
>See below.  We get to pick the block sizes to suit the application, so the
>wastage isn't a problem, and we really like the constant-time behaviour.
>
>
>> Second, you should probably take a look at some of the work on
>> allocators and collectors in the GC literature.  Including stuff on
>> compaction.  Many of these do indeed have guranteed worst case

>> behaviors.  In particular, check out Henry Baker's work on this stuff
>> (including his realtime GC papers).  These may or may not work for
>> you, but unless you are targetting realtime engine control, or some
>> such, they will likely be OK.
>
>Will do.  Do you have more specific references?  Thanks.
>
>We are doing the equivalent of engine control in many places.
>
>
>> > True, but our applications are happy with from three to six different
>> > block sizes; the specific spectrum of sizes varies with the specific
>> > application.
>>
>> OK, fine, then maybe a suite of 3-6 fixed size allocators will work
>> for you.  Of course, this may well be memory inefficient as well, but
>> if it is good enough, go for it.
>
>It *does* work.  These values are taken from at least a billion dollars
>worth of fielded systems.
>
>
>> > Remember, I don't have to solve as general a problem as does
>> > a compiler or runtime writer, and I am more interested in predictability
>> > and behaviour under overload and near overload than memory efficiency per
>> > se.  Nor do I agree that there is one "best" algorithm, for all
>> > applications.
>>
>> OK, I can pretty much agree with all of this.
>
>Thanks.
>
>
>Joe Gwinn
>Date:    Wed, 31 Dec 1997 02:12:33 GMT
>From:    Phil Brereton <elwood@OSC.U-NET.COM>
>Subject: gnat-3_10p1-nt and C++ ?
>
>I have just installed gnat and found out that it can compile C, I've
>been told that to compile C++ I need cc1plus.exe and the C++ library.
>How do I install these correctly? Any advice will be gratefully
>received.
>Best wishes for the New Year,
>Phil
>Date:    Thu, 1 Jan 1998 07:18:00 CST
>From:    mail2news-19980101-comp.lang.ada+comp.lang.ada@ANON.LCS.MIT.EDU
>Subject: We're hoping that 1998 will be your most prosperous year!
>
>Your name was found on the web; so either you, or a company you
>are affiliated with, have a web site and are probably trying to
>attract business.
>
>If you have been around on the web awhile, you surely know that
>great graphics, a mall site, banners, and all of the reciprocal
>links in the world just don't do the job -- they don't increase
>traffic and they don't create sales.
>
>Why kid yourself?  This coming year, go ahead and try something
>that WILL REALLY WORK.  Our trial model is FREE, and during the
>five day demonstration period, you will definitely see results.
>
>***************************************************************
>
>This notice was brought to you by MarketCom's all new MktAgent,
>the Internet's Premier Web Site Promotion and Publicity Engine!
>
>Good Luck! God Bless! Do Business!    http://www.MarketCom.com/
>
>Mirror sites can be found at:
>
>                      http://www.famailcrt.com/marketcom4/
>                      http://www.aoci.com/fontsasoc/marketcom4/
>
>***************************************************************
>
>PLEASE NOTE:  You are NOT part of a mailing list.
>
>You were chosen to receive this note because your Email address
>was publicly posted on a home page.  You'll not receive it more
>than once at this mailbox.
>
>***************************************************************
>

>nqnzwxklzctywsqrxuh qrs  mqmg  doedzbzrjhvv dupf
>Date:    Wed, 31 Dec 1997 00:38:14 GMT
>From:    arnie sherman <eatTheSpam@DIAC.COM>
>Subject: Re: Which language pays most -- C++ vs. Java?
>
>to return briefly to the original topic of this thread:
>
>i'm studying programing, including smalltalk (smalltalk express), &
>would like to know not so much which language will pay the most, but
>rather, which will be more likely to make me employable in the
>shortest time (as an entry level programmer) ? i am guessing c & c++,
>even though i do find smalltalk to be a cleaner & more refined
>programming environment. additionally, i am primarilly interested in
>graphics, i.e. multimedia, inteerface design, internet apps., etc.
>
>whenever i discuss web design w/ placement people they immediatly want
>to know if i know java. i suspect this is a trendy thing, though also
>reflecting some real possibilities for employment in the immediate
>future.
>
>any thoughts?
>thanks
>arnie sherman
>
>arnie@diac.com
>http://www.diac.com/~arnie
>please replace eatTheSpam w/ "arnie" to reply...
>Date:    Thu, 1 Jan 1998 17:30:54 GMT
>From:    Henry Baker <hbaker@NETCOM.COM>
>Subject: Re: Variable-block memory managers bad in realtime
>MIME-Version: 1.0
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 8bit
>
>In article <uf90t16x43.fsf@synquiry.com>, Jon S Anthony <jsa@synquiry.com>
>wrote:
>
>> gwinn@res.ray.com (Joe Gwinn) writes:
>> > Will do.  Do you have more specific references?  Thanks.
>
>> > We are doing the equivalent of engine control in many places.
>>
>> If that's really true (with cycle times measured in microseconds),
>> this stuff isn't going to work for you.
>
>Well, it depends upon what you mean by 'this stuff'.
>
>Well-engineered dynamic storage algorithms can be used for hard real-time
>applications, but they do have to be designed for this purpose.  A number
>of 'multi-media' systems with hard real-time requirements have been built
>using real-time GC techniques.
>
>Most dynamic storage allocators -- including nearly all implementations
>of 'malloc' -- have not been designed for hard real-time use.  Most mallocs
>have been designed to make the standard benchmarks run fast (if even that!)
>and probably have to be replaced for many serious applications.  There have
>been some very interesting measurements of the 'standard' mallocs that ship
>with various operating systems, and they aren't pretty.  So the problem
>isn't _GC_, per se, but non-real-time allocators themselves.
>
>A number of people in the GC community are interested in embedded systems
>applications of GC.  Do a web search for Kelvin Nielsen.
>Date:    Tue, 30 Dec 1997 18:38:53 +0100
>From:    Jean-Pierre Rosen <rosen.adalog@WANADOO.FR>
>Subject: Re: Ada - State of the art tools... lacking
>
>Paul Whittington a icrit dans le message <34A74195.46994669@srv.net>...
>>> If we wrote our code for Delphi, there
>>> is no reason to think that Borland won't make major changes to the
>language
>>> next year that breaks our system.
>>
>>[...]
>>  I've used TurboPASCAL since 1.0 and Borland
>>has NEVER done anything even close to what your talking about here.

>Seems you forgot the move from version 3 to version 4.
>I still have an old version 3 on my computer because of an old application
>that I never took the time to convert (would have involved a major
>rewriting).
>Date:    Wed, 31 Dec 1997 13:31:04 +0100
>From:    Jakob Ulysses Gaertner <jak@JTEK.NET>
>Subject: GNAT/RTEMS
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>I heard about a cross-development environment GNAT -> RTEMS.
>Does anyone know where to get it?
>
>Favourite host would be Linux for political reasons.
>
>Thanks
>
>Happy New Year!
>Date:    Wed, 31 Dec 1997 08:13:10 -0500
>From:    Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>
><<He said integers, and int without any modifier is signed. I was talking in
>terms of addition, and when you add or multiply by positive numbers, I
>would expect the only way to change sign is with overflow. If a newgative
>number you are adding, sign change is possible, but then we wouldn't worry
>about overflow. Anyway, probably the best way to handle this is to make
>classes Integer, and UnsignedInteger, overload operators, and let the
>internals worry about checking for overflow conditions.
>>>
>
>Unfortunately, the point is that there is no reasonable way to program
>these internals in an efficient portable manner in C++
>Date:    Wed, 31 Dec 1997 09:42:40 -0500
>From:    "R. Karl Werner" <rkwerner@CYBERCOMM.NET>
>Subject: Re: gnat-3_10p1-nt and C++ ?
>
>If anyone can help I need the same info.  I'm using PCGRASP and would like
>to have the C++ capability.
>
>Karl
>
>Phil Brereton wrote in message <34a9aa01.38963143@news.u-net.com>...
>>I have just installed gnat and found out that it can compile C, I've
>>been told that to compile C++ I need cc1plus.exe and the C++ library.
>>How do I install these correctly? Any advice will be gratefully
>>received.
>>Best wishes for the New Year,
>>Phil
>Date:    Wed, 31 Dec 1997 12:28:20 -0500
>From:    Guillermo Schwarz <gschwarz@ITS.CL>
>Subject: Re: Which language pays most 17457 -- C++ vs. Java?
>MIME-Version: 1.0
>Content-Type: multipart/mixed;
boundary="------------3DDDA4709FEFF727FDE888E1"
>
>
>
>Lawrence Kirby wrote:
>
>>  Unix
>> was gaining strength from the exposure it was getting in Universities.
>
>Yes.
>
>> Most people who bought DOS weren't even aware that Unix existed.
>>
>
>In the early 80's that was true. But in the late 80's UNIX was known
toreplace
>other OS's. It did. But now there in Windows NT in the horizon,
>which for the most part has been behind Novell Netware, and I think
>has almost killed it.
>What does this have to do with Smalltalk?
>Everything!
>Smalltalk was created in Xerox PARC as was the graphic workstation,
>the mouse and the ethernet. Guess which part is missing in every single
>desktop...
>
>> > They did not see that UNIX provided better performance (for
>> >the money), or that is was more reliable - which it wasn't at the time.
>>
>> What is your definition of "relaiblae"?
>
>Relaiblae? It must be latin for reliable ;^)Everybody knows it means
"performs
>as

>expected".
>UNIX didn't stay up more than 3 days until LINUX was born.
>I've seen linuxes uptime as long as 1 year.
>Long life to Linux.
>
>> >Finally, I don't understand why everyone is in such vehement opposition to
>> >me on this.  Even if you *don't* believe that there have been better
systems
>> >than UNIX in the past, you must admit that UNIX is *NOT* perfect;
>
>I would have to see the original Smalltalk box to see if it was better or
not.I
>think they must have been a big powerful workstation easily configurable
>as a Mac and easily programable as any Smalltalk environment seen today
>(probably Squeak).
>--
>I use CAPS to emphasize, not to yell.
>I take unpopular positions.
>This signature is copyrighted and used without permission.
>
>
>Date:    Wed, 31 Dec 1997 09:59:05 -0500
>From:    John Slaman <john.slaman@SHAW.WAVE.CA>
>Subject: Re: Which language pays most -- C++ vs. Java?
>
>Which language will make you employable in the shortest amount of time ?
>
>    Microsoft's Visual Basic 5
>
>Why
>- easy to learn
>- large market
>- it's in demand (because systems written in VB need to be rewritten every
>couple of years)
>
>Words of caution
>- you will never be respected (and rightly so)
>- it doesn't pay much (because you'll be competing with people with no
>degrees and non-Computer Science degrees who are self taught, and the people
>doing the hiring don't value the process of software engineering).
>
>Regards
>
>
>
>arnie sherman wrote in message <34a991f0.2379476@news.diac.com>...
>>to return briefly to the original topic of this thread:
>>
>>i'm studying programing, including smalltalk (smalltalk express), &
>>would like to know not so much which language will pay the most, but
>>rather, which will be more likely to make me employable in the
>>shortest time (as an entry level programmer) ? i am guessing c & c++,
>>even though i do find smalltalk to be a cleaner & more refined
>>programming environment. additionally, i am primarilly interested in
>>graphics, i.e. multimedia, inteerface design, internet apps., etc.
>>
>>whenever i discuss web design w/ placement people they immediatly want
>>to know if i know java. i suspect this is a trendy thing, though also
>>reflecting some real possibilities for employment in the immediate
>>future.
>>
>>any thoughts?
>>thanks
>>arnie sherman
>>
>>arnie@diac.com
>>http://www.diac.com/~arnie
>>please replace eatTheSpam w/ "arnie" to reply...
>Date:    Fri, 2 Jan 1998 02:22:09 GMT
>From:    BENJAMIN ELIZONDO <flamenco@IX.NETCOM.COM>
>Subject: Translation services
>
>We are offering Spanish/English and English/Spanish translation
>services.  If interested please e-mail
>
>Benjamin Elizondo
>Miami, Florida
>Date:    Wed, 31 Dec 1997 11:29:49 -0600
>From:    "Keith G. Murphy" <keithmur@MINDSPRING.COM>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>David Thornley wrote:
>[snip good stuff]
>>
>> Think of the standard as what you can count on in the language.  The
>> actual language a given compiler will accept is different, of course,

>> and the range of C "dialects" increases with every release with a
>> new feature or pragma or whatever.  If you are writing a particular
>> program for use with one version of one compiler on one system
>> (and I haven't done that in a *long* time), you can go wild with
>> the extensions.  If you might want to reuse some of your code
>> sometime, be careful with them.
>>
>And remember, we tend to underestimate the range of platforms and time
>frame within which code will be forced to run.  Witness this little
>thing called the Y2K problem...
>Date:    Wed, 31 Dec 1997 17:32:47 GMT
>From:    David Thornley <thornley@VISI.COM>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>
>In article <68c66j$ei3$1@client3.news.psi.net>,
>Dann Corbit <dcorbit@solutionsiq.com> wrote:
>>Robert Dewar wrote in message ...
>>>Kaz says
>>>
>>><<That is absurd. Overflow invokes undefined behavior in C++. To check
>>>for sign reversal, you would have to depend on a particular platform's
>>>handling of overflow. On two's complement systems, overflow on addition or
>>>subtraction can be detected by examining the most significant bit of the
>>>result and those of the operands. This isn't true in general, however.
>>>
>>>It's possible to determine whether a given operation will occur by
>>>writing a test expression (or assertion) which itself does not invoke
>>>overflow.
>>>>>
>>>
>>>
>>>Yes, it is possible, but gruesome, especially for multiplication. And
rather
>>>silly, since at the hardware level it is typically easy to detect overflow.
>>
>My preferred solution is the Common Lisp one.  It will handle integers
>of any size, subject of course to machine limitation.  I can write a
>program that will handle integers accurately, without overflow.  The
>downside is the performance hit, but there are ways around that.
>First, I can introduce spot checks to see if my integers are staying
>in the "fixnum" range rather than the "bignum" range; second, I can
>use declarations to tell the compiler to optimize performance at the
>expense of safety.  It fits in well with my attitude of getting it
>working without worrying about low-level optimization.
>
>
>--
>David H. Thornley                        | These opinions are mine.  I
>david@thornley.net                       | do give them freely to those
>http://www.thornley.net/~thornley/david/ | who run too slowly.       O-
>Date:    Wed, 31 Dec 1997 17:55:35 GMT
>From:    Billy Chambless <billy@CAST.MSSTATE.EDU>
>Subject: Re: Which language pays most 17457 -- C++ vs. Java?
>
>In article <34AA80B3.E651528D@its.cl>, Guillermo Schwarz <gschwarz@its.cl>
>writes:
>
>|> What does this have to do with Smalltalk?
>|> Everything!
>|> Smalltalk was created in Xerox PARC as was the graphic workstation,
>|> the mouse and the ethernet. Guess which part is missing in every single
>|> desktop...
>
>Hmmm.... sounds like vendors stole the usable ideas, and left the
>rest. ;)
>
>|> UNIX didn't stay up more than 3 days until LINUX was born.
>
>Hmmm....maybe you've had bad luck with Unix. This certainly doesn't
>fit with my own experiences with various Unixes, including SunOS,

>AIX, SCO, Irix, and errr... whatever TI called their Unix that they put
>on their long-forgotten workstations.
>
>|> I've seen linuxes uptime as long as 1 year.
>
>The only time we usually reboot any of our 20 or so Unix machines is for
>power outages or hardware upgrades.
>
>|> Long life to Linux.
>
>Can't argue with that! ;)
>Date:    Wed, 31 Dec 1997 13:11:19 -0500
>From:    John Porter <jdporter@MIN.NET>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Dann Corbit wrote:
>>
>> Now, with Ada we can simply declare precision, and I will agree this is
very
>> nice.  But we can make the same sort of decisions for other languages
and use
>> efficient fixed sizes or new types of our own design.  Instead of growing a
>> bit at a time, we grow in jumps.  Now, if I declare a type of 60 bits of
>> precision, am I guaranteed that it will never overflow?  Obviously, I still
>> have to perform the same analysis that I would need for any other software
>> system.  Getting exactly what you want is much easier, though.
>>
>> Exception handling is not perfect a solution either.  It is even better to
>> engineer a solution where the types used never extend beyond the design
>range.
>> If there is any possibility that a counter of type short is not large
enough,
>> use long.  And if there is any chance that long is too small, use a larger
>> type or invent one.  Same for float, double, long double.
>
>Of course in C++ it would be pretty easy to make a class that implements
>integers of unlimited (dynamic) size.  Making it efficient would be a
>little
>harder...
>
>John Porter
>Date:    Fri, 2 Jan 1998 09:00:15 GMT
>From:    Peter Hermann <ica2ph@ALPHA1.CSV.ICA.UNI-STUTTGART.DE>
>Subject: Re: Help: Truncating Decimal Types
>
>Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
>> John asks
>
>> <<Does anyone have an easy way to extract the integer portion of a decimal
>> number - short of writing a function? Seems Ada should allow this (and
>> other attributes) for fixed and decimal types, but it doesn't without
>> first converting the value to decimal.
>> >>
>
>>
>> This is trivial, just convert it to a decimal type whose delta is 1.0.
>> The default for such conversions is truncation.
>
>This is indeed new to me. It seems I have to change my mind.
>I always thought that the Ada rule is most easily rememberable
>in that
>   -- conversions will round,
>   -- integer divisions will truncate.
>
>puzzled
>
>--
>Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
>Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
>Team Ada: "C'mon people let the world begin" (Paul McCartney)
>Date:    Wed, 31 Dec 1997 18:01:58 GMT
>From:    "Terry J. Westley" <westley@CALSPAN.COM>
>Subject: general-purpose vs. domain-specific programming languages
>MIME-Version: 1.0
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 7bit
>
>In his Practical Programmer column in Sept and Dec of CACM, Robert Glass
>discussed the failure of "modern" languages to address the needs of IS

>programmers.  Many are still using COBOL because very few newer
>languages provide the domain-specific features required for IS.
>
>He suggests that adding libraries to a general-purpose language does
>not solve the fundamental problem.  He argues by analogy (socket
>wrenches vs. a Monkey wrench) and several examples that domain-focused
>languages are sometimes more useful and productive than general-purpose
>languages.
>
>In my situation, where 90% of a 500KSLOC system is Ada (a general-purpose
>language) and approximately 8% is Tcl/Tk (great for interacting with
>Unix utilities, building user interfaces, and "gluing" together several
>Ada programs into a whole system), I recently introduced Perl for a
>specific purpose for which it is very well suited (that is, for
>searching and replacing data in text files).  This was very successful
>because it was much easier and faster to code than Ada and executed
>much faster than Tcl.
>
>But, now I am wondering if that was such a good thing in our environment.
>Since Ada and Tcl are our primary languages, we have many workers with
>those skills, but very few in Perl (I'm the only one!).  I am concerned
>for our ability to maintain this code in the future.
>
>Are you aware of any serious programming language research which
>addresses the issues of
>
>1) what makes one language more suited to a particular domain than
>   another, and
>2) how does one decide when to abandon the general-purpose language
>   in favor of the domain-focused language?
>
>Here are the sorts of questions I would like such research to address:
>   Why do people use Perl so much for CGI programming?
>   Why can't I write some libraries so that Ada is just as easy to
>      use to search and replace data in text files as Perl?
>   Why is string and list handling so much easier in Tcl and Perl
>      than in Ada?
>
>--
>Terry J. Westley, Principal Engineer
>Calspan SRL Corp, P.O. Box 400, Buffalo, NY 14225
>westley@calspan.com   http://www.calspansrc.com/
>Date:    Wed, 31 Dec 1997 13:51:13 -0500
>From:    Jon S Anthony <jsa@SYNQUIRY.COM>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>
>John Porter <jdporter@min.net> writes:
>
>> Of course in C++ it would be pretty easy to make a class that implements
>> integers of unlimited (dynamic) size.  Making it efficient would be a
>> little
>> harder...
>
>There is nothing special about C++ in this respect.  You can do this
>in anything (in particular the Ada take would in all likelihood look
>very close to the C++ take).  Now, OTOH (as someone else already
>mentioned), you already get this for free in Common Lisp.  Of course
>making it efficient is rather more than "a little harder"...
>
>/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
>Date:    Wed, 31 Dec 1997 14:40:56 -0500
>From:    Robert Dewar <dewar@MERV.CS.NYU.EDU>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>
>David says
>
><<My preferred solution is the Common Lisp one.  It will handle integers
>of any size, subject of course to machine limitation.  I can write a

>program that will handle integers accurately, without overflow.  The
>downside is the performance hit, but there are ways around that.
>>>
>
>Sure, but you should be able to program this easily in any language.
>Unfortunately, in practice it is often difficult to program efficient
>multiple precision arithmetic because none of the common languages
>provide the necessary primitives, e.g.
>
>
>   Add A+B generating sum, carry
>   Add A+B+carry, generating sum, carry
>
>In addition you need
>
>   Multiply single length giving double length
>
>   Divide single into double giving single quotient and single remainder
>
>COBOL has the last two, but other languages do not. Your compiler may
>recognize some idiom such as
>
>   x = (long)a + (long)b;
>
>or
>
>   X := Long_Integer (A) + Long_Integer (B);
>
>(C or Ada)
>
>and generate reasonable code, but it may well not, and you may end up with
>a horror, particularly if the addition is replaced by multiplication in
>the above assignments.
>Date:    Fri, 2 Jan 1998 10:52:24 GMT
>From:    Tor Iver Wilhelmsen <toriw@ONLINE.NO>
>Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>On Sat, 27 Dec 1997 10:11:55 -0400, Guillermo Schwarz
><gschwarz@netup.cl> uttered:
>
>>That's true. C is not object oriented. C++ is just an Smalltalk
>>wannabe.
>
>Um, nope. Stroustrup missed the language Simula, so C++'s OO roots
>like in the language Simula-67. For a Smalltalk wannabe, try
>Objective-C, which essentially is "C with embedded Smalltalk
>statements". Other OO C-like languages include LPC, C+@ ("cat"), TADS
>etc. The "language list" is posted to comp.lang.misc every now and
>then, and is accessible via the web, though I do not have an URL
>handy.
>
>--
>"In practical terms, borders are little more than lines on a map."
>- FAO lady, "The X-Files"
>toriw@online.no      http://www.pvv.org/%7etoriver/
>Date:    Fri, 2 Jan 1998 14:30:17 +0000
>From:    Philip Hunt <phil@OYSTER.CO.UK>
>Subject: Re: Which language pays most -- C++ vs. Java?
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>arnie sherman wrote:
>>
>> to return briefly to the original topic of this thread:
>>
>> i'm studying programing, including smalltalk (smalltalk express), &
>> would like to know not so much which language will pay the most, but
>> rather, which will be more likely to make me employable in the
>> shortest time (as an entry level programmer) ?
>
>C++ and Java.
>
>> whenever i discuss web design w/ placement people they immediatly want
>> to know if i know java. i suspect this is a trendy thing, though also
>> reflecting some real possibilities for employment in the immediate
>> future.
>
>If you want to get into web-based stuff, Java is particularly
>useful. Perl is also quite useful (for CGI scripts).
>
>--
>Phil Hunt                   phil@oyster.co.uk
>Oyster Systems Ltd    http://www.oyster.co.uk
>