September 25, 2015
On 23/09/2015 22:02, Ola Fosheim Grøstad wrote:
>> IDE is not just a nice interface to write code. It's a way to organize
>> files, AST based file browsing, github integration, and - the most
>> important aspect for me - is the *integrated debugging support*. I'll
>> never use dmd from command line and the lack of IDE support would be
>> definitely a stopper for me.
>
> While it is easy to agree with you, I don't think a lack of IDE or even
> libraries is something one should expect to be addressed by the language
> developer. Those are issues one can find solutions to if D is suitable
> and different people have different taste. Go and Rust have been in the
> same boat. This is not a show stopper...

Dunno if "expect" is the right word, but a language team that puts IDE support as part of its development effort, will have a big competitive advantage.

D is not on the same boat as Rust here. The Rust team is investing much more in toolchain support (beyond the compiler and basic tools). For example, they contracted an external developer to help them with debugger issues (https://michaelwoerister.github.io/2014/02/28/mozilla-contract.html). And more than that, they are also now effecting plans to improve their tools (or create new ones) to support IDE functionality ( https://github.com/nrc/rfcs/blob/2410d2ce1682813ea79debbf13a99868e6a6bd8a/text/0000-ide.md )


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
September 25, 2015
On Friday, 25 September 2015 at 10:57:23 UTC, rumbu wrote:
> On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:
>> On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:
>>
>>> And I don't use dub, last time I checked, it's messing with my AppData folder.
>>
>> "I don't use this program, it's storing internally used data in the folder specifically designated for programs to store internally used data in" whut?
>
> The AppData\Roaming folder is synchronized automatically on our domain controller (this is normal behaviour). Since dub is storing all dependencies in this folder and each user profile storage is limited, I'd prefer to have control over this space. More than that comparing thousands of source code files at each login/logout it's not a nice thing. When I login to another computer, all dub data is replicated on this computer.

Fair enough, I guess this wasn't considered when dub was designed. Have you considered making a github issue for this (https://github.com/D-Programming-Language/dub)? It would be really great for people to be able to choose their own cache directory

> I hardly consider source code files as "internal used data".

Meh, don't see any important distinction.
September 25, 2015
On Friday, 25 September 2015 at 11:13:38 UTC, Timon Gehr wrote:
> On 09/25/2015 12:45 PM, rumbu wrote:
>> ... Me, I don't have *any* reason to go back in time
>> 20 years ago,
>
> I'd advise to stop making those ridiculous and disrespectful statements. It's slightly annoying and does not add anything to your point.
>

Is that more ridiculous or disrespectful than following statements?

>> "I don't use this program, it's storing internally used data in the
>> folder specifically designated for programs to store internally used
>> data in" whut?

or

>> Yeah I hate such programs too... even more than the ones that create temporary files in >> the system temporary folder !!

I didn't start the gratuitous sarcasm. Even that's only truth in my words, there are more than 20 years since DOS era. And since Borland reinvented the IDE in the DOS world.

September 25, 2015
On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:
> I don't buy this, command line is something obsolete compared to any gui/web interface, at least in Windows world.
>

I don't get this, Windows shops have programmers and the command-line is used as much as everywhere.
September 25, 2015
On Friday, 25 September 2015 at 11:33:40 UTC, John Colvin wrote:
> Fair enough, I guess this wasn't considered when dub was designed. Have you considered making a github issue for this (https://github.com/D-Programming-Language/dub)? It would be really great for people to be able to choose their own cache directory

Already done 1,5 years ago: https://github.com/D-Programming-Language/dub/issues/229


September 25, 2015
On Friday, 25 September 2015 at 05:55:08 UTC, jdeath wrote:
>
> you guys are nuts.

Of course we are! Else we wouldn't embrace something that the mainstream shies away from and that doesn't make us rich. But can you rule it out that in 15 years the guys in your company will marvel at D saying "Fair f**ks to them guys, they kept on pushing it and now we have something really nice to work with"?

> instead of thinking about this shit, you should think about how to make D usable for windows programmers.

You're welcome to write plugins for D. It's come up on this forum so many times that I don't care to remember, but the answer still is: You want it - do it yourself. D is not a restaurant like Java or C# where you have a set menu. D is the kitchen, if you want to eat, open the fridge, get the ingredients and cook something.

> don't think about linux crutsches. in my company people are not even willing to think about D, since it has stone age tools, few usable libraries and is changing at a rate that is incredible.
> now c# will be compiled to machine code - people you lost.

And would they really care, if D had all the nice tools? Or would they say that in VS there's a yellow button to compile and run C#, but for D the button is green - deal breaker.

As so often we're mixing the language with _tools_ for the language here.
September 25, 2015
On Friday, 25 September 2015 at 11:50:43 UTC, rumbu wrote:
> On Friday, 25 September 2015 at 11:33:40 UTC, John Colvin wrote:
>> Fair enough, I guess this wasn't considered when dub was designed. Have you considered making a github issue for this (https://github.com/D-Programming-Language/dub)? It would be really great for people to be able to choose their own cache directory
>
> Already done 1,5 years ago: https://github.com/D-Programming-Language/dub/issues/229

I posted a link to these few messages, hopefully we'll see some movement on it. Do you have a github account to participate on the discussion there? If your circumstances are as common as you say they are, it would useful to have your experience on board.
September 25, 2015
On Friday, 25 September 2015 at 11:24:04 UTC, Bruno Medeiros wrote:
> Dunno if "expect" is the right word, but a language team that puts IDE support as part of its development effort, will have a big competitive advantage.

Indeed, when you are production ready having a top notch IDE becomes a big competitive advantage! I don't know if an IDE attracts people who work on compilers/debuggers though...

> and basic tools). For example, they contracted an external developer to help them with debugger issues

