stadler@Apple.COM (Andy Stadler) (04/25/91)
Language wars can be very hot and religious. Everybody has a reason to like and dislike the languages they are currently using, the languages they aren't using, and the languages they *wish* they were using. Let me humbly throw in a few comments from someone who's been there - I've been developing production software at a variety of companies, for the Apple II and other platforms, since the early 1980's. A recent poster summed it up best - use the right langauge for the job. There have been a lot of arguments about why one language is better than another, especially in the world of the Apple II programmer. I quickly agree that for the 8-bit Apple II, there really is no good well supported high level language (perhaps Apple Pascal but it's too old and no longer actively supported). So I will confine my comments to the Apple IIgs world. Instead of arguing the merits of particular languages, let's approach this problem from the point of view program design. There are two major concerns a programmer has - to create a program which works correctly; And to create a program which is reasonably efficient (in speed and space). Remember, a program which does the right thing slowly is MUCH more useful than a program which does the wrong thing, no matter how quickly! So it's important to start with a language which allows rapid prototyping, and easy debugging. Why do I mention prototyping? Because nobody can design the perfect program the first time. I'd much rather have an environment in which I can quickly write three or four proposed implementations of an idea, and then use them for a while (especially if there are others who can try them out). Later, only after I've chosen a specific solution, is the right time for a detailed, correct implementation which I'm going to live with for the future. So face it, folks, assembly just isn't the language for this. No matter how good a programmer you are, you just can't help but make mistakes when writing assembly code. So you spend a bunch of time fixing them. And because assembly takes so many steps to do things, you spend a lot of your time just sweating the details. It's harder to step back and concentrate on the -big picture-. And not just conceptually - it's a PHYSICAL problem too because you just can't fit as much functionality on a printed page or editor screen. So let's assume we've written a program, using a high-level language, and it's too slow. What are we going to do? While working on HyperCard IIGS, I learned a very important lesson from Bill Atkinson (author of Apple II Pascal, Quick- Draw, MacPaint, HyperCard, etc). Bill always used to tell me: "Measure, THEN optimize." Boy was he right. Time and again I'd look at some code and try to guess why it was slow; Then I'd _measure_ it's performance and discover I was TOTALLY WRONG. Performance and bottlenecks in any moderately complex program are simply UNpredictable. So don't waste your time! Instead, use measurement tools to determine QUANTITATIVELY the real problems. And after a while you'll discover something else. A program spends 95% of its time in 5% of its code. Amazingly, this still doesn't mean rewriting in assembly. You could do that, but often there's an alternative. Here's an example. Suppose you discover a routine, in which 40% of your time is being spent. And suppose by some great feat of programming, you pull out all the stops and -double- its speed. You might be real proud of yourself, but stop for a minute. For all that work, you've only sped up your program 20%. Before speeding up any routine, you should first ask yourself "why am I calling it so often!" More often than you might expect, a simple change one or two levels higher can reduce or eliminate calls to a routine. You don't even have to touch the routine because suddenly its speed becomes unimportant. This is another good reason for HLL, at least for the upper framework of a program - it's MUCH easier to make large- scale LOGICAL changes often with great performance benefits. -Concentrate on algorithms, not implementation.- Of course, when all else fails, take that time hog and rewrite it. You do use standard calling sequences, right? (see my earlier posting about calling procedures and stack frame macros) If you've set everything up correctly, you should be able to rewrite the module and simply drop it in with no change to any other portions of your program.... One thing you may find suprising is how little of your program will need rewriting to gather great speed increases. Let me quote some statistics from the authors of the original AT&T unix system: "The UNIX kernel consists of about 10,000 lines of C code and about 1,000 lines of assembly code. The assembly code can further be broken down into 200 lines included for the sake of efficiency (the could have been written in C) and 800 lines to perform hardware functions not possible in C." That's right - less than TWO PERCENT of the unix kernel was moved to assembly for speed reasons. So, in summary, I believe that a program will be written with the best design, quickest implementation, fewest bugs, and best performance, if you use the following steps: a. design, prototype, implement, and begin testing, using HLL b. begin debugging effort c. begin performance analysis d. identify key bottleneck routines e. rewrite upper level algorithms to avoid bottlenecks f. rewrite remaining bottlenecks in assembly g. continue debugging and tuning By the way, don't get the idea that I'm totally against writing original code in assembly language. Some functions, especially graphics and certain types of data manipulation (like string munging) are clearly destined to be written in assembly, and it would be a waste of time to write in high level. But that's about it. What about C versus Pascal? Well, it would be nice if we could freely choose between them, but in the limited set of compilers available for the IIGS we can't. If you are using MPW IIGS, surprisingly Pascal is the best choice because PascalIIGS is a very good compiler and CIIGS is pretty crummy. On APW, however, the ORCA compilers are both pretty good and you might find C a better choice for portability's sake. Andy Stadler Author, HyperCard IIGS Apple Computer, Inc.
psonnek@pro-mansion.cts.com (Patrick Sonnek) (04/27/91)
In-Reply-To: message from stadler@Apple.COM
I'm not going to pull in and edit that message for quote, I've got to get
to work in half an hour! :)
Anyways, to paraphrase. You claim that A good assembler programmer could
not prototype in assembly because it's just to difficult. That sounds like
the same noise I hear from all the coders and consultants around here every
day. A good Assembler programmer will, for complex, and complete
applications, (As opposed to a stand alone program) make HLL programmers
look silly. I for one can write, and completely rewrite assembler code
faster than I can HLL. I might add, our HLL guru's can't write/rewrite HLL
as fast, and as bug free, as I do assembler.
It's easy to pick one specific routine and compare HLL's to Assemblers. But
for a complete system/application, Assembler, in the hands of an assembler
programmer, will make the HLL look silly, both in coding time, and in
execution time.
I'm going to say something that is going to make a lot of people mad, but
every assembler programmer I've talked to agrees with me.
A lot of HLL programmers are poorer programmers than Assembler programers,
they lack the sophistication to program in assembler, they don't comprehend the
internals of the computer so anyAssembler code that they would write is full
of bugs, and does take a long time to debug. And because they insist that the
Assembler has to fit into thier HLL world, it dosn't even run all that fast.
And those HLL programmers who do understand all the internals, are for the
most part to lazy to program good assembler.
----
ProLine: psonnek@pro-mansion Sysop Pro-mansion: 507/726-6181
Internet: psonnek@pro-mansion.cts.com MCImail: psonnek
UUCP: crash!pro-mansion!psonnek ARPA: crash!pro-mansion!psonnek@nosc.mil
BITNET: psonnek%pro-mansion.cts.com@nosc.mil
<<Real programmers don't program in HLL's.>>
<<HLL's are for wimpy application coders!!>>meekins@anaconda.cis.ohio-state.edu (Tim Meekins) (04/28/91)
In article <8867@crash.cts.com> psonnek@pro-mansion.cts.com (Patrick Sonnek) writes: >In-Reply-To: message from stadler@Apple.COM > >Anyways, to paraphrase. You claim that A good assembler programmer could >not prototype in assembly because it's just to difficult. That sounds like >the same noise I hear from all the coders and consultants around here every >day. A good Assembler programmer will, for complex, and complete >applications, (As opposed to a stand alone program) make HLL programmers >look silly. I for one can write, and completely rewrite assembler code >faster than I can HLL. I might add, our HLL guru's can't write/rewrite HLL >as fast, and as bug free, as I do assembler. Hey, I kinda like this guy :) I also write 100% in assembly on the GS (100% C on Unix). A good story, for those of you in the business world, you probably realize that lastr year the format of the W-2 form changed, thusly voiding about every payroll system ever written, including the one used here. Anyways, all I needed was a quick program to print W-2's to the imagewriter. Since the data from the payroll system couldn't be accessed, I just printed out the *old* W2s on blank paper. So I wrote in about 3 hours an interactive prorgram which would allow me to enter the entire information for an employee then format it and print it on the W2. The ENTIRE program was written in assembly. It would have taken me twice as long if I had tried to write it in C and Pascal. What's so funny about this, is that this is one of those quick and dirty applications most of you would have said that HLL's were so well suited for. Oh, well... > >It's easy to pick one specific routine and compare HLL's to Assemblers. But >for a complete system/application, Assembler, in the hands of an assembler >programmer, will make the HLL look silly, both in coding time, and in >execution time. !!!! But, what you all tend to ignore is file size. I hear arguments that asm is only 10% faster and I don't need that extra speed, but every consider that the asm version is 2 to 10 times smaller? > >I'm going to say something that is going to make a lot of people mad, but >every assembler programmer I've talked to agrees with me. > >A lot of HLL programmers are poorer programmers than Assembler programers, >they lack the sophistication to program in assembler, they don't comprehend the >internals of the computer so anyAssembler code that they would write is full >of bugs, and does take a long time to debug. And because they insist that the >Assembler has to fit into thier HLL world, it dosn't even run all that fast. > >And those HLL programmers who do understand all the internals, are for the >most part to lazy to program good assembler. > I'm not mad :) But I do know some great asm programmers that also enjoy/prefer using HLLs for large projects and I have nothing against that (because I know I can write a competing system in asm and beat 'em w/ speed and space :) ) Another comment about prototyping. I think I came out as agreeing with you that protyping can be done very well in assembly. I don't mean to sound like that. I actually do prototype in other languages when testing algorithms. But, to keep things simple, a lot of times I just use good old Applesoft, but for the more complex prototyping I'll use C or Pascal. HLL's are great for prototyping and experimenting with algorithms, but the only problem is that usually an entirely different approach should be used when implementing in asm. Different methodolgies are employed in different languages to make things work the best, so sometimes protyping in one language what is to be implemented in another is not always a good idea. Anyways, enough rambling... -- +---------------------------S-U-P-P-O-R-T-----------------------------------+ |/ Tim Meekins <<>> Snail Mail: <<>> Apple II \| |> meekins@cis.ohio-state.edu <<>> 8372 Morris Rd. <<>> Forever! <| |\ timm@pro-tcc.cts.com <<>> Hilliard, OH 43026 <<>> /|
gtephx (Brian Campbell) (04/30/91)
In article <51986@apple.Apple.COM>, stadler@Apple.COM (Andy Stadler) writes: .... lots deleted .... > So, in summary, I believe that a program will be written with the best design, > quickest implementation, fewest bugs, and best performance, if you use the > following steps: .... lots deleted .... > Andy Stadler > Author, HyperCard IIGS > Apple Computer, Inc. Andy's comments are among the best I have seen on this debate. I have over 10 year's experience in professional software design and implementation, and to me, his statements seem natural and obvious. I don't think I could seriously disagree with anything stated. Also, an HLL is an enabler. With its abstraction of execution flow, and data structures, it enables designers to tackle more complex designs, and produce products with greater depth. So you can get large and robust applications like Hyper Card and (put your favorite game here). Otherwise we might still be in the "stone age days" of PONG and SPACE INVADERS.
gwyn@smoke.brl.mil (Doug Gwyn) (04/30/91)
In article <8867@crash.cts.com> psonnek@pro-mansion.cts.com (Patrick Sonnek) writes: >And those HLL programmers who do understand all the internals, are for the >most part to lazy to program good assembler. Ah, so there's supposed to be something wrong with taking the approach that requires less work to get the job done? I've programmed for twenty-five years, in literally dozens of distinct assembly languages over a vast variety of machine architectures. Yet you won't find me using assembly language very often these days; I don't have the time for macho bullshit. I have applications to produce.
MQUINN@UTCVM.BITNET (05/01/91)
On Mon, 29 Apr 91 20:53:34 GMT Brian Campbell said: > >Also, an HLL is an enabler. With its abstraction of execution flow, >and data structures, it enables designers to tackle more complex >designs, and produce products with greater depth. >So you can get large and robust applications like Hyper Card >and (put your favorite game here). Otherwise we might still be >in the "stone age days" of PONG and SPACE INVADERS. I agree with what you say about HLLs, but I don't think that they're the best for games. Try doing what FTA did in anything other than assembly (OKAY, when the 17Mhz ZIP comes out, it may be possible.... :) ---------------------------------------- BITNET-- mquinn@utcvm <------------send files here pro-line-- mquinn@pro-gsplus.cts.com
rhyde@ucrmath.ucr.edu (randy hyde) (05/02/91)
>> (paraphrased)... I can code faster in assembly than most HLL programmers >> can in their HLL.... You coule probably program faster in a HLL than they could as well. If you're a better programmer (and good assembly language programmers are generally better programmers than most, in *any* language) you'll be able to program faster than most programmers, period. In my experience, most programmers are not all that good (if they were, we would have to raise the standards a bit, eh?). Personally, I feel that the language of choice *can* make a significant difference in the coding time. A program which ICON, SNOBOL4, or AWK is suitable for would be miserable to program in C (or assembly) without the proper library functions *which are not generally available*. Same for APL, LISP, etc. *HOWEVER* as some people are quick to point out, when optimizing things, why concentrate on the things which don't consume the most time. Several of you have used this line against me as a reason why you shouldn't use assembly language, now let me turn it around and use it against you. In a *real* project, coding represents a small percentage of the time. Other factors such as testing, debugging, optimizing, and *especially* documentation consume the most time. On very large projects, documentation consumes as much as 70% of the total project time. Project leaders on defense contracts can support this figure (BTW, I'm not making these numbers up, I teach software engineering at Cal Poly Pomona, several texts cite these numbers). Figuring you can reduce development time by using an appropriate HLL or VHLL may be misleading, you may only be saving 7.5% of the total time. Furthermore, writing in assembly in the first place makes opti- mization easier (though debugging may be more difficult for the inexperienced). Of course, this applies to large projects. Large projects require many programmers working together. Using assembly language in such a setting would be a disaster because it is next to impossible to get that many *good* assembly language programmers together for the project. To those who claim that C is a more appropriate vehicle than assembly, I offer this word of advice-- stick with C. If this is your attitude, it's clear that you probably shouldn't be messing with assembly without a lot more practice. To those arguing for assembly, keep up the argument, perhaps you can convince a few more people to learn assembly which will make them better programmers, even when they write in HLLs. As for the Learn ASM or HLL crowd: from personal experience I can tell you, HLLs are the only way to go. Good, motivated, intelligent people can pick up anything in any order and sort out the details themselves. Unmotivated people, on the other hand, need the hand-holding that a HLL provides (BTW, C is a lousy language to teach to beginners. It does very little hand holding).
rhyde@ucrmath.ucr.edu (randy hyde) (05/02/91)
*That's* the major difference between you and I. I have to *sell* them once I produce them! :-) If the quantity of my work was more important than the quality, I'd certainly be using HLLs. In general, I've found the robustness of my pascal programs to be slightly better than my assembly programs, the robustness of my C programs to be worse than my assembly programs and the robutness of programs in other languages to be directly proportional to how well I know the language. The speed of the assembly is higher in all cases (generally by a factor of at least two). As for development time, sure, it's easier to get something working in Pascal which is cleaner, more elegant, etc., faster than in assembly. However, what about the time you spend optimizing the code (assuming you need the speed)? On projects I've worked on in the past, the combined time of coding, testing, debugging, profiling, rewriting portions in asm, testing, debugging (more difficult than asm alone, I might add!) turned out to be more time than writing, testing, and debugging directly in asm. Of course if you need portability, you have no choice. But most people only own one machine and only write code for that one machine so portability is not an issue. On the other side of the coin, I suspect that a lot of Apple owners will be switching to something else in the next five years so perhaps portability will begin to mean something. It surely will if people keep writing in C or Pascal on the GS rather than Assembly! The 65816 is just too slow (I believe in 17Mhz '816s when I can buy one!) *** Randy Hyde
rhyde@ucrmath.ucr.edu (randy hyde) (05/02/91)
I would also like to comment on HLLs being an "enabler"...
If HLLs enable people to do so much on the GS, how come we aren't
seeing a plethoria of software for the GS. There are at least five or
six HLL compilers for the GS I'm aware of. Sure, a few applications
dribble in (Hypercard, e.g.), but I don't see people porting a lot
of software from the PC or the MAC to the GS. Most software over there
was written in Pascal or C. What's the problem?
(That, if you hadn't guessed, is a rhetorical question:-) )
There are two basic problems with porting C and Pascal programs to the GS:
(1) Most C and Pascal programs are not portable! C portability is a myth.
Pascal is even worse. I'll attack C. I can't speak for MPW C, but I
know for a fact that ORCA and APW C's standard libraries are anything
but (of course, "standard library" is an oxymoron). You think segment-
ation on a PC is bad, try segmentation on the 816! Finally, most C and
Pascal programs written on PCs or Macs were written specifically for
PCs or Macs. They are system dependent. Sure, you can port a lot of
UNIX utilities to APW, but are they that useful if you don't have
UNIX? Being able to type "ls" rather than "cat" doesn't excite me.
(2) Once you manage to port your program from a bigger machine to the GS,
you'll find that it runs horribly slow. I've tried a few programs on
my 80386 and GS. The ORCA/C version ran about 50-100 times slower than
the Turbo C version. That's why you don't see a lot of developers porting
games to the GS. Even if they can lick the compatibilty problems, you've
still got a problem with speed.
Don't get me wrong. There are many decent applications you can write in
C on the GS. Heck, people have been writing reasonable applications in
Applesoft for over a dozen years.
One thing really bothers me about this group though,
people constant complain about the fact that the Apple IIGS can do wonderful
things if you really push it.
Then people start attacking the use of assembly language.
The only way you can get an Apple IIGS to perform like a Mac is to write
in assembly while mac authors write in Pascal or C. If you write in C on
the GS, the 68000 C code will blow yours away.
(of course, it may be the people who are constantly putting down the GS'
capabilities [not me, I only claim someone would be nuts to buy one today
given it's price/performance] that claim you shouldn't ever use asm.)
*** Randy Hydetoddpw@nntp-server.caltech.edu (Todd P. Whitesel) (05/02/91)
rhyde@ucrmath.ucr.edu (randy hyde) writes: > You think segment- ation on a PC is bad, try segmentation on the 816! I have. I prefer the 65816's handling of segmentation far more than the x86 segmentation. The 65816 at least has absolute long, for direct 16Mbyte addressing at any time. On an 8086 you have to mess with the segment registers to access anything other than the four 64K segments and they are DAMN SLOW when you have real time interrupt response to worry about, or data objects that are larger than 64k. Last year we built a digitizer/playback unit that required servicing a CODEC every 128 microseconds. With all the segment registers to bop around (assuming a real interrupt handler that does not restore certain registers) I couldn't get it to work using interrupts (80188 @ 8 mhz). I tried to use the DMA section to do the actual sound I/O, but couldn't get them to kick in -- I eventually gave up and wrote the thing to be a completely polled system so I could get it finished before my extension ran out. The same project with a 65816 would have been a hell of a lot easier to do -- I could have used NMI for the CODEC and IRQ for the serial chip and keypad polling with plenty of CPU left over for the rest of it. Todd Whitesel toddpw @ tybalt.caltech.edu
gwyn@smoke.brl.mil (Doug Gwyn) (05/03/91)
In article <14106@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: >I would also like to comment on HLLs being an "enabler"... >If HLLs enable people to do so much on the GS, how come we aren't >seeing a plethoria of software for the GS. There are at least five or >six HLL compilers for the GS I'm aware of. Sure, a few applications >dribble in (Hypercard, e.g.), but I don't see people porting a lot >of software from the PC or the MAC to the GS. Most software over there >was written in Pascal or C. What's the problem? Where is all the ASSEMBLY-LANGUAGE software for the IIGS? You don't see much commercial software support for the IIGS, period. This has very little to do with programming languages. >(1) Most C and Pascal programs are not portable! C portability is a myth. > Pascal is even worse. I'll attack C. I can't speak for MPW C, but I > know for a fact that ORCA and APW C's standard libraries are anything > but (of course, "standard library" is an oxymoron). You think segment- > ation on a PC is bad, try segmentation on the 816! Finally, most C and > Pascal programs written on PCs or Macs were written specifically for > PCs or Macs. They are system dependent. Sure, you can port a lot of > UNIX utilities to APW, but are they that useful if you don't have > UNIX? Being able to type "ls" rather than "cat" doesn't excite me. Perhaps you should make logical arguments rather than trying to come up with rationalizations for a position you already hold on other grounds. ORCA/C most certainly does provide a rather complete implementation of the library functions specified in the C standard. There is nothing "oxymoronic" about the concept of standard library functions. APW C predated the C standard, but even it provides a fairly complete set of standard C library functions. C is, in my opinion as a specialist in software portability, the best language to use for programming for portability. Nobody in his right mind would maintain that any choice of a programming language automatically guarantees complete portability of code written in the language; however, if you are TRYING to code portably, C provides good support for doing so. I have written hundreds of applications that run on a variety of different systems, from 8-bit Apple IIs to Cray-2s. They were coded carefully in C and were easy to port, in many cases requiring NO editing whatsoever. AT&T UNIX System source code is available only under license, and the cost is prohibitive for licensing the source for home use. Therefore porting UNIX source code is not an option. I have several independent reimplementations of UNIX utilities, and they have been QUITE useful on my Apple //e, originally, and now my IIGS. By the way, one does not need to create an executable program simply to alias "ls" to "CAT" in the APW or ORCA shell environments. >(2) Once you manage to port your program from a bigger machine to the GS, > you'll find that it runs horribly slow. I've tried a few programs on > my 80386 and GS. The ORCA/C version ran about 50-100 times slower than > the Turbo C version. That's why you don't see a lot of developers porting > games to the GS. Even if they can lick the compatibilty problems, you've > still got a problem with speed. Given your exhibited level of experience with HLLS on the Apple IIGS so far, it doesn't surprise me that your ports worked poorly. (Note also that the speed comparison was between different knids of hardware and you failed to mention the relevant clock rates etc. Certainly a 33MHz 80386 should be EXPECTED to run faster than a 2.8MHz IIGS.) I've gotten reasonable performance from lots of applications coded in C on my IIGS. Further, I have many applications running on my IIGS that I would not have had the time to code in assembler, but did have the time to port from another system where the C code already existed. By all means, if you think you don't have but the one machine to deal with, make a hobby out of it. When you finally discover that you have to move to another platform and none of your applications are available due to having coded them all in an excessively machine-dependent manner, remember that some of us tried to warn you in advance.
jerry@polygen.uucp (Jerry Shekhel) (05/03/91)
psonnek@pro-mansion.cts.com (Patrick Sonnek) writes: > >A lot of HLL programmers are poorer programmers than Assembler programers, >they lack the sophistication to program in assembler, they don't comprehend >internals of the computer so any assembler code that they would write is full >of bugs, and does take a long time to debug. And because they insist that the >Assembler has to fit into their HLL world, it dosn't even run all that fast. > This whole article is the biggest bunch of bull I've ever read. NO language ever made it difficult to write BAD programs. Assembler programmers don't make HLL programmers look silly, but GOOD programmers make BAD programmers look silly. The programming language makes no difference. > >And those HLL programmers who do understand all the internals, are for the >most part to lazy to program good assembler. > GOOD programmers that use HLLs can write HLL programs that are just as fast and efficient as GOOD assembler programs. They choose HLLs over assembler not because they are too lazy, but because that's what they prefer, period. The other issue is portability. In this world of new hardware coming out every few days and super-optimizing compilers, the only programmers for whom it's sensible to use assembler are the ones who work for the hardware manufacturers writing the lowest-level OS kernel routines. > > <<Real programmers don't program in HLL's.>> > <<HLL's are for wimpy application coders!!>> > You're right. Real programmers use on-off switches to enter compressed archives of binary code directly. -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
rhyde@clemente.ucr.edu (randy hyde) (05/04/91)
>> re: all you need is alias to do "ls" instead of "cat"
How much do you use UNIX? Probably less than I do! ls and cat do not produce
the same output. If you've got a shell script which pipes the output of ls
to some other program (like awk) it most certainly will not work if your ls
produces different output than UNIX's ls. My comment was that most GS/APW
or ORCA users don't need these fancy scripts (since the GS doesn't support
multiprogramming, hence effectively eliminating the possibility of many
UNIX scripts).
I believe you've gotten reasonable performance out of programs written in C on
your GS. Like my post stated, people have gotten reasonable performance out of
Applesoft BASIC on a 1mhz Apple II for many years. If you're the only person
using said software, or it has no competition, people can complain but it won't
do 'em any good. OTOH, if your program is written in C and it has to compete
against a product written in assembly, you may be in a bit of trouble.
re: 80386 should be expected to run faster than a 65816. Exactly the point I
was making. That's why people don't develop software for the GS. It`s easier,
especially for mediocre (nee average) programmers to write in C rather than in
assembly. If their products don't work well on the GS, no sweat, they sell 'em
on other platforms and forget the GS.
ORCA's libraries are fine if you're writing your software for the GS
from scratch.
I still argue that porting software from other platforms demonstrates
some holes
in the ORCA library. I could care less about AT&T licensing costs.
It's Byteworks problem to provide decent libraries. Because they
didn't, few people
can port their PC applications (indeed, BW should go beyond the standard
"UNIX" libraries and supply the superset provided by most PC C compiler
vendors).
If you think you're so good, here's a challenge, start with a PC or Mac-based
version of FLEX and BISON and port them to the GS (Yes, this has been done, the
results I've seen [due to segment limitations on the GS] is not very pretty).
I would like to ask the TEX porting team, "How's it going?" If porting
software
to the GS was so easy, why don't simple recompilations work? BTW, I'm not
putting down the efforts of those who are porting software to the GS, I have
considerable praise to heap on them; I'm just say that it's not as easy as on
other platforms and the result isn't as good as on other platforms.gwyn@smoke.brl.mil (Doug Gwyn) (05/04/91)
In article <14159@ucrmath.ucr.edu> rhyde@clemente.ucr.edu (randy hyde) writes: >>> re: all you need is alias to do "ls" instead of "cat" >How much do you use UNIX? Probably less than I do! Your ignorance of the UNIX community is showing. >ls and cat do not produce the same output. Of course they don't. You said that you didn't think that being able to type "ls" instead of "CAT" was such a big deal. If that was your only concern, then aliasing "ls" to "CAT" would provide even that. However, if you do need to obtain a simple list of filenames, then the absence of a UNIX-like "ls" IS a big deal. In fact, I've felt the need for a UNIX-like "ls" quite frequently in the course of IIGS software development. >My comment was that most GS/APW or ORCA users don't need these fancy >scripts (since the GS doesn't support multiprogramming, hence effectively >eliminating the possibility of many UNIX scripts). Very few UNIX shell scripts actually require multitasking. The main requirement is for unidirectional pipes, which the ORCA shell does provide. >It's Byteworks problem to provide decent libraries. Because they >didn't, few people >can port their PC applications (indeed, BW should go beyond the standard >"UNIX" libraries and supply the superset provided by most PC C compiler >vendors). ByteWorks provides practically the entire set of standard (not "UNIX") C library functions, which is all that portable C programs can rely on, plus interfaces for the Apple toolsets, GS/OS, and the shell. I don't know what else you seem to want, but it isn't a reasonable expectation. >If you think you're so good, here's a challenge, start with a PC or Mac-based >version of FLEX and BISON and port them to the GS (Yes, this has been done, the >results I've seen [due to segment limitations on the GS] is not very pretty). I don't accept such challenges. If one wants to port GNU software, he should start with the GNU sources, not with the result of hackery by PC butchers. Such an effort would also be a test of the portability of the GNU software itself, which is not necessarily very high to start with. Remember that the GNU project is specifically aimed at providing software in a UNIX-like environment, and so it is entitled to exploit UNIX-specific features that are not available under other operating systems. Also, GNU code might assume that you will use GCC, so some of it makes essential use of the nonstandard extensions to C that GCC provides. I have ported to the IIGS a large amount of C code that was designed for portability. The only ByteWorks ORCA/C library limitation that still (as or ORCA/C 1.2) gets in my way is the lack of the v*printf() functions. Releases of ORCA/C before 1.2 had so many compiler bugs that porting was inordinately difficult; release 1.2 is much better. My usual procedure is to develop utilities on UNIX, which has a much better software development environment, then port them to my IIGS when I need them. I have never encountered any "segment limitations", whatever they are.
rhyde@ucrmath.ucr.edu (randy hyde) (05/06/91)
>>>>
This whole article is the biggest bunch of bull I've ever read. NO language
ever made it difficult to write BAD programs. Assembler programmers don't
make HLL programmers look silly, but GOOD programmers make BAD programmers look
silly. The programming language makes no difference.
<<<<
You're absolutely right, of course. The programming language in use is not
what differentiates good and bad programmers. There are many bad assembly
language programmers out there. On the other hand, those who master
assembly language are, in general, better programmers than the average lot.
This is an observation, not a hard and fast rule. I'm sure you can find
many exceptions. Though, as I've said, I found it to be true in general.
*** RAndy HydeMQUINN@UTCVM.BITNET (05/07/91)
On Fri, 3 May 91 16:16:01 GMT Jerry Shekhel said: > >GOOD programmers that use HLLs can write HLL programs that are just as >fast and efficient as GOOD assembler programs. I agree with everything you said in your post, except this one sentence. This is definitely not true. It's impossible to program something like what FTA does in HLL alone. HLLs are not as fast as assembly. That's just the way it is. You can't write a 3200 color paint program in Pascal because you HAVE to use assembly because of it's speed advantage. Try writing an animation program in a HLL, then try it in Assembly and see which is faster. >They choose HLLs over >assembler not because they are too lazy, but because that's what they >prefer, period. The other issue is portability. You're right on the money here (for the most part). You have to admit though, that not all HLL programmers know assembly and many of those people would assembly if they knew it, but for the most part, people would choose a HLL. >In this world of new >hardware coming out every few days and super-optimizing compilers, >the only programmers for whom it's sensible to use assembler are the >ones who work for the hardware manufacturers writing the lowest-level >OS kernel routines. There are still some things that just can't be done in HLLs (such as 3200 colors for example). Super-optimizing compilers are still no where near the max, but they're getting there. For compilers to be as efficient as human assemblers, they're going to have to start getting into AI, which will be awhile, because todays computers are just too slow to handle it now. >+-------------------+----------------------+---------------------------------+ >| ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | >| jerry@polygen.com | >+----------------------------------------------------------------------------+ ---------------------------------------- BITNET-- mquinn@utcvm <------------send files here pro-line-- mquinn@pro-gsplus.cts.com
fadden@cory.Berkeley.EDU (Andy McFadden) (05/07/91)
In article <9105061749.AA08371@apple.com> MQUINN@UTCVM.BITNET writes: >On Fri, 3 May 91 16:16:01 GMT Jerry Shekhel said: >>GOOD programmers that use HLLs can write HLL programs that are just as >>fast and efficient as GOOD assembler programs. > >I agree with everything you said in your post, except this one sentence. >This is definitely not true. It's impossible to program something like >what FTA does in HLL alone. HLLs are not as fast as assembly. That's just [snip] Yup. I originally wrote Arc3D in APW C (even the line drawing code). There's an order of magnitude difference, even though I wrote the C code with translation to assembly in mind (i.e., the algorithms didn't change). Hell, the C version of Bresenham's algorithm was even slower than the toolbox... >>In this world of new >>hardware coming out every few days and super-optimizing compilers, That's the problem... there's no super-optimizing compiler for the //gs. Since there very likely will never be one, assembly is here to stay. >>| jerry@polygen.com | > pro-line-- mquinn@pro-gsplus.cts.com -- fadden@cory.berkeley.edu (Andy McFadden) ..!ucbvax!cory!fadden fadden@hermes.berkeley.edu (when cory throws up)
jerry@polygen.uucp (Jerry Shekhel) (05/13/91)
In article <14193@ucrmath.ucr.edu> rhyde@ucrmath.ucr.edu (randy hyde) writes: > >On the other hand, those who master >assembly language are, in general, better programmers than the average lot. > Those who master *ANY* language are, in general, better programmers than the average lot. I think that mastering a language means more than memorizing it's syntax. -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
whitewolf@gnh-starport.cts.com (Tae Song) (05/18/91)
|>>>> |This whole article is the biggest bunch of bull I've ever read. NO language |ever made it difficult to write BAD programs. Assembler programmers don't |make HLL programmers look silly, but GOOD programmers make BAD programmers |look silly. The programming language makes no difference. |<<<< | |You're absolutely right, of course. The programming language in use is not |what differentiates good and bad programmers. There are many bad assembly |language programmers out there. On the other hand, those who master |assembly language are, in general, better programmers than the average lot. |This is an observation, not a hard and fast rule. I'm sure you can find |many exceptions. Though, as I've said, I found it to be true in general. |*** RAndy Hyde How's about the opinion, when your using HLL, you're only good as the compiler. When you're using assembly, your only good as you are. Take in to account all things are relative... Expressing an opinion. INET: whitewolf@gnh-starport.cts.com UUCP: crash!gnh-starport!whitewolf ARPA: crash!gnh-starport!whitewolf@nosc.mil