On 2015-09-26 11:50, Manu via Digitalmars-d wrote:

> *anything* that is perceived as friction is written off
> almost immediately.

Yet they still use C++ :)

-- 
/Jacob Carlborg

On Saturday, 26 September 2015 at 10:14:38 UTC, Jacob Carlborg wrote:
> On 2015-09-26 11:50, Manu via Digitalmars-d wrote:
>
>> *anything* that is perceived as friction is written off
>> almost immediately.
>
> Yet they still use C++ :)

C++ has its issues, but it's still a great language - especially in comparison to many other languages. And even if the programmer in question really doesn't like C++ that much, they're at least familiar with it and used to dealing with its downsides. Using a new language takes them completely outside their comfort zone and requires them to deal with a different set of pros and cons, and it requires them to learn a new a language, which meany programmers just don't want to deal with. So, if a new language seems to have problems that they're current one doesn't (even if it supposedly has other aspects which are way better), many folks simply aren't going to be interested. It's a risk to try something new, and it takes time. And many folks simply don't want to do that. You tend get similar problems when trying to get someone to use any program that replaces something that they're currently using (trying to get someone to switch to LibreOffice or to Linux would be good examples of that).

Unfortunately, with the kinds of folks that we're talking about here, you need to get pretty much _everything_ right in order to not run into problems like Manu is talking about. It tends to take almost nothing for someone to decide that trying something out isn't worth it if they're not actively looking for something better. So, while we have a lot to gain by improving the out-of-the-box user experience for D, it's also a fight that we can't really ever win. There's always going to be _something_ which makes it seem like too much friction to many folks. But if we can do better, then at least that will make it so that fewer people react so negatively, even if many (or even most) still will.

I don't think that there's any question that we have an easier time of convincing someone who's actually interested in finding something better and actually giving D a shot than someone who's simply trying it out and dismiss it if they can. And it sounds like Manu is dealing a lot with the latter type of folks.

- Jonathan M Davis

On 9/26/2015 1:21 AM, Manu via Digitalmars-d wrote:
>> I'll leave that to the GDC and LDC teams.
>
> And right there is the problem as I see it, summarised in one sentence ;)
>
> If you take the D ecosystem as aggregate, these issues are just as
> much issues for the core dev team as they are for these couple of guys
> with a distinctly unfair burden.

Everything is unfair, but the idea behind having 3 compilers is there is no one right way to make a compiler. Me telling the LDC and GDC teams what to do and trying to be their manager is inappropriate.


> An example that comes to mind; I think one of the biggest technical
> problem in the D ecosystem right now is that LDC doesn't support CV8
> debuginfo writing. You might be one of the world's most qualified
> experts on that, would you consider adapting that work to LLVM?

The CV8 support in DMD is open source and the format of the CV8 records is readily apparent by reading that source code. There's nothing magical about it. It's about a thousand lines of code.

  https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cv8.c

But you're asking me to become an expert on LLVM internals, which is a lot harder.

I'm flattered that you believe I am such a superman I can do leading edge work on three totally different modern compilers simultaneously, and work on the language design, run D conferences, do presentations on D, help people with the daily emails asking for help, write articles, etc. But I assure you I am not that good. Oh, and I'm asked to write an IDE, too. I got a sincere proposal yesterday that I write a gui D debugger. I suppose I could do that before lunch tomorrow!

On Saturday, 26 September 2015 at 09:51:19 UTC, Manu wrote:
> Are we making a tool for professional programmers, or is this
> community an intellectual hobby that attracts language nerds? We need
> to learn how to impress well on working professionals, in the few
> moments that we get to do so; typically just a couple of minutes.

Professional programmers pay for their tools, is anybody here paying?  D is not going to have the polish to attract them because it's a small OSS project, without the funding llvm/clang gets from Apple or all the consulting/hardware companies who chip in to gcc.

I'd advise to go the Facebook route and try to get D used for some dev tools here and there, especially on the server, like Warp.  Being easy for desktop devs is never going to happen without some company like Apple putting more polish on the tools and building an IDE around it, like they once did around gcc and now do around clang/llvm.  You're wasting your time if you think you're going to get that from an OSS project that has no associated business model, like llvm/clang/Xcode does.

On Saturday, 26 September 2015 at 09:51:19 UTC, Manu wrote:
> On 26 September 2015 at 16:35, schweik via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Saturday, 26 September 2015 at 05:35:04 UTC, Walter Bright wrote:
>>>
>>> Polish certainly matters a lot.
>>
>>
>> Improving quality is an exponetial problem. After a while to reach the upper level requires a lot of work for almost none signifiant value added.
>
> False, the value is indeed subtle, but extremely powerful. I don't necessarily advocate there-were-10_000-QA-testers-banging-at-this-for-years 'perfect', but it has to work reliably, especially the first time, and without manual configuration.

Generally true but here we are talking about setting-up a compiler.

Maybe a perfect setup could open the door to more new users but those who would gave up in front of the configuration problem will give up anyway because of the problems inherent to programming. The PATH thing is just a joke compared to the mountain a new user has to climb.

I really think that currently there is no problem. Just download the zip, unpack it and put the 'dmd\bin' folder to the PATH...when a new version is released rename the previous dmd folder and unpack the new dmd folder to the same location, and so on. It just works.

On 09/26/15 13:10, Walter Bright via Digitalmars-d wrote:
> On 9/26/2015 1:21 AM, Manu via Digitalmars-d wrote:
>>> I'll leave that to the GDC and LDC teams.
>>
>> And right there is the problem as I see it, summarised in one sentence ;)
>>
>> If you take the D ecosystem as aggregate, these issues are just as much issues for the core dev team as they are for these couple of guys with a distinctly unfair burden.
> 
> Everything is unfair, but the idea behind having 3 compilers is there is no one right way to make a compiler. Me telling the LDC and GDC teams what to do and trying to be their manager is inappropriate.

I'm pretty sure what was meant was more (tri-directional) coordination,
not management.


> The CV8 support in DMD is open source and the format of the CV8 records is readily apparent by reading that source code. There's nothing magical about it. It's about a thousand lines of code.
> 
>   https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cv8.c

Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed.


> I'm flattered that you believe I am such a superman I can do leading edge work on three totally different modern compilers simultaneously, and work on the language design, run D conferences, do presentations on D, help people with the daily emails asking for help, write articles, etc. But I assure you I am not that good. Oh, and I'm asked to write an IDE, too. I got a sincere proposal yesterday that I write a gui D debugger. I suppose I could do that before lunch tomorrow!

The one thing that you, and only you, can do is to make the available free parts accessible, for example by publishing a git repo with them, but w/o any non-open-source code. Nobody else can do that (ie the result wouldn't be sufficiently trustworthy).

Open source code hidden somewhere deep inside a non-free compiler implementation might just as well not exist, as noone interested will be willing to look for it there.

artur

On 26 Sep 2015 4:31 pm, "Artur Skawina via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 09/26/15 13:10, Walter Bright via Digitalmars-d wrote:
> > On 9/26/2015 1:21 AM, Manu via Digitalmars-d wrote:
> >>> I'll leave that to the GDC and LDC teams.
> >>
> >> And right there is the problem as I see it, summarised in one sentence
;)
> >>
> >> If you take the D ecosystem as aggregate, these issues are just as much issues for the core dev team as they are for these couple of guys with a distinctly unfair burden.
> >
> > Everything is unfair, but the idea behind having 3 compilers is there
is no one right way to make a compiler. Me telling the LDC and GDC teams what to do and trying to be their manager is inappropriate.
>
> I'm pretty sure what was meant was more (tri-directional) coordination,
> not management.
>

The only coordination in place is that upstream DMD codebase must never break GDC or LDC's ability to build it and pass the testsuite.

For the time being this is enough.  As for common codebase, we are in a state of divulging further apart for the first time in a while, but I don't see it as my role to keep tabs on every change upstream does.  And there are already some horrible things that need sorting out (or that need reapplying because they've vanished in the D implementation) but not worth my efforts until it comes to switching proper.

Iain.

On Saturday, 26 September 2015 at 15:01:06 UTC, Iain Buclaw wrote:
> For the time being this is enough.  As for common codebase, we are in a state of divulging further apart for the first time in a while, […]

I think it's quite the contrary for LDC. We are releasing a 2.067-based version soon, just started testing the 2.068.2 merge, and will hopefully have a DDMD-based version by late October.

 — David

On Saturday, 26 September 2015 at 03:55:50 UTC, Manu wrote:
> [snip]
> Editing the path variable is one of the most unenjoyable and annoying things to do in windows. start -> settings -> system -> advanced system settings -> environment variables -> PATH -> note the stupid window that appears; a single-line text box created in 1995 (or earlier?), which barely lets you see a single path in a line that's probably a few kb long... whenever you touch it, you know you're likely breaking something on your system that currently works ;) People do it if they have to; in my current case, dev's MUST setup emscripten to build the web frontend, and they proceed to complain about how shit the toolchain experience is, but they are forced to use it regardless... nobody is forced to use D. They must find themselves actively drawn to use D.

Just a little aside tip, Windows search these days is actually really excellent for settings like this (and programs). Windows Key + "env" + Enter is enough to get you to the dialog.

I completely agree that you should almost never have to do this though.

On Saturday, 26 September 2015 at 14:31:15 UTC, Artur Skawina wrote:

> Given the DMD licensing situation, nobody will (or should) even look inside the DMD repo for info. Especially that "backend" string is really scary. I decided to blindly trust your words above, and, with trembling hands, somehow managed to click that link. Phew. That file really appears to be boost licensed.
...>
> Open source code hidden somewhere deep inside a non-free compiler implementation might just as well not exist, as noone interested will be willing to look for it there.


out of curiosity, what is your concern?  as I understand it you can produce derived works but the restriction is on redistribution of the compiler, and if you care about that you ask Walter and he says yes.