Sure, excellent debugging support (lldb/gdb) is important.

September 25, 2015
On Friday, 25 September 2015 at 11:24:04 UTC, Bruno Medeiros wrote:
> On 23/09/2015 22:02, Ola Fosheim Grøstad wrote:
>>> IDE is not just a nice interface to write code. It's a way to organize
>>> files, AST based file browsing, github integration, and - the most
>>> important aspect for me - is the *integrated debugging support*. I'll
>>> never use dmd from command line and the lack of IDE support would be
>>> definitely a stopper for me.
>>
>> While it is easy to agree with you, I don't think a lack of IDE or even
>> libraries is something one should expect to be addressed by the language
>> developer. Those are issues one can find solutions to if D is suitable
>> and different people have different taste. Go and Rust have been in the
>> same boat. This is not a show stopper...
>
> Dunno if "expect" is the right word, but a language team that puts IDE support as part of its development effort, will have a big competitive advantage.
>
> D is not on the same boat as Rust here. The Rust team is investing much more in toolchain support (beyond the compiler and basic tools). For example, they contracted an external developer to help them with debugger issues (https://michaelwoerister.github.io/2014/02/28/mozilla-contract.html). And more than that, they are also now effecting plans to improve their tools (or create new ones) to support IDE functionality ( https://github.com/nrc/rfcs/blob/2410d2ce1682813ea79debbf13a99868e6a6bd8a/text/0000-ide.md )

Out of curiosity, how much money  would be needed to do something similar for D ?  Not that I can help for now, but it's good to understand the magnitude of things.
September 25, 2015
On Friday, 25 September 2015 at 13:13:29 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 25 September 2015 at 11:24:04 UTC, Bruno Medeiros wrote:
>> Dunno if "expect" is the right word, but a language team that puts IDE support as part of its development effort, will have a big competitive advantage.
>
> Indeed, when you are production ready having a top notch IDE becomes a big competitive advantage! I don't know if an IDE attracts people who work on compilers/debuggers though...
>
>> and basic tools). For example, they contracted an external developer to help them with debugger issues
>
> Sure, excellent debugging support (lldb/gdb) is important.

Having followed this forum for 2 or 3 years now, I doubt whether an IDE would attract people at this stage. If we had a full-fledged IDE, there would be other concerns (or excuses). D scares people away. It's too raw, too bare bones, everything is still moving like hot lava, and maybe people are intimidated by it, because they feel they might be considered bad programmers, if they don't know the ins and outs of it.

Yesterday someone said too me "You must know D inside out by now!" I replied "I know it well enough to know that I don't know it well enough." There's no end to D in terms of knowledge, in terms of learning about programming, and this scares people away. They prefer a set menu, they want rules and strict guidelines. They want to feel comfortable and secure in what they're doing. Java, C# and Go cater for this. D doesn't, and that's why it has no traction. D openly shows what's going on under the hood, not just a nice facade. But nobody really wants to see that. The frequent demands for an IDE are a symptom of this.