It's not that he brings up Java, it's his attitude that Java is somehow faster than C++ as a language which makes no sense and is fallacious.
JVM has dynamic dead code elimination. If you set your logging level to INFO or ERROR, and you've got plenty of if (logger.isDebugLoggingEnabled) calls in your code, those ifs will be completely elided, as they are guaranteed to be always false until someone turns the debug logging on. C++ can't do that. The only thing you can do is ship two different builds to the customer - one with debug logging and another without. Additionally, the debug-build will have overhead everywhere, while in Java you can selectively enable logging for a few classes and you pay only for that. So you don't pay for what you don't use.
Although I accept that there are situations where using a logging framework might be justified or even necessary, there are also situations where you really don't need something so complicated.
chrisname, I can somewhat agree but I'd still rather use a library! I'd rather use something that someone else constantly updates than spend my own time on it. It's a bit redundant otherwise and I don't think I can do a better job than someone who spends more time into research on properly implementing logging features (albeit they are not complicated, I believe this concept can apply to anything).
If I want detailed logging for say server code or client code for network connections, for example, then I would use a library. Usually, I just check if the thing does what I want and if it doesn't I simply output an error message to a file. I could go either way, but if it is complex I would use a library to save time developing the tools and be able to just focus on the code of my program.
I guess it's a difference of approach then. Personally, in many cases, I would rather reinvent the wheel than have extra dependencies except where using a library removes a lot of work. I like keeping my programs as small as possible, with as little superfluous code and dependencies as possible, so if I think I can do mostly the same thing the library does with less code then that's what I do. Also, I like my code to be highly structured and uniform, and using libraries is an obstacle to that since every library developer has his own coding style, which means I end up writing wrappers for everything anyway. Finally, lots of popular libraries for various things are really horribly designed (mostly C libraries, particularly Gtk: The Oversized Toolkit That Couldn't (have been written in C++ so they could stop doing that horrible fake-OOP thing), FFmpeg: Prepare to Write Boilerplate Edition and libarchive in Everybody Loves Function Pointers).
Conveniently, most Boost libraries fit all of my criteria: small (many of them are just header files), highly structured, use largely the same naming conventions I do, and well-designed. If Jesus had been a programmer, he would have used Boost.
chrisname, I try and keep a balance... efficiency with productivity. Large projects are fine if they're structured well and your build system can handle it (unfortunately, I run into more building issues than is comfortable, I sometimes just resort to a bash script or tup file since I'm never happy with any current build system).
I end up taking longer than usual with my projects. After I get a lot done, feel a surge of OCD, where I try to make my code as neat as possible, using the least code possible, and sometimes I end up breaking what I spent 2 days working on, ending up with me spending 1 day making it work again. It's sad, really.
I know exactly what you mean chris. I hate the way SDL is structured and stuff, so I just take a few hours to write a wrapper (Not always OOP, I hate when people think you MUST use OOP for everything), then a day or two testing and fixing bugs.
(BTW I actually am not diagnosed with OCD)
EDIT: Actually, I think I do have OCD. I do tend to over-analyze things a lot.