27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

"I always write them in assembly. Just as you said, it's just natural. I once took a look at some C-code and I simply could not figure it out!" AH HA! So I NOT the only old fart that can't get my head around C!!!! (Snicker!) I have written in Fortran, Cobol, Basic, Visual Basic, and a couple of others I have forgotten but I earned my bread and butter writing Assembler for industrial applications for 10 years. When the industry was moving away from Assembler toward C, I bought C - how hard can this be, right? After enough frustration, I bought "C For Dummies", then I eventually threw away C and went back to Assembly! I always used "fast" "efficient" and words like that to explain my preference for Assembly rather than admit I never met a C that I liked! ;-) Yup, good to know I am not alone. Just as an aside on the understandability of Assembly..... Most of the designers I worked with in years past were male (obviously) and I used to find it difficult to to work on someone else's code (modifications or such) because they tackled the tasks differently. In the early 80's the company hired a female engineer and I was asked to make a change to her software while she was away on vaction. I was astounded to find her code was as logical and systematic as mine - in each section I knew where we were going before we got there and how she had gone about it! Men "think different" and it shows in Assembly language programming. Not that one is "right" and the other isn't - just "different" - VIVA LA DIFFERENCE! Dianne __________________________________

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

They must Dianne, I found it very hard to work out who said what in your email below ... hehe Darren Moore > -----Original Message----- > From: Calamity Jane [mailto:] > Sent: Thursday, 25 November 2004 10:14 > To: MC68HC11Group > Subject: [m68HC11] C v.s. Assembly! > > "I always write them in assembly. Just as you said, > it's just natural. I once took a look at some C-code > and I simply could not figure it out!" > > AH HA! So I NOT the only old fart that can't get my > head around C!!!! (Snicker!) > > I have written in Fortran, Cobol, Basic, Visual Basic, > and a couple of others I have forgotten but I earned > my bread and butter writing Assembler for industrial > applications for 10 years. > > When the industry was moving away from Assembler > toward C, I bought C - how hard can this be, right? > After enough frustration, I bought "C For Dummies", > then I eventually threw away C and went back to > Assembly! > > I always used "fast" "efficient" and words like that > to explain my preference for Assembly rather than > admit I never met a C that I liked! ;-) > > Yup, good to know I am not alone. > > Just as an aside on the understandability of > Assembly..... > > Most of the designers I worked with in years past were > male (obviously) and I used to find it difficult to to > work on someone else's code (modifications or such) > because they tackled the tasks differently. In the > early 80's the company hired a female engineer and I > was asked to make a change to her software while she > was away on vaction. I was astounded to find her code > was as logical and systematic as mine - in each > section I knew where we were going before we got there > and how she had gone about it! > > Men "think different" and it shows in Assembly > language programming. Not that one is "right" and the > other isn't - just "different" - VIVA LA DIFFERENCE! > > Dianne

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Dear Calamity and others, I know from sore experience about fixing / modifying someone else's code can be painful. Most of the problems I encounter is that whoever wrote the original code did not bother to put in any comments. I don't know if this is a gender thing or not. Regards, Charlie

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Melear Charles-rdph40 wrote: >Dear Calamity and others, > >I know from sore experience about fixing / modifying someone else's code can be painful. Most of the problems I encounter is that whoever wrote the original code did not bother to put in any comments. > >I don't know if this is a gender thing or not. > >Regards, > >Charlie You hit the nail on the head, Charlie. If you can't even figure out where it starts or where it ends, you have to waste time figuring it all out. After that, THEN you can start to figure out what is wrong with it. Maybe it isn't a gender thing at all. Maybe, it's a "job security" thing! Just my cheap two cents worth. Jack Donoghue

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Nov 24, 2004, at 5:42 PM, Melear Charles-rdph40 wrote: > I know from sore experience about fixing / modifying someone else's > code can be painful. Most of the problems I encounter is that whoever > wrote the original code did not bother to put in any comments. > > I don't know if this is a gender thing or not. I don't believe it has anything to do with gender. Its rare to find another's code makes any sense. I'm a rare case in that years later my own code still makes pretty good sense to me. Sadly I think most "just believe its not supposed to make sense", not even to themselves, not even when its being written. Another thing I've concluded is that most no longer expect software to work. That its a foregone conclusion one must have full time MCSE's on staff to keep Windows desktops and servers running. C can be a very good tool for quickly producing reliable code. The biggest problem is that most managers have the notion that anybody who can write a line of C can write embedded firmware. There are some C compilers which try to encourage this notion. I've seen plenty of very bad C, and its not just "comments and formatting" which makes it bad. You know you will find trouble when you find "#include <stdio.h>" at the top of a supposedly embedded source file. -- David Kelly N4HHE, ======================================================================== Whom computers would destroy, they must first drive mad.

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

