On Friday, 25 September 2015 at 13:54:40 UTC, Chris wrote:
> 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

Yes, stability is important for commercial development. I notice some people say that you can just lock yourself to a particular compiler, but this does not work. Not even for C++. Yesterday I had to upgrade to a more recent version of clang just to get a library to work, which used some C++14 features.

Yet, it would be a tragedy for D to freeze on backwards compatibility like C++ has done. Rust and D has the advantage that they can move forward faster than C++. Having lots of commerical development in D right now would just be a drag, IMO.

Though, I think a lighter version of D geared towards embedded and asm.js could be a good commercial option (no gc in release, no exceptions, no classes, no growable slices etc). Basically enter a market where there is less competition (just C and perhaps Rust).

On Friday, 25 September 2015 at 14:21:56 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 25 September 2015 at 13:54:40 UTC, Chris wrote:
>> 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
>
> Yes, stability is important for commercial development. I notice some people say that you can just lock yourself to a particular compiler, but this does not work. Not even for C++. Yesterday I had to upgrade to a more recent version of clang just to get a library to work, which used some C++14 features.
>
> Yet, it would be a tragedy for D to freeze on backwards compatibility like C++ has done. Rust and D has the advantage that they can move forward faster than C++. Having lots of commerical development in D right now would just be a drag, IMO.
>
> Though, I think a lighter version of D geared towards embedded and asm.js could be a good commercial option (no gc in release, no exceptions, no classes, no growable slices etc). Basically enter a market where there is less competition (just C and perhaps Rust).

Look at Node thats stuff changes like every hour yet ppl still use it.  Angular 2 is breaking stuff, React and React-Router is changing for the next release, Rust is still changing.  C++ cant really just up and break backwards compatibility  at this point.

I think some people do like the structure but if you look at something like Node then you can see some don't.  NPM is like the wild west.  Even though I don't use an IDE it is important to have a couple decent options.  Just like its nice to have a few options in anything.  I can goto Python or Java and prolly have a few options for web development, and just about anything.  I think we have a few decent IDE choices but they prolly just need work.  Do ppl really use and IDE with Go/Rust though?

I still think a good way to get more visibility for D is Youtube.  Thats free advertisement and there a numerous features of D and Vibe that would make great video series.  Also maybe latch on to other things that are hot.  People are learning stuff like React, Redux, Flux....  Make the backend API in Vibe or something and make a video series and github page on it.... Im learning redux for work and may try and do this.  Bottomline is its hard to get those "Enterprisy" developers to change their ways from their Java/.NET world. Just focus on making good s*** and ppl will come.

On Friday, 25 September 2015 at 14:21:56 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 25 September 2015 at 13:54:40 UTC, Chris wrote:
>> 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
>
> Yes, stability is important for commercial development. I notice some people say that you can just lock yourself to a particular compiler, but this does not work. Not even for C++. Yesterday I had to upgrade to a more recent version of clang just to get a library to work, which used some C++14 features.
>
> Yet, it would be a tragedy for D to freeze on backwards compatibility like C++ has done. Rust and D has the advantage that they can move forward faster than C++. Having lots of commerical development in D right now would just be a drag, IMO.

The funny thing is that people demand that D be changed, else they won't use it. And at the same time they claim they don't use it, because it changes too fast.

On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis wrote:
> I, for one, was very excited when I found out that you could actually run VS builds from the command line rather than having to open up VS. And at my last job, I redid our build stuff so that we used cmake to generate the build stuff for both Linux and Windows so that we didn't have two build systems to maintain, and with that, the _only_ reason that I ever had to open up VS was to debug on Windows. It was great.
>
> Unfortunately, at my current job, we're entirely Windows, so everything's a huge mess in VS rather than using cmake, and most of the devs are totally Windows devs, so they'd probably freak out at the idea that the .vcproj files are generated, and you don't edit any settings inside of VS. So, there's no way that I'm going to get the beauty of cmake again here. I'm forced to open up VS more - and we're using the muck that is TFS, which pretty much requires opening up VS to manage source control (though the TFS power tools help).

TFS has a CLI client. Why would you automate builds if you can't automate getting fresh sources from source control?

On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:
> Nice to meet you too, Paolo. Browsing through your posts, I saw that you are using "mainly Mono-D" :) Don't tell me that you are coloring the keywords in your code using a marker.

Heh, to install 6GB IDE for a syntax highlighter, which is only 100 LOC, doesn't sound very good.

On Friday, 25 September 2015 at 14:34:31 UTC, Kagamin wrote:
> On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:
>> Nice to meet you too, Paolo. Browsing through your posts, I saw that you are using "mainly Mono-D" :) Don't tell me that you are coloring the keywords in your code using a marker.
>
> Heh, to install 6GB IDE for a syntax highlighter, which is only 100 LOC, doesn't sound very good.

it is s shame that you people don't start thinking about what you need to do so that developers can easily and quickly use D on windows. what are the most common used libraries, interfaces to other software ...
instead you incense yourselves on tools that no company will touch (well maybe - when the decision makers are drunk) and are about to loose a huge part of the developers.

well good luck in the future on commandline and linux.

