On Saturday, 26 September 2015 at 01:37:57 UTC, Manu wrote:
> On 25 September 2015 at 22:17, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> [...]
>
> This is because I am constantly introducing new users to D, and even
> more important when those users are colleagues in my workplace.
> If I talk about how cool D is, then point them at the website where
> they proceed to download and install the compiler, and their
> experience is immediately hindered by difficulty to configure within
> seconds of exposure, this paints a bad first impression, and
> frustratingly, it also reflects badly on *me* for recommending it;
> they're mostly convinced I'm some ridiculous fanboy (they're probably
> right). This is based exclusively on their experience and
> first-impressions. These basic things really matter!
>
> Understand; people with no vested interest in D, and likely some
> long-term resistance to every new trend in the software world jumping
> up and down fighting for their attention (which includes fanboys like
> me!), will not be impressed unless the experience is efficient and
> relatively seamless.
> I'm talking about appealing to potential end-users, not enthusiasts.
> My experience is, over and over again, for years now, that these tiny
> little things **REALLY MATTER**, more than literally anything else. If
> they're turned away by first impressions, then literally nothing else
> matters, and you rarely get a second chance; people don't tend to
> revisit something they've written off in the past.

They just don't care. This is what I think when I read this. If it's not the setup it would be something else. They would find something else to mask their uninterest. Human beings are talented at lying to themselves.

They're just not honest enough with themselves, it's that simple. Don't be so gullible and try to understand what's behind the excuses !

On 26 September 2015 at 14:24, anon via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 26 September 2015 at 01:37:57 UTC, Manu wrote:
>>
>> On 25 September 2015 at 22:17, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> [...]
>>
>>
>> This is because I am constantly introducing new users to D, and even
>> more important when those users are colleagues in my workplace.
>> If I talk about how cool D is, then point them at the website where
>> they proceed to download and install the compiler, and their
>> experience is immediately hindered by difficulty to configure within
>> seconds of exposure, this paints a bad first impression, and
>> frustratingly, it also reflects badly on *me* for recommending it;
>> they're mostly convinced I'm some ridiculous fanboy (they're probably
>> right). This is based exclusively on their experience and
>> first-impressions. These basic things really matter!
>>
>> Understand; people with no vested interest in D, and likely some
>> long-term resistance to every new trend in the software world jumping
>> up and down fighting for their attention (which includes fanboys like
>> me!), will not be impressed unless the experience is efficient and
>> relatively seamless.
>> I'm talking about appealing to potential end-users, not enthusiasts.
>> My experience is, over and over again, for years now, that these tiny
>> little things **REALLY MATTER**, more than literally anything else. If
>> they're turned away by first impressions, then literally nothing else
>> matters, and you rarely get a second chance; people don't tend to
>> revisit something they've written off in the past.
>
>
> They just don't care. This is what I think when I read this. If it's not the setup it would be something else. They would find something else to mask their uninterest. Human beings are talented at lying to themselves.
>
> They're just not honest enough with themselves, it's that simple. Don't be so gullible and try to understand what's behind the excuses !

I don't think that's true at all. Humans are very susceptible to first
impressions. It's all about presentation, getting them excited, and
maintaining that excitement for some relatively short period of time,
like, half an hour... as opposed to the first 3 minutes where it may
have been rejected on initial contact. If people spend enough time
that they start to feel invested, they're on the hook.
In the case of D, they need to feel it's solid, and they need to feel
cool and productive writing their first few lines. In my experience,
it does well to have them perform some task that is a classic
frustration in their 'native' language. For C++ users, I often get
people to write 'static if', that's usually all it takes ;)
What has proven to be very important to me, is that they be able to
complete their first experimental task, whatever it is, painlessly,
without ecosystem problems. I lost my boss at this step, because I
suggested he look into vibe.d to do a simple webserver (websockets).
He experienced problems, and it's practically impossible to debug
exceptions (using VisualD, at the time), and that was enough to send
him packing. If he did successfully complete that task, I'm certain my
company would be using D today.

I believe expanding the D user base in 2015 is mostly about psychology and advertising. D is pretty good technically these days.

On 9/25/2015 9:07 PM, Manu via Digitalmars-d wrote:
> I did file each one yesterday as I encountered these problems.

Ah, wonderful!

> My post
> was about something slightly different though, I just want to try and
> bring it to attention again that the little things matter more than
> the attention they tend to get.
> I think it's important to realise that the ecosystem is taken in
> aggregate. DMD can do a great job of this stuff, but if LDC doesn't
> have the same love, it's 'D' in general that gets the blame.