> I don't believe it has anything to do with gender. Its rare to find > another's code makes any sense. I'm a rare case in that years later my > own code still makes pretty good sense to me. Sadly I think most "just > believe its not supposed to make sense", not even to themselves, not > even when its being written. It is a matter of values. If a developer values quality, maintainability and other 'ilities, then programs are well designed, well documented and the code is appropriately annotated. If the developer values a quick and dirty solution, then not even he/she (a.k.a. code jock) will be able to understand it a few days later. And, no matter how well the code works, it is crap. If the code is good, it will likely endure and will live to be modified. If it is bad, it will be tossed because it will always be easier to start all over again than to reverse engineer bad code. Interestingly, programmers (as a group) spend more time refactoring existing programs than writing new programs. > You know you will find trouble when you find "#include <stdio.h>" at > the top of a supposedly embedded source file. If it is required, then the .h should be visibly included in the file it is being used with a comment as to why it is included. If it is not required, it should not be included. All too often, .h files are included "just in case" which increases the size of the "haystack" when looking for bugs. my $0.02, which has dropped in value to $0.01 2001 dollars. Bfn, Bob Furber __________________________________________________________ Connect your micro to the internet the easy way www.microcommander.com Microcontroller with an obscenity of I/O & features ..in a small footprint www.steroidmicros.com __________________________________________________________

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

On Nov 24, 2004, at 6:56 PM, Bob Furber wrote: > >> You know you will find trouble when you find "#include <stdio.h>" at >> the top of a supposedly embedded source file. > > If it is required, then the .h should be visibly included in the file > it is > being used with a comment as to why it is included. If it is not > required, > it should not be included. All too often, .h files are included "just > in > case" which increases the size of the "haystack" when looking for bugs. My point being that stdio.h traditionally defines a lot of things which rarely belong in an embedded application. Typedefs and prototypes for FILE, stdin, stdout, etc. The kind of things which generally do not belong on HC11's and kin. Its a bit different story if one has a 68360 or PowerPC pumping many data channels and/or ethernet. There would be some justification with an embedded web server. -- David Kelly N4HHE, ======================================================================== Whom computers would destroy, they must first drive mad.

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

At 2004-11-25 00:14, Calamity Jane wrote: >"I always write them in assembly. Just as you said, >it's just natural. I once took a look at some C-code >and I simply could not figure it out!" > >AH HA! So I NOT the only old fart that can't get my >head around C!!!! (Snicker!) Congratulations, you are now also at least two languages behind! >I have written in Fortran, Cobol, Basic, Visual Basic, >and a couple of others I have forgotten but I earned >my bread and butter writing Assembler for industrial >applications for 10 years. Shame on the people that hired you then. >When the industry was moving away from Assembler >toward C, I bought C - how hard can this be, right? >After enough frustration, I bought "C For Dummies", >then I eventually threw away C and went back to >Assembly! The dummies series can be very frustrating. I bought the XML for dummies book and it kept repeating itself. When buying books about programming: Most of the O'Reilly books are unbeatable, but they are a commercial enterprice so not all of the books are perfect. As regards books about C, however, there is no excuse for not buying the K&R (Kernighan and Richie) original book (or the ANSI-version). The first part is a very clear introduction to the language and the last part is a very clear definition of the language. It even cleared up all the issues I had whilst writing the C-compiler. It's sooo much better than Wirth's book defining Pascal... >I always used "fast" "efficient" and words like that >to explain my preference for Assembly rather than >admit I never met a C that I liked! ;-) There is only one C and although it's not perfect it's a clear standard that solved a lot of problems with earlier languages. That the market for embedded C compilers is so small and the quality of the compilers and navenant isn't something you should blame C and credit assemblers. Especially since most assemblers also suck. >Yup, good to know I am not alone. That is the problem with women: They rather suffer knowing that others suffer too than do something about their plight. Greetings, Jaap

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

