[RcouF1uZ4gsC]

I think code completion is missing. Sure you can always try to grep your function call, but seeing the parameters and return type of a function you are calling as you are coding is really nice.

Also a real IDE does much better debugging. Using Visual Studio for debugging your program is much easier than using GDB, which is probably why the more Unix programmers use printf debugging rather than try to fire up GDB.

[quicklime]

Now that language servers (https://microsoft.github.io/language-server-protocol/) are a thing, the code completion in terminal-based editors like vim and emacs can be just as good as what you'd get in an IDE.

[gravypod]

Does anyone have a good solution for orchestrating language servers? With a mildly complex code base (grpc/thirft + python + build system) there's a lot of languages in play. At any small to medium company you're looking at around >5 different languages used. Downloading, configuring, starting, and providing context to (what files can see what other files, what the final build looks like, etc) to all of the language servers you want to use can sometimes be a huge pain. This is something that IntellJ with gradle does very easily.

[flukus]

What works for me is having a script per project/directory a script that set all the configs (as environment variables) and various other functions for that project. If the script exists then it runs when I cd in and other scripts can use the environment variables. So a script like start-language-server would check for the environment variable PYTHONLS and PYTHONLSPORT and start it if it's not running, or it can be started straight from the cd.

Never had to handle multiple languages in one project though, I find vims builtin completion enough for the rest.

[mstwntd_g]

vim has basic completion builtin.. and there's a lot of code complemention plugins..

[glouwbug]

Keep your declarations on a single line:

    int fun(void*);

And

    grep -r fun *.h

Will tell you everything you need

[brachi]

also, you could use ctags.

[socialdemocrat]

You can do that in a lot of editors. Don't need an IDE for that. You got standardized language servers now which are often easy to integrate in a multitude of editors.

But personally I don't like IDE style completions that much. In editors I often prefer completions based on what is in the file I am editing. But I also work a lot in a REPL environment.

I personally think a good REPL is a much better debugging tool than most IDE debuggers.

> Using Visual Studio for debugging your program is much easier than using GDB, which is probably why the more Unix programmers use printf debugging rather than try to fire up GDB.

That does not really have anything to do with IDE vs command line. My experience as a C++ developer for many years on Linux is that debuggers just don't work that well. Many of the issues has to do with the complexities of C++ and how gcc stores debug information.

Most IDE style debuggers on Linux are quite crappy, because they are slow and undependable. Printf is faster, more dependable and gives more flexibility in how you display data you are interested in.

[RcouF1uZ4gsC]

> My experience as a C++ developer for many years on Linux is that debuggers just don't work that well.

That has been my experience on Linux. On Windows, Visual C++ debugger works amazingly well.

[macinjosh]

Not sure why you're being downvoted. IMHO, printf based debugging is more ergonomic and requires less context switching. Instead of using my mouse to work with debugger or remembering a myriad of shortcuts for navigating through it I can just keep typing right in my editor where I already am. For me it fall under the keep it simple stupid category.

[alkonaut]

How do you add more watches (printfs) without recompiling/restarting though (That seems like a basic requirement for calling it ergonomic tbh)

[pvg]

The author addresses some of that directly - the series is really a collection of tutorials on how to get various programmer-ish things done in Unix. The title is a stroke of viral genius.