On 9/3/2018 11:55 AM, Joakim wrote:
> On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote:
>> But if you're ever expecting IDE support to be a top priority of many of the contributors, then you're going to be sorely disappointed. It's the sort of thing that we care about because we care about D being successful, but it's not the sort of thing that we see any value in whatsoever for ourselves
> 
> Why is that? I've never used an IDE much, but I wonder why you don't and what your impressions are of why many other core D users don't either.

If you're going to start a new thread, which is a good idea in this giant thread, just changing the Subject isn't enough. You can't mark is as a "followup".

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.

On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
> On 8/24/2018 6:04 AM, Chris wrote:
>> For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.
>
> Every programmer who says this also demands new (and breaking) features.

I realize I'm responding to this discussion after a long time, but this is the first chance I've had to return to this thread...

What you write is correct. There's nothing wrong with wanting both change and stability, because there are right ways to change the language and wrong ways to change the language.

If you have a stable compiler release for which you know there will be no breaking changes for the next two years, you can distribute your code to someone else and know it will work. It's not unreasonable to say "Your compiler is three years old, you need to upgrade it." You will not receive a phone call from someone that doesn't know anything about D in the middle of your workday inquiring about why the program no longer compiles. Having to deal with the possibility that others might have any of twelve different compiler versions installed just isn't sustainable.

On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright wrote:
>
> Autodecode - I've suffered under that, too. The solution was fairly simple. Append .byCodeUnit to strings that would otherwise autodecode. Annoying, but hardly a showstopper.

import std.array : array;
import std.stdio : writefln;
import std.uni : byCodePoint, byGrapheme;
import std.utf : byCodeUnit;

void main() {

  string first = "á";

  writefln("%d", first.length);  // prints 2

  auto firstCU = "á".byCodeUnit; // type is `ByCodeUnitImpl` (!)

  writefln("%d", firstCU.length);  // prints 2

  auto firstGr = "á".byGrapheme.array;  // type is `Grapheme[]`

  writefln("%d", firstGr.length);  // prints 1

  auto firstCP = "á".byCodePoint.array; // type is `dchar[]`

  writefln("%d", firstCP.length);  // prints 1

  dstring second = "á";

  writefln("%d", second.length);  // prints 1 (That was easy!)

  // DMD64 D Compiler v2.081.2
}

Welcome to my world!

[snip]

On 9/4/2018 5:37 PM, bachmeier wrote:
> Having to deal with the possibility that others might have any of twelve different compiler versions installed just isn't sustainable.

Back in the bad old DOS days, my compiler depended on the Microsoft linker, which was helpfully included on the DOS distribution disks (!)

The problem, however, was Microsoft kept changing the linker, and every linker was different. At one point I had my "linker disk" which was packed with every version of MS-Link I could find.

Now that was unsustainable.

The eventual solution was Bjorn Freeman-Benson wrote a linker (BLINK) which we then used. When it had a bug, we fixed it. When we shipped a compiler, it had a predictable linker with it. It made all the difference in the world.

Hence my penchant for "controlling our destiny" that I've remarked on now and then. It's also why the DMD toolchain is boost licensed - nobody is subject to our whims.

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.

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

> Hang on a second.
>
> assert(preserve == Yes.preserveAttributes);
>
> Something is smelling an awful lot here.
>
> Up to Windows 7 CopyFileW which is used for Windows didn't copy the attributes over[0] but it does now.
>
> This is a bug on our end, which should include a fallback to copying manually the file contents over.
>
> [0] https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-copyfilew

Yeah, keeping exactly the same behavior on every supported platform is never easy.

And when you need to support Windows too, by experience I know it can quickly become a pain in the *ss...

> 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

+1

What must be absolutely standardized is what is *shared* across the members of the team (code presentation, tabs, naming conventions, build process, versioning, test and deployment procedures, etc etc).

But as long as the coding standard is followed, obviously any code editor should be fine if it makes you more productive.

For instance, even for contract work, I use Geany for all my developments.

And a portable IDE like Geany is especially useful when developping *crossplatform* C++ multimedia applications which must be edited and tested both on Windows, MacOS and Linux.

It is the perfect companion to cmake, behaving exactly the same whatever the platform (editing, find and replace, find in files, macros, settings, etc).

And indeed you can still open your project in Visual Studio when you need to use a Windows debugger.

Personally I use Geany even for Unity game development, as Unity allows to define which editor should be used to show the erroneous line of C# code when double clicking onto an error message.

Geany is great for that too, as it opens often much faster than other IDE...

So my point is, as long as all the shared team standard procedures are respected, I fon't see why any company should decide which code editor *must* be used by all its developers...

On Wednesday, 5 September 2018 at 13:11:18 UTC, Jonathan M Davis wrote:

[snip]

>
> 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.

True, which is the reason I was referring to the "the equivalent Vim/Emacs structure" provided (possibly) by plugins in Vim [1] and Emacs [2] to manage projects/solutions.

It anyway appears that Vim/Emacs are often extended by plugins, and this will be the only way to have some project manage features.

[1] https://stackoverflow.com/questions/1119585/vim-is-there-an-easy-way-to-manage-visual-studio-solutions-makefile-projects
[2] https://github.com/bbatsov/projectile

I maintain that it is not practical trying to duplicate this in your editor of choice except if the amount of time you will save (from increased productivity) exceed the time taken to do this. I maintain that for bug fixing/support in a big organization this will hardly ever be the case.

But even if you avoid this step and can build/run/test from the command-line it may not be optimal in certain debugging scenarios. See next point.

>
> 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.
>

Right, but depending on your type of debugging there is some things which just make more sense to do from right inside the debugger. If you hit a data value break-point or such on an attached debugger you can just double-click the line in the stack trace to go to the appropriate line in the IDE editor. No need to switch tasks to Vim/Emacs, do a go-to or whatever to get to the same place. The type of debugging I'm talking about is not your 'single step' variety.

I sometimes wonder if the Vim/Emacs 'affectionados' spend so much time mastering their editors (which by all accounts have a steep learning curve), that they forgot that IDE development did not stagnate after they left!

> 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.

Agreed.

>
> 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.
>

Again, it depends on what you mean by 'editing'. If you are referring to coding where you are developing from scratch, then sure - I agree. You will be doing a lot of coding before building the 1st time. And then the build will fail for the 1st few times with initial bugs. And then (unit/CI) testing will show up some more bugs, which will necessitate more changes/fixes. Repeat and rinse until the project is finally delivered. In this phase the editor of your choice is really nice/handy (if you can handle everything from the command-line).  I suspect this is your (and Nick's) primary use-case. And is maybe the primary use case for the majority of D contributors.

But the whole point of my post was to point out that this is not the only use-case for some of us. And in some of these other use-cases IDEs are actually superior to editors.

For another example IDEs are also in some ways a 'standard' inside big organizations in a way that any editor cannot be - the lowest barrier of entry to get new members up to speed in a team. And for some languages (Java/C#) you give up a lot by not developing inside an IDE. In fact, for Java and C#, the appeal/power of the languages is in many ways directly related to the IDE! Now throw in mixing C# with C++ (or even D) development... I'm sure you get my drift!