From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,62a0d4ce540fd3e,start X-Google-Attributes: gid103376,public From: DSCI-New Jersey Subject: Re: INFO-ADA Digest - 1 Jan 1998 to 2 Jan 1998 - Special issue Date: 1998/01/02 Message-ID: <199801021856.KAA04673@iceland.it.earthlink.net> X-Deja-AN: 312248066 Sender: Ada programming language References: <199801021750.JAA05705@belize.it.earthlink.net> X-Sender: dsci@mail.earthlink.net Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-01-02T00:00:00+00:00 List-Id: 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 >Sender: Ada programming language >From: Automatic digest processor >Subject: INFO-ADA Digest - 1 Jan 1998 to 2 Jan 1998 - Special issue >To: Recipients of INFO-ADA digests > >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 >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 >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 , >> Joshua Waxman 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 >Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. > >Kaz says > ><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 >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 >> >><>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 >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 >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 , Jon S Anthony >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 >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 >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 >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 , Jon S Anthony >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 >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 >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 >Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. > ><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" >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 >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 >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 >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" >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 >Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. > >In article <68c66j$ei3$1@client3.news.psi.net>, >Dann Corbit wrote: >>Robert Dewar wrote in message ... >>>Kaz says >>> >>><>>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 >Subject: Re: Which language pays most 17457 -- C++ vs. Java? > >In article <34AA80B3.E651528D@its.cl>, Guillermo Schwarz >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 >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 >Subject: Re: Help: Truncating Decimal Types > >Robert Dewar (dewar@merv.cs.nyu.edu) wrote: >> John asks > >> <> 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" >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 >Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. > >John Porter 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 >Subject: Re: Which language pays most? Smalltalk, not C++ nor Java. > >David says > ><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 >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 > 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 >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 >