Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!harrier.ukc.ac.uk!mr3 From: mr3@ukc.ac.uk (M.Rizzo) Newsgroups: comp.sys.amiga.programmer Subject: Good programmers and assembly language Message-ID: <7214@harrier.ukc.ac.uk> Date: 3 Apr 91 19:21:52 GMT Organization: Computing Lab, University of Kent at Canterbury, UK. Lines: 370 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@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 :-) * *********************************************************