www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D needs to get its shit together!

reply Mike B Johnson <Mikey Ikes.com> writes:
Seriously! D is starting to gain momentum and if things are not 
stabilized it's going to slow D down.

1 ==>> The VERY FIRST order of business is very simple:

When a new user goes to start using D for the first time, D is a 
PITA to get working! Don't believe me?!?!

Just try getting D installed on all 3 major systems for DMD, LDC, 
GDC, with an IDE, some utilities, possibly arm support(even 
though it's new and expected to have some issues), etc. The 
issues really start popping up when you are trying to use x86 + 
x64. Library issues that result in strange error messages instead 
of "This compiler is not compatible with the phobos v2.4324".

And guess what? This happens to regular users too! They either. 
A) know how to fix them from fixing them in the past or helping 
others(so it doesn't count because the problem still exists) or 
B) have a specific setup that happens to avoid the major 
issues(e.g., just use linux x86) then act like there isn't any 
problems with D.

But no one wants to work on the part of D that deals with these 
problems cause it's boring and most "experts" can deal with the 
problems in a few mins to a few hours... doesn't seem like a huge 
waste of time(even though it is, since it's a waste).

D needs to just work! Library errors, setup problems, IDE 
integration should just work! It seems the changes of it working 
are about 75-85%... that IS LOW! It should be 99%. (And I'm 
talking across the board)

DMD, LDC, GDC, Visual D, Coedit(or whatever the other main IDE's 
are), the utilities(Dustmite, DFormat, etc) should all just work 
seamlessly and without hassle with each other.

What is the main problem? It's very simple: The way the paths are 
stored and retrieved is ancient and prone to bugs and it seems 
there is no clear cut way on how to get everything to find 
everything else. Also, versioning is not always there so even if 
the paths are right, the files in them may not be!

Multiple versions should be able to exist side by side(since D is 
ever changing and sometimes new versions simply don't work like 
they should, then downgrading starts causing problems).


Solution Ideas:

This is a simple problem that needs to be fixed. The installer 
needs to be updated to act as more of a package manager(a 
graphical one for us on windows) that has versioning checks and 
such in it. It doesn't have to be fancy, but should do a bit more 
work than the current on which is basically more trouble then 
just compressing the zip and editing sc.ini by hand.

1. A unified path/directory layout that is unambiguous and every 
D app can rely on.

e.g.,

\Dlang\Compilers\DMD\v2\73.01  (the v2 stuff hence forth replaced 
with <version>
\Dlang\Compilers\DMD\v2\main <- a junction/link to the current 
version, usually the latest

\Dlang\Compilers\DMD\Lib\Phobos\x86\coff\<version>
\Dlang\Compilers\DMD\Lib\Phobos\x86\omf\<version>
\Dlang\Compilers\DMD\Lib\Phobos\x64\coff<version>
\Dlang\Compilers\DMD\Lib\Phobos\x64\omf<version> (even though it 
doesn't exist, just empty, maybe a text file in it stating that 
it is not used for x64)

\DLang\Source\DMD\v...
\DLang\Docs\v...
\DLang\IDEs\VisualD\v...
\DLang\Utilities\DFormat\v...
\DLang\Utilities\DustMite\v...

\DLang\Packages\Derelict\v...
....

and so fourth. I'm not saying it has to be exactly like the one 
above, but the above is unambiguous. One could change compiler 
versions, even have a "master" compiler that simply chooses dmd, 
ldc, gdc, etc and could verify versions if necessary, etc.


Everything gets organized and has a place that is logical and 
hence easy to find, easy to use, and helps in diagnosing 
problems. Versioning and dependencies could be charted. (e.g., a 
change in one version of something doesn't necessarily break it's 
usage with everything else that hasn't been updated, so  we can 
have a table of things that work with each other based on 
versions. We can change, say, the version of DMD to use and the 
front end can consult the master version table to see what 
utilities that work with it and then update all the hard links.

External usages(like windows dlls, link.exe) are all handled. 
They are a) copied from their windows locations. b) noted the 
location they are copied from by adding a text file in the 
directory, etc) (and the installer\manager can refresh everything)

One can install on demand any aspect so everything isn't created 
at once.

