CompuServe Messages

>>..unless, of course, there's a bug in the assembler. :-)<< > >True of course, and I have met one or two. The big advantage, even then, is >that assembler errors are generally very much easier to track down and >circumvent than compiler errors. I see your use of generally, and do agree the translation to machine code is simpler, and I hate to keep saying this, but that simply does not follow. Even if we quality better exactly what "an assembler" means, I still think we cannot necessarily get at this except for a case by case review of the error. If it is a doozie, then it is a doozie. Some are obvious, some are not. Assembler might be too low and involved to see some things. And so on. A bug is a bug and it's the skill of the person to get at it. Some bugs are easier, ditto for the predicaments. I won't deny this. But that alone doesn't seem to suffice to me. Further, I think you are leaving out significant things, like: macro assemblers, assemblers that actually have HLL constructs, etc. >In my experience at least. "One is often best at what one does best." This implies habits, savvy, the whole pot. IOW, perhaps you are an assembler expert and have never quite put your mindset wholeheartedly into other approaches et al. For sure then, you might find program, compiler, OS, etc bugs in assembler faster and so on that in a HLL language. Just like I will probably do so in C and C++ than in Ada. >In theory at least, writing portable code is good programming practice. I don't see it as a good (or bad) issue. I see it as a decision made on an educated slate. >However this also depends on what levels of quality you >want to achieve. If you write portable code you'll never get the most of the >two different platforms. A chain is never stronger than its weakest link. Your point is not invalid per se, but don't push it either. Assembler definitely does not solve this problem. In fact, hardly at all. Indeed, it is possible to obtain quality code that is very portable. Where the links become not perfect is more say with different GUI's, and generic frameworks atop of them, or where perhaps sizeof int might be important, etc. Many can be coded, or arranged, for. >I had an extremely bad >experience years ago. I decided to write an accounting package that worked on >the Amiga, PC, Atari and Mac. It never really worked. Different bugs in all the >compilers made the project impossible. I'm beginning to wonder if you've really ever allowed yourself the proper exposure and getting used to to HLLs. I know some people who always seems to purchase a lemon car, no matter how good the model seems to currently be rated. Perhaps, Murphy was not on your side with this experience and it has left an (improper and hence unfortunate) sour taste in your mouth? >An example: the program for the client database needed 2Megs of internal >memory. Now, in assembler, it needs about 100K and it does more than the >old one. That's an order of magnitude of 20. Unless you were running some sort of debugging interpreter for the language in question, I cannot accept that the language alone was the reason for this. >I am not against an easy high level language. But what is 'easy'? >I consider it to be my deontology to feel responsible for >every bug in my programs. Therefore I feel compelled to do everything in >assembler. I don't understand you technical decision, but I find this noble, and wish everybody felt this same way.