Fair enough, you raise valid points.lucasart wrote: ↑Sat Nov 03, 2018 2:02 am I used to like IDEs, and goet fed up. Was using Codelite, and Code::Blocks. I guess these IDEs are good for doing GUI programming, although Qt Creator is probably a better choice for that.
But for chess programming, I just use a terminal. Plain and simple. Text Editor + Clang/GCC. I'm not going to say which text editor, because that can start a flamewar.
I also gave up on using debuggers. That has forced me to be more careful in the way I write and test code. Basically, I want to write code that debugs itself. And otherwise, I use good old-fashion printf() debugger.
The thing about chess programming is that is much more about quality than quantity. It's not about IDE features that save some keystrokes with auto-completion, or building some (crappy) Object Oriented boiler plate for you (like click a few buttons to build class hierarchies). It's about writing and maintaining in a holistic manner an extremely dense and precise code-base. For every patch, the time spent typing code is less than 0.1%. The rest is thinking and testing. So even something basic like nano is just fine.
I always start a new project in IDEs as empty, I really don't like the crap it generates for me.
Another option is to use cmake or premake, which generate the projects for you for the specific platform/IDE you want.
As for printf debugging, I use logging sometimes when something goes wrong (not in a chess project), but I prefer to use debuggers,
because I don't have to insert printfs everywhere and then delete them (ok, you can do git reset, but still).
Actually debugging is the #1 reason why I use IDEs, I can inspect the contents of variables when I get a crash, this is invaluable and difficult
to do with printfs. Most IDEs also support conditional breakpoints, the reason I like debugging is that it's non-invasive and I can to also inspect
callstacks of other threads, I don't really see a replacement for debuggers in multi-threaded situations.
We have awesome tools today, compilers can do instrumentation (address sanitizers, ...), we have runtime tools like valgrind or dr. memory and
those will catch the most obvious bugs for us, like unaddressable accesses, dangling pointers, uninitialized access and so on, so using a minimalistic setup + terminal is perfectly viable for smaller projects.
