An IDE on top of that always felt restricting to me. Like why limit yourself? But maybe that's a windows/Mac thing.
An IDE on top of that always felt restricting to me. Like why limit yourself? But maybe that's a windows/Mac thing.
This view is exactly the view esposed by Brian W. Kernighan and Rob Pike in The Unix Programming Environment from 1984:
https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
If Unixheads would stop pretending their stone-knives-and-bearskins development tools were equivalent to full-fledged IDEs, development would have advanced much more than it has decades ago.
It continues to amaze me that "it's worth becoming familiar with a wide range of tools and then pick the one that's going to work best for you in any given situation" is a concept so many people have trouble with.
The old unix editors have had rename across project, find references, go to definition/implementation for several years at this point via lsps (the same way vscode gets its functionality).
> What about integrated debugging
Those are usually (slightly ecosystem dependent) wrappers around a terminal debugger.
> What about hot reload?
Correct me if I'm wrong, but these are also wrappers around cli functionality (once again, might be ecosystem dependent). And you're probably just saving yourself the trouble of writing/running a script.
>Those are usually (slightly ecosystem dependent) wrappers around a terminal debugger.
And, in my experience, are vastly more convenient than terminal debuggers alone.
But that's not really a good thing: you only have one system, therefore only one environment.
For example:
How do you use multiple versions of the same library for different project? It's not an easy thing to do if you rely on the system paths for libraries.
It's much better if libraries are just a thing you install to the current project rather than being a system wide thing.