Two hour drive, ~$300. It's a wee bit steep, but I may have to invest in the trip. I'll have to get more info on the talks and tutorials to decide if it is worth it.
Once again, str* as a specific example is in C. But the general principle remains as I have stated it. And in my review, I said only that the world would have been better with compare_string, not strcmp, which is true, in general, not accounting for specific issues such as the linker's limit on characters.
I beg to differ. I think if you take a major application, such as the GIMP (which I've never read the source code), you will find it to be complex.
There's the OS (a complex beast in itself). X above it. Toolkits: gdk, GTK+, etc. Probably some GIMP utility modules. Modules for the graphics. Modules for the UI. Modules for the plugins.
All together, it is complex. Probably it is understandable because it is well designed, by two people. You are correct though that when you are working on a larger project with several teams of 8-10 programmers each, where the architecture has been poorly documented and subverted in cases, that complexity becomes overwhelmingly obvious.
In summary, strcmp is a simple function. It needn't be complex, and shouldn't be. But many software systems in general are quite complex.
I don't see how hard physical constraints would invalidate an otherwise good general guideline. That is, of course there will be special exceptions to the rule and perhaps this is one.
Also, I realize that strcmp is more of a global than a local name. I didn't intend for it to be an example strengthing that specific point I made, only an example of the more general point of naming.
Just today I was helping a colleague at my former employment, where he had gone through my prototype code (excusably imperfect) and changed some (local) variable names to be better named: clearer, longer, more expressive. I have to admit the code was more understandable to myself, who wrote it. That's to say nothing of those who will have to finish implementing it.
I'm curious, how does Pike advocate dealing with the complexity of modern software without layers of abstraction, design patterns, etc.? I may be misinterpreting, can you elaborate on his views?
I wouldn't be so quick to absolve older, more experienced programmers. Myself and my younger colleagues have fixed too many of their bugs and design flaws to have that much faith in them, even if they are otherwise quite capable and smart.
Well, YMMV. I don't obey everything in WSC and CC but still found them to be good sources of information.
I actually went out and bought the other K&R and K&P books after dwelling on them. I don't need them to program (I programmed UNIX professionally for 2 years, though likely not at a "hacker" level) but felt they were gospel.
After writing this review and reflecting on the quality of the book, I went to Chapters and purchased The UNIX Programming Environment, The C Programming Language 2nd ed., and The Awk Programming Language.
I record titles and authors in my Palm Pilot, so I can keep track of what's in stock in Chapters and what the online reviews say. They should have net access in the store.
Well, I (personally) review them as I read them. Sometimes I read recent books, and sometimes I read slightly older books. It's not my full-time job (I am a professional programmer) so you get what I read.:-)
I must agree. Part of the reason I get books like these is so I can share them with others. I didn't mention that in my review, but I photocopied a select section or two for junior developers I was working with. In general I try to convince them to purchase and read the entire book. It only helps me later.:-)
You are correct. For builtin types, which pretty much means all C types, pre and post increment are the same. Although, I have heard it argued that post increment still requires a temporary somewhere, and so still is slightly slower.
But for user defined types, there is a performance hit. Therefore, in the interest of standardizing on one, I prefer that. Also, I find it more semantically appropriate in most cases.
Finally, I believe STL iterators promise the availability of preincrement but not necessarily postincrement. Therefore, consistency with STL iteration would also dictate preincrement.
It is published by Microsoft Press, but not written by Microsoft. McConnell is not an employee. Probably Microsoft doesn't follow his advice wholly.
But it is an excellent book. It covers more than Writing Solid Code. It backs up its statements with references to studies and further reading. It is long enough to cover the topic of software construction rather fully.
I've read each of Writing Solid Code, Code Complete, and The Practice of Programming and each is worth reading.
A boolean that was a byte would be smaller than a short int which was two bytes.
The oft-overlooked point is that in structures and classes, the compiler may pad and align members to that it takes 2/4/8 bytes anyways, defeating your efforts.:-)
Well, I am a professional software developer, a rather good one, and I benefited from reading that book. Even after reading Code Complete and Writing Solid Code and other such books. I still benefited somewhat. Imagine if I hadn't read those other books!
I've been playing with the search applet a little further. I found its help page.:-)
I see now that it does search for more than one term, but for some unknown reason it may only highlight one in the search results. That was why I was confused and thought it only searched for one term, an especially easy mistake to make if the other term is elsewhere in the paragraph.
It also takes wildcards, although not regular expressions. I'm not as convinced now that regular expressions are really necessary for the search applet to be useful. However, it would be nice to have AND, OR, NOT, etc.
In summary, I'm happier with the search applet now and glad that I didn't dock a point off the CD because of my perceived shortcomings with it.
Slashdot Mirror
Two hour drive, ~$300. It's a wee bit steep, but I may have to invest in the trip. I'll have to get more info on the talks and tutorials to decide if it is worth it.
Is it really that different in Canada? The mania seems more subdued but the same dynamics are at work.
I didn't care for school as well. I did great, and turned out okay, but I really wish I could do it all over again, with different choices.
I read it the summer before I began my computer science studies. It was as good as I'd heard. I can't even remember where I'd heard of it from.
I have Metamagical Themas and Fluid Concepts, but haven't tackled them yet. Perhaps it's time for a re-read of GEB, then on to those...
"Upon receipt of this actual letter, you must immediately remove all DILBERT uses from the Internet."
Are they expected to write an Internet WORM to do that?
Once again, str* as a specific example is in C. But the general principle remains as I have stated it. And in my review, I said only that the world would have been better with compare_string, not strcmp, which is true, in general, not accounting for specific issues such as the linker's limit on characters.
I beg to differ. I think if you take a major application, such as the GIMP (which I've never read the source code), you will find it to be complex.
There's the OS (a complex beast in itself). X above it. Toolkits: gdk, GTK+, etc. Probably some GIMP utility modules. Modules for the graphics. Modules for the UI. Modules for the plugins.
All together, it is complex. Probably it is understandable because it is well designed, by two people. You are correct though that when you are working on a larger project with several teams of 8-10 programmers each, where the architecture has been poorly documented and subverted in cases, that complexity becomes overwhelmingly obvious.
In summary, strcmp is a simple function. It needn't be complex, and shouldn't be. But many software systems in general are quite complex.
I understand that reasoning.
But cos is universal in math as cosine. If I went to a non-computer-type and wrote "strcmp" they would be puzzled.
In C++/Java we use namespaces/packages to partition the global namespace, and not naming conventions.
I've long suspected that I control the computer book industry, either through my purchases or through my reviews. :-)
Say hi to K. for me.
I don't see how hard physical constraints would invalidate an otherwise good general guideline. That is, of course there will be special exceptions to the rule and perhaps this is one.
Also, I realize that strcmp is more of a global than a local name. I didn't intend for it to be an example strengthing that specific point I made, only an example of the more general point of naming.
Just today I was helping a colleague at my former employment, where he had gone through my prototype code (excusably imperfect) and changed some (local) variable names to be better named: clearer, longer, more expressive. I have to admit the code was more understandable to myself, who wrote it. That's to say nothing of those who will have to finish implementing it.
I'm curious, how does Pike advocate dealing with the complexity of modern software without layers of abstraction, design patterns, etc.? I may be misinterpreting, can you elaborate on his views?
I wouldn't be so quick to absolve older, more experienced programmers. Myself and my younger colleagues have fixed too many of their bugs and design flaws to have that much faith in them, even if they are otherwise quite capable and smart.
Functional programming?
Maybe I should read and review Coplien's Multi-Paradigm Design for C++ next. I understand it is a good book, but have yet to read my copy.
Well, YMMV. I don't obey everything in WSC and CC but still found them to be good sources of information.
I actually went out and bought the other K&R and K&P books after dwelling on them. I don't need them to program (I programmed UNIX professionally for 2 years, though likely not at a "hacker" level) but felt they were gospel.
After writing this review and reflecting on the quality of the book, I went to Chapters and purchased The UNIX Programming Environment, The C Programming Language 2nd ed., and The Awk Programming Language.
I record titles and authors in my Palm Pilot, so I can keep track of what's in stock in Chapters and what the online reviews say. They should have net access in the store.
You are correct, Scott Meyers actually advises on knowing the differences and issues involved. They apply both to writing and to using the operators.
I see several compelling reasons to always prefer pre:
1) it isn't slower
2) it can be faster
3) STL iterators work that way
4) consistency
5) can be argued that it is more semantically correct
In the end, those were just my personal nitpickings and are to be taken with a grain of salt. Others will have different nitpickings.
Actually the K&R style bracing really annoys me and I can't believe I didn't mention that as well...
Yes I meant humility. The internal dictionary must have failed me.
Well, I (personally) review them as I read them. Sometimes I read recent books, and sometimes I read slightly older books. It's not my full-time job (I am a professional programmer) so you get what I read. :-)
I must agree. Part of the reason I get books like these is so I can share them with others. I didn't mention that in my review, but I photocopied a select section or two for junior developers I was working with. In general I try to convince them to purchase and read the entire book. It only helps me later. :-)
You are correct. For builtin types, which pretty much means all C types, pre and post increment are the same. Although, I have heard it argued that post increment still requires a temporary somewhere, and so still is slightly slower.
But for user defined types, there is a performance hit. Therefore, in the interest of standardizing on one, I prefer that. Also, I find it more semantically appropriate in most cases.
Finally, I believe STL iterators promise the availability of preincrement but not necessarily postincrement. Therefore, consistency with STL iteration would also dictate preincrement.
It is published by Microsoft Press, but not written by Microsoft. McConnell is not an employee. Probably Microsoft doesn't follow his advice wholly.
But it is an excellent book. It covers more than Writing Solid Code. It backs up its statements with references to studies and further reading. It is long enough to cover the topic of software construction rather fully.
I've read each of Writing Solid Code, Code Complete, and The Practice of Programming and each is worth reading.
A boolean that was a byte would be smaller than a short int which was two bytes.
:-)
The oft-overlooked point is that in structures and classes, the compiler may pad and align members to that it takes 2/4/8 bytes anyways, defeating your efforts.
Well, I am a professional software developer, a rather good one, and I benefited from reading that book. Even after reading Code Complete and Writing Solid Code and other such books. I still benefited somewhat. Imagine if I hadn't read those other books!
Exactly, use the idiom to suit the language.
K&P use int in Java code where boolean should be used. That was my beef.
I used WDB 0.75 on HP-UX a year ago. It is their new strategic source level debugger.
I've been playing with the search applet a little further. I found its help page. :-)
I see now that it does search for more than one term, but for some unknown reason it may only highlight one in the search results. That was why I was confused and thought it only searched for one term, an especially easy mistake to make if the other term is elsewhere in the paragraph.
It also takes wildcards, although not regular expressions. I'm not as convinced now that regular expressions are really necessary for the search applet to be useful. However, it would be nice to have AND, OR, NOT, etc.
In summary, I'm happier with the search applet now and glad that I didn't dock a point off the CD because of my perceived shortcomings with it.