Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 12/15/2012 04:03 PM, Mark Woodward wrote: > I started programming back in the 1970s. When I learned C, C was a new > language. ANSI C was a big thing and we had to "port" to ANSI C > because various vendors implemented vagueness in the C syntax > differently. Those of us who understood portability between C > compilers fared better. Anyway, when C++ came along, it was a similar > sort of deal. The rough edges around the language were different > across different vendors. Templates especially. Understanding this > always made maintaining the code, over time, easier. > > As C++ developed, those of us who were conservative in our > implementations fared well in the Borland/Microsoft C++ war. In > adopting C++, the general rule was to use the "safe" constructs of the > language and use only those aspects of the language that facilitated > the architecture and leave the rest alone. Even today, aspects of C++ > create immense bloat in code. (Templates) > > Maybe old habits are hard to break, I don't know, but I still consider > the old way a good design philosophy. The whole "[OT] C++ strings" > discussion is a perfect example. A C++ programmer and/or architect > should resist the temptation to be "language lawyers" and design > software that requires understanding the arcana of the language to > understanding the body of the code. It may be clever, but it makes the > code hard to understand and of reduced value in the future. Clear and concise code with good comments works well in C, C++, COBOL, and Fortran. Essentially I consider myself a C programmer although I used to work in COBOL and Fortran, and nearly all the code I work with today is C++, BASH scripts and tcl. Much of my career has been involved with having to maintain some very old code. At Digital, I had lint, lex, yacc, and a bunch of other as well as the Assembler for the Alpha (which I was on a small development team to write). Whenever you get into code maintenance, you get to see why it is important to write relatively clear and concise code. I was also on the team to write an ANSI C compiler for the PDP11 before the standard was adopted. I still have one of the draft standards we used in 1988. My job was to write the entire standard C library in C, not assembler. We also had to fully comply with the draft standard. The math library was the only part I had some difficulty with. -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |