mr3@ukc.ac.uk (M.Rizzo) (04/04/91)
A few days ago I replied to Mike Schwartz about his statement about the opinion of people who don't know assembler. Dunno why he replied back to me by mail not on the newsgroup. But I thought some people might find this interesting, so here's my reply: NB >> Is Mike Schwartz's original post > Is my original reply Indented text is Mike Schwartz'z mail reply to me Non-indented text is me talking now :-) >In article <mykes.0476@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >> >>I know lots of people that don't know assembler and think of themselves >>as great programemrs. If they don't understand what it means to use >>assembler, their opinions carry little weight. > >I am sick and tired of seeing posts by people who think that they >are the greatest programmers in the universe because they can program >in assembly language. > I am not the best programmer in the world and don't pretend to be. Sorry, I guess I came on a bit too strong. True, you never said that about yourself, but you seem to imply that people who can program in assembler (including yourself) have the edge over those who can't and I can't agree with that principle in general. I am not suggesting that ALL software be written in assembler language, just games. I am talking about your implication (above) that people who don't know assembler can't possibly be respectable programmers and their opinions bear little weight. I also refer you to your old .sig which said "Assembler separates the men from the boys" which makes no explicit reference to games. If you really believe in your old .sig then your opinions may be respectable as far as arcade games go, but I personally wouldn't pay heed to your opinion as far as general programming issues are concerned. I am sick of people talking about assembler language who know nothing about it. I do think that people who don't know assembler will be better programmers by at least understanding the low level functionality of computers, even if they don't use assembler. I agree that every self-respecting programmer/computer scientist should have an understanding of the low level functionality of computers. But I stress that it is NOT neccessary to have loads of experience of programming in assembly language in order to be a good programmer. >First of all, there is a difference between knowing how to program >in assembly language and using assembly language to hit the Amiga >hardware directly. Programming in assembly language is EASY. It is >also tedious but that does not make it difficult. Knowing how to >use the Amiga hardware directly is another issue - it is harder >than knowing how to program in assembly language, but it has >nothing to do with being able to program in assembly language. >It is more a matter of being a good hardware engineer - definitely >not a good programmer. > Have you made up your own mind about this, or is this just something someone (a teacher perhaps?) told you and you believed them. I made up my own mind about everything in the post I made, based on books I've read, courses/meetings/seminars I've attended, people I've spoken to, and my own programming experiences with 6809 and 8086 assembly language (I dabbled with 68000 a bit too), Pascal, C, Basic, C++, Smalltalk, COBOL, Miranda, Prolog and LISP (I'm also familiar with a few others through reading but without practice). As for people telling me things, I only believe them if they have sufficient evidence to support it. I don't know which part of the quoted paragraph you are talking about. If you are contesting my assertion that assembler is easy, then why don't you take a look at Prolog, Hope, Miranda or ML - that should change your mind as it did mine. I once thought assembler was hard to write in too - but that was a long time ago and was due to the way crappy magazines (of which there are many) made it look. Programming in assembler is no harder than programming in C, the main difference being that assembler is more tedious and admittedly allows you to optimize code better to the underlying architecture (with the increased loss of portability of course!) The overall mentality is still the same i.e IMPERATIVE PROGRAMMING If you're questioning my second point i.e. the difference between good programming and good understanding of hardware, then I'm sorry but your understanding of what programming is all about is a bit fuzzy. Programming deals with abstract concepts - algorithms, appropriate organization of code etc Some programmers have to hit the hardware e.g. to write device drivers, but in doing so they are combining programming expertise with knowledge of hardware which is a separate issue. >Some of the essential qualities of a good programmer: > o Using the appropriate language for the task at hand - > this need not be the whole program, but just a small > part of it (as is often in the case with the need for > assembler) > o Writing well-expressed, concise, readable programs > o Understanding and using software engineering concepts > such as abstraction, modularity and re-usability > o Writing portable routines where possible > >I do not consider the ability to program in assembly language a required >quality of a good programmer: I know people who don't know assembler >and are excellent programmers. A lot of UNIX programmers don't know >anything but C and they've worked on far more complex projects than >any Amiga game. In UNIX its a big sin to program in assembly language >because you lose portability across different platforms. So >Mr. Schwartz, go tell the UNIX community that their opinions carry >little weight ! > Again, the only thing I am suggesting assembler language for is games. Then be careful how you choose your words because you seemed to imply it in general (again, remember your old .sig). Even the above statement needs arranging - some games can be perfectly well written without assembler. Games don't have to be arcade games you know - there are adventures, puzzles, simulations, strategy games etc. Then again, even arcade games can be written perfectly well without assembler. But I agree that where neccessary, assembler should be used if time-critical requirements cannot be satisfied in any other way (such as a faster algorithm), and this is often the case with sophisticated arcade games. But anything that can be written in any language can be implemented in assembler, too. The resulting programs are smaller on disk and faster to execute (I'm talking about Amigas, PCs, Macs, STs, C64s, Z80s, etc.). If you sell software to a customer, they might care about these things and it and then makes sense to use it. If I was a customer I'd also care about support and I'd expect enhanced versions of the software to come out regularly. This would take ages if all was coded in assembler - just look at how long WordPerfect are taking to come out with a decent update for the Amiga. With games you don't have such problems because they only come out once. I consider it a quality required in a good games programmer. ^ arcade Maybe, but again that's not always what you said in your postings and definitely not what you said in your old .sig The AMiga OS is not portable ... You never know - in the future Commodore may develop an Amiga based on a RISC processor, just like SUN moved from 680x0 to the SPARC. Software written in C would just have to be recompiled. Assembler programs would have to be re-written from scratch. ... and neither is anything written to use it. What other machine has Intuition? You are going to have to do a lot of rewriting to port a program that uses it. If written carefully, program code related to the interface could be separated from the rest of the application. In this way, only the interface module need be re-written for another platform - much quicker than re-writing the whole thing. The interface shouldn't be too difficult to re-write anyway for other machines, not with the plethora of toolkits and tools that are becoming increasingly available for building user interfaces. I don't care about porting my software to Unix anyway. It is possible to port back and forth, but you can only use UNIX compatible subroutines provided by a 'C' library. Open() does not work on Unix, but open() does. So open() should be used if you want portability. If you don't that's up to you - I was just stating that the issue of portability is one that a complete, respectable programmer should understand. >Then there are the MASTERS who devise new ways of writing programs, >making it possible to write better programs from a Software Engineering >viewpoint. There are other types of programming languages such >as functional languages e.g. Miranda, and declarative languages >e.g. Prolog which take a totally different approach to programming. > You are talking about an entirely different universe than I am. Lemmings is a game. Games are what we are talking about. Games are not what we are talking about. We are talking about what makes a good programmer. We are talking about whether "Assembler separates the men from the boys" or not. Game programmers that take over the machine are certainly devising new ways of writing programs. No they are not - they are using an established way of writing programs, namely assembler, to merely re-invent the wheel, refusing to accept and use what others have written. You have absolutely no idea of what I'm talking about when I say "new ways of writing programs" because you've only used IMPERATIVE programming languages. Using the OS is using OLD ways of writing programs. The OS does not provide a way of writing programs - the language does. You don't seem to have a clue of what I'm talking about. >Ever tried Miranda ? Complicated programs can be written so concisely >and neatly - take a look at quicksort in Miranda - just a few lines >as compared to the dozens (or hundreds) you'd need in assembler. It >can be harder to write programs in Miranda, MUCH harder than in assembler, >but it removes the tediousness associated with assembler and at the >end of the day, you're left with programs which are shorter, more >concise, understandable, easer to modify and re-use elsewhere etc. > One of the things I like best about assembler is that instead of object code libraries, you use source code libraries. When a subroutine works, in any language, it works. In assembler, I cut and paste WHOLE working subroutines from one program to another and the subroutine still works. What ?! First of all you can use and generate object code libraries with assembly language (and that's the proper way to do it). Secondly you can cut and paste sub-routines in ANY language to your heart's content but I can't see why you would ever want to do that. If the routine is one you use often, it should be in a library. You can use source code libraries with C using #include but this would mean longer compilation times and would be utterly stupid. Ever try assembler? Yes. 8086 and 6809 on non-trivial projects plus a bit of 68000 to use the blitter as part of a larger AMIGA project written mostly in C. If not, get a clue. You can abuse any language, including assembler. ^^^^^ Abuse? What do you mean ? There is no reason why assembler language programs can't be readable. I've seen lots of cryptic high level language programs... Well that's because the language may not have been used properly or because the code implemented a very complex algorithm. In the latter case, there is no doubt that the assembler language equivalent would be even more confusing. >The people with the REAL programming skills are those with a >good understanding of software engineering skills. Assembler >cannot teach you these skills - it is totally hopeless as far >as conciseness, readability, portability and abstraction are >concerned. So for those people who ONLY know assembler and think >they are top programmers, sorry, but as far as I'm concerned >you've still got a long way to go. > I've programmed in lots of other languages besides assembler. I've used Forth, Pascal, PL/I, 'C', Fortran, Basic, TAL, and a few others. I've written compilers, assemblers, operating systems, and applications (like music programs). No matter what language I use, the knowledge of assembler language has always helped me make better programs. The knowledge of good algorithms helps me make better programs, too, even in assembler language. >Michael Rizzo What I have observed is that as a project gets larger and larger, the benefits of a high level language over assembler language decrease. I see this from having done LARGE projects in both languages. Have you actually observed any different? WHAT ON EARTH ARE YOU SAYING ?! The benefits of a high level language INCREASE not DECREASE as a project gets larger. The advantages of high-level languages over assembler are minimal with small and simple systems in all respects e.g. Portability benefit increases as project gets larger Using assembler, programs can be re-written for different platforms, but this is harder to do as the project gets larger. Using a high-level language, the same code is used (with at most a few twiddles here and there). As the project grows, portability does NOT get harder. Therefore the benefit of portability of high-level languages over assembler INCREASES as the project grows since it is becoming harder and harder to port the assembler. e.g. Conciseness and readability benefits increase as project grows Let us first consider a simple example - a function which takes an integer and returns twice its value. In Miranda f x = 2 * x In assembler (in my own pseudo-assembler language) shl 1, ax (shl stands for left shift instruction) As far as conciseness and readability go, there is not much difference here, save that it may not always be obvious that the shift is being used for multiplication. Now let us consider a more complex routine - one which will sort a list of numbers using the Quicksort algorithm. In Miranda all you need is three lines: qsort :: [*] -> [*] qsort [] = [] qsort (a:X) = qsort [b|b<-x; b<=a] ++ [a] ++ qsort [b|b<-x; b>a] The first line says that qsort is a function which maps a list of items of arbitrary type to another list of the same type. Thus, this SAME qsort routine will also work for strings as well as for numbers. The second line says that applying qsort to an empty list returns an empty list. This is important to stop the recursion employed in the third line. The third line is just about one of the best examples of conciseness I've ever seen. It is also very readable when you get used to the notation of Miranda (which resembles that of Mathematics). It simply states, that given a list whose first element is a, and whose tail (remaining elements in the list) is X, return the list formed by concatenating the following three lists: qsort [b|b<-x; b<=a] The sorted list of elements in X which are less than or equal to a [a] The list containing a itself qsort [b|b<-x; b>a] The sorted list of elements in X which are greater than a In assembler, the same quicksort routine would require several lines, definitely more than 40, and then again for numbers only not for an arbitrary type. I'd liked to have included an assembler version of quicksort here but I didn't have the time - it would take much longer. If anybody has done this I'd like a copy please. At a glance, a Miranda programmer would know what the function qsort did (even if it was called foo instead of qsort). Given the assembler equivalent, an expert assembler programmer would take time to figure out what the list of instructions was doing. As programs get more complicated, assembler loses conciseness and readability more quickly than high-level languages. Also it takes longer to express algorithms in machine code than it does in high-level languages and this gets worse as one tackles more and more complex and larger problems. Michael Rizzo -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ******************************************************** -- ********************************************************* * There's a good book called "Software Engineering" by * * Brian Ratcliff. Unfortunately its a few hundred pages * * long, but it's well worth reading if you want to talk * * about programming without saying rubbish :-) * *********************************************************
bairds@eecs.cs.pdx.edu (Shawn L. Baird) (04/04/91)
mr3@ukc.ac.uk (M.Rizzo) writes: [ lots of stuff of interest deleted for brevity (yeah, right) ] >If you're questioning my second point i.e. the difference between >good programming and good understanding of hardware, then I'm sorry >but your understanding of what programming is all about is a bit fuzzy. >Programming deals with abstract concepts - algorithms, appropriate >organization of code etc Some programmers have to hit the hardware >e.g. to write device drivers, but in doing so they are combining >programming expertise with knowledge of hardware which is a >separate issue. I don't think knowledge of the hardware is as seperable from computer programming as you might like to think. When designing an efficient program, it pays to take heed of the hardware's capabilities and limitations. Every piece of hardware has them, and the target hardware for your program should be a valid consideration. For example, anyone can code a ray tracer in C on just about anything. But a 64k C-64 really isn't the appropriate hardware to carry it out on. Not only do you have to know the limitations of the hardware, but for a succesful piece of software (that is, profitable) you also have to consider the typical hardware of your end user. For a program like The Art Department, your program will require a lot of memory. This is something that, I'm sure, the developers considered in advance. Their target market would be professionals in the video field, and so would be expected to have more memory (and more money to spend on products). They can expect to sell fewer copies than a game, for instance, and adjust the price accordingly. I diverge from my original point, however, that some knowledge of the hardware capability is essential. Designing a filled polygon three dimensional game with a frame rate of 60 frames per second requires the programmer to know the hardware. In fact, it has to be determined if the hardware is even capable of a frame rate that fast. If you are designing programs for device (hardware) independancy, you still need to know the target hardware of the end user. I admit, this isn't directly focusing on your original point, again. Let me say that designing a program for an operating system such as Unix and designing a program for a machine such as the Amiga is vastly different. On most Unix systems you won't have to worry about your application running out of memory and/or resources. Instead you worry about the allocation/deallocation of resources and the efficiency of the program. Designing a program on the Amiga, however, requires more intimate hardware knowledge. Anyone can pop of piece of portable C code onto the Amiga, hack on it and make it work. Sure, it may require 4 megabytes of memory and take 8 years to finish one run, but it works. To improve the efficiency of your program you're probably going to need to use assembly in critical sections to speed it up. Maybe you'll optimize the rest of the assembler output. Well, you say, no problem? Wait! Doesn't knowing assembly language imply some knowledge of the hardware? Ick! Most of the languages you mention above are nice on larger systems, but on an Amiga you're wasting your time. Shall we look for statistics on what two languages are used most for developement now? I would guess the answers would be C and assembly. Just how many commercial PC applications are developed in Prolog? In Pascal? In FP? In Lisp? We're not talking about developing for Unix here. We're talking about a machine where the average user has 512k of memory. Now don't get me wrong. I'm not an advocate for take over the machine and trash the OS. I figure if you have to do it, then do it, otherwise leave it alone. I strongly feel that all programmers should spend the extra effort to learn about the machines they program for. That way, instead of getting lousy ports of games like SimCity, we'll get games like Populous. (Why play a mayor when you can be a god?) As for your knowledge or assembly language, I can only feel remorse for the person who knows 8086 assembly and 6809 assembly. If that's where you developed your opinion on assembly language, no wonder it's so horrible. Anything with less than 4 32-bit GENERAL PURPOSE registers ought to be junked. >>>Some of the essential qualities of a good programmer: >>> o Using the appropriate language for the task at hand - >>> this need not be the whole program, but just a small >>> part of it (as is often in the case with the need for >>> assembler) >>> o Writing well-expressed, concise, readable programs >>> o Understanding and using software engineering concepts >>> such as abstraction, modularity and re-usability >>> o Writing portable routines where possible >>> >>>I do not consider the ability to program in assembly language a required >>>quality of a good programmer: I know people who don't know assembler >>>and are excellent programmers. A lot of UNIX programmers don't know >>>anything but C and they've worked on far more complex projects than >>>any Amiga game. In UNIX its a big sin to program in assembly language >>>because you lose portability across different platforms. So >>>Mr. Schwartz, go tell the UNIX community that their opinions carry >>>little weight! The Unix community's opinion (of which most of us are part) bears very little relevance to programming an Amiga. Let me ask you, how many of these Unix hackers could actually program an Amiga game, if their complexity is so inferior to that of their Unix projects. Mr. Schwartz is a game programmer, and from what I've seen of his postings he's probably pretty good at it. As for his .sig, I suppose you'll be calling AT&T next to see if they've licensed the BS I'm writing now? Writing in assembler in Unix is a sin? Gee boss, parts of the OS are written in assembler, guess we'd better junk it! Just how did a seperate convention for 68000 assembly come about, if nobody ever uses assembly with Unix? Assembly is used in commerical Unix products that need the extra speed it offers. About the only reason public domain products don't use it is it's inherent unportability. Why does Sun try to remain binary compatible through most of their line? Because, some of the stuff can't just be ported and recompiled on a new machine. >>Again, the only thing I am suggesting assembler language for is >>games. And rightfully so. Games, however, are not the only place that assembly language is used. I think Mr. Rizzo is biased against assembly language programmers, and is somewhat stereotypical in his judgement that if you use assembly you are less than a real programmer. >assembler. But I agree that where neccessary, assembler should be used >if time-critical requirements cannot be satisfied in any other way >(such as a faster algorithm), and this is often the case with >sophisticated arcade games. Although games may be written without assembler, I would state that those that use it for critical sections (if they have any) are more efficient. I doubt that any decent arcade style game can be written without assembler. Even the best optimizing compiler can only do so much, and the operating system routines hold you back too far when you have specific requirements. I suppose you could mimic assembly with custom = 0xdff000, etc., but this kind of defeats the point and takes even longer than assembly. >>But anything that can be written in any language can be >>implemented in assembler, too. The resulting programs are smaller >>on disk and faster to execute (I'm talking about Amigas, PCs, Macs, >>STs, C64s, Z80s, etc.). If you sell software to a customer, they >>might care about these things and it and then makes sense to use it. >If I was a customer I'd also care about support and I'd expect enhanced >versions of the software to come out regularly. This would take ages >if all was coded in assembler - just look at how long WordPerfect are >taking to come out with a decent update for the Amiga. With games you >don't have such problems because they only come out once. I believe Sculpt-3D and series were all coded directly in assembly. Why people persist in claiming that assembler code is unmaintainable I just can't figure out. If your assembler code is unmaintainable then it's your own coding techniques that are at fault. Assembly provides macros, definitions, etc. that give it support facilities that rival most higher level languages. If a programmer uses equates for constants, macros when needed, etc., that programmer is writing efficient and maintainable code. >>The AMiga OS is not portable ... >You never know - in the future Commodore may develop an Amiga based >on a RISC processor, just like SUN moved from 680x0 to the SPARC. >Software written in C would just have to be recompiled. Assembler >programs would have to be re-written from scratch. I believe that there is some capability in the Sparc Stations to run older Sun executables. Regardless, it is nice to use the OS when it is effective, but chastising someone who has no choice as to what language to use because of changes that _may_ happen borders on the ridiculous. I don't think anyone would reasonably expect most games to survive a processor transition like that. Or for that matter, a lot of other software. As for the assembler being re-written from scratch, it's more likely it would have to be modified extremely. The framework of the program would probably be intact. If you insist that programmers maintain hardware compatibility buy using nothing but system calls you force programmers to go through very slow routines like DrawPixel(), and thereby degrade the overall quality of the game. (For games that need the performance) Here's a small list of things that I can come up with that require knowledge of assembly: writing an OS, writing device drivers, writing _fast_ programs (for instance, Sculpt-3D had to be fast. They didn't use the best algorithms in the world, however, so it should have been faster), writing compilers (yeah, those things you use in preference to assembly). Inherently, anthing that needs to be either low level, or fast. Did you notice how most colleges require some sort of course like Computer Organization? (a class dedicated to familiarizing computer science majors with what makes the hardware tick) Do you suppose they have this class just to irk you? >>... and neither is anything written to use it. What >>other machine has Intuition? You are going to have to do a lot of >>rewriting to port a program that uses it. Well, if it is an application written for X, OS/2, or other windowing system, there is probably an event driven setup, which, although not providing a straight port, would provide a somewhat easier port. However, given the context of the argument (that is, games) you probably aren't going to see a lot of porting to Unix or OS/2. >>Games are not what we are talking about. We are talking about what >>makes a good programmer. We are talking about whether "Assembler >>separates the men from the boys" or not. Not to mention whether or not AT&T has licensed my message yet. Assembler sure as hell doesn't hurt a programmer, and remaining ignorant of other methods or writing applications is never a good thing. I, myself, have exposed myself to a variety of languages. None of them have made me into a "good" programmer, but I feel that all of them have made me a "better" programmer. Assembler seperates the knowledgable from the ignorant. If that means the men from the boys, then yes. Anyone who intends to never learn assembly is just perpetuating his/her own ignorance. >>Game programmers that take over the machine are certainly devising >>new ways of writing programs. >No they are not - they are using an established way of writing programs, >namely assembler, to merely re-invent the wheel, refusing to accept and >use what others have written. You have absolutely no idea of what I'm >talking about when I say "new ways of writing programs" because you've >only used IMPERATIVE programming languages. Re-inventing the wheel is an important concept in learning anything. I would say that one of the things that makes a good programmer is education, and refusing to learn is certainly a sign of a lack of education. I know programmers who don't want to sulley themselves with the dirt of programming in assembly language. These are the same people who have no desire to learn anything about the hardware they use, and no desire to try new (or old but as yet unlearned) ways of doing things. Tell me, did you start math at the Calculus level (or above), or did you develop from earlier tools such as Algebra? >>Ever try assembler? >Yes. 8086 and 6809 on non-trivial projects plus a bit of 68000 to use >the blitter as part of a larger AMIGA project written mostly in C. I guess that one experience wasn't enough to show you that 8086 & 6809 assembly is hardly worth considering as assembly. For a real laugh, try assembly on a PDP-11. >>If not, get a clue. You can abuse any language, including assembler. >Abuse? What do you mean? Anyone who can write in assembly and who is proficient in C or some mid to high level language can write clear and accurate assembly. Abuse of assembly can occur just like abuse of a higher level language. It can also be damn near as elegant. >>>The people with the REAL programming skills are those with a >>>good understanding of software engineering skills. Assembler >>>cannot teach you these skills - it is totally hopeless as far >>>as conciseness, readability, portability and abstraction are >>>concerned. So for those people who ONLY know assembler and think >>>they are top programmers, sorry, but as far as I'm concerned >>>you've still got a long way to go. So, having REAL programming skills denies any ability in programming assembly? Of course assembly isn't the only language worth learning, as Mr. Schwartz points out himself. I feel sorry for people who think they're REAL programmers with REAL skills who can't even acknowledge the use of a REAL programming language. >>I've programmed in lots of other languages besides assembler. >>I've used Forth, Pascal, PL/I, 'C', Fortran, Basic, TAL, and >>a few others. I've written compilers, assemblers, operating >>systems, and applications (like music programs). No matter >>what language I use, the knowledge of assembler language has >>always helped me make better programs. The knowledge of good >>algorithms helps me make better programs, too, even in assembler >>language. Exactly my feelings on the matter. Assembly language is worth knowing, without a doubt. You aren't a REAL programmer until you've learned it. Assembler is a critical language. If you don't learn assembler, you're missing out on the only way to do some programs. (Such as OS programming) >In Miranda all you need is three lines: >qsort :: [*] -> [*] >qsort [] = [] >qsort (a:X) = qsort [b|b<-x; b<=a] ++ [a] ++ qsort [b|b<-x; b>a] >The first line says that qsort is a function which maps a list >of items of arbitrary type to another list of the same type. >Thus, this SAME qsort routine will also work for strings as well >as for numbers. >The second line says that applying qsort to an empty list returns >an empty list. This is important to stop the recursion employed in >the third line. >The third line is just about one of the best examples of conciseness >I've ever seen. It is also very readable when you get used to the >notation of Miranda (which resembles that of Mathematics). It >simply states, that given a list whose first element is a, and >whose tail (remaining elements in the list) is X, return the >list formed by concatenating the following three lists: > qsort [b|b<-x; b<=a] The sorted list of elements in X which are > less than or equal to a > [a] The list containing a itself > qsort [b|b<-x; b>a] The sorted list of elements in X which are > greater than a You go on mooning over Miranda through this entire article. Great, it lets you do a quick sort in 3 lines. Let's see you write a program that renders a 60 frame per second arcade game on the Amiga, with it. In fact, let's see you do the above with anything but assembler. Hell, at least I cn do a quicksort in assembly. >In assembler, the same quicksort routine would require several lines, >definitely more than 40, and then again for numbers only not for an >arbitrary type. I'd liked to have included an assembler version of >quicksort here but I didn't have the time - it would take much >longer. If anybody has done this I'd like a copy please. >At a glance, a Miranda programmer would know what the function qsort >did (even if it was called foo instead of qsort). Given the assembler >equivalent, an expert assembler programmer would take time to figure >out what the list of instructions was doing. Yes, but sometimes you pay for readability with performance, and most programs that use quicksorts probably don't need the speed as much as an Amiga arcade game. >As programs get more complicated, assembler loses conciseness and >readability more quickly than high-level languages. Also it takes >longer to express algorithms in machine code than it does in >high-level languages and this gets worse as one tackles more and >more complex and larger problems. This isn't necessarily true. Yes, you program gets longer (and therefor occupies more physical space), but if you've written a general purpose quicksort routine in assembly, there isn't much reason to code it several times. I suspect that when you use it, you'll by using a macro that looks remarkably similar to calling quicksort in a higher level language. Of course, I can always write the C version of quicksort on a single line (provided enough characters. ;) >>>Michael Rizzo >Michael Rizzo >>-- >>******************************************************** >>* Appendix A of the Amiga Hardware Manual tells you * >>* everything you need to know to take full advantage * >>* of the power of the Amiga. And it is only 10 pages! * >>******************************************************** >-- >********************************************************* >* There's a good book called "Software Engineering" by * >* Brian Ratcliff. Unfortunately its a few hundred pages * >* long, but it's well worth reading if you want to talk * >* about programming without saying rubbish :-) * >********************************************************* -- ********************************************************** * Of course, I doubt "Software Engineering" tells you * * everything you need to know to take full advantage of * * the power of the Amiga, even considering it's great * * length. :P "Software Engineering" principles are * * valid in any project, but you assume that programming * * in assembler violates the rules of "Software * * Engineering", when assembler is just a tool. It is * * the programmer, who, in the end, either violates or * * doesn't violate valid principles of "Software * * Engineering". * ********************************************************** * Knowledge seperates the men from the boys! * ********************************************************** --- Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD The above message is not licensed by AT&T, or at least, not yet.
cg@ami-cg.UUCP (Chris Gray) (04/05/91)
In article <2220@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: [lots of other stuff deleted] >Writing in assembler in Unix is a sin? Gee boss, parts of the OS are >written in assembler, guess we'd better junk it! Just how did a >seperate convention for 68000 assembly come about, if nobody ever uses >assembly with Unix? Assembly is used in commerical Unix products that >need the extra speed it offers. About the only reason public domain >products don't use it is it's inherent unportability. Why does Sun >try to remain binary compatible through most of their line? Because, >some of the stuff can't just be ported and recompiled on a new machine. Last I checked the Sun Unix kernal had a couple of hundred lines of code in assembler. Stuff to fiddle with the MMU, setup interrupt vectors, etc. I don't believe ANY of the user-level utilities are written in assembler. (I believe troff was in PDP-11 assembler waaaaay back, but no longer.) >I believe that there is some capability in the Sparc Stations to run >older Sun executables. Not that I know of, unless they went to the trouble of writing an emulator. The instruction sets aren't even similar. >Here's a small list of things that I can come up with that require >knowledge of assembly: writing an OS, writing device drivers, writing >_fast_ programs (for instance, Sculpt-3D had to be fast. They didn't >use the best algorithms in the world, however, so it should have been >faster), writing compilers (yeah, those things you use in preference >to assembly). It's a good thing you say "knowledge of assembly" or I could really flame you! Most OS's nowadays are written by groups of people. Most of those people probably never program in assembly, and don't need to have. (Most probably have, but that's just because of the timing of their careers.) Writing a device driver for UNIX requires looking at sample source much more than it requires any assembly knowledge - I found the undocumented UNIX internal conventions (like for 'select'!) much more troublesome than straightforward fiddling with a couple of registers. I don't believe I've ever seen a current UNIX device driver that had any assembler in it. I've written a half dozen compilers in my time, and seen a few others. None had any assembler parts in them (older IBM mainframe ones did, and I hear Turbo stuff on MSDOS is in assembler, however). The only assembler I did for my entire Draco compiler/libraries/etc was some run-time support stuff (like doing 32 bit mul/div on the 68000). You definitely need to know the CPU to write a code generator for it, and having programmed in assembler is a definite asset for hand coding a code generator. However, some of the research and retargettable compilers nowadays have automatically produced code generators and optimizers - the programmer need only read the CPU manual and convert the instruction descriptions to the proper form - the software does the rest. I must agree, though, that knowing a bit about assembler programming is a useful skill for programmers who will be coming at all close to the machine. It's not clear that scientists doing numerical simulations and graphics need it, however. -- Chris Gray alberta!ami-cg!cg or cg%ami-cg@scapa.cs.UAlberta.CA
forgeas@swinjm.UUCP (Jean-Michel Forgeas) (04/05/91)
In article <7214@harrier.ukc.ac.uk>, M.Rizzo writes: > A few days ago I replied to Mike Schwartz about his statement about > the opinion of people who don't know assembler. As an english translation of french words: you are searching lice on the head of a bald man. ;-) > Dunno why he replied > back to me by mail not on the newsgroup. Mike Schwartz had his reasons. > But I thought some people might > find this interesting, so here's my reply: Mike Schwartz did not say what you wanted to understand from him. This is your problem. And in this case, a too big posting. I post this, because if I email your are able to repost it :-) Regards, Jean-Michel -- \___/ Jean-Michel Forgeas \-/ cbmvax!cbmehq!cbmfra!swinjm!forgeas | The Software Winery -^- And, where is the universe ?
mr3@ukc.ac.uk (M.Rizzo) (04/05/91)
I think in his reply to my post Mr. Baird twisted a few of the things I said and put them in a different context. Here goes - In article <2220@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >mr3@ukc.ac.uk (M.Rizzo) writes: > >I don't think knowledge of the hardware is as seperable from computer >programming as you might like to think. When designing an efficient >program, it pays to take heed of the hardware's capabilities and >limitations. When designing an efficient program, the first important thing to do is choose/devise efficient algorithms. A person who can get the required efficiency from a better algorithm is better than one who uses an inferior algorithm in assembler. >is essential. Designing a filled polygon three dimensional game with a >frame rate of 60 frames per second requires the programmer to know the >hardware. In fact, it has to be determined if the hardware is even >capable of a frame rate that fast. Yes, agreed, but there the programmer is delving into hardware. It is not a requirement of a general programmer to know the hardware in any detail. An arcade games programmer might have to go into it - but its not programming - its knowledge of machine architecture, and many people can do perfectly good jobs without it. >... Let me say >that designing a program for an operating system such as Unix and >designing a program for a machine such as the Amiga is vastly >different. On most Unix systems you won't have to worry about your >application running out of memory and/or resources. Instead you worry >about the allocation/deallocation of resources and the efficiency of >the program. Designing a program on the Amiga, however, requires more >intimate hardware knowledge. I think the Amiga OS knows how to handle resources just fine - so I'd say it requires knowledge of the OS not the hardware. How is an "intimate knowledge of the hardware" supposed to help you with checking if you've got enough memory to proceed, or whether a particular resource is available or not. >Doesn't knowing >assembly language imply some knowledge of the hardware? Ick! It implies knowledge of the processor not ALL the hardware. What I was talking about with Mr. Schwartz was whether programming things such as the blitter, copper, disk controller etc directly had anything to do with assembly language programming or not. It is NOT related to assembly language programming but to knowledge of the Amiga's hardware. > Most of >the languages you mention above are nice on larger systems, but on an >Amiga you're wasting your time. I note that you most conveniently did not include my original text here. Did I say anything about the Amiga ? I was just listing the languages I've had experience with because Mr. Schwartz was asking me whether what I was saying was my own opinion or whether some teacher brainwashed me. DON'T CHANGE THE CONTEXT OF WHAT I SAY PLEASE ! > [Chunk of irrelevant stuff about languages used on Amiga deleted] >Now don't get me wrong. I'm not an advocate for take over the machine >and trash the OS. I figure if you have to do it, then do it, otherwise >leave it alone. Again totally irrelevant to the discussion. >As for your knowledge or assembly language, I can only feel remorse for >the person who knows 8086 assembly and 6809 assembly. If that's where >you developed your opinion on assembly language, no wonder it's so >horrible. Anything with less than 4 32-bit GENERAL PURPOSE registers >ought to be junked. Your use of the word "junked" only makes you sound immature. There are a lot of things you can learn using any processor - the basic principles of assembly language are the same. Admittedly, there may be some tricks that you can do with one processor and can't do on another - but calling the 8086 and 6809 (great chip back in the days of the good old Dragon 32 :-) junk only shows your ignorance. Have you ever even used them ? >The Unix community's opinion (of which most of us are part) bears very >little relevance to programming an Amiga. Again I am not talking about the Amiga specifically - I am talking about programming in general. In any case I can't agree with the above statement. Do you think that the only thing people do with Amiga's is write games for them ? Look at Matt Dillon's excellent programs for the Amiga - don't tell me he wasn't influenced by UNIX ! >Let me ask you, how many of these Unix hackers could actually program >an Amiga game, if their complexity is so inferior to that of their Unix >projects. First of all I was talking about programming in general NOT only games. Secondly, let me ask you how many Amiga game programmers would be capable of working on a really large-scale project involving very complex algorithms, thousands and thousands of lines of code, working with dozens and dozens of people, and a highly complex problem domain. Mr. Schwartz mentioned use of "source-code libraries" which is absolutely ridiculous! What happens if two modules both include the same library then eh ? Or maybe he doesn't organize his code into modules but just has one massive listing which he assembles every time, implying that he probably doesn't know how to use such tools as MAKE. >Mr. Schwartz is a game programmer, and from what I've seen >of his postings he's probably pretty good at it. I don't doubt that and never did. But that does not make him a pretty good programmer in general. Some of the things he said in his reply to my original post were very confused, like saying the benefits of high-level languages over assembler decrease with larger projects (see below). >As for his .sig, I >suppose you'll be calling AT&T next to see if they've licensed the BS >I'm writing now? You haven't supported Mr. Schwartz' statement "Assembler separates ..." one bit. Try and give support for it instead of saying silly things. >Writing in assembler in Unix is a sin? Gee boss, parts of the OS are >written in assembler, guess we'd better junk it! Very funny. There are obviously parts of the OS written in assembler but I'm equally obviously talking about applications. >Just how did a >seperate convention for 68000 assembly come about, if nobody ever uses >assembly with Unix? Assembly is used in commerical Unix products that >need the extra speed it offers. About the only reason public domain >products don't use it is it's inherent unportability. Why does Sun >try to remain binary compatible through most of their line? Because, >some of the stuff can't just be ported and recompiled on a new machine. OK I admit that my statement was a bit too strong. Nevertheless, most UNIX programs are written in C. Assembler is rarely used. Many UNIX programmers (probably the majority) do not use assembler. >I think Mr. Rizzo is biased against >assembly language programmers, and is somewhat stereotypical in his >judgement that if you use assembly you are less than a real programmer. I think you need to attend a course in logic. I said that being able to use assembler does not _neccessarily_ make you a better programmer than one who doesn't. This DOES NOT IMPLY that if you use assembly you are less than a real programmer. I NEVER said or implied such a stupid thing. >Why people persist in claiming that assembler code is unmaintainable I >just can't figure out. If your assembler code is unmaintainable then >it's your own coding techniques that are at fault. Assembly provides >macros, definitions, etc. that give it support facilities that rival >most higher level languages. If a programmer uses equates for constants, >macros when needed, etc., that programmer is writing efficient and >maintainable code. I wouldn't say unmaintainable, but definitely much less maintainable than high-level programming languages. For a start, code is longer and therefore less concise - the more split up into low-level instructions, the less concise a program is - you can't get away with that. There is inadequate support for abstraction, data hiding, re-usability (e.g. polymorphism in some more recent high-level languages - I'll bet you that half the game programmers on the Amiga haven't even heard of such a thing) Do macros and equates make programs maintainable ? Readable maybe, but not exactly maintainable. For maintainability you need to to be able to change parts of a program without affecting the rest of it. You need local environments at the least and parameter passing mechanisms to hide the implementation of a routine and reveal only its interface. >I believe that there is some capability in the Sparc Stations to run >older Sun executables. Regardless, it is nice to use the OS when it >is effective, but chastising someone who has no choice as to what >language to use because of changes that _may_ happen borders on the >ridiculous. I don't think anyone would reasonably expect most games >to survive a processor transition like that. I don't either but then again I never said so. >Here's a small list of things that I can come up with that require >knowledge of assembly: writing an OS, writing device drivers, writing >_fast_ programs (for instance, Sculpt-3D had to be fast. They didn't >use the best algorithms in the world, however, so it should have been >faster), writing compilers (yeah, those things you use in preference >to assembly). Inherently, anthing that needs to be either low level, >or fast. Did you notice how most colleges require some sort of >course like Computer Organization? (a class dedicated to familiarizing >computer science majors with what makes the hardware tick) Do you >suppose they have this class just to irk you? Any self-respecting Computer Science graduate knows about Computer Architecture and programming in assembly language (no need for any large-scale project mind you - just an appreciataion). But we are talking about what makes a good programmer. >Well, if it is an application written for X, OS/2, or other windowing >system, there is probably an event driven setup, which, although not >providing a straight port, would provide a somewhat easier port. > >However, given the context of the argument (that is, games) you The context of the argument is NOT games. I made that very clear in my last post. >Assembler sure as hell doesn't hurt a programmer, Never said it did >and remaining ignorant of other methods or writing applications is >never a good thing. Never said it was. But it isn't neccessarily a bad thing not to learn assembler. >I, myself, have exposed myself to a variety of languages. >None of them have made me into a "good" programmer, but I feel that >all of them have made me a "better" programmer. Agreed. >Assembler seperates the knowledgable from the ignorant. Rubbish. This slightly contradicts what you said above. You can't use one property to distinguish the knowledgeable from the ignorant. A language like Prolog demands more intelligence than does assembler but it still doesn't distinguish the knowledgeable from the ignorant. >If that means >the men from the boys, then yes. Anyone who intends to never learn >assembly is just perpetuating his/her own ignorance. Sorry but this is is a load of BS. >Re-inventing the wheel is an important concept in learning anything. I >would say that one of the things that makes a good programmer is >education, and refusing to learn is certainly a sign of a lack of >education. I know programmers who don't want to sulley themselves with >the dirt of programming in assembly language. These are the same >people who have no desire to learn anything about the hardware they use, >and no desire to try new (or old but as yet unlearned) ways of doing >things. No human can learn everything. If you argue that people who use high-level languages should know low-level languages, then I tell you that every assembler programmer should have knowledge of the inner workings of the microchip ... all the way down to its molecules and all. You know programmers who don't want to sulley themsleves with the dirt of programming in assembler - well I know programmers who are afraid to even try to learn a bit about Prolog. So what ? People learn the things they NEED to learn. If you want to write fast games and feel you NEED to know assembler fine. But not everybody needs it - the majority of people don't, and that doesn't neccessarily make you any better than they are. >Tell me, did you start math at the Calculus level (or above), or did >you develop from earlier tools such as Algebra? Did you start maths with a proof of why 0 + 0 = 0. No because it involved ideas which were too hard to understand at that age. But math students see the proof for 0 + 0 = 0 in the first year of their BSc, even though they've been using the result all their lives. Also some people can use 0 + 0 = 0 without ever needing to know why. >>the blitter as part of a larger AMIGA project written mostly in C. > >I guess that one experience wasn't enough to show you that 8086 & 6809 >assembly is hardly worth considering as assembly. For a real laugh, >try assembly on a PDP-11. The PDP-11 holds an important place in the history of computing. Laugh as much as you want - I won't and many others won't either. >>>>The people with the REAL programming skills are those with a >>>>good understanding of software engineering skills. Assembler >>>>cannot teach you these skills - it is totally hopeless as far >>>>as conciseness, readability, portability and abstraction are >>>>concerned. So for those people who ONLY know assembler and think >>>>they are top programmers, sorry, but as far as I'm concerned >>>>you've still got a long way to go. > >So, having REAL programming skills denies any ability in programming >assembly? I really HATE it when people misquote me. I never said that. I said that it can't teach you certain concepts. People who do understand these concepts are no less competent if they can program in assembler. Sheesh ! >Of course assembly isn't the only language worth learning, >as Mr. Schwartz points out himself. I feel sorry for people who >think they're REAL programmers with REAL skills who can't even >acknowledge the use of a REAL programming language. I think that any decent programmer should at least be conscious of other types of programming languages other than imperative ones. I think that is just one of many more important things that make a complete programmer than being able to program in assembly language. There are programmers who don't even know that totally different approaches to programming exist. All they know about is purely IMPERATIVE languages like assembler, C, PASCAL etc and know nothing about declarative, functional or object-oriented approaches. >>>I've programmed in lots of other languages besides assembler. >>>I've used Forth, Pascal, PL/I, 'C', Fortran, Basic, TAL, and >>>a few others. I've written compilers, assemblers, operating >>>systems, and applications (like music programs). No matter >>>what language I use, the knowledge of assembler language has >>>always helped me make better programs. The knowledge of good >>>algorithms helps me make better programs, too, even in assembler >>>language. >Exactly my feelings on the matter. Assembly language is worth knowing, >without a doubt. Agreed. > You aren't a REAL programmer until you've learned it. Rubbish ! >Assembler is a critical language. More rubbish ! >If you don't learn assembler, >you're missing out on the only way to do some programs. (Such as OS >programming) Not all programmers HAVE to know how to do (low-level) OS programming. >... Miranda ... >lets you do a quick sort in 3 lines. Let's see you write a program >that renders a 60 frame per second arcade game on the Amiga, with it. >In fact, let's see you do the above with anything but assembler. You missed the point and are again twisting my intentions. I was simply demonstrating to Mr. Schwartz that the benefits of high-level languages INCREASE not decrease (as he said) as the project gets larger. Read carefully ! >Hell, at least I cn do a quicksort in assembly. Hell I can spell "can" properly :-) Well I can too coz' I did it in Pascal and it shouldn't be much different from that because its imperative. I didn't because my Amiga and PC are a few thousand miles away from where I am now. At the moment I only have SUN's and DEC's at my disposal and I don't have the time to get into assembly on them. >>In assembler, the same quicksort routine would require several lines, >>definitely more than 40, and then again for numbers only not for an >>arbitrary type. I'd liked to have included an assembler version of >>quicksort here but I didn't have the time - it would take much >>longer. If anybody has done this I'd like a copy please. > >>At a glance, a Miranda programmer would know what the function qsort >>did (even if it was called foo instead of qsort). Given the assembler >>equivalent, an expert assembler programmer would take time to figure >>out what the list of instructions was doing. > >Yes, but sometimes you pay for readability with performance, and True but out of point yet again. >most programs that use quicksorts probably don't need the speed as >much as an Amiga arcade game. Er - I think there a lot of games that could make use of quicksort actually, or would you prefer to use bubble sort instead, simply because its easier to write in assembly. >>As programs get more complicated, assembler loses conciseness and >>readability more quickly than high-level languages. Also it takes >>longer to express algorithms in machine code than it does in >>high-level languages and this gets worse as one tackles more and >>more complex and larger problems. > >This isn't necessarily true. Yes, you program gets longer (and >therefor occupies more physical space), but if you've written a >general purpose quicksort routine in assembly, there isn't much >reason to code it several times. I suspect that when you use it, >you'll by using a macro that looks remarkably similar to calling >quicksort in a higher level language. Of course, I can always A macro ? I hope you wouldn't be putting ALL the quicksort routine in a macro 'coz if you used quicksort 10 times in your program you'd get the code duplicated 10 times. And even if you just used the macro to load registers followed by a jump to a subroutine, it would be pretty messy and still involve code duplication. >-- >********************************************************** >* Of course, I doubt "Software Engineering" tells you * >* everything you need to know to take full advantage of * >* the power of the Amiga, even considering it's great * >* length. :P "Software Engineering" principles are * >* valid in any project, but you assume that programming * >* in assembler violates the rules of "Software * I did not assume it violated anything. I said that it did not support certain concepts adequately, as well as (some) high-level languages do. >********************************************************** >* Knowledge seperates the men from the boys! * >********************************************************** Agreed - knowledge not assembler. >--- > Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD > The above message is not licensed by AT&T, or at least, not yet. Conclusion: For the umpteenth time, I am talking about programming in general not games programming ! Again I remind you that Mr. Schwartz's old sig used to say "Assembler separates the men from the boys" which does NOT mention games. Secondly I have nothing against assembly language: I use it myself where appropriate, and I explicitly said that it should be used where appropriate, though I really can't see why a WHOLE program should have to be written in assembly langauage. Finally, the whole point of me opening my big mouth in the first place was to point out that there are a lot of issues which people who claim to be great programmers don't even know about, let alone know how to use. Some of these issues are much more important to make a complete programmer than the ability to program in assembler. Assembly language is a good thing to know and can make a programmer wiser. But it is NOT as essential or important as many other issues are. Michael Rizzo
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/06/91)
In article <7214@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >A few days ago I replied to Mike Schwartz about his statement about >the opinion of people who don't know assembler. Dunno why he replied >back to me by mail not on the newsgroup. But I thought some people might >find this interesting, so here's my reply: M. Rizzo, I am sure Mike is carrying on this argument through email with several people, myself included, and I am sure that it's gotten beyond the emotional state with more than several of us... BUT, the idea of using email vs the newsgroup is to carry on a more private conversation, and unless there's a general agreement to post private email to the net, it is not in good form to do so. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/06/91)
In article <2220@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >mr3@ukc.ac.uk (M.Rizzo) writes: > >Writing in assembler in Unix is a sin? Gee boss, parts of the OS are >written in assembler, guess we'd better junk it! Just how did a >seperate convention for 68000 assembly come about, if nobody ever uses >assembly with Unix? Assembly is used in commerical Unix products that >need the extra speed it offers. About the only reason public domain >products don't use it is it's inherent unportability. Why does Sun >try to remain binary compatible through most of their line? Because, >some of the stuff can't just be ported and recompiled on a new machine. Most people do not use assembly with UNIX... OBVIOUSLY the OS needs *some* assembly, but in fact *most* device drivers are written entirely in C, including the interrupt handler (with only a tag in assembly). Even the serial interrupt handler is usually done in C, though not always. The reasons are obvious.. you have a tiny market writing a program that only works on one type of UNIX box. It grows a hundred times larger if you write the code in a portable manner (C or some other high level language). These reasons have nothing to do with programming on the amiga specifically. >Here's a small list of things that I can come up with that require >knowledge of assembly: writing an OS, writing device drivers, writing >_fast_ programs (for instance, Sculpt-3D had to be fast. They didn't OS yes device drivers no (but obviously need some know. of hardware) fast programs no >use the best algorithms in the world, however, so it should have been >faster), writing compilers (yeah, those things you use in preference >to assembly). Inherently, anthing that needs to be either low level, compilers - yes (in knowledge), assuming you don't generate intermediate output code and run it through sombody's (GNUs) code generator. >or fast. Did you notice how most colleges require some sort of >course like Computer Organization? (a class dedicated to familiarizing >computer science majors with what makes the hardware tick) Do you >suppose they have this class just to irk you? But not for the purpose of assembly programming, rather, those classes are designed to give the student some insite into how the machine works. I'm not sure what your point is here. >Not to mention whether or not AT&T has licensed my message yet. >Assembler sure as hell doesn't hurt a programmer, and remaining >ignorant of other methods or writing applications is never a good >thing. I, myself, have exposed myself to a variety of languages. >None of them have made me into a "good" programmer, but I feel that >all of them have made me a "better" programmer. It works both ways (the first statement). I agree with (the second statement). >Assembler seperates the knowledgable from the ignorant. If that means >the men from the boys, then yes. Anyone who intends to never learn >assembly is just perpetuating his/her own ignorance. That isn't true at all, you can turn the argument around just as easily... i.e. that high level language knowledge separates the knowledgable from the ignorant. Wrong both ways... the real answer is: (1) experience in (2) algorithms you have devised or learned relating to (3) broad area of learning (e.g. broad knowledge base). >Re-inventing the wheel is an important concept in learning anything. I >would say that one of the things that makes a good programmer is >education, and refusing to learn is certainly a sign of a lack of >education. I know programmers who don't want to sulley themselves with >the dirt of programming in assembly language. These are the same >people who have no desire to learn anything about the hardware they use, >and no desire to try new (or old but as yet unlearned) ways of doing >things. I suppose that's true in a general sense, but you are equating knowledge as REQUIRING to know assembly. Considering that assembly is only a very SMALL part of the industry I do not see how you can equivicate it as you have. >I guess that one experience wasn't enough to show you that 8086 & 6809 >assembly is hardly worth considering as assembly. For a real laugh, >try assembly on a PDP-11. Do you *know* PDP-11 assembly? The VAX instruction set was loosly based on the PDP-11 (even has a compatibility mode in 780's) and the 680x0 instruction set was based on the VAX. >>>If not, get a clue. You can abuse any language, including assembler. > >>Abuse? What do you mean? > >Anyone who can write in assembly and who is proficient in C or some >mid to high level language can write clear and accurate assembly. >Abuse of assembly can occur just like abuse of a higher level >language. It can also be damn near as elegant. Uh, no... not true at all. I know people who know a number of languages, including several assembly languages, and their coding is about the worst I've seen. >Exactly my feelings on the matter. Assembly language is worth knowing, >without a doubt. You aren't a REAL programmer until you've learned >it. Assembler is a critical language. If you don't learn assembler, >you're missing out on the only way to do some programs. (Such as OS >programming) Personally, I agree that assembly language is worth knowing, and using. However, your statement insinuating that assembly is required to be a REAL programmer is extremely biased and incorrect, and shows a lack of perspective. > Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD > The above message is not licensed by AT&T, or at least, not yet. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (04/06/91)
In article <cg.8088@ami-cg.UUCP> cg@ami-cg.UUCP (Chris Gray) writes: In article <2220@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >Here's a small list of things that I can come up with that require >knowledge of assembly: writing an OS, writing device drivers, writing >_fast_ programs, writing compilers Actually, there are cases of all of those where you don't need to know assembler. Burroughs are good machines to look at for that - they didn't sell assemblers for their large machines, because you largely didn't need them. That the microcde was part of the process context probably had something to do with this. However, some of the research and retargettable compilers nowadays have automatically produced code generators and optimizers - the programmer need only read the CPU manual and convert the instruction descriptions to the proper form - the software does the rest. Nowadays? We were using Graham-Glanville generators 15 years ago that did that. Even better, you fed it instruction timing information and the code generator tooke a time or size option that gave a weight to time or size (the other got a weight of 1 - x). I must agree, though, that knowing a bit about assembler programming is a useful skill for programmers who will be coming at all close to the machine. It's not clear that scientists doing numerical simulations and graphics need it, however. Yup. It gives you a feel for the machine. <mike -- Love and affection, Mike Meyer Of the corporate kind. mwm@pa.dec.com It's just belly to belly, decwrl!mwm Never eye to eye.
cs450a03@uc780.umd.edu (04/06/91)
Michael Rizzo writes: >Did you start maths with a proof of why 0 + 0 = 0. No because it >involved ideas which were too hard to understand at that age. But >math students see the proof for 0 + 0 = 0 in the first year of their >BSc, even though they've been using the result all their lives. Also >some people can use 0 + 0 = 0 without ever needing to know why. heh. Just for the record, those proofs of "0 + 0 = 0" begin by assuming that "+" is not addition, but something with some of the properties of addition. [or semantically equivalent assumptions] Obligatory nonsense: Real Programmers don't use assembly, they use Machine Language Monitors (with macro support, of course ;-). Followups to comp.lang.war Raul Rockwell
dfrancis@tronsbox.xei.com (Dennis Heffernan) (04/07/91)
In article <7214@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: |In Miranda all you need is three lines: | |qsort :: [*] -> [*] |qsort [] = [] |qsort (a:X) = qsort [b|b<-x; b<=a] ++ [a] ++ qsort [b|b<-x; b>a] | In email to Mr. Schwartz, I said that I was currently studying assembly, but if doing so meant adopting his attitude I'd gladly switch to Fortran. (He politely apologized for coming on too strong.) If learning a high-level language means putting up with gibberish like THAT, I think I'll switch to raw hex instead. dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "Using C will definitely cut your life expectancy by 10 years or more." --Carl Sassenrath, GURU'S GUIDE TO THE COMMODORE AMIGA #1
mr3@ukc.ac.uk (M.Rizzo) (04/08/91)
In article <dillon.6061@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > M. Rizzo, I am sure Mike is carrying on this argument through email... <stuff deleted to satisfy our news policy of more new text than old :-) > > ... unless there's a general agreement to post private > email to the net, it is not in good form to do so. You're right, Matt. Sorry Mike (Schwartz) - I should've asked before posting private mail to the news. Please accept my apologies. Michael Rizzo
limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) (04/08/91)
In article <1523@tronsbox.xei.com> dfrancis@tronsbox.xei.com (Dennis Heffernan) writes: > >In article <7214@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: > >qsort :: [*] -> [*] > >qsort [] = [] > >qsort (a:X) = qsort [b|b<-x; b<=a] ++ [a] ++ qsort [b|b<-x; b>a] > If learning a high-level language means putting up with gibberish like > THAT, I think I'll switch to raw hex instead. Anyone that's taken Discrete Mathematics could easily see that the above code is a quicksort. I don't even know Miranda. I guess it's like people said about Matt Dillion and good education having an effect on the code you write. Now I understand the minority of computing professionals that have suggested that the government set up a way for programmers to get some sort of certification. Programmers wouldn't be required to have a license to work, but certification would be something that employeers could look for when hiring for certain jobs. Certainly military contracts would require programmers to have certain certifications just like solder-jockeys have military certification. [ Let's not debate the certification issue. If you want to, take it to comp.misc and tell me so I can subscribe to that newsgroup. By the way, there are TONS of ACM articles and letters-to-the-editor about the topic for those that are interested. ] Tom -- Tom Limoncelli -- tlimonce@drew.bitnet tlimonce@drew.edu -- 201-408-5389 Three witches making a potion. One says, "A Liza Minnelli record, light beer, poppers, Frye boots; what's this spell for anyway?"
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (04/12/91)
Not about to wade through Mike Rizzo's whole 435 article again at 1200 baud to quote four lines, but the claim was made in an inclusion that "the quicksort programmer would have less need than an assembly games writer to make his program faster". This shows an incredible lack of knowledge of programming as a field of endeavor. Some of the most valuable products, with the most invested man-years, and at the highest prices (and profits) for sale in the business data processing market place are sort packages, and they sell based entirely on speed. This is easy to confirm; just go pick up the latest copy of ComputerWorld, look for the full page sort package ads, and note the prominent position and size of the histograms comparing speed against the competitors' products. Why, you may ask, is speed so important in this field? Because 75% of _all_ cpu cycles in business data processing are spent doing sorts. Shave off 1/15th of the time needed to run the sort, and you've added 1/5th to the time available to do the rest of the job, and made the hardware 1/5th more productive. Write a faster sort and the world will pave your pathway with cold, hard cash. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>