But programming is supposed to be a science and a process. If you prepare a precision algorythm and carefully test it before coding with all manner of valid and absurd inputs, then it shouldn't matter what level of so called skill a programmer has when the coding proceeds.
Oh, you mean a 'good programmer' is one who by lucky accident gets working code without using developing a complete algorythm first? What do you guys do, design microwave ovens for a living?
There's no such thing as a good vs average programmer. There's only those who follow the algorythm and the lucky artists.
What a load of horse shit!
First, without a good programmer on hand, who do you think is going to design the 'precision algorithm' or the test plans? For any given problem there are countless different solutions (most of which, as the aphorism says, are simple, easy and wrong), and figuring out which solutions will be appropriate to the problem domain, and scale well as the problem evolves, is an unavoidably creative process, for which you need creative people (i.e. good programmers).
Second, even when you have an algorithm already in hand, you need to have someone who can write the code in such a way that it can be easily understood, maintained and extended. This is also an unaviodably creative process: for any given algorithm and any given implementation language, there are, again, countless concrete implementations, each with their own advantages and handicaps. If you hire an average programmer, one without imagination or initiative, you can only hope that they will stumble, by pure luck, on the minority of implementations that don't paint you into some unfortunate corner two years down the road (requiring an astronomical investment in re-engineering the program). Hiring creative and independant people (i.e. again good programmers) will greatly increase the liklihood that the resulting programs will be well engineered.
Anyone who doesn't understand these two simple facts is either a nitwit of a PHB or an average programmer. Engineering of any type is hard, unavoidably so, and software engineering is harder than most other disciplines. The only people who think otherwise are either not aquainted with real-world software engineering (ivory tower types) or are simply blowhard dilettantes with no real interest in the problem (often with a silver bullet to sell).
for the x86 assembly, I think you are looking for something more like:
mov numone,ax add numtwo,ax mov ax,numone
although the sources and destinations may need to be reversed. I don't think that x86 supports memory to memory operations directly.
The professor's comment about RISC being impossible to program in assembly simply shows that he has not kept current with modern technology. There was a time, about 10 years ago, when machine code needed to be carefully scheduled in order to get the best performance on RISC architectures. The MIPS line of processors were famous for requiring odd transformations of code in order to avoid stalls due dependancies on branches, arithmetic evaluation and memory accesses. With modern RISC architectures, however, the need to reschedule machine code -- in order to handle branch delay slots for instance -- is greatly reduced and RISC machine code can again be written by mere mortals. (or at least demi-gods)
Slashdot Mirror
What a load of horse shit!
First, without a good programmer on hand, who do you think is going to design the 'precision algorithm' or the test plans? For any given problem there are countless different solutions (most of which, as the aphorism says, are simple, easy and wrong), and figuring out which solutions will be appropriate to the problem domain, and scale well as the problem evolves, is an unavoidably creative process, for which you need creative people (i.e. good programmers).
Second, even when you have an algorithm already in hand, you need to have someone who can write the code in such a way that it can be easily understood, maintained and extended. This is also an unaviodably creative process: for any given algorithm and any given implementation language, there are, again, countless concrete implementations, each with their own advantages and handicaps. If you hire an average programmer, one without imagination or initiative, you can only hope that they will stumble, by pure luck, on the minority of implementations that don't paint you into some unfortunate corner two years down the road (requiring an astronomical investment in re-engineering the program). Hiring creative and independant people (i.e. again good programmers) will greatly increase the liklihood that the resulting programs will be well engineered.
Anyone who doesn't understand these two simple facts is either a nitwit of a PHB or an average programmer. Engineering of any type is hard, unavoidably so, and software engineering is harder than most other disciplines. The only people who think otherwise are either not aquainted with real-world software engineering (ivory tower types) or are simply blowhard dilettantes with no real interest in the problem (often with a silver bullet to sell).
for the x86 assembly, I think you are looking for something more like:
mov numone,ax
add numtwo,ax
mov ax,numone
although the sources and destinations may need to be reversed. I don't think that x86 supports memory to memory operations directly.
The professor's comment about RISC being impossible to program in assembly simply shows that he has not kept current with modern technology. There was a time, about 10 years ago, when machine code needed to be carefully scheduled in order to get the best performance on RISC architectures. The MIPS line of processors were famous for requiring odd transformations of code in order to avoid stalls due dependancies on branches, arithmetic evaluation and memory accesses. With modern RISC architectures, however, the need to reschedule machine code -- in order to handle branch delay slots for instance -- is greatly reduced and RISC machine code can again be written by mere mortals. (or at least demi-gods)
- Jeff Dutky