On Friday, 25 September 2015 at 14:29:33 UTC, Kagamin wrote:
> On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis wrote:
>> I, for one, was very excited when I found out that you could actually run VS builds from the command line rather than having to open up VS. And at my last job, I redid our build stuff so that we used cmake to generate the build stuff for both Linux and Windows so that we didn't have two build systems to maintain, and with that, the _only_ reason that I ever had to open up VS was to debug on Windows. It was great.
>>
>> Unfortunately, at my current job, we're entirely Windows, so everything's a huge mess in VS rather than using cmake, and most of the devs are totally Windows devs, so they'd probably freak out at the idea that the .vcproj files are generated, and you don't edit any settings inside of VS. So, there's no way that I'm going to get the beauty of cmake again here. I'm forced to open up VS more - and we're using the muck that is TFS, which pretty much requires opening up VS to manage source control (though the TFS power tools help).
>
> TFS has a CLI client. Why would you automate builds if you can't automate getting fresh sources from source control?

I don't know what you mean by automating in this context. I'm not automating anything. This is all stuff that I'm doing as I develop, not stuff dealing with nightly builds or anything like that. Do you mean build from the command line? I did that at my previous job where we were using cmake and had made the directory structure very neat, and all of the VS stuff was separate from the actual code, since we didn't build in the source directories, but at my current job, everything was set up with VS by folks who use VS for everything, and the directory structure is a complete mess, making doing stuff from the command line a lot messier than it should be. I have done some TFS stuff from the command line but not a lot, since I'm stuck having the GUI open anyway, and I tend to touch TFS with kid gloves, because it seems to behave badly in general, and I have to be really careful that I don't do something like commit code from multiple branches at the same time or merge stuff badly.

What I really want to do is use git-tfs (and maybe even use that in an attempt to convince folks to switch to git from TFS), but for some reason, it doesn't work correctly with our repos - it doesn't pull in a lot of the files, making it unusable. The sad thing is that when they chose TFS a while back (before I was working there), the lead dev was pushing for Mercurial, but the other folks didn't listen, and he lost (even though he had Mercurial up and running very quickly, and they took over a week to sort out TFS). So, we could have had decent source control, but we're stuck with TFS instead - probably because most of the devs involved are too Windows-centric. And given how messy the TFS branching stuff is (e.g. it doesn't retain history when merging), I bet that using git or mercurial would save our build guy a ton of time, but he just wants to use TFS and thinks that it's great (probably because it's what he's used to, and it's from MS).

- Jonathan M Davis

On Friday, 25 September 2015 at 14:50:13 UTC, jdeath wrote:

>
> it is s shame that you people don't start thinking about what you need to do so that developers can easily and quickly use D on windows. what are the most common used libraries, interfaces to other software ...
> instead you incense yourselves on tools that no company will touch (well maybe - when the decision makers are drunk) and are about to loose a huge part of the developers.
>
> well good luck in the future on commandline and linux.

You're obviously interested in D, else you wouldn't be here. It'd be nice to get some input from you. What do you need, which libraries are needed, what problems did you encounter? Chances are that there are other Windows developers here you could hook up with and create something useful.

On Friday, 25 September 2015 at 14:27:25 UTC, David DeWitt wrote:
> Look at Node thats stuff changes like every hour yet ppl still use it.

I'll never understand why anyone would use node.js. The only explanation is that they are hellbent on using javascript for everything? But I guess it is no worse than Php and Perl... so who am I to judge.

> Angular 2 is breaking stuff,

Angular 1 users complain loudly, but Google do what they want, and they had to change because of the competition from other frameworks.

> changing for the next release, Rust is still changing.

The adoption of Rust is not high AFAICT and library dependencies are not high either, but the Rust devs claim that Rust 1.4 will be "stable and suitable for commercial"? Who knows. I think the current attention is more a sign of people evaluating Rust than actual usage, but I could be wrong. I would wait at least 1 year before adopting it.

> anything.  I think we have a few decent IDE choices but they prolly just need work.  Do ppl really use and IDE with Go/Rust though?

Emacs? I think Dart got some attention because of their rather good Eclipse integration, but it did not lead to a lot of user contribution. I think the Dart IDE primarily attracted people looking to create apps and not infrastructure. Google eventually dropped the Dart IDE (and by that time it had some annoying regressions).

It says a lot that Google does not focus on IDE development for their own langauges, but only focus on the code that can feeds IDEs with semantic information. A good reason is that it is expensive to do well, comes with a never ending maintenance cost, and once you get traction commercial IDEs will blow you out of the water anyway... So, it's an all-for-nothing investment.

Unless the language is the IDE (e.g. graphical diagrams, REPL etc).

On Friday, 25 September 2015 at 14:50:13 UTC, jdeath wrote:
> On Friday, 25 September 2015 at 14:34:31 UTC, Kagamin wrote:
>> On Wednesday, 23 September 2015 at 20:41:38 UTC, rumbu wrote:
>>> Nice to meet you too, Paolo. Browsing through your posts, I saw that you are using "mainly Mono-D" :) Don't tell me that you are coloring the keywords in your code using a marker.
>>
>> Heh, to install 6GB IDE for a syntax highlighter, which is only 100 LOC, doesn't sound very good.
>
> it is s shame that you people don't start thinking about what you need to do so that developers can easily and quickly use D on windows. what are the most common used libraries, interfaces to other software ...
> instead you incense yourselves on tools that no company will touch (well maybe - when the decision makers are drunk) and are about to loose a huge part of the developers.
>
> well good luck in the future on commandline and linux.

For the record: microsoft C++ compiler tools all have command line interface: the compiler (cl.exe), linker, librarian. I guess, C# compiler exists as a command line tools and as a library (which is not even an executable program). You think, these microsoft tools are not used by companies?