As time evolves, this system of organization gets cleaner, 
clearer, and more optimal rather than the current system which 
seems to just be stagnant and relatively broke. It works, for the 
most part, but as time goes on it doesn't get any better at it's 
job. It's usually the same problems over and over and that is why 
you always get a steady stream of users having issues with D due 
to problems that are easily fixable with a little elbow grease 
and thought and a significant amount of desire to get the problem 
fixed[breath!]. Versioning gets better and better. If D1 had this 
type of system, we could simply set the version of to a D1 
compiler and everything would automatically be fixed up. No 
trying to hunt down libraries that work with the correct versions 
and no using utilities that do not work with it. Then with a 
flick of a switch, switch back to D2. With a master site that 
essentially keeps the installation files in a similar 
configuration, the manager just retrieves them... so we don't 
actually have to keep old versions around. We can just download 
them and it will download everything required and their proper 
versions.
Jun 15
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-16 05:53, Mike B Johnson wrote:
 Seriously! D is starting to gain momentum and if things are not 
 stabilized it's going to slow D down.
 
 1 ==>> The VERY FIRST order of business is very simple:
 
 When a new user goes to start using D for the first time, D is a PITA to 
 get working! Don't believe me?!?!
 
 Just try getting D installed on all 3 major systems for DMD, LDC, GDC, 
 with an IDE, some utilities, possibly arm support(even though it's new 
 and expected to have some issues), etc. The issues really start popping 
 up when you are trying to use x86 + x64. Library issues that result in 
 strange error messages instead of "This compiler is not compatible with 
 the phobos v2.4324".
 
 And guess what? This happens to regular users too! They either. A) know 
 how to fix them from fixing them in the past or helping others(so it 
 doesn't count because the problem still exists) or B) have a specific 
 setup that happens to avoid the major issues(e.g., just use linux x86) 
 then act like there isn't any problems with D.
 
 But no one wants to work on the part of D that deals with these problems 
 cause it's boring and most "experts" can deal with the problems in a few 
 mins to a few hours... doesn't seem like a huge waste of time(even 
 though it is, since it's a waste).
 
 D needs to just work! Library errors, setup problems, IDE integration 
 should just work! It seems the changes of it working are about 75-85%... 
 that IS LOW! It should be 99%. (And I'm talking across the board)
 
 DMD, LDC, GDC, Visual D, Coedit(or whatever the other main IDE's are), 
 the utilities(Dustmite, DFormat, etc) should all just work seamlessly 
 and without hassle with each other.
 
 What is the main problem? It's very simple: The way the paths are stored 
 and retrieved is ancient and prone to bugs and it seems there is no 
 clear cut way on how to get everything to find everything else. Also, 
 versioning is not always there so even if the paths are right, the files 
 in them may not be!
 
 Multiple versions should be able to exist side by side(since D is ever 
 changing and sometimes new versions simply don't work like they should, 
 then downgrading starts causing problems).
 
 
 Solution Ideas:
 
 This is a simple problem that needs to be fixed. The installer needs to 
 be updated to act as more of a package manager(a graphical one for us on 
 windows) that has versioning checks and such in it. It doesn't have to 
 be fancy, but should do a bit more work than the current on which is 
 basically more trouble then just compressing the zip and editing sc.ini 
 by hand.
 
 1. A unified path/directory layout that is unambiguous and every D app 
 can rely on.
 
 e.g.,
 
 \Dlang\Compilers\DMD\v2\73.01  (the v2 stuff hence forth replaced with 
 <version>
 \Dlang\Compilers\DMD\v2\main <- a junction/link to the current version, 
 usually the latest
DVM [1] is doing some of this. [1] https://github.com/jacob-carlborg/dvm -- /Jacob Carlborg
Jun 15
next sibling parent reply Mike B Johnson <Mikey Ikes.com> writes:
 DVM [1] is doing some of this.
Cool, does it keep things well organized and deals with windows issues(link.exe., dlls, etc) or just uses the "D way" which is a hairball?
Jun 16
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-16 09:53, Mike B Johnson wrote:
 DVM [1] is doing some of this.
Cool, does it keep things well organized
It depends on what you definition of organized. DVM is a tool that allows you to easily install D compilers. It also allows to easily switch between multiple versions of the compiler. That is, you can have one window (terminal) with one version and another window with another version. On Posix it installs everything ~/.dvm. Each compiler is placed in its own directory, it's mostly the zip archives available on dlang.org unpacked. Here's an example of how the directory structure looks like on Posix: $ tree -L 2 .dvm .dvm ├── archives │ ├── dmd.2.073.0.osx.zip │ ├── dmd.2.074.0-b1.osx.zip │ └── dmd.2.074.0.osx.zip ├── bin │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 │ ├── dvm │ ├── dvm-current-dc │ ├── dvm-default-dc ├── compilers │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 ├── env │ ├── default │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 └── scripts └── dvm
 and deals with windows issues(link.exe., dlls, etc) or just uses the "D way"
which is a hairball?
I'm not that familiar with Windows (the Windows support was contributed by another developer) so I'm not sure which issues you refer to. -- /Jacob Carlborg
Jun 16
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Friday, 16 June 2017 at 17:10:41 UTC, Jacob Carlborg wrote:
 On 2017-06-16 09:53, Mike B Johnson wrote:
 DVM [1] is doing some of this.
Cool, does it keep things well organized
It depends on what you definition of organized. DVM is a tool that allows you to easily install D compilers. It also allows to easily switch between multiple versions of the compiler. That is, you can have one window (terminal) with one version and another window with another version. On Posix it installs everything ~/.dvm. Each compiler is placed in its own directory, it's mostly the zip archives available on dlang.org unpacked. Here's an example of how the directory structure looks like on Posix: $ tree -L 2 .dvm .dvm ├── archives │ ├── dmd.2.073.0.osx.zip │ ├── dmd.2.074.0-b1.osx.zip │ └── dmd.2.074.0.osx.zip ├── bin │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 │ ├── dvm │ ├── dvm-current-dc │ ├── dvm-default-dc ├── compilers │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 ├── env │ ├── default │ ├── dmd-2.073.0 │ ├── dmd-2.074.0 │ ├── dmd-2.074.0-b1 └── scripts └── dvm
 and deals with windows issues(link.exe., dlls, etc) or just 
 uses the "D way" which is a hairball?
I'm not that familiar with Windows (the Windows support was contributed by another developer) so I'm not sure which issues you refer to.
Thanks. At least D has something going on correctly here. My feeling is, unless DVM works well with windows, that it probably currently doesn't offer much help. If it does manage the versioning well and can deal with the environmental issues well then it is close to what I am asking. If that's the case, it should be polished off and used as the main front end and hosted by D. You didn't state if it works congruently with all the major compilers. The issues in windows are: 1. coff/omf. Requires use of windows and visual studio/C stuff who's locations and versions change over the years. This can be a major headache finding the right version. Mainly because the error messages, when using the wrong version, do not suggest that it is a versioning error. dvm could have the option to search the entire system for the files it needs(e.g., link.exe, various dlls that are generally used, etc) and attempt get things to work. 2. Managing different compilers: Not too bad but if you end up with some problems here, then it gets multiplied by the factor of the number of issues with each compiler. if LDC has an issue with the x64 dlls and dmd with the x32 and they are always looking in the same place because the versions are different and wrong, then it becomes a issue with a "factor of 4" problem. This can become even worse when you try cross compiling and such. 3. Re-installation can be problematic. sci.ini is overwritten. If you hand coded the paths to get everything to work, guess what? Well, who cares? You have plenty of time to waste, right? 4. Reinstalling one thing can break something else. This depends on how fragile the setup was at the start. 5. People that don't have problems with their setup generally think everything "just works" and bitch at others for complaining. Ignorance is bliss, but it's still ignorance. Life is more complicated and everything just doesn't work for everyone because everyone system is different. I don't use standard paths to install things and when an installer hard codes paths that don't exist, it breaks on my system. That is not my fault. The installer shouldn't be so ignorant and do it's job properly. Usually it was written by someone who thinks that when other people have problems on their system, it is due to their ignorance rather than the ignorance of the installer writer(Because they think: Hey, it worked on my system and my system is the same as everyone elses). Same goes for utilities. I have over 1 billion files on my system, I use it for around 20 different non-complementary subjects(graphics, music, programming, etc). When everything is "competing for space" and things are not set up to work together, one seemingly unrelated program and effect every other one. (e.g., simply by adding to the path variable and break things with error messages that are meaningless to the real problem) Most ignorant people do not take those things in to account because they oversimplify... and that usually causes problems down the road for the rest of us. As D becomes increasing popular, there are going to be more variation in the system and the flaws in it will become larger and larger. It's best to start working on fixing those flaws before they become too large to manage and weaken the whole structure. We all know this to be true on some level, but it is actually fact. It is the way of life, everything breaks down. The more flaws it has at the start, the faster it will break down... unless they are fixed at the start. Fixing them near the end just results in a huge waste of time and resources. e.g., same problem with a human being. If a kid doesn't take care of themselves, they will have many problems when they get old... then tons of money will be wasted on trying to "fix" them. If the kid took care of himself when he was young, those problems would be minimized. Same with a utility, app, or installer. But most humans treat their work like their life... they don't do the right thing until they are forced too, and by then it's too late. The point with all this is that D needs to start doing the right things that now rather than wait until it's too late. I'm not saying it is not doing anything right, but it is obvious by some of the comments that some people just don't get it and think it's everyone else's problem(and these people are generally the one that fucks it up for the rest of us, just look at the world today for the constant reminder). D and be the shining city on the hill or it can just be another New York or Dallas. Sure, they are big, but full of problems. Some people are happy and some are not. The goal is to make everyone happy. That starts by, first, by having a good foundation.
Jun 16
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-06-17 08:06, Mike B Johnson wrote:

 Thanks. At least D has something going on correctly here.

 My feeling is, unless DVM works well with windows, that it probably
 currently doesn't offer much help. If it does manage the versioning well
 and can deal with the environmental issues well then it is close to what
 I am asking. If that's the case, it should be polished off and used as
 the main front end and hosted by D.

 You didn't state if it works congruently with all the major compilers.
No, unfortunately it only allows to install DMD.
 The issues in windows are:

 1. coff/omf. Requires use of windows and visual studio/C stuff who's
 locations and versions change over the years. This can be a major
 headache finding the right version. Mainly because the error messages,
 when using the wrong version, do not suggest that it is a versioning error.

 dvm could have the option to search the entire system for the files it
 needs(e.g., link.exe, various dlls that are generally used, etc) and
 attempt get things to work.
No, DVM doesn't do anything to try to find the installation of Visual Studio. Unless the compiler already can find it, it won't help. DVM was created before the compiler supported Visual Studio and I haven't kept the tool up to date to match that.
 3. Re-installation can be problematic. sci.ini is overwritten. If you
 hand coded the paths to get everything to work, guess what? Well, who
 cares? You have plenty of time to waste, right?
That's a difficult problem. What if you messed up sc.ini and that's the reason you want to reinstall? -- /Jacob Carlborg
Jun 17
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 17 June 2017 at 06:06:53 UTC, Mike B Johnson wrote:

 1. coff/omf. Requires use of windows and visual studio/C stuff 
 who's locations and versions change over the years. This can be 
 a major headache finding the right version. Mainly because the 
 error messages, when using the wrong version, do not suggest 
 that it is a versioning error.
This isn't as severe as you make it sound. If the latest version of VS doesn't work, the one before will. It's easy to prevent such issues in the future. Since we never know if a new version of VS will break things, this can be solved by one person who can monitor the beta releases of VS and submit PRs to the appropriate repositories if the paths change, or (as happened with VS 2015) the C runtime library changes, or some other breakage arises. Then DMD can get support for the new version before it's released. Could that person be you?
 2. Managing different compilers: Not too bad but if you end up 
 with some problems here, then it gets multiplied by the factor 
 of the number of issues with each compiler. if LDC has an issue 
 with the x64 dlls and dmd with the x32 and they are always 
 looking in the same place because the versions are different 
 and wrong, then it becomes a issue with a "factor of 4" 
 problem. This can become even worse when you try cross 
 compiling and such.
What I've done in the past is to keep the latest DMD on the system path, then set up Command Prompt shortcuts initialized with a different batch file to set override it with paths to different compilers/versions. If DVM could get support for LDC and GDC, then you'd have everything in one convenient app.
 3. Re-installation can be problematic. sci.ini is overwritten. 
 If you hand coded the paths to get everything to work, guess 
 what? Well, who cares? You have plenty of time to waste, right?
Backup the sc.ini file.
 4. Reinstalling one thing can break something else. This 
 depends on how fragile the setup was at the start.
Like what?
 5. I have over 1 billion files on my system, I use it for 
 around 20 different non-complementary subjects(graphics, music, 
 programming, etc). When everything is "competing for space" and 
 things are not set up to work together, one seemingly unrelated 
 program and effect every other one. (e.g., simply by adding to 
 the path variable and break things with error messages that are 
 meaningless to the real problem)

 Most ignorant people do not take those things in to account 
 because they oversimplify... and that usually causes problems 
 down the road for the rest of us.
So, what are you proposing here? Educate us. What are we supposed to take into account? I use my computer also for graphics, music, programming, document editing, all sorts of stuff. The only breakage I've ever had has usually been related to anti-virus software, though in the past there was an occasional issue with things like SecuRom. What exactly should the D community to in order to alleviate these major breakages you have on your system?
 As D becomes increasing popular, there are going to be more 
 variation in the system and the flaws in it will become larger 
 and larger.  It's best to start working on fixing those flaws 
 before they become too large to manage and weaken the whole 
 structure.
I would like to reiterate here what I mentioned earlier in this thread -- people in the D community are currently fixing flaws all the time. That we aren't fixing the flaws that particularly peeve you does not mean nothing is being done. I would also like to reiterate that if something is important enough to you, then you could do something about it besides coming to the forums and calling the rest of us ignorant. Write a DIP. File issues on Bugzilla. Submit pull requests. Take on responsibility for ensuring Visual Studio compatibility. Or do nothing, but please don't act as if we're all just sitting here twiddling our thumbs.
Jun 17
next sibling parent reply bachmeier <no spam.net> writes:
As D continues to grow, there will be messages like this posted 
more frequently. Imagine that you work at a large company and are 
considering adopting D so you decide to check out the forum.

Posts like this have to be deleted from the website and users 
that post such things need to be banned. Like it or not, this is 
marketing.


On Sunday, 18 June 2017 at 08:40:22 UTC, Mike B Johnson wrote:
 On Saturday, 17 June 2017 at 15:01:34 UTC, Mike Parker wrote:
 On Saturday, 17 June 2017 at 14:01:38 UTC, Mike B Johnson 
 wrote:

 You realize your mentality is like a dead rat? It just 
 stinks. Your solutions are not solutions. They are patches. I 
 wouldn't hire you to fix my plumbing because in a few months 
 I'll have to fix it again. You are ok with that, because you 
 get paid either way.  Keep kicking the can down the road... 
 It may get you a bit of exercise but in the long run you are 
 just wasting everyone's time. I also suggest you get out of 
 the 1970's. Software and computers have come a long way. We 
 shouldn't have to resort to the same mind set 40+ years ago. 
 I shouldn't have to backup sc.ini, just because you think it 
 is the way doesn't mean it is. That mindset for sc.ini 
 pervades all your so called solutions. There are better ways, 
 too bad you don't care or are too ignorant to see them.
That's fine. One more piece of advice I have for you. If you want anyone to take you seriously, check the attitude at the gate. Good luck!
Cool. Since we are friends now, I have some advice for you: I suggest that if you want anyone to take you seriously, I suggest you check your mediocrity mentality at the door. See how that works?!?! Probably not. I suggest you get with the program and stop assuming it's ok to waste peoples time, including your own. The world would be a better place if people like you stopped playing your little games and grow up. Then people like me wouldn't have to constantly put you in your place.
Jun 18
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 18.06.2017 13:59, bachmeier wrote:
 
 Posts like this have to be deleted from the website and users that post 
 such things need to be banned.
Then maybe don't quote the offending post next time.
Jun 18
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 18 June 2017 at 11:59:34 UTC, bachmeier wrote:
 As D continues to grow, there will be messages like this posted 
 more frequently. Imagine that you work at a large company and 
 are considering adopting D so you decide to check out the forum.

 Posts like this have to be deleted from the website and users 
 that post such things need to be banned. Like it or not, this 
 is marketing.
I strongly disagree about deletion and banning. The moment you start removing dissenting opinions, you move towards a bubble where you get isolated from the world. These people are detailing real frustrations that they had, albeit in a shrill manner, feedback that doesn't hurt. As for their posts affecting corporate perception, better they see the truth now and know what they're getting into, rather than the companies coming in here and ranting later, only to get their posts deleted too! :D On Sunday, 18 June 2017 at 14:53:57 UTC, Wulfklaue wrote:
Perhaps _this_ is the right packaging for D right now, to keep 
away the kinds of casual users who would not be suited for D.
It angers the hell out of me when people look down on other developers because they do not have the right background or are somehow considered less trying to deal with inadequacies in the D ecosystem.
You left out the bit after that where I noted that D is a sprawling, lower-level language, and that I had no strong opinion on that guess about this being the right packaging for D right now. The fact is that people who deal with languages like D are usually fine with more complex setups and require less hand-holding. New languages like Rust, Go, and Swift are upping the AoT-compiled language game and making things better, but all are still prone to the issues you raise. What I was saying is that if you made D _really easy_ to install, as easy as installing a scripting language in a linux distro except on every OS, it would be really easy for them to get going, but not easier to actually grasp a much more complex language. It is a basic concept of distribution that you put your product where and how you can get the types of users you want, ie you would not try and sell a buzzsaw or backhoe in the corner grocery store. You can call that "looking down," I call it a fact. Also, a lot of this polish is missing because D is an OSS project that doesn't have corporate involvement driving it. No pure OSS project without heavy corporate involvement has ever gotten everywhere, you will find corporate hands all over everything from the linux kernel to gcc to Python. D has some, but not that much yet. It is amazing how far it has gotten without it. Finally, my point was that since D is not at the stage where it has corporate support to polish it up to the sheen you want, perhaps it's better to keep away the kind of users who want that level of integration. That's not to say they're "less," but that D is not ready for them yet. We all hope D gets there someday, but maybe it's not yet ready to make that leap.
Jun 18
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 6/18/17 11:04 PM, Joakim wrote:
 I strongly disagree about deletion and banning.  The moment you start 
 removing dissenting opinions, you move towards a bubble where you get 
 isolated from the world.
Foul or abusive language has nothing to do with dissenting. It's really simple - using unprofessional language that could get you fired from a workplace is not accepted here. Thanks. -- Andrei
Jun 18
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 18 June 2017 at 20:42:55 UTC, Andrei Alexandrescu 
wrote:
 On 6/18/17 11:04 PM, Joakim wrote:
 I strongly disagree about deletion and banning.  The moment 
 you start removing dissenting opinions, you move towards a 
 bubble where you get isolated from the world.
Foul or abusive language has nothing to do with dissenting. It's really simple - using unprofessional language that could get you fired from a workplace is not accepted here. Thanks. -- Andrei
I don't see any foul or abusive language in the post bachmeier quoted, nor did bachmeier say that was his concern, so we weren't talking about that. These are two new users who are unhappy with the state of D and unfortunately larding a lot of attitude into their complaints, which is why I've largely ignored them. That may be accepted if they're paying up the butt to use D, but they're getting it for free, so why deal with their entitlement and potentially escalate the situation? But even if there were foul or abusive language, which we may disagree on whether the posts in this thread qualify as, I'd only consider the extreme measures cited after repeated warning, as such removals are then often abused to silence criticism. We may not like the strong way they worded it, but post deletion and the banhammer should really be reserved for extreme situations. I don't think this qualifies.
Jun 18
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 6/19/17 12:07 AM, Joakim wrote:
 On Sunday, 18 June 2017 at 20:42:55 UTC, Andrei Alexandrescu wrote:
 On 6/18/17 11:04 PM, Joakim wrote:
 I strongly disagree about deletion and banning.  The moment you start 
 removing dissenting opinions, you move towards a bubble where you get 
 isolated from the world.
Foul or abusive language has nothing to do with dissenting. It's really simple - using unprofessional language that could get you fired from a workplace is not accepted here. Thanks. -- Andrei
I don't see any foul or abusive language in the post bachmeier quoted, nor did bachmeier say that was his concern, so we weren't talking about that.
Walter and I talk about that. -- Andrei
Jun 18
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/18/2017 2:07 PM, Joakim wrote:
 I don't see any foul or abusive language in the post bachmeier quoted,
Insulting forum members by telling them to "grow up", "stinks", for example, is abusive language. As is the Subject of the post. Professional decorum is expected in this n.g. and on the dlang github forums. For further questions about what constitutes professional decorum, I recommend reading "Emily Post" books on manners which are readily available.
Jun 18
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 18 June 2017 at 21:44:11 UTC, Walter Bright wrote:
 On 6/18/2017 2:07 PM, Joakim wrote:
 I don't see any foul or abusive language in the post bachmeier 
 quoted,
Insulting forum members by telling them to "grow up", "stinks", for example, is abusive language. As is the Subject of the post.
Not to me. In any case, is it now your policy to go around deleting all such mild infractions? Good luck with that.
 Professional decorum is expected in this n.g. and on the dlang 
 github forums.
I know of no profession that doesn't regularly see much worse. We should strive to be better, but if some newbies pop off once in awhile, let's not overreact with deletions and bans. We all agree that these two went overboard, where we may disagree is on whether deletions and bans are warranted.
 For further questions about what constitutes professional 
 decorum, I recommend reading "Emily Post" books on manners 
 which are readily available.
I would never read such a thing. I subscribe more to the Linus school that such books are written by schoolmarms who simply squeeze the negativity into other possibly more corrosive behavior: "Because if you want me to 'act professional,' I can tell you that I'm not interested. I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways." https://arstechnica.com/information-technology/2013/07/linus-torvalds-defends-his-right-to-shame-linux-kernel-developers/ That is not to say I'd go around cursing like Linus, and again we agree these two went overboard, but it's not a big deal and I don't think it merits anything more than a warning, both here and in general. I'll stop responding after this, as I've now made my position clear, and we don't need to turn this into a big etiquette discussion. :)
Jun 18
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 06/18/2017 06:21 PM, Joakim wrote:
 On Sunday, 18 June 2017 at 21:44:11 UTC, Walter Bright wrote:
 For further questions about what constitutes professional decorum, I 
 recommend reading "Emily Post" books on manners which are readily 
 available.
I would never read such a thing. I subscribe more to the Linus school that such books are written by schoolmarms who simply squeeze the negativity into other possibly more corrosive behavior: "Because if you want me to 'act professional,' I can tell you that I'm not interested. I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways." https://arstechnica.com/information-technology/2013/07/linus-torvalds-defends-his-right-to-shame-linu -kernel-developers/ That is not to say I'd go around cursing like Linus, and again we agree these two went overboard, but it's not a big deal and I don't think it merits anything more than a warning, both here and in general. I'll stop responding after this, as I've now made my position clear, and we don't need to turn this into a big etiquette discussion. :)
Hear, hear!
Jun 20
prev sibling next sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 18 June 2017 at 20:04:48 UTC, Joakim wrote:
 On Sunday, 18 June 2017 at 11:59:34 UTC, bachmeier wrote:
 As D continues to grow, there will be messages like this 
 posted more frequently. Imagine that you work at a large 
 company and are considering adopting D so you decide to check 
 out the forum.

 Posts like this have to be deleted from the website and users 
 that post such things need to be banned. Like it or not, this 
 is marketing.
I strongly disagree about deletion and banning. The moment you start removing dissenting opinions, you move towards a bubble where you get isolated from the world. These people are detailing real frustrations that they had, albeit in a shrill manner, feedback that doesn't hurt. As for their posts affecting corporate perception, better they see the truth now and know what they're getting into, rather than the companies coming in here and ranting later, only to get their posts deleted too! :D
Yes - from my perspective, the way you know something is true is if you can recognise it as potentially such and expose it to critique and there hasn't been a _good_ argument against it. It's certainly true that the more corporate types will be put off by the directness and passion of discussions here, but I really don't think they are likely to be earlier adopters of D. The people who will be early adopters are discerning principals who have the ability to make decisions personally and bear the consequences rather than managerial agent types operating in a world where social perception dominates. The managerial types will come later - that's the price of success that it draws a different kind of person. From a hiring perspective, it's a positive thing that very few people are involved with D primarily for careerist reasons - even though I can think of quite a few people for whom it's turning out to be pretty good indeed, and where taking a more conventional route would not have had this payoff over time. This being said, there is only one problem which is that anyone can say anything and until you know who is insightful then it's not in the beginning obvious. Some people here (not many) for example that are highly intelligent are constantly criticising the direction of the language - but I'm really not sure they do much in D at all - they just like hanging out here and arguing: for them it is like sports. So I think people should earn the right to be listened to and who they are and what they have contributed sets the context for how one should understand a passionate critique, even rant. If Manu, for example, (I am thinking of a while back) expresses frustration and in very specific terms about infelicities then that's something we should take seriously because it's evident that he cares about the language and community and would just like to remove such infelicities because they get in the way of it being adopted by colleagues and associates. We might not be able to change much in the short term, but such a thing one should take seriously. As Walter said you should listen to your current best customers not the people who give you friendly 'free advice' when they do not actually have skin in the game. A community isn't a democracy - you listen to people who have shown they know what they are talking about, and the amount of noise people make is not very related to how much insightful they have to say.
Jun 18
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
On Sunday, 18 June 2017 at 20:04:48 UTC, Joakim wrote:
 I strongly disagree about deletion and banning.  The moment you 
 start removing dissenting opinions, you move towards a bubble 
 where you get isolated from the world.  These people are 
 detailing real frustrations that they had, albeit in a shrill 
 manner, feedback that doesn't hurt.

 As for their posts affecting corporate perception, better they 
 see the truth now and know what they're getting into, rather 
 than the companies coming in here and ranting later, only to 
 get their posts deleted too! :D
Couldn't have said it better. Though I just filed [Add some Hackernews-like ranking and upvoting](https://github.com/CyberShadow/DFeed/issues/84) because relevance and not wasting people's time matters.
 Finally, my point was that since D is not at the stage where it 
 has corporate support to polish it up to the sheen you want, 
 perhaps it's better to keep away the kind of users who want 
 that level of integration.  That's not to say they're "less," 
 but that D is not ready for them yet.

 We all hope D gets there someday, but maybe it's not yet ready 
 to make that leap.
You have quite a good point there, that said the Windows experience is fairly bad, no point about it. That's mostly because VisualStudio integration is required, be it for their linker and libc only, and that isn't too well done.
Jun 18
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 18 June 2017 at 21:01:10 UTC, Martin Nowak wrote:
 On Sunday, 18 June 2017 at 20:04:48 UTC, Joakim wrote:
 I strongly disagree about deletion and banning.  The moment 
 you start removing dissenting opinions, you move towards a 
 bubble where you get isolated from the world.  These people 
 are detailing real frustrations that they had, albeit in a 
 shrill manner, feedback that doesn't hurt.

 As for their posts affecting corporate perception, better they 
 see the truth now and know what they're getting into, rather 
 than the companies coming in here and ranting later, only to 
 get their posts deleted too! :D
Couldn't have said it better. Though I just filed [Add some Hackernews-like ranking and upvoting](https://github.com/CyberShadow/DFeed/issues/84) because relevance and not wasting people's time matters.
 Finally, my point was that since D is not at the stage where 
 it has corporate support to polish it up to the sheen you 
 want, perhaps it's better to keep away the kind of users who 
 want that level of integration.  That's not to say they're 
 "less," but that D is not ready for them yet.

 We all hope D gets there someday, but maybe it's not yet ready 
 to make that leap.
You have quite a good point there, that said the Windows experience is fairly bad, no point about it. That's mostly because VisualStudio integration is required, be it for their linker and libc only, and that isn't too well done.
Is it possible to use lld on Windows? I never tried it myself. https://lld.llvm.org/
Jun 18
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 18 June 2017 at 21:06:07 UTC, Laeeth Isharc wrote:
 On Sunday, 18 June 2017 at 21:01:10 UTC, Martin Nowak wrote:
 You have quite a good point there, that said the Windows 
 experience is fairly bad, no point about it. That's mostly 
 because VisualStudio integration is required, be it for their 
 linker and libc only, and that isn't too well done.
Is it possible to use lld on Windows? I never tried it myself. https://lld.llvm.org/
They say it's mostly done: https://lld.llvm.org/windows_support.html kinke integrated the Windows support in the latest ldc beta, so that you can cross-compile and link with ldc and lld to Windows from any other ldc/lld-supported platform, like macOS or linux, provided you have the MSVC libc available for executables or shared libraries (libc not needed for static libraries of course): https://github.com/ldc-developers/ldc/releases/tag/v1.3.0-beta2
Jun 18
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Sunday, 18 June 2017 at 21:06:07 UTC, Laeeth Isharc wrote:
 Is it possible to use lld on Windows?  I never tried it myself.
 https://lld.llvm.org/
Says they don't support debug info (debugger being another dependency on VisualStudio). But yes, different toolchains (mingw, lld) and cross compilation (gdc, ldc) might improve the situation. The last gdc cross-compiler supported Windows is from 1/24/16. ftp://ftp.gdcproject.org/binaries/4.9.2/x86_64-linux-gnu/ AFAIK clang had quite some Windows support issues as well, so maybe we can draw some bits from their solutions. Part of the problem is that we have very few contributors that are using Windows, so there isn't much personal motivation to work on that.
Jun 18
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 18 June 2017 at 21:37:13 UTC, Martin Nowak wrote:
 On Sunday, 18 June 2017 at 21:06:07 UTC, Laeeth Isharc wrote:
 Is it possible to use lld on Windows?  I never tried it myself.
 https://lld.llvm.org/
Says they don't support debug info (debugger being another dependency on VisualStudio). But yes, different toolchains (mingw, lld) and cross compilation (gdc, ldc) might improve the situation. The last gdc cross-compiler supported Windows is from 1/24/16. ftp://ftp.gdcproject.org/binaries/4.9.2/x86_64-linux-gnu/ AFAIK clang had quite some Windows support issues as well, so maybe we can draw some bits from their solutions. Part of the problem is that we have very few contributors that are using Windows, so there isn't much personal motivation to work on that.
I wasn't using Windows but we are now, and there's an author of one Phobos module that will be starting to help me full-time from maybe August, so we could look at what could be done if we could start small. Windows has been a bit of a pain, but mostly from the native code library side. It should be easy to install google snappy right? On Linux it is. On Windows, not so much... And that's just one library. I almost never use debuggers myself so might be interesting to get lld working with ldc (dmd too?) if it's possible as could simplify our builds a bit.
Jun 18
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 18 June 2017 at 21:47:48 UTC, Laeeth Isharc wrote:
 Windows has been a bit of a pain, but mostly from the native 
 code library side.
I've found D on Windows to be very easy for myself and for my end users... but not for intermediate developers. For myself, I just set up the necessary .lib files in my dmd lib folder and problem solved. I can do conversions or generation as needed. For the end users, I'll just do a binary distribution and things just work for them. But intermediate devs having to set up the environment can be a pain... that's why my libs are set up in a particular way to work with dmd out of the box and other stuff opt in..
Jun 18
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 18 June 2017 at 22:15:41 UTC, Adam D. Ruppe wrote:
 On Sunday, 18 June 2017 at 21:47:48 UTC, Laeeth Isharc wrote:
 Windows has been a bit of a pain, but mostly from the native 
 code library side.
I've found D on Windows to be very easy for myself and for my end users... but not for intermediate developers. For myself, I just set up the necessary .lib files in my dmd lib folder and problem solved. I can do conversions or generation as needed. For the end users, I'll just do a binary distribution and things just work for them. But intermediate devs having to set up the environment can be a pain... that's why my libs are set up in a particular way to work with dmd out of the box and other stuff opt in..
Yes, but suppose you want to build a C library like Google snappy, nanomsg or leveldb. It's a bit of a pain on Windows. No worse with D than C++. But it looks awfully complicated coming from C#.
Jun 18
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 18 June 2017 at 22:24:47 UTC, Laeeth Isharc wrote:
 Yes, but suppose you want to build a C library like Google 
 snappy, nanomsg or leveldb.  It's a bit of a pain on Windows.
Well, that's kinda what I mean by intermediate developer pain... but there's also lessneed to build libraries on Windows since you can just use the binary distribution for the libs, if it is available, but on Windows they often are.
Jun 18
prev sibling parent reply Brad Anderson <eco gnuk.net> writes:
On Sunday, 18 June 2017 at 21:47:48 UTC, Laeeth Isharc wrote:
 [snip]
 Windows has been a bit of a pain, but mostly from the native 
 code library side.  It should be easy to install google snappy 
 right?  On Linux it is.  On Windows, not so much...  And that's 
 just one library.
vcpkg is making it pretty easy to get C and C++ libraries on Windows. Snappy is supported. https://github.com/Microsoft/vcpkg
Jun 21
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 22 June 2017 at 05:59:05 UTC, Brad Anderson wrote:
 On Sunday, 18 June 2017 at 21:47:48 UTC, Laeeth Isharc wrote:
 [snip]
 Windows has been a bit of a pain, but mostly from the native 
 code library side.  It should be easy to install google snappy 
 right?  On Linux it is.  On Windows, not so much...  And 
 that's just one library.
vcpkg is making it pretty easy to get C and C++ libraries on Windows. Snappy is supported. https://github.com/Microsoft/vcpkg
+1 Every library I care about is available through vcpkg. And it's much cleaner to use, IMO, than NuGet or Chocolatey.
Jun 22
prev sibling parent reply Mark <smarksc gmail.com> writes:
On Sunday, 18 June 2017 at 20:04:48 UTC, Joakim wrote:
 Also, a lot of this polish is missing because D is an OSS 
 project that doesn't have corporate involvement driving it.  No 
 pure OSS project without heavy corporate involvement has ever 
 gotten everywhere, you will find corporate hands all over 
 everything from the linux kernel to gcc to Python.  D has some, 
 but not that much yet.  It is amazing how far it has gotten 
 without it.
Why not, really? All due respect to Sociomantic, Weka, etc., but I'm suprised there isn't more coporate interest in the language.
Jun 18
parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 18 June 2017 at 23:45:10 UTC, Mark wrote:
 On Sunday, 18 June 2017 at 20:04:48 UTC, Joakim wrote:
 Also, a lot of this polish is missing because D is an OSS 
 project that doesn't have corporate involvement driving it.  
 No pure OSS project without heavy corporate involvement has 
 ever gotten everywhere, you will find corporate hands all over 
 everything from the linux kernel to gcc to Python.  D has 
 some, but not that much yet.  It is amazing how far it has 
 gotten without it.
Why not, really? All due respect to Sociomantic, Weka, etc., but I'm suprised there isn't more coporate interest in the language.
Since the complaints here seem largely related to Windows integration, Sociomantic is only on linux, to the point where their D stdlib, Ocean, only runs on linux, same as their concurrent GC. Weka is doing their own hardware, doubt they're using Windows on there. ;) I think even Laeeth, whose hedge fund has sponsored some work like Excel-D, said they don't use Windows much. I too am mystified there isn't more corporate backing. However, there are always other avenues, like bounties (https://www.bountysource.com/teams/d/backers), donations to the D foundation (http://dlang.org/foundation), or private paid work that's eventually open-sourced, so there are many ways to build D up.
Jun 18
prev sibling parent John Carter <john.carter taitradio.com> writes:
On Sunday, 18 June 2017 at 11:59:34 UTC, bachmeier wrote:
 As D continues to grow, there will be messages like this posted 
 more frequently. Imagine that you work at a large company and 
 are considering adopting D so you decide to check out the forum.
Ruby talk in the early days went through a fairly painful phase like this..... attracting trolls like flies. Oh gawd: Remember that one guy who analysed each language by a long long list of somewhat odd criteria and demanded all deficiencies be remedied...? Fortunately the overwhelming niceness of the community prevailed. I do think liberal application of https://en.wikipedia.org/wiki/Disemvoweling of any personal attacks and/or nastiness would rapidly starve these threads of oxygen.
Jun 18
prev sibling parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Sunday, 18 June 2017 at 08:40:22 UTC, Mike B Johnson wrote:
 Cool. Since we are friends now, I have some advice for you: I 
 suggest that if you want anyone to take you seriously, I 
 suggest you check your mediocrity mentality at the door.

 See how that works?!?! Probably not. I suggest you get with the 
 program and stop assuming it's ok to waste peoples time, 
 including your own. The world would be a better place if people 
 like you stopped playing your little games and grow up. Then 
 people like me wouldn't have to constantly put you in your 
 place.
Mike, if people do not want to listen, simply accept that... Going on a yelling tirade solves nothing. I already concluded from this "discussion" that there is no point trying to point out issues with D. Maybe too many people in the past pointed out the same stuff and they are tired of it. Whatever the issue is, simply move on. If they do not want to attract new people or want to make it more easy, who are we to talk about it ( as the same new people ). There are good people in the D community but in some responses you get the attitude like "how do you not know something so simple". And i am not talking about this topic. There are responses that borderline "how stupid are you". Maybe not in those words but you can read it clearly. Maybe because i got some of those responses that i also felt more "inflammatory" in this topic by generalizing. But reading comments like:
Perhaps _this_ is the right packaging for D right now, to keep 
away the kinds of casual users who would not be suited for D.
It angers the hell out of me when people look down on other developers because they do not have the right background or are somehow considered less trying to deal with inadequacies in the D ecosystem. I am not targeting any person here but there are people here with good intentions and people who to not realize how there responses look down on people. Some do not understand that not everybody has 10+ years in developing C/C++ programs and knows every terminology and understands every aspect of the memory management and the ins and out. But there is no point fighting this attitude. Just use D for what you need it or move to a different language. I am at this moment contemplating moving my code base to different language for this same reason. My impression of D: * The forums is a mixed bag of good intention people who give you the answer you need. Some people who look down for asking a stupid question. Some people who take criticism about D such a personal level. And people who are simply rude, maybe there have good intention but have short fuse ( i wonder who that is :) ). * Git: I found the people who managed the code summations to D GIT way more helpful and frankly very pleasant. I learned a lot in a short amount of time despite being a total noob at this. Frankly, sometimes i wish i NEVER discovered the forums because seeing some of the discussions and reading the past discussions, it feels like a darn pool of evil. Good, bad and just ugly. It frankly demotivates... And it has now **highly** opinionated my attitude about D, to the point that makes me wonder. As a potential employer: If i hire people with no D knowledge and they need to learn D. They go to these forums and get sucked into this. What about easy of learning, issues they may run into. It means time i need to spend teaching new employees to avoid some of the issues mentioned here ( and a lot of past topics that i found ). I do not understand because on other language forums the discussions are more civilized, there seem to be less looking down on people. Maybe i use the Rust argument a bit too much but to be good at Rust a good background is extreme helpful and yet, i do not notice the same attitude with people ask stupid questions or are not happy about something. I really, REALLY think that some people have been living so long in a bubble, that they do not understand how person some of there responses are and how it affects future posting from new members. There are a lot of other things... but it will sidetrack things even more. Its already a wall of text by now. But it really comes down in its most simple form: "Language good, library can use some work but useful, standard documentation disaster ( until you discover the library doc ), community mixed bag, 3th party plugins again mixed bag ( some good, some bad, some not maintained ), language future not 100% sure about where it will end up". And that is my personal and honest opinion... ------------- ------------- And please, do not quote my text piece by piece, ripping me a new one for being inflammatory or whatever. Its how I from MY perceptive see things. Just as you, the person reading this will have there own opinion. ------------- ------------- As for me, i will be looking a bit more into other languages and there communities. For a hobby project D is perfectly fine but as a future employer my standard is much more ridge. I want to hire people first with lower experience ( cheaper ) and let them learn on the job. And well ... lets say that my impression has been a mixed experience so far. Especially if this means exposing people with maybe scripting language experience to a compile language like D. Maybe its time to tidy the ship because first impression count for a lot. I see nothing that i can add to this. I only wanted to respond because the topic is getting way too heated and i hope this turns it into a different direction with ALL parties looking back a bit at what is being written. /end wall of text. Now excuse me will i put time into different and more productive things.
Jun 18
next sibling parent meppl <mephisto nordhoff-online.de> writes:
On Sunday, 18 June 2017 at 14:53:57 UTC, Wulfklaue wrote:
 But it really comes down in its most simple form: "Language 
 good, library can use some work but useful, standard 
 documentation disaster ( until you discover the library doc ),
some people keep saying that. and i dont understand them. i think the documentation of the d language is good. i could learn the whole language with just looking at http://dlang.org/spec/spec.html It contains many examples and is easy to read. Someone exclusively coming from the scripting-world might have issues though, i am not sure
Jun 18
prev sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 18 June 2017 at 14:53:57 UTC, Wulfklaue wrote:
 I already concluded from this "discussion" that there is no 
 point trying to point out issues with D. Maybe too many people 
 in the past pointed out the same stuff and they are tired of it.
In an open-source community, the best way to change something is to make a start on it yourself and try to get others interested. Or if you can afford it you can see if Walter or Andrei might be interested in helping you under a consulting arrangement, or try to find someone else in the community that you could pay to change it for you. If you don't want to do the work, and can't pay, then you can still try to persuade people - and often enough, if you are gently persistent and your point is good, you'll be able to influence things over time. What doesn't work is complaining and expecting others to fix your stuff for you. In theory, when you purchase products and services your supplier ought to be much more responsive than where you don't pay. My experience has been that even when you pay quite a lot - millions of dollars - one can often be disappointed in just how responsive a commercial supplier will be. So increasingly over time for me I have come to see the merits of open-source, because at least I can figure out how to change something and find someone who will help me do the work.
 There are good people in the D community but in some responses 
 you get the attitude like "how do you not know something so 
 simple". And i am not talking about this topic. There are 
 responses that borderline "how stupid are you". Maybe not in 
 those words but you can read it clearly.
I do not recognise this attitude at all - in fact it's remarkable how helpful people are, and how some of the best people in the community spend a great deal of time helping others for free.
Perhaps _this_ is the right packaging for D right now, to keep 
away the kinds of casual users who would not be suited for D.
Yes - it's an advantage for D in its present state of development that the frictions act as a shield and tend to mean the people who persist have a high level of technical ability and resourcefulness, and the people shape the culture. If you go buy something precious, they don't give you the hard sell. They say this X is not for everyone, but if you would like to understand it, here is what the thing is like. And I think it's like that with D - it's not for everyone, but if it were I wouldn't be here.
 I am not targeting any person here but there are people here 
 with good intentions and people who to not realize how there 
 responses look down on people. Some do not understand that not 
 everybody has 10+ years in developing C/C++ programs and knows 
 every terminology and understands every aspect of the memory 
 management and the ins and out.
Personally I programmed intensely in C and assembler from 1983 - 1988 at high school, a little from 1996-1998 and I picked up programming again in 2014. So in the beginning I had no idea why people were so focused on memory because when I learnt to program memory was pretty fast vs CPU and that changed whilst I was doing other things. But I learnt a lot just in a couple of years from being around here - and it wouldn't have been the case in a different community. I don't think it's true that people here look down on you or that they expect you to understand every nuance of memory management. One might feel initially inadequate, yes, but that's what it's like to learn something new. And people may also be a bit short on time - but it's not their responsibility to spend their free time to teach you. It's nice when they do, but it's up to us to teach ourselves using whatever resources we can find.
 Frankly, sometimes i wish i NEVER discovered the forums because 
 seeing some of the discussions and reading the past 
 discussions, it feels like a darn pool of evil. Good, bad and 
 just ugly. It frankly demotivates...
You must be reading different forums from me.
 And it has now **highly** opinionated my attitude about D, to 
 the point that makes me wonder. As a potential employer:

 If i hire people with no D knowledge and they need to learn D. 
 They go to these forums and get sucked into this.
I'm paying people to work in D, and have done since 2015. I personally would never hire someone who would be put off by robust exchanges or who would lack the resourcefulness and ability to tolerate discomfort that everything not being completely shiny (documentation, installation on Windows) would deter them. In fact, I would go further and say that D is a good hiring filter for the very reasons that you find offputting (though you interpret the meaning of things differently from me). And I'm in a different business, most likely, and it may be that at this point the language is a good fit for me and not for some others - that's okay. D isn't for everyone, and it doesn't need to appeal to most people to continue to grow at a stunning pace. It just needs to appeal a little more to those already on the fence or for whom D is a solution to their pain.
 What about easy of learning, issues they may run into. It means 
 time i need to spend teaching new employees to avoid some of 
 the issues mentioned here ( and a lot of past topics that i 
 found ). I do not understand because on other language forums 
 the discussions are more civilized, there seem to be less 
 looking down on people. Maybe i use the Rust argument a bit too 
 much but to be good at Rust a good background is extreme 
 helpful and yet, i do not notice the same attitude with people 
 ask stupid questions or are not happy about something.
Why can't the French be more like the English? Well, because they are French. And it's the same with computer language communities - they each have their own history and culture, and it isn't going to change much to wish things were different from how they are. BTW where people have been harshest here, I see that much more amongst people who are natural technical leaders and have strong opinions on things - that are often thought through and insightful. And I think it's mostly just what you expect to see in a community where people care about technical excellence - they want to do things right and can't stand to see it done wrong. There's going to be a bit more discord if you have people like that, but it will be generative discord, and it's the only way you get to excellence. (Try the kernel mailing list if you doubt me). I don't see much harshness from experienced people towards newcomers, and Walter and Andrei and others are pretty quick to put a stop to that on very rare occasions when it happens.
 standard documentation disaster ( until you discover the 
 library doc )
?
 And please, do not quote my text piece by piece, ripping me a 
 new one for being inflammatory or whatever. Its how I from MY 
 perceptive see things. Just as you, the person reading this 
 will have there own opinion.
Sure, but you must expect people to have different perspectives from you and want to explain why they disagree.
 As for me, i will be looking a bit more into other languages 
 and there communities. For a hobby project D is perfectly fine 
 but as a future employer my standard is much more ridge.
I'd be interested to see what you find. If gentleness is important to you, I do think you will find places that emphasize that more. On the other hand if language quality, versatility, plasticity, readability, productivity are important and it needs to be native code then I am not so sure. One only gets to quality via robust debate, and the nature of electronic communication means that it unavoidably doesn't always stay gentle - that's the price one pays for the benefits of this new form of social organisation.
 I want to hire people first with lower experience ( cheaper ) 
 and let them learn on the job
Fair enough. There's a massive difference in productivity of people - if you can spot the best people then less experienced ones might not be so expensive and they can learn quickly. But hiring people who aren't the best but are cheap is very expensive in the long run. I very much doubt very good people will struggle to learn D, and the doc situation is way better than when I started myself.
 And well ... lets say that my impression has been a mixed 
 experience so far. Especially if this means exposing people 
 with maybe scripting language experience to a compile language 
 like D.
I think that if one only knows a scripting language and has never played with electronics and microprocessors then one has a basic hole in one's knowledge as a programmer. Remedying that will take time (and it's harder for many adults than in childhood), no matter what language you learn next. But that's a fault of the education system and the modern intolerance of discomfort, not D.
 Maybe its time to tidy the ship because first impression count 
 for a lot.
I think you get the fundamentals right first and worry about polishing it in time. Lipstick on a pig - it is still a pig. And I don't think first impressions in the sense you mean count that much, particularly if you have relatively low market share. I mean if people think the language is pretty good but documentation isn't yet good enough they won't write it off forever and will be open to taking another look in two or three years.
Jun 18
prev sibling parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Friday, 16 June 2017 at 06:58:57 UTC, Jacob Carlborg wrote:
 DVM [1] is doing some of this.

 [1] https://github.com/jacob-carlborg/dvm
Might it not be better when some of this is actually part of D? - Multi-version support - Integrated all the tools so editors know/can rely on them. I have seen this topic a few times reading here. - Editor support like half working in a lot of cases - ... There are always tools out there to "fix" some issues with D but Mike does have a point in stating that everything feels fragmented. /++ DMD / LDC are totally different installations. LDC requiring different setup. LDC is frankly the default if you need real performance but the way its developed / published / talked about, its a side project not a main part of D. And because of that LDC feels like it always needs to cache-up to D mainline. Ifs ironic that i needed to use: dub --compiler=C:\D2\bin\ldc2.exe To get ldc to work... If i take a look at Rust ... RustUp great installer, multi platform support, great cross compiling support ( still some issue with dependencies ). Go has the same great cross platform compile support. But D it feels like a struggle to figure out. Why not publishing Dmd and LDC together as one package, one installation, one version. /++ Why is dcd, dfmt, dscanner, not part of the base installation of D??? Webfreak wrote workspace-d and is now writing serve-d to combine code-d and the rest. But its again a side project. Its odd there is no default language server protocol for D and it needs a 3th party developer to implement it and then maintain it outside of D again. So if webfreak gets too busy with life, a breaking change happens in D, there goes the support. Like with many 3th party plugins ... How about file watching, i know there is a D plugin that monitors your directory and allows for recompiling ( most languages have a feature like this ) but again, its 3th party not part of D mainline, despite it being darn handy. D is indeed way too fragmented. Clearly a lot of good developers but the way its handled, it feels like DMD and Phobos are the only focus. And all the rest is side or not integrated. This is just my feeling. And when resources are split like this, it is indeed much more difficult for new users to get going.
Jun 16
parent reply Seb <seb wilzba.ch> writes:
On Friday, 16 June 2017 at 10:12:06 UTC, Wulfklaue wrote:
 On Friday, 16 June 2017 at 06:58:57 UTC, Jacob Carlborg wrote:
 DVM [1] is doing some of this.

 [1] https://github.com/jacob-carlborg/dvm
Might it not be better when some of this is actually part of D?
There is an official D installer for Posix systems that can handle multiple compilers and all versions quite well. IIRC does dvm only support DMD?
 - Multi-version support
 - Integrated all the tools so editors know/can rely on them. I 
 have seen this topic a few times reading here.
I think you are just complaining about Windows. Everything is nicely packaged under Linux, Posix and OSX.
 - Editor support like half working in a lot of cases
The beauty of D is that you don't need a fancy editor.
 - ...

 There are always tools out there to "fix" some issues with D 
 but Mike does have a point in stating that everything feels 
 fragmented.

 /++

 DMD / LDC are totally different installations. LDC requiring 
 different setup.
Really? curl i.dlang.io | bash -s dmd curl i.dlang.io | bash -s dmd-2.072.2 curl i.dlang.io | bash -s dmd-newCTFE curl i.dlang.io | bash -s dmd-nightly curl i.dlang.io | bash -s ldc curl i.dlang.io | bash -s ldc-beta curl i.dlang.io | bash -s ldc-1.1.0 curl i.dlang.io | bash -s gdc
 LDC is frankly the default if you need real performance but the 
 way its developed / published / talked about, its a side 
 project not a main part of D. And because of that LDC feels 
 like it always needs to cache-up to D mainline.
Are there any features between 2.073.2 (latest LDC beta) and 2.074.1 that you actually miss?
 Ifs ironic that i needed to use:

 dub --compiler=C:\D2\bin\ldc2.exe

 To get ldc to work...
--compiler=ldc2 works very well for me.
 If i take a look at Rust ... RustUp great installer, multi 
 platform support, great cross compiling support ( still some 
 issue with dependencies ). Go has the same great cross platform 
 compile support. But D it feels like a struggle to figure out.

 Why not publishing Dmd and LDC together as one package, one 
 installation, one version.
Because the top contributors to DMD are unfamiliar with the LDC codebase. However, there are ongoing efforts to make the frontend accessible as a library.
 /++

 Why is dcd, dfmt, dscanner, not part of the base installation 
 of D???
Because there is a very easy way to fetch & build them since DUB is part of the release: dub fetch dscanner dub build dscanner There is even a DUB API that tools can use. Too complicated?
 Webfreak wrote workspace-d and is now writing serve-d to 
 combine code-d and the rest. But its again a side project. Its 
 odd there is no default language server protocol for D and it 
 needs a 3th party developer to implement it and then maintain 
 it outside of D again.

 So if webfreak gets too busy with life, a breaking change 
 happens in D, there goes the support. Like with many 3th party 
 plugins ...
Don't forget that D is an open source project driven by volunteers.
 How about file watching, i know there is a D plugin that 
 monitors your directory and allows for recompiling ( most 
 languages have a feature like this ) but again, its 3th party 
 not part of D mainline, despite it being darn handy.
Because there's​ only so much that can be in a standard library. It's way to thick imho anyways. What's wrong with using a DUB package? If it is that common to your work, you can add the project to you D include directory.
 D is indeed way too fragmented. Clearly a lot of good 
 developers but the way its handled, it feels like DMD and 
 Phobos are the only focus. And all the rest is side or not 
 integrated. This is just my feeling. And when resources are 
 split like this, it is indeed much more difficult for new users 
 to get going.
Yes because tools come and go whereas a standard library or a package manager stays. With the limited volunteers time there's only so much that can be done. And in your free time, you usually work on problems that are interesting to you?
Jun 16
parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Friday, 16 June 2017 at 10:38:44 UTC, Seb wrote:
 There is an official D installer for Posix systems that can 
 handle multiple compilers and all versions quite well.
 IIRC does dvm only support DMD?
Good for the poxis platform set ... but D is used on more then only linux and osx.
 I think you are just complaining about Windows. Everything is 
 nicely packaged under Linux, Posix and OSX.
And that makes the point wrong? No it does not ...
 The beauty of D is that you don't need a fancy editor.
That is a straw man argument... Every language can be more productive with a editor, especially when people first learn the language. Lets not turn this into a editor/ide vs ... discussion. You got your preference, that is clear by now.
 Really?

 curl i.dlang.io | bash -s dmd
 curl i.dlang.io | bash -s dmd-2.072.2
 curl i.dlang.io | bash -s dmd-newCTFE
 curl i.dlang.io | bash -s dmd-nightly
 curl i.dlang.io | bash -s ldc
 curl i.dlang.io | bash -s ldc-beta
 curl i.dlang.io | bash -s ldc-1.1.0
 curl i.dlang.io | bash -s gdc
Thanks but again besides the point. The Original poster is referring to the experience for new users. Do you expect every user to know Linux commands? Do you expect them to run Linux? The fact that your over emphasizing on this, clearly shows that there is a gap in D there multi-platform support. Thanks for the information. Its useful for me but that is NOT THE POINT!
 Are there any features between 2.073.2 (latest LDC beta) and 
 2.074.1 that you actually miss?
Up to recently Dmd and Ldc used to be much more separated in there future set. And please do tell ... having 2.073.2 vs 2.074.1 version difference may not be a lot but its still not a single platform support. Bugs or issues solved in DMD 2.074.1 can hamper somebody who is cross compiling for production. And visa versa. Is it that difficult to have both versions synchronized and released as one package? Why the push back to even mentioning this.
 --compiler=ldc2 works very well for me.
Nice to know, yet, that did not work in my case and it needed the path.
 Because the top contributors to DMD are unfamiliar with the LDC 
 codebase. However, there are ongoing efforts to make the 
 frontend accessible as a library.
Good to know...
 Because there is a very easy way to fetch & build them since 
 DUB is part of the release:

 dub fetch dscanner
 dub build dscanner
Again, this is straw man argumentation. This assumes knowledge of dub, knowledge of the tools used, it assume the editor can interact and find the builds. And frankly, running it like that also pollutes a project ( seen it, done it, got the medal ). Read the freaking original poster his text. He is frustrated that for new users, maybe people with little to no background D is simply a mess. I pointed out that Rust and Go are WAY more easy to setup everything and interact with advanced features because they integrated a lot more. And on a side note: There is nothing more fun as running into a bug with dfmt or some other third party plugin because a change that happened in dmd. Example: latest DMD, a change happened, plugin does not compile. Now please do tell how a totally new user will find his way around? They will post here, get some crispy comment and maybe leave. Or hell, they may not even post here.
 Don't forget that D is an open source project driven by 
 volunteers.
So do you and every other person remind the people who point out issues. And the point is? Well, its all volunteer project so never expect a improvement until somebody wants to fix it. Strange because Rust is highly volunteer based and yet they have a more coherent structure. So why is that? Now that is a good question...
 Because there's​ only so much that can be in a standard 
 library. It's way to thick imho anyways. What's wrong with 
 using a DUB package?
What i am talking about is not part of the standard library, hell, it has nothing to do with the library at all. Its part of the standard tool set. Total different things...
 If it is that common to your work, you can add the project to 
 you D include directory.
Again ... very, VERY unclear how and what is possible in D. Sure, i can figure it things out but it takes time. And the next guy also needs to put time into this. And the next guy...
 Yes because tools come and go whereas a standard library or a 
 package manager stays. With the limited volunteers time there's 
 only so much that can be done.
 And in your free time, you usually work on problems that are 
 interesting to you?
Maybe that is the same reason why D has a issue drawing in new non-C/C++ developers? Maybe because too many people live in there high tower assuming its easy for everybody else. And no offense but some responses here feel like: "Hey somebody pointed out a problem. Lets jump on this person for pointing it out". I am already seeing the arguments that D is all about volunteers and the push back. "Hey, D is all volunteers. Why do you not do it. Well, if you do not do it, it will never happen". And round and round that discussion goes. On Friday, 16 June 2017 at 10:55:04 UTC, Moritz Maxeiner wrote:
 Everything *I* need works well enough (and I'm fairly convinced 
 it is the same for the majority of D users, though that is 
 speculation). If you want something fixed, do it yourself or 
 pay someone to do it.
Well, i do not have the time. Want me to donate? Does that solve the issue. No ... because there is no clear infrastructure in place to actually hire people to work on the language and the environment. Pointless to even mention this, it like all the other discussions like this. People mention issue. Blow back. Heated discussions. And the people who complain give up. Those that point fingers continue living in there bubble and ... nothing changes or improves. I do not have a issue donating money. In the process of setting up a company and maybe can support D from that angle. But i do have a issue when people react like this whenever people with good intention get blow back. The original poster his topic title is a bad choice but his points are not. Just reading the history on the mail group and you see so many time the same issues. And the exact same responses. And the exact same nothing happening because people give up. D for me works but i like to see D also grow. When D grows, it means the language will get longer support. A bigger community is more resources. Win win for everybody. But for some reason i can not help to feel that some people are almost against this, the attitude here simply STINKS when it comes down to issues. The whole "it works for me, so how dare you complain" is really demotivating and frankly scares people away. Hey, it works for me "not dumb dumb" but its the wast of time figuring out things that are much more easy in other languages. But that also means anybody coming with limited programming knowledge or no linux knowledge and wants to do more then a "hello world", will run into the exact time wasting issues. But please, do shoot the messengers. Like that will help. I am already far into my project with D but at the same time i can not help getting this nagging feeling that D has major issues beyond its base language. Mostly its community and structure. I see less of this with for instance Rust despite being a WAY younger language and audience. Its almost like D is stuck in the past, in some kind of pre-2000 C++ attitude. Like i said, maybe its me. D as a base language works but for such a old language ( lets be honest about that ), its a real struggle on the other areas beyond the language.
Jun 16
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 16 June 2017 at 11:50:20 UTC, Wulfklaue wrote:
 On Friday, 16 June 2017 at 10:55:04 UTC, Moritz Maxeiner wrote:
 Everything *I* need works well enough (and I'm fairly 
 convinced it is the same for the majority of D users, though 
 that is speculation). If you want something fixed, do it 
 yourself or pay someone to do it.
Well, i do not have the time.
Then hire someone.
 Want me to donate?
Straw man. Donations are not the same as paying for a specific service (i.e. no contractual obligations).
 Does that solve the issue.
Yes.
 No ... because there is no clear infrastructure in place to 
 actually hire people to work on the language and the 
 environment.
Claiming a solution does not work because it's hard to use does not help your cause. If you are interested in donations, there is such infrastructure, it's called the D Foundation. If you are interested in contract work, you are correct, there is no such infrastructure; however, there not being a ready made infrastructure for hiring does not preclude you from finding someone yourself, e.g. through the accounce newsgroup.
 Pointless to even mention this, it like all the other 
 discussions like this. People mention issue. Blow back. Heated 
 discussions. And the people who complain give up. Those that 
 point fingers continue living in there bubble and ... nothing 
 changes or improves.
You are deliberately inflaming a previously neutral subthread with hyperboles and a personal attack. The matter remains simple: If you (or anyone else) has an issue, it's good (as I stated) to raise awareness for it; but if you want something done and don't want (or can't) do it yourself, you have to either convince someone else that your time is worth more than theirs, or you have to pay someone to deal with it.
 I do not have a issue donating money. In the process of setting 
 up a company and maybe can support D from that angle. But i do 
 have a issue when people react like this whenever people with 
 good intention get blow back.
Again, you are deliberately using inflammatory speech against someone who has given the OP a rational response as to why I think doing *only* this won't help his cause.
 The original poster his topic title is a bad choice but his 
 points are not.
Straw man. I never said anything on those points.
 Just reading the history on the mail group and you see so many 
 time the same issues.
In the very post of mine you quote I write about stating this every time these kinds of issues pop up (which strongly implies that it does so not rarely).
 And the exact same responses.
I'm not sure why that bothers you. It would be strange to me for the same kind of issue in the same context to receive a different response.
 And the exact same nothing happening because people give up.
That is the crux of having limited human resources in a volunteer project.
 [...] But for some reason i can not help to feel that some 
 people are almost against this, the attitude here simply STINKS 
 when it comes down to issues. The whole "it works for me, so 
 how dare you complain" is really demotivating and frankly 
 scares people away.
This is the third time you are being intentionally inflammatory in a previously neutral correspondence, even utterly twisting my post into something that simply is not there. What I wrote boils down to "It works for me, so don't expect me to fix it for you for free. I think it is the same for most others here". If that is demotivating to you, I am forced to wonder if you consider your time objectively worth more than that of others.
 Hey, it works for me "not dumb dumb" but its the wast of time 
 figuring out things that are much more easy in other languages.
Fourth time you are being inflammatory, even going as far as completely inventing statements I have not made.
 But that also means anybody coming with limited programming 
 knowledge or no linux knowledge and wants to do more then a 
 "hello world", will run into the exact time wasting issues.
And if that bothers you enough to take action, your courses are *still* the following: - Do the work yourself - Hire someone to do the work - Convince someone that their time is better spend on dealing with this than on whatever it is that interests them
 But please, do shoot the messengers. Like that will help.
Fifth time you are being intentionally inflammatory and trying to twist my post. I informed the OP that I think it unlikely this will convince someone to choose to spend their free time on this, than on something else. It boggles my mind how you could possibly twist that into "shooting the messengers".
 I am already far into my project with D but at the same time i 
 can not help getting this nagging feeling that D has major 
 issues beyond its base language. Mostly its community and 
 structure. I see less of this with for instance Rust despite 
 being a WAY younger language and audience. Its almost like D is 
 stuck in the past, in some kind of pre-2000 C++ attitude.
No, it's almost like Rust has a global player with its software on a significant share of human interfaceable internet devices rigorously pushing for it, pouring time, money, and a huge preexisting viral fan base into it. Like the Mozilla foundation.
 Like i said, maybe its me. D as a base language works but for 
 such a old language ( lets be honest about that ), its a real 
 struggle on the other areas beyond the language.
Age of a PL (beyond some initial dev time) has little effect on the viability of its ecosystem. An even if, while D1 dates to around 2001, and Rust to around 2010 (which is not a particularly long time in the first place when compared to the competitors C and C++), D2 (which due to it's several deep changes can be considered a different language) dates to around 2007, which is a negligible difference to Rust.
Jun 16
next sibling parent reply Wulfklaue <wulfklaue wulfklaue.com> writes:
On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote:
 Fifth time you are being intentionally inflammatory and trying 
 to twist my post.
Well, i am sorry that you see it all as intentionally inflammatory. You might have noticed that after responding to you, my post was more general. Not person specific. My apology to you for the misunderstanding. I will not post about this anymore. No point wasting anybody there time. Its not like anything is going to change anyway, that much is now clear to me.
Jun 16
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 16 June 2017 at 13:54:54 UTC, Wulfklaue wrote:
 On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote:
 Fifth time you are being intentionally inflammatory and trying 
 to twist my post.
Well, i am sorry that you see it all as intentionally inflammatory.
Only those specific instances where you used expressions designed to elicit an emotional response.
 You might have noticed that after responding to you, my post 
 was more general. Not person specific. My apology to you for 
 the misunderstanding.
The trouble is that you replied to two different people in the same post (this is btw not very well supported by newsgroups, for which the forum is a frontend) and even after becoming more general kept referring to points I made in my post.
 I will not post about this anymore.
That is your choice, though I fail to see why you think you shouldn't. I think you should keep reporting such issues in the ecosystem, since without that there is indeed no way they are ever going to be dealt with. It's just that reporting in and of itself does not guarantee a fix with our current human resources. If you want such a guarantee, it's on you to convince someone (be that yourself or someone else) to do it.
 No point wasting anybody there time. Its not like anything is 
 going to change anyway, that much is now clear to me.
It shouldn't, because it's not the case. The ecosystem is being worked on, albeit slowly. No progress != slow progress.
Jun 16
prev sibling parent reply Mark <smarksc gmail.com> writes:
On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote:
 If you are interested in donations, there is such 
 infrastructure, it's called the D Foundation.
I imagine that it's not possible to make donations to the foundation that are restricted for the use of advancing a specific aspect of the language (e.g. tooling). I don't know if anyone is looking at the state of the ecosystem from the persepctive of a corporation considering whether or not to use D for some project. Of course, such a perspective is immaterial if there is little community interest in corporate adaption of D...
Jun 17
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 17 June 2017 at 22:57:46 UTC, Mark wrote:
 On Friday, 16 June 2017 at 13:14:46 UTC, Moritz Maxeiner wrote:
 If you are interested in donations, there is such 
 infrastructure, it's called the D Foundation.
I imagine that it's not possible to make donations to the foundation that are restricted for the use of advancing a specific aspect of the language (e.g. tooling).
IANAL, but if you tie a monetary exchange to a specific service, it's not a donation, but payment for services (to be) rendered.
 I don't know if anyone is looking at the state of the ecosystem 
 from the persepctive of a corporation considering whether or 
 not to use D for some project.
I would imagine the people at Sociomantic do.
 Of course, such a perspective is immaterial if there is little 
 community interest in corporate adaption of D...
People who work on/with something in their free time for their own purposes are imho (rightfully) unlikely to care about catering to third party corporate interests.
Jun 17
parent Mark <smarksc gmail.com> writes:
On Saturday, 17 June 2017 at 23:14:24 UTC, Moritz Maxeiner wrote:
 IANAL, but if you tie a monetary exchange to a specific 
 service, it's not a donation, but payment for services (to be) 
 rendered.
Good point.
 People who work on/with something in their free time for their 
 own purposes are imho (rightfully) unlikely to care about 
 catering to third party corporate interests.
Okay. Fair enough.
Jun 17
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 16 June 2017 at 11:50:20 UTC, Wulfklaue wrote:

 I am already far into my project with D but at the same time i 
 can not help getting this nagging feeling that D has major 
 issues beyond its base language. Mostly its community and 
 structure. I see less of this with for instance Rust despite 
 being a WAY younger language and audience. Its almost like D is 
 stuck in the past, in some kind of pre-2000 C++ attitude. Like 
 i said, maybe its me. D as a base language works but for such a 
 old language ( lets be honest about that ), its a real struggle 
 on the other areas beyond the language.
We don't notice the rivers carving the canyons in our brief lifespans, so would never know that it happened without some point of reference in the past to compare to. While D's progress doesn't move at such a glacial pace (thankfully!), it still won't be very noticeable to someone who hasn't been around here long enough. If you could move your point of reference back in time a bit, you'd know that a great deal of progress has been made. That doesn't mean that such complaints aren't valid and shouldn't be raised, but it's nice to have some perspective to moderate your expectations. Progress *is* being made. The volunteer argument keeps coming up because that *is* the reality. There's no one around here who can snap their fingers and get a team of people to put their heads down and make improvements on a daily basis. Rust and Go, however, do have that benefit. So we move forward, bit-by-bit, slowly but surely. I've been using D and coming to these forums since 2003 (and, by the way, using DMD on Windows without a hitch for all that time) and I can point to many periods in the intervening years when we passed major milestones. There used to be no IDE plugins at all. No installers. DMD was distributed in a single zip for all platforms. We had no build tools, no DUB, no web frameworks, a substandard standard library, a clunky web interface for the newsgroups... So please, don't take your snapshot view of the current state of affairs and take that as evidence that the rivers aren't carving the canyons, because they very much are.
Jun 16
prev sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Friday, 16 June 2017 at 11:50:20 UTC, Wulfklaue wrote:
 Maybe that is the same reason why D has a issue drawing in new 
 non-C/C++ developers?
What's your evidence for this? I'm curious. Not that the composition of new adopters matters particularly - it's just interesting to know.
 Well, i do not have the time. Want me to donate? Does that 
 solve the issue. No ... because there is no clear 
 infrastructure in place to actually hire people to work on the 
 language and the environment.
If you're serious, put up some money and maybe I can match it (and there is a decent chance one or two other larger commercial users might contribute also). One doesn't need much infrastructure to organise things, BTW. I have a private gitlab instance and a way to pay people and we're already trying to make the ecosystem a better in modest ways - for example we have already contributed back our internal changes on our own fork to dub.
Jun 18
prev sibling next sibling parent lobo <swamplobo gmail.com> writes:
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 Seriously! D is starting to gain momentum and if things are not 
 stabilized it's going to slow D down.

 [...]
I don't know what is so hard about tar -zxvf dmd.XYZ.tar.xz or unzip dmd.XYZ.zip. Am I missing something? Perhaps rather than developing a wall of text maybe you could spend the time and energy learning how to compile and link code using an actual compiler instead of an IDE framework. You would then have the skills to use D anywhere with/without the flavour of the month IDE. bye, lobo
Jun 16
prev sibling next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 When a new user goes to start using D for the first time, D is 
 a PITA to get working! Don't believe me?!?!

 Just try getting D installed on all 3 major systems for DMD, 
 LDC, GDC, with an IDE, some utilities, possibly arm 
 support(even though it's new and expected to have some issues), 
 etc. The issues really start popping up when you are trying to 
 use x86 + x64. Library issues that result in strange error 
 messages instead of "This compiler is not compatible with the 
 phobos v2.4324".

 And guess what? This happens to regular users too! They either. 
 A) know how to fix them from fixing them in the past or helping 
 others(so it doesn't count because the problem still exists) or 
 B) have a specific setup that happens to avoid the major 
 issues(e.g., just use linux x86) then act like there isn't any 
 problems with D.

 But no one wants to work on the part of D that deals with these 
 problems cause it's boring and most "experts" can deal with the 
 problems in a few mins to a few hours... doesn't seem like a 
 huge waste of time(even though it is, since it's a waste).
I'm going to summarize this as "D has issues that aren't likely to be worked on any time soon by the core team". It boils down the following (and I write this every time I see this gets posted): People working on (and with) D for free are already invested in things they are interested in. Your choices are - Invest time to work on these yourself (-> directly leads to results) - Pay someone to work on these (-> should directly lead to results unless you get swindled) - Write about it here (-> raise awareness, may lead to results, but unlikely) While I can understand your frustration (and share it for a couple of issues) and raising awareness for issues is a good thing, the third of these options is (historically speaking) unlikely to yield results by itself in this community as people's time is limited. If you want these issues dealt with, go with option one or two.
 D needs to just work! Library errors, setup problems, IDE 
 integration should just work! It seems the changes of it 
 working are about 75-85%... that IS LOW! It should be 99%. (And 
 I'm talking across the board)
Everything *I* need works well enough (and I'm fairly convinced it is the same for the majority of D users, though that is speculation). If you want something fixed, do it yourself or pay someone to do it.
Jun 16
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 Seriously! D is starting to gain momentum and if things are not 
 stabilized it's going to slow D down.

 [...]
All decent ideas- except for the bit about D1, as it has been deprecated- but obviously nobody has been willing to work on adding such fit and finish. If you believe someone should volunteer their time to work on this, the obvious question is why don't you do it? If you think there is a market for paid support that includes such polish, you could charge for it. On the other hand, maybe D is not meant for the kind of user who needs such an easy path. What does it matter if you set D up really easily and then can't grasp such a sprawling, lower-level language? Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D. I don't have a strong opinion on that, just making an observation. It works well for me, and having a long history of using OSS projects that are _much_ worse to set up, I can't complain. :)
Jun 16
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 16 June 2017 at 13:30:21 UTC, Joakim wrote:
 On the other hand, maybe D is not meant for the kind of user 
 who needs such an easy path.  What does it matter if you set D 
 up really easily and then can't grasp such a sprawling, 
 lower-level language?  Perhaps _this_ is the right packaging 
 for D right now, to keep away the kinds of casual users who 
 would not be suited for D.
Today I agree with that, but in 1-2 years when mir/lubeck are in better shape I'm probably going to disagree. Hoping someone packages something together like an Anaconda for D that just easily works.
Jun 16
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Friday, 16 June 2017 at 14:40:42 UTC, jmh530 wrote:
 On Friday, 16 June 2017 at 13:30:21 UTC, Joakim wrote:
 On the other hand, maybe D is not meant for the kind of user 
 who needs such an easy path.  What does it matter if you set D 
 up really easily and then can't grasp such a sprawling, 
 lower-level language?  Perhaps _this_ is the right packaging 
 for D right now, to keep away the kinds of casual users who 
 would not be suited for D.
Today I agree with that, but in 1-2 years when mir/lubeck are in better shape I'm probably going to disagree. Hoping someone packages something together like an Anaconda for D that just easily works.
What's missing from Lubeck that you would like to see? Wrt Anaconda for D - it's the native code (C) libraries that are the biggest pain point. Same thing as with Python really. So I wonder if we could figure out a way to host build configuration and build itself for the C libraries underlying dub bindings and wrappers. It's really a Windows-specific problem, because even today there doesn't seem to be a great answer. I played with chocolatey a bit, but it doesn't always seem to be that helpful in practice.
Jun 18
next sibling parent Seb <seb wilzba.ch> writes:
On Sunday, 18 June 2017 at 21:53:35 UTC, Laeeth Isharc wrote:
 Wrt Anaconda for D - it's the native code (C) libraries that 
 are the biggest pain point.  Same thing as with Python really.

 So I wonder if we could figure out a way to host build 
 configuration and build itself for the C libraries underlying 
 dub bindings and wrappers.
Sometimes it can be a problem on Linux / OS X as well, especially if one wants to link to little known C/C++ libraries, e.g. libnoise for the DREPL. There is a DEP about it: https://github.com/dlang/dub/wiki/DEP5
Jun 18
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 18 June 2017 at 21:53:35 UTC, Laeeth Isharc wrote:
 What's missing from Lubeck that you would like to see?
I don't have an issue with missing functions at this point. I just hope that we can get some operator overloading so that I don't have to write mtimes all over the place. My ideal would be a DIP that adds the option to overload opBinary for \, .+, .-, .*, ./. Lubeck could use \ for inverse, .+ etc. for element-wise matrix operations, and * for mtimes, etc. Very Matlab-like.
 Wrt Anaconda for D - it's the native code (C) libraries that 
 are the biggest pain point.  Same thing as with Python really.
Wrt to my post above, I had forgotten that I made the point about anaconda already. Long weekend away.
 So I wonder if we could figure out a way to host build 
 configuration and build itself for the C libraries underlying 
 dub bindings and wrappers.  It's really a Windows-specific 
 problem, because even today there doesn't seem to be a great 
 answer.  I played with chocolatey a bit, but it doesn't always 
 seem to be that helpful in practice.
Sounds like something to think about.
Jun 19
parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Monday, 19 June 2017 at 12:46:19 UTC, jmh530 wrote:
 I just hope that we can get some operator overloading so that I 
 don't have to write mtimes all over the place. My ideal would 
 be a DIP that adds the option to overload opBinary for \, .+, 
 .-, .*, ./. Lubeck could use \ for inverse, .+ etc. for 
 element-wise matrix operations, and * for mtimes, etc. Very 
 Matlab-like.
I'd like to second more flexibility around unary and binary operators, perhaps we can have another keyword for instance "record" that is essentially a D struct but allows the user to specify their own operators - it could be included unofficially at first without impacting the rest of the D language with the stipulation that it is not used in D's core libraries or in anything important. This functionality would allow notation native to different fields in analysis to be used.
Jun 21
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 21 June 2017 at 18:35:33 UTC, data pulverizer wrote:
 On Monday, 19 June 2017 at 12:46:19 UTC, jmh530 wrote:
 I just hope that we can get some operator overloading so that 
 I don't have to write mtimes all over the place. My ideal 
 would be a DIP that adds the option to overload opBinary for 
 \, .+, .-, .*, ./. Lubeck could use \ for inverse, .+ etc. for 
 element-wise matrix operations, and * for mtimes, etc. Very 
 Matlab-like.
I double-checked and noticed that Matlab doesn't actually have .+/.-, just +/-. Since D's a[] + b[] doesn't seem all that different from Matlab's a + b, with the restriction that there needs to be destination memory, it seems like it would be a confusing to add in another way of doing things. So maybe just add \ and another operator for matrix multiplication. I don't really know.
 I'd like to second more flexibility around unary and binary 
 operators, perhaps we can have another keyword for instance 
 "record" that is essentially a D struct but allows the user to 
 specify their own operators - it could be included unofficially 
 at first without impacting the rest of the D language with the 
 stipulation that it is not used in D's core libraries or in 
 anything important. This functionality would allow notation 
 native to different fields in analysis to be used.
An interesting idea, but I don't know if they would go to for it. If you want more operator overloading on a class, you could put the class as a member of the "record" and alias this it?
Jun 21
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 D needs to just work!
I think that D is quickly gaining increasingly picky and demanding users because it's breaking out in the general programmer population. Not all of these programmers have used C++ and perhaps have higher expectations when it comes to "just work". If you look at the complaints from 8 years ago (where ragequitting D was more common), everyone of their points have be adressed, and most things have improved. Perhaps complaints are poised to get higher in intensity precisely because things have become better ;)
Jun 16
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2017-06-16 at 15:08 +0000, Guillaume Piolat via Digitalmars-d
wrote:
 On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 D needs to just work!
=20 =20 I think that D is quickly gaining increasingly picky and=20 demanding users because it's breaking out in the general=20 programmer population. =20 Not all of these programmers have used C++ and perhaps have=20 higher expectations when it comes to "just work". =20 If you look at the complaints from 8 years ago (where=20 ragequitting D was more common), everyone of their points have be=20 adressed, and most things have improved. =20 Perhaps complaints are poised to get higher in intensity=20 precisely because things have become better ;) =20
The corollary is that The D Foundation has to make sure the D experience (DMD, RDMD, LDC, LDMD, GDC, GDMD, Dub, etc.) works out of the box, either with a downloader or a Chocolatey package on Windows; downloader, MacPorts and Homebrew on MacOS, and packaging for Debian, Fedora, Arch, OpenBSD, FreeBSD, etc. Most of it is there, but it isn't as slick an experience as say Rust and Go. It about being a good and proactive downstream for all the packaging systems (which is mostly there) and having good installers where needed, mostly there. I suspect a big part of the difficulty is resources, but it is also having three tool chains. Clearly Rust and Go have people paid (directly or indirectly) to deal with front of house, customer facing stuff. D has some volunteers most of whom are back office, just want to get on with code please type people. If it is true that there is increased traction for D, then getting some resource into the front of house stuff will be critical to that traction fading and disappearing. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 16
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 16 June 2017 at 15:47:15 UTC, Russel Winder wrote:
 If it is true that there is increased traction for D, then 
 getting some resource into the front of house stuff will be 
 critical to that traction fading and disappearing.
Yes, daily downloads of dmd are up 25-30% this year: http://erdani.com/d/downloads.daily.png
Jun 16
parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Friday, 16 June 2017 at 15:54:36 UTC, Joakim wrote:
 On Friday, 16 June 2017 at 15:47:15 UTC, Russel Winder wrote:
 If it is true that there is increased traction for D, then 
 getting some resource into the front of house stuff will be 
 critical to that traction fading and disappearing.
Yes, daily downloads of dmd are up 25-30% this year: http://erdani.com/d/downloads.daily.png
" But when will D take off. There are no jobs in D. D hasn't taken off yet so it won't etc etc. "
Jun 18
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-06-16 17:47, Russel Winder via Digitalmars-d wrote:

 Most of it is there, but it isn't as slick an experience as say Rust
 and Go. It about being a good and proactive downstream for all the
 packaging systems (which is mostly there) and having good installers
 where needed, mostly there. I suspect a big part of the difficulty is
 resources, but it is also having three tool chains. Clearly Rust and Go
 have people paid (directly or indirectly) to deal with front of house,
 customer facing stuff. D has some volunteers most of whom are back
 office, just want to get on with code please type people.
Also, IIRC, Go uses its own tool chain, i.e. not relying on system compiler and linker. This can help as well since you have more control over the tool chain. -- /Jacob Carlborg
Jun 16
prev sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2017-06-16 at 16:47 +0100, Russel Winder wrote:
=20
[=E2=80=A6]
 If it is true that there is increased traction for D, then getting
 some
 resource into the front of house stuff will be critical to that
 traction fading and disappearing.
s/to that/to avoid that/ --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 16
prev sibling next sibling parent reply Sebastien Alaiwan <ace17 free.fr> writes:
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 When a new user goes to start using D for the first time, D is 
 a PITA to get working! Don't believe me?!?!
I'm running Debian GNU/Linux (testing). Here's the installation process for the 3 major D compilers. $ apt install gdc $ gdc my_first_program.d GDC is too old for you? Fine, let's use ldc: $ apt install ldc $ ldc2 my_first_program.d Or if you want the bleeding edge version of D: (download dmd .deb package from dlang.org) $ dpkg -i dmd_*******.deb $ rdmd my_first_program.d Debian maintainers, one word: Thank you!
Jun 17
next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2017-06-17 at 08:27 +0000, Sebastien Alaiwan via Digitalmars-d
wrote:
 On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 When a new user goes to start using D for the first time, D is=20
 a PITA to get working! Don't believe me?!?!
=20 I'm running Debian GNU/Linux (testing). Here's the installation=20 process for the 3 major D compilers. =20 $ apt install gdc $ gdc my_first_program.d
Or use aptitude, which I believe remains the Debian preferred high- level tool.
 GDC is too old for you? Fine, let's use ldc:
=20
 $ apt install ldc
 $ ldc2 my_first_program.d
Definitely, caveat aptitude.
 Or if you want the bleeding edge version of D:
=20
 (download dmd .deb package from dlang.org)
 $ dpkg -i dmd_*******.deb
 $ rdmd my_first_program.d
I wonder if it is better to use the d-apt repository for DMD rather than downloading. Downloading is always a pain for updating packages. http://d-apt.sourceforge.net/ OK so it is on SourceForge, but it does work.
 Debian maintainers, one word: Thank you!
That's two words. :-) --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jun 17
prev sibling parent Mike B Johnson <Mikey Ikes.com> writes:
On Saturday, 17 June 2017 at 08:27:33 UTC, Sebastien Alaiwan 
wrote:
 On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 When a new user goes to start using D for the first time, D is 
 a PITA to get working! Don't believe me?!?!
I'm running Debian GNU/Linux (testing). Here's the installation process for the 3 major D compilers. $ apt install gdc $ gdc my_first_program.d GDC is too old for you? Fine, let's use ldc: $ apt install ldc $ ldc2 my_first_program.d Or if you want the bleeding edge version of D: (download dmd .deb package from dlang.org) $ dpkg -i dmd_*******.deb $ rdmd my_first_program.d Debian maintainers, one word: Thank you!
Sorry, doesn't help me or people in general. Also, simple examples are not proof that the solutions are general. It may be that easy on linux or it may not be, but it's definitely not that case on windows FOR almost ALL installations.
Jun 17
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 Just try getting D installed on all 3 major systems for DMD, 
 LDC, GDC, with an IDE, some utilities, possibly arm 
 support(even though it's new and expected to have some issues), 
 etc. The issues really start popping up when you are trying to 
 use x86 + x64. Library issues that result in strange error 
 messages instead of "This compiler is not compatible with the 
 phobos v2.4324".
Might be worth considering something like the Android SDK installer. It looked like this: http://cache.filehippo.com/img/ex/4515__android_sdk_1_8_5_15.png Essentially it was a cross-platform package manager GUI, which allowed installing platform support for various platform versions side-by-side, as well as additional utilities and dependencies. It also exposed its functionality via command-line tools and IDE integrations. This translates fairly well to the D ecosystem, and could serve as a decent work-around for Windows' lack of native package management. We have some of the pieces as separate tools (Digger, DVM, the dlang.org/install.sh script, the Windows' installer's Visual Studio detection/integration), could be nice tying them together into a palatable GUI. Digger has a rudimentary one, which probably could be wrapped into a native-like app using Electron, but still lacking features such as managing GDC/LDC.
Jun 18
next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 18 June 2017 at 15:47:34 UTC, Vladimir Panteleev wrote:
 On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 Just try getting D installed on all 3 major systems for DMD, 
 LDC, GDC, with an IDE, some utilities, possibly arm 
 support(even though it's new and expected to have some 
 issues), etc. The issues really start popping up when you are 
 trying to use x86 + x64. Library issues that result in strange 
 error messages instead of "This compiler is not compatible 
 with the phobos v2.4324".
Might be worth considering something like the Android SDK installer. It looked like this: http://cache.filehippo.com/img/ex/4515__android_sdk_1_8_5_15.png Essentially it was a cross-platform package manager GUI, which allowed installing platform support for various platform versions side-by-side, as well as additional utilities and dependencies. It also exposed its functionality via command-line tools and IDE integrations. This translates fairly well to the D ecosystem, and could serve as a decent work-around for Windows' lack of native package management. We have some of the pieces as separate tools (Digger, DVM, the dlang.org/install.sh script, the Windows' installer's Visual Studio detection/integration), could be nice tying them together into a palatable GUI. Digger has a rudimentary one, which probably could be wrapped into a native-like app using Electron, but still lacking features such as managing GDC/LDC.
Digger is great, as is the Windows installer, and I appreciate the work that has gone into them. Sadly though in the current year we have been ruined by everything being made easy for us - personally I have no problem taking things apart to get to the bottom of a problem when it doesn't work, but in the business world that is not universally true, alas. So I think what lets us down sometimes is tiny little things that maybe aren't complicated to fix, but are maybe a bit specific. For example it's not so easy to build 64 bit dmd on Windows from the command line (and I don't understand why we don't distribute a binary). Or the installer somehow doesn't seem to work with VS 2015 and I haven't even had the time to figure out what the problem is because it's not on my machine and I don't develop much on Windows at all myself. Having a tsar of ergonomics or user experience might be something valuable. Not really a tsar, but just someone to co-ordinate improvement of those little frictions that one doesn't even notice after using D for a while, but that are a big impediment to a newcomer. I mean you could sit with someone new to the language and see what they struggle with, or do it remotely and chat every week. You would learn a lot that way. It doesn't need to be an expensive resource - an intern could do that. The culture is shaped a bit by C/C++ world, but actually I disagree with Joakim that D is a low-level language. I don't really use it that way myself, and others before me - including Liran at Weka (who is pretty low-level when he needs to be) - have observed that D has qualities of a compiled Python. And people who use it like the latter are a bit accustomed to comfort, and so it's a bit of a shock when for exaple someone comes from C# or Python on Windows and wants to install zeromq and realises (or worse, doesn't) they have to build the C library themselves on Windows when they never even heard of cmake before. This was a real example, and the person grumbled that D was a lousy language for that reason... It's also true that an excessive love of comfort is a civilisation-killer, and I think that's one of the strengths of the community - that people who persist are those who aren't put off by things being a bit difficult in the beginning - but perhaps its a matter of balance, and one could think about how to make the experience a bit easier. (Yes, I realise that even today, Windows native code library management is a problem - I just use that as an example).
Jun 18
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 18 June 2017 at 21:02:40 UTC, Laeeth Isharc wrote:
 The culture is shaped a bit by C/C++ world, but actually I 
 disagree with Joakim that D is a low-level language.  I don't 
 really use it that way myself, and others before me - including 
 Liran at Weka (who is pretty low-level when he needs to be) - 
 have observed that D has qualities of a compiled Python.  And 
 people who use it like the latter are a bit accustomed to 
 comfort, and so it's a bit of a shock when for exaple someone 
 comes from C# or Python on Windows and wants to install zeromq 
 and realises (or worse, doesn't) they have to build the C 
 library themselves on Windows when they never even heard of 
 cmake before.
I think there is scope for a D version of something like anaconda for python. The easier it is to get users up and running, the better.
Jun 19
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2017-06-19 at 12:36 +0000, jmh530 via Digitalmars-d wrote:
 [=E2=80=A6]
=20
 I think there is scope for a D version of something like anaconda=20
 for python. The easier it is to get users up and running, the=20
 better.
I'd say the Dub repository is this, or at least should be at least the basi= s for it. Ceylon has Herd, JVM languages otherwise has Maven Central and JCenter, C++ now has Conan. However, I think Cargo for Rust is current the technology leader in mixing a curated central repository. Dub could usefull= y be split into two a curated part where stuff gets removed as well as added, with review and possible rejection before adding, and a free for all sectio= n from which is never lost and can be added to freely. Cargo and Ceylon effectively have this. The trick is not to actually have a free for all added bit (a la PyPI) but to allow for DVCS accessed packages. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.winder ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder
Jun 19
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 19 June 2017 at 13:36:01 UTC, Russel Winder wrote:
 I'd say the Dub repository is this, or at least should be at 
 least the basis for it. Ceylon has Herd, JVM languages 
 otherwise has Maven Central and JCenter, C++ now has Conan. 
 However, I think Cargo for Rust is current the technology 
 leader in mixing a curated central repository. Dub could 
 usefully be split into two a curated part where stuff gets 
 removed as well as added, with review and possible rejection 
 before adding, and a free for all section from which is never 
 lost and can be added to freely. Cargo and Ceylon effectively 
 have this. The trick is not to actually have a free for all 
 added bit (a la PyPI) but to allow for DVCS accessed packages.
dub is more like conda, Anaconda's package manager. What I mean is one thing that someone can download and install one file and everything just works. For instance, one download and a (Windows) user has DMD/LDC/DUB, DlangScience/Mir/Lubeck, and some of the database and plotting libraries installed. Basically, reduce the amount of time for a Python/R/Matlab user to get up and running on D. Would help get new users.
Jun 19
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 2017-06-19 at 14:43 +0000, jmh530 via Digitalmars-d wrote:
=20
[=E2=80=A6]
 dub is more like conda, Anaconda's package manager.
Good point. Also I should separate dub the executable from Dub the repository of stuff more carefully.
 What I mean is one thing that someone can download and install=20
 one file and everything just works. For instance, one download=20
 and a (Windows) user has DMD/LDC/DUB, DlangScience/Mir/Lubeck,=20
 and some of the database and plotting libraries installed.=20
 Basically, reduce the amount of time for a Python/R/Matlab user=20
 to get up and running on D. Would help get new users.
Continuum Analytics do a great job with Anaconda/Miniconda but they have an income stream against which they can post the costs of the people and equipment to keep it working and up to date. Dub, both executable and repository, seem to have a little volunteer labour, and hence maintenance i= s not reliable, in the sense of there is no guarantee effort can be put into it. But yes, I'd say putting effort into something like Anaconda/Miniconda for = D and it's packages would be a good idea. I am guessing extending dub so that when it downloads and builds executables, it can also install them in a platform specific way. For the package managed platforms by building a local package and installing it? I am guessing the next step would be packaging dmd, rdmd, ldc2, and gdc? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.winder ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder
Jun 20
prev sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Sunday, 18 June 2017 at 15:47:34 UTC, Vladimir Panteleev wrote:
 On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
 Just try getting D installed on all 3 major systems for DMD, 
 LDC, GDC, with an IDE, some utilities, possibly arm 
 support(even though it's new and expected to have some 
 issues), etc. The issues really start popping up when you are 
 trying to use x86 + x64. Library issues that result in strange 
 error messages instead of "This compiler is not compatible 
 with the phobos v2.4324".
Might be worth considering something like the Android SDK installer. It looked like this: http://cache.filehippo.com/img/ex/4515__android_sdk_1_8_5_15.png
+1
Jun 19