D IDE

[ShadoLight]

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.

For example, all devs in my team, besides participating in 1 or 2 
projects's _development_ at any one time, you also have to do 
support: most of this entails fixing some reported issue in 
applications in production that you (often) did not write or even 
contribute to (we have a lot of legacy projects still in 
production - a few go as far back as VC++ 6 solutions!). Lets say 
in a legacy VS2008 C++ solution (1xEXE project with many (often 
10+) DLL projects). Often with these kind of projects the 
EXE/DLL/LIB output is directed to a specific folder (with the 
necessary INI/CFG files, test files, etc are all present) as well 
as scripts to update registry, etc - i.e. to set up everything to 
allow testing.

It is quite quick (and VS is normally very reliable with this) to 
import the legacy VS2008 solution into VS2015 - rebuild the whole 
thing, set some breakpoints and start debugging (and I echo 
Manu's sentiments here - VS has the best integrated debugger in 
the business bar none!). Find the bug. Fix the bug. Run unit/CI 
tests. (All from within VS). Update release-note. Release new 
updated version to Deployment. Check fixed sources into Version 
control. Move on to next bug or back to normal dev...

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.

Whether you believe your Vim/Emacs can be tuned with the 
necessary plugins to achieve the same result is actually 
irrelevant here - the question is can you fix each bug as quickly 
as I can by just staying in the original VS ecosystem.

It is also not a question if your employer/organization allows 
you to code in your editor of choice (we are allowed to do this 
in fact - I frequently use (and love!) Notepad++, and I even have 
VisualD installed at work to toy with D over lunch). The real 
question is if your organization has/needs a standard for project 
solutions under source control. So in our case, irrespective of 
what you use to develop the project, under source control it has 
to be a VS solution - because that is the standard dev tool in 
the team.

It is simply not viable to imagine that everyone can check out 
and convert each project solution (be it VS/eclipse/whatever) 
into their own favorite editor equivalent (mostly through a host 
of different plugins, with no standard way in sight!). And then 
having to update the (lets imagine VS) solution under source 
control with the Vim equivalent solution (for future Vim users), 
just for the next guy to add the Sublime way.

As much as I too would have liked unfettered freedom to do things 
"my way", I can fully appreciate why there needs to be a 
"standard way" (at least in serious engineering organizations 
where multiple developers can and do work on the same code bases).

Note that I do not think my organization "sucks" because of this 
requirement and that this necessitates finding another job "if 
you have an ounce of dev self respect" left! (I know, I 
exaggerate a bit here, but you get the drift!). I think you 
should consider yourself quite privileged if you can dictate the 
choice of all the tools you use - this is obviously easier for 
new projects or if you work alone on a project or other 
developers will not need to access/change/fix your code base.

Also note that this is not much different to why, even for D, 
there is still an insistence to follow D's coding standards for 
contributors. Both are intended to simply make it easier for 
multiple devs/contributors to code/fix/contribute. It is the same 
principle.