I understand.

> Out of curiosity, what is the strategy wrt LDC and GDC moving forward?
> Will they move towards simultaneous releases? Will they be included in
> CI builds, such that PR's which break (or don't work) the other
> compilers do fail CI?
> GDC as a culture has different packaging expectations so I don't think
> it's affected so much, but especially for Windows users LDC is the way
> forward, and it should be as solid as DMD in terms of presentation.

I'll leave that to the GDC and LDC teams.

On 9/25/2015 8:55 PM, Manu via Digitalmars-d wrote:
> 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.

You can edit sc.ini instead of PATH, as sc.ini overrides it.

Anyhow, I edit the PATH from the path line like:

PATH >foo.bat

... edit foo.bat and put SET in front of it...

foo

> This is my experience over many years now. The toolchain and compiler
> are now more-or-less sufficiently stable that anyone writing code will
> have a good experience. I believe it's the little things that matter
> more than anything in 2015.

Polish certainly matters a lot.

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.

The whole topic is absurd. It's not a problem for someone who's really interested to setup a few things, including writing one entry in the PATH. If that's perceived as a barrier then the person has probably nothing to do in the field.

On 26 September 2015 at 15:17, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 9/25/2015 9:07 PM, Manu via Digitalmars-d wrote:
>>
>> I did file each one yesterday as I encountered these problems.
>
>
> Ah, wonderful!
>
>> My post
>> was about something slightly different though, I just want to try and
>> bring it to attention again that the little things matter more than
>> the attention they tend to get.
>> I think it's important to realise that the ecosystem is taken in
>> aggregate. DMD can do a great job of this stuff, but if LDC doesn't
>> have the same love, it's 'D' in general that gets the blame.
>
>
> I understand.
>
>> Out of curiosity, what is the strategy wrt LDC and GDC moving forward?
>> Will they move towards simultaneous releases? Will they be included in
>> CI builds, such that PR's which break (or don't work) the other
>> compilers do fail CI?
>> GDC as a culture has different packaging expectations so I don't think
>> it's affected so much, but especially for Windows users LDC is the way
>> forward, and it should be as solid as DMD in terms of presentation.
>
>
> 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.

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?

Are GDC/LDC actively building against DMD head these days? I might be
out of date, but that wasn't the case in the past.
Last time I was current, they were updating periodically, and at great
effort to adapt all the changes in the meantime that didn't consider
their builds. Do we know what kind of time the GDC/LDC guys spend
fixing up breakages like that? Would it be better to catch those
breakages when the initial PR is accepted, rather than a wall of
issues every now and then? If I had to guess, I'd say it looked like
this is probably the reason for infrequent frontend updates, and the
other compilers always being a couple of versions behind DMD, which is
very toxic for the ecosystem. I might be completely wrong on that, but
it looks that way.

Am Fri, 25 Sep 2015 16:30:03 +0000
schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Friday, 25 September 2015 at 16:06:44 UTC, Kagamin wrote:
> > I suppose, PATH variable on windows works the same as on unix? And path hell can be easily reproduced on unix too. Nothing windows-specific here.
> 
> AFAIK, PATH on Windows works basically the same as it does on *nix, but a big difference is that on *nix, there are generally some very specific places where programs go, and almost nothing needs to touch PATH - e.g. a binary is usually going to be in /bin, /usr/bin, or /usr/local/bin, all of which are likely to be in your PATH variable. And if you installed something as your user, then you'd generally put the binary (or a symlink to it) in ~/bin. Windows really doesn't have anything like bin. Everything gets installed in its own directory (usually under Program Files), and if you want it to be usable on the command line, you have to add it to PATH. And since all of these programs are separate, they can have executables with the same name (e.g. link.exe), whereas that's much less likely on *nix, because almost all executables get installed to one of a few bin directories. So, you won't even end up installing conflicting binaries, because they'd overwrite each other.
> 
> I really don't know what the "correct" way to deal with this is in Windows, but the way that it's set up does seem to naturally cause more problems with PATH than you typically get in *nix.
> 
> - Jonathan M Davis

IIRC the windows way is not using PATH if possible. Instead you can usually check if a program is installed and where using some registry keys.

On 26 September 2015 at 15:35, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 9/25/2015 8:55 PM, Manu via Digitalmars-d wrote:
>>
>> 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.
>
>
> You can edit sc.ini instead of PATH, as sc.ini overrides it.
>
> Anyhow, I edit the PATH from the path line like:
>
> PATH >foo.bat
>
> ... edit foo.bat and put SET in front of it...
>
> foo

