Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!cedman From: cedman@golem.ps.uci.edu (Carl Edman) Newsgroups: comp.sys.amiga.tech Subject: Re: What's Wrong with ARP!!!! Message-ID: Date: 21 Nov 90 02:47:22 GMT References: <114.273F7E66@myamiga.UUCP> <1990Nov14.034507.19784@hoss.unl.edu> <7039@sugar.hackercorp.com> <90318.162021DXB132@psuvm.psu.edu> <1990Nov20.045016.8678@phoenix.pub.uu.oz.au> Organization: University of California, Irvine, USA. Lines: 75 Nntp-Posting-Host: lynx.ps.uci.edu In-reply-to: static@phoenix.pub.uu.oz.au's message of 20 Nov 90 04:50:16 GMT In article <1990Nov20.045016.8678@phoenix.pub.uu.oz.au> static@phoenix.pub.uu.oz.au (geoff c wing) writes: In cedman@golem.ps.uci.edu (Carl Edman) writes: >Assembler is a minus ? What are you getting at ? Assembler programming >certainly is the best and most taxing way of programming for programmers. Agreement. >It produces invariably the smallest and fastest code for users. Maybe >programmers who don't write in assembler can be forgiven for their >by their users if they: > a) use C and the fastest C-compilers on the market Disagreement. > b) are aware that they are sacrifying the quality of the programm > and the convinience of the user against their laziness and > development time. Agreement. >And now using assembler is a "big no-no" ? What is the world coming to ? [..... stuff deleted .....] C has only one good use for real programmers, and that is that it is portable. If you want to do some proper coding without being lazy then assembly is the only choice. Amiga's LHArc was originally in C. Wasn't that a fast program? Of course, ARP was a big advancement in programming in DOS, especially the tracking functions, because now you can LAZY and not close anything or free memory, just like C. Wow. So all you lowclass programmers who can only program in one language(especially if you can only code in C) stop posting this rubbish to amiga.tech. If you have to post it post it to alt.garbage.dump Now please, don't be offensive. Being quite a high-class programmer :-> and being able to write software in at least half a dozen languages (counting only major differences in languages , and software only large projects) easily and able to read at least 3 dozen more languages without problem, I don't think your comment applies to me (if you intended it to). But lets remember one thing: There was a time when all of us only knew one language (if we learned to program at all :-) and if that one language was C or assembler and not BASIC or PASCAL, then that is already quite a good start. The only good use of C is portability ? I deny that. On almost all environments a well-written C program (compiled with a decent compiler) is second only to a well-written assembler program in speed and size. That there are badly written C-programs (like LHArc) is no point against C. There are just as many (and I might venture to guess, more) badly-written assembler programs, which lose just as badly. About not closing things ? True: One of the worst sins of brainless coders is it not to return resources to the system as soon as possible. But HOW he causes that to happen really isn't terribly important. Having ARP return the resources creates smaller code, prevents any resources from being forgotten in one uncommon termination, allows external termination of the program with correct return of resources, and (for most resources) only insignificantly affects the size of the required resources (for tracking information). Merely spewing abuse over ARP for offering (not requireing !) this service doesn't make any point. BTW, how did you ever get the idea that you don't have to free memory/files when using C ? You aren't using c-library routines which do tracking instead of the system calls , and get linked at link-time to create HUGE execs, are you ? Carl "Who wouldn't have thought to get attacked from that corner" Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu