D IDE

[Jonathan M Davis]

On Wednesday, September 5, 2018 6:35:59 AM MDT ShadoLight via Digitalmars-d 
wrote:
> On Tuesday, 4 September 2018 at 22:38:08 UTC, Nick Sabalausky
>
> (Abscissa) wrote:
> > On 09/04/2018 04:00 PM, Jonathan M Davis wrote:
> >> On Tuesday, September 4, 2018 5:56:54 AM MDT ShadoLight via
> >> Digitalmars-d
> >>
> >> wrote:
> >>> We work full-time for employers which, in my case, employs
> >>> thousands of engineers - and as a result engineering
> >>> principles
> >>> are applied to everything - including tools. So all SW dev
> >>> teams
> >>> here use standardized tooling/processes/coding standards/etc.
> >>> -
> >>> you simply do not have a choice to use your own editor of
> >>> choice.
> >>
> >> Honestly, I don't understand why it would make any sense to
> >> require that all
> >> of the programmers use a particular code editor. Standardizing
> >> the build
> >> tools makes perfect sense (in fact, it would be crazy not to),
> >> and I've
> >> certainly worked at places that have required that a specific
> >> tool like
> >> visual studio or eclipse be used, because it's used for
> >> building, but
> >> they've never then disallowed using a tool like vim or emacs
> >> for code
> >> editing. And if an employer did, I'd almost certainly be
> >> looking for a new
> >> job (though finding a job that sucks less than your current
> >> one is
> >> frequently far from easy).
> >
> > Yes, exactly. Out of all the actual employment-based jobs I've
> > had writing code, not a single one would've cared what editor I
> > was using, as long as I was getting my work done and not
> > causing problems.
>
> I in fact share your (and Jonathan's) view on this i.t.o.
> editing. But it is not as simple as you make it sounds - the fly
> in the ointment is often debugging, not coding.

[snip]

> Are you really telling me you are going to port each of these VS
> Solutions with all the project details into the equivalent
> Vim/Emacs structure just for each and every of the projects you
> have to fix? Every time? The actual coding part (fixing the bug)
> actually most of the time takes much less time than the rest of
> this process.

Except that you don't have projects or solutions with something like vim or
emacs. There is no structure specific to them. You can set them up to do the
build from inside them, and with emacs, you can run gdb inside it if you're
on an appropriate platform, but you're not going to have a "vim" project or
an "emacs" project. That whole concept is an IDE thing. They edit files, and
they can do that perfectly fine regardless of what's being used to run the
build or whatever other tools are necessary for the development process.

If I'm in a situation like you describe, then I usually set it up so that I
can just run the build and tests from the command line and not even bother
opening up Visual Studio. VS projects actually have a way to do that. You
don't actually have to open up VS to do any building. And if I really need
to open up VS to run the debugger, then I'll do that, but I won't use VS for
anything that I don't have to use it for. And in my experience, the debugger
is pretty much the only thing that would typically require actually opening
up VS.

There is no reason to muck with the build process or source control stuff in
order to use vim or emacs. That stuff can pretty much always be done from
the command-line using all of the standard tools that everyone else is
using. Just because most developers would use the IDE to run the build
doesn't mean that it's actually required for it. If it were, then stuff like
automated builds wouldn't be possible.

Regardless, I use vim for editing code. And if I'm actually forced to have
an IDE like VS or Eclipse open because of some tool that has to be run from
inside for some reason (which aside from the debugger is rarely the case),
then I'll have the IDE open for whatever it has to be open for. But I don't
use the IDE for editing code, because that would be a horribly inefficient
way to do go about it.

- Jonathan M Davis