That kinda seems like more work... but whatever works for you ;)

But regardless, I wasn't talking about DMD pathing troubles. The only
DMD related issue I mentioned was the uninstaller failing. In the case
I gave, LDC was finding the wrong linker.
My claim is that it is wrong for tools to find their dependencies in
PATH on windows. That should be a last resort in lieu of proper
configuration, and proper configuration should have ideally happened
during installation (as is the case with DMD).

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.

> The whole topic is absurd. It's not a problem for someone who's really interested to setup a few things, including writing one entry in the PATH. If that's perceived as a barrier then the person has probably nothing to do in the field.

I don't know where you work, but I've been working for almost 2 decades with hundreds of 'professional programmers'. They're not like OSS programmers. They don't really care about technology, they don't study it on the side, they don't read tech blogs, they don't keep up with the latest trends. They don't care, they just go to work from 9-5, they have a task list, and they need to strike items off that list and *anything* that is perceived as friction is written off almost immediately. They have firmly set habits formed over many years, and they're not interested in changing unless they can immediately perceive a significant benefit to their productivity. They're also averse to risk, so balancing that sense of risk requires a really encouraging first experience.

These are of course gross generalisations, but I feel they are more-or-less accurate. This is how it is. At least in my neck of the woods.

Obviously, this is way off topic and extends to far more than paths and configuring the tool, but it's just that this path thing is endlessly recurring, it seems like such a no brainer that this sort of thing should never fail and I kinda lost my shit.

Your comment is based on the assumption that the user *wants* to use D
(is "really interested"), or approaches it like some tool they must
install and configure to complete their task. That's not the case. In
2015, users are almost entirely indifferent if not skeptical towards
[new language here] (in this case, D), and likely fatigued by the
background noise of shiny new technologies forced upon them, or
otherwise fighting for their attention. They're effectively humoring
me, allowing me an opportunity to prove their preconception wrong, and
it had better be the case that nothing goes wrong during these few
precarious minutes; every little thing is very damaging to
impressions. Conversely, if it all goes smoothly and looks slick, it
makes a very good impression... as if what I'm peddling might be true
;)
My comments are anecdotes. I've been witnessing the exact same
patterns, over and over and over for years. It's not that they want to
hate D, it's that D has to make a valuable impression on them very
quickly before they lose interest and get back to work.

*I JUST WANT TO USE D PROFESSIONALLY*

I don't like having my time wasted, and the amount of time that C++
wastes is... kinda painful to quantify. I want to enjoy my career, and
I don't enjoy programming C++ anymore.
At the same time, I can't seem to use D professionally for apparently
trivial, almost intangible reasons. I think most D users understand
this feeling well.

Perhaps part of the problem is that the bar presented by C++ is fairly high? C/C++ is like, really established, and Visual Studio is pretty good. The quality of the compiler isn't very important; MSVC is so bad it's not funny! The most important things are that it 'just works'™ out of the box, the debugger MUST work well, F12 (go to definition) also works well, and autocomplete works most of the time. I can say with confidence that those things are all that my colleagues care about. They will test those features in the first 2 minutes, and if it doesn't work, they will stop. VisualD does pretty well, but we fail at debugging.

I have advocated in my workplaces/community for years with varying
degrees of success, but every single workplace anecdote I have has
basically gone "colleagues heard my rants, got excited, tried it out
briefly, fell down due to [insert whatever reason foiled this
attempt]". And there is rarely a second chance.
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.

I'm driving my company's tech towards a completely language agnostic platform, where components may pick and choose between suitable languages for specific tasks. I'll have another good go at a sell for D at that point since it's further matured since my last attempt a year ago. It will almost definitely be another failure because LDC doesn't support CV8 debuginfo, or Emscripten, but I'll keep trying, maybe get there one day... :/

</rant> ... sorry!

On 2015-09-26 05:08, Manu via Digitalmars-d wrote:

> Windows is just a terrible operating system and I wish it would die
> already, but OSS just can't get a reasonable Microsoft Office,
> Photoshop, or Visual Studio alternative together. I don't even care if
> it's free, I'd pay good money for a linux version of each of these
> programs, they just have to exist.

Photoshop and Microsoft Office are available on OS X. Visual Studio Code is also available on OS X, although not the same as the regular Visual Studio, I have no experience how they compare.

On OS X there's also Pixelmator as an alternative to Photoshop. I've heard it's pretty good but I'm not experienced in this area so can't really say if it's a viable option.

Sure OS X is not Linux, but it's a Unix system. Better than nothing :)

-- 
/Jacob Carlborg