At 2004-11-25 00:42, Melear Charles-rdph40 wrote: >I know from sore experience about fixing / modifying someone else's code can be painful. Indeed. >Most of the problems I encounter is that whoever wrote the original code did not bother to put in any comments. I had to disassemble a lot of code to have a look at it and even that (wasn't properly commented ;-) and) was a waste of time to analyze except what I learned from it about the interface. >I don't know if this is a gender thing or not. She brought it up not we. (I know it's 'us' in English, but I think it's illogical, because you can add: brought it up.) Greetings, Jaap

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

At 2004-11-25 01:56, Bob Furber wrote: >Interestingly, programmers (as a group) spend more time refactoring existing >programs than writing new programs. I also used to do that for years and mainly with my own code and being able to express everything as clearly as possible within a 80*24 character screen was important. >> You know you will find trouble when you find "#include <stdio.h>" at >> the top of a supposedly embedded source file. Of course. I use the Microsoft C-compiler on Xenix (an early x86, Unix implementation later exploited by SCO, but started and 'powered by' Microsoft. MS developed most of it's Windows shit on it... Anyway this C-development environment was very complete and compatible with the same environment on Windows/DOS but much more stable! But I ... >If it is required, then the .h should be visibly included in the file it is >being used with a comment as to why it is included. Of course not. You can't have programmers explain everywhere what they did (in terms of the later beholder). During development things like environments change. And a programmer is a programmer and not a historian documenting his programming. A programmer is busy programming and he is solving a puzzle and when he writes comments he writes them for himself and not for the second echelon of programmers. Real programmers don't program the program in their mind first but program as they go along. That alse means that most of the comment is obsolete once the program is finished. So you want real programmers, artisans of their art to go back to the source code, and connote it like clerks? Greetings, Jaap

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

> And a programmer is a programmer and not a historian > documenting his programming. A programmer is busy > programming and he is solving a puzzle and when he > writes comments he writes them for himself and not > for the second echelon of programmers. Real programmers > don't program the program in their mind first but > program as they go along. That alse means that most > of the comment is obsolete once the program is finished. You sound like a hot blooded "code jock" ;o). Certainly, for prototyping, there is a place for such an attitude: Get the job done quickly and prove the point. The code will be tossed anyway, so why worry about the "ilities"? If the code is going to be part of a product, then, by and large, the "ilities" (maintainability, scaleability, enhanceability..) become imperative. I like to call the overall effort "software development", which is quite different from "programming". In fact, programming plays quite a small part in the overall effort, with Requirements development and Design being far more important. In software product development, a "real" programmer (i.e., a code jock) can actually be a hinderance, no matter how brilian she is. > So you want real programmers, artisans of their art > to go back to the source code, and connote it like > clerks? Sorta. Software development has evolved from the domain of artisans to that of software engineers, technicians, researchers, technical writers (clerks?), testers, etc... Bfn, Bob Furber __________________________________________________________ Connect your micro to the internet the easy way www.microcommander.com Microcontroller with an obscenity of I/O & features ..in a small footprint www.steroidmicros.com __________________________________________________________

(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )