www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Lost a new commercial user this week :(

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
Sadly, I failed to create a new commercial D user this week, and I'm
really disappointed.
It was rejected for exactly the same practical reasons I've been saying forever.

There were a few contributing factors, but by far the most significant
factor was the extremely poor Windows environment support and Visual
Studio debugging experience.

We were trying to use vibe.d, and we encountered bugs.

We were unable to build Win64 code (vibe.d doesn't support Win64 it
seems), and the 32bit compiler produces useless OMF output. We
couldn't link against any of our existing code which was a serious
inconvenience, but they were understanding and we worked around it.

The real trouble hit when vibe.d's WebSocket support didn't work as
advertised; it crashed in various circumstances, and debugging was
impossible.
vibe.d uses exceptions everywhere, which caused an office full of
C/C++ programmers to explode with terror, and Visual Studio completely
craps itself when there are exceptions being thrown.

We tried the VS debugger, and also Mago. Both presented different
kinds of issues, which lead to people seriously questioning the
quality of the ecosystem, if 2 out of 2 available debug tools don't
work, and for different reasons.

We had to revert to running without the debugger, and trying to
printf() debug, but that proved to be a massive waste of time, and
caused enough distaste to the other engineers that it shattered
whatever confidence I had built up in D. The decision was made to
abandon ship and revert to node.js, which satisfied our needs within a
couple of hours.

The result was a bunch of die-hard native C programmers, initially
excited to use a native language to write a webserver, instead saying
stuff like "wow, node.js just worked! that's amazing, javascript is
awesome!"... and then mocking me about my D language thing.


What's the take-away here? Well, like I've been saying endlessly for
years now, *first impressions matter*, and quality of tooling matters
more than anything.

They made comments about the installer, where VisualD's installer
failed to remember the path that we installed DMD only moments
earlier.
They immediately made comments about goto-definition not working, and
auto-completion not working reliably.

They then made HUGE noises about the quality of documentation. The
prevailing opinion was that the D docs, in the eyes of a
not-a-D-expert, are basically unreadable to them. The formatting
didn't help, there's a lot of noise and a lack of structure in the
documentation's presentation that makes it hard to see the information
through the layout and noise. As senior software engineers, they
basically expected that they should be able to read and understand the
docs, even if they don't really know the language, after all, "what is
the point of documentation if not to teach the language..."
I tend to agree, I find that I can learn most languages to a basic
level by skimming the docs, but the D docs are an anomaly in this way;
it seems you have to already know D to be able to understand it
effectively. They didn't know javascript either, but skimming the
node.js docs they got the job done in an hour or so, after having
wasted *2 days* trying to force their way through the various
frictions presented but their initial experience with D.


I have spent months discussing D with other engineers, dropping little
tidbits and details out to the floor here and there, getting people
excited and jazzed to try something new, and quietly waiting for the
opportunity to arise where I can suggest writing some new code in D.

I have spent months where people are coming up to me most days asking
about some shit thing in C/C++ and how D does it better, to which I
usually have a good answer for them, and they walk away excited.

...the moment came. I've built confidence and excitement in these
people, but when their first impression is a shambles, it completely
undoes all that work, and almost completely shattered their
confidence.

I also feel personally hurt. I'm frequently putting my reputation on
the line when I recommend D to organisations I work in, and all my
colleagues. And in this case, I received a serious blow, and that's
hard to swallow.


I want to see flawless debugging put on the road map as top priority.
We need a test environment for the windows installer and VS
integration that is thorough and that we can depend on.
It's 10 years overdue. We need to get this practical shit together if
people are going to take D seriously!

I think most importantly though, we need LDC! Assuming those other
things come good, we need a compiler with a backend to produce the
expected performance, and which integrates in a well known way with
the ecosystem around it.

Currently, I understand that the only outstanding issue with LDC for
Windows is the debuginfo output? I think this is mainly with the LLVM
crew, but is there anything we can do to help with this?


One of the take-away quotes I think, was "D seems to be a language for
people who actively want to go and look for it, and take the time to
learn it. That's never going to be a commercial success."
It's painful to accept the truth in that statement. Go and try and
learn any other trendy language today. The homepage looks modern,
there has been professional design, testing, and there are
instructional videos recorded by a professional voice actor with that
trendy bloody upbeat ukulele music in the background that's in all
tech videos these days...

I think we need a budget for presentation, and we need to pay money
and hire some professionals to make the content. Is there a
kickstarter campaign here? I'll contribute for sure.
Dec 14 2014
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/12/2014 9:37 p.m., Manu via Digitalmars-d wrote:

 Sadly, I failed to create a new commercial D user this week, and I'm
 really disappointed.
 It was rejected for exactly the same practical reasons I've been saying
forever.

 There were a few contributing factors, but by far the most significant
 factor was the extremely poor Windows environment support and Visual
 Studio debugging experience.

 We were trying to use vibe.d, and we encountered bugs.

 We were unable to build Win64 code (vibe.d doesn't support Win64 it
 seems),


Yup, unfortunately I don't really have the knowledge or the willingness 
to get it. Otherwise this would have been fixed long ago.


 and the 32bit compiler produces useless OMF output. We


That has already been sorted out in master after all. So getting there.


 couldn't link against any of our existing code which was a serious
 inconvenience, but they were understanding and we worked around it.

 The real trouble hit when vibe.d's WebSocket support didn't work as
 advertised; it crashed in various circumstances, and debugging was
 impossible.


What I wish happened with Vibe.d is to scope it really REALLY down.
It is not a web service framework. It is a web SERVER framework.
There is a big difference such as WebSocket proberbly shouldn't even be 
in Vibe.d.


 vibe.d uses exceptions everywhere, which caused an office full of
 C/C++ programmers to explode with terror, and Visual Studio completely
 craps itself when there are exceptions being thrown.


Unfortunately I'm in the camp of, if exceptions don't work. Don't use 
Vibe.d.


 We tried the VS debugger, and also Mago. Both presented different
 kinds of issues, which lead to people seriously questioning the
 quality of the ecosystem, if 2 out of 2 available debug tools don't
 work, and for different reasons.


Debugger is asking for trouble :/


 We had to revert to running without the debugger, and trying to
 printf() debug, but that proved to be a massive waste of time, and
 caused enough distaste to the other engineers that it shattered
 whatever confidence I had built up in D. The decision was made to
 abandon ship and revert to node.js, which satisfied our needs within a
 couple of hours.

 The result was a bunch of die-hard native C programmers, initially
 excited to use a native language to write a webserver, instead saying
 stuff like "wow, node.js just worked! that's amazing, javascript is
 awesome!"... and then mocking me about my D language thing.


 What's the take-away here? Well, like I've been saying endlessly for
 years now, *first impressions matter*, and quality of tooling matters
 more than anything.

 They made comments about the installer, where VisualD's installer
 failed to remember the path that we installed DMD only moments
 earlier.
 They immediately made comments about goto-definition not working, and
 auto-completion not working reliably.


For some strange reason I have never liked VS or VisualD.


 They then made HUGE noises about the quality of documentation. The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The formatting
 didn't help, there's a lot of noise and a lack of structure in the
 documentation's presentation that makes it hard to see the information
 through the layout and noise. As senior software engineers, they
 basically expected that they should be able to read and understand the
 docs, even if they don't really know the language, after all, "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a basic
 level by skimming the docs, but the D docs are an anomaly in this way;
 it seems you have to already know D to be able to understand it
 effectively. They didn't know javascript either, but skimming the
 node.js docs they got the job done in an hour or so, after having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.


Agreed its rather an interesting position. But that's why there is e.g. 
Ali's book and TDPL to do just that teach.
This should proberbly be made into a big flashing banner, wanna learn 
D?, go here!


 I have spent months discussing D with other engineers, dropping little
 tidbits and details out to the floor here and there, getting people
 excited and jazzed to try something new, and quietly waiting for the
 opportunity to arise where I can suggest writing some new code in D.

 I have spent months where people are coming up to me most days asking
 about some shit thing in C/C++ and how D does it better, to which I
 usually have a good answer for them, and they walk away excited.

 ...the moment came. I've built confidence and excitement in these
 people, but when their first impression is a shambles, it completely
 undoes all that work, and almost completely shattered their
 confidence.

 I also feel personally hurt. I'm frequently putting my reputation on
 the line when I recommend D to organisations I work in, and all my
 colleagues. And in this case, I received a serious blow, and that's
 hard to swallow.


 I want to see flawless debugging put on the road map as top priority.
 We need a test environment for the windows installer and VS
 integration that is thorough and that we can depend on.
 It's 10 years overdue. We need to get this practical shit together if
 people are going to take D seriously!

 I think most importantly though, we need LDC! Assuming those other
 things come good, we need a compiler with a backend to produce the
 expected performance, and which integrates in a well known way with
 the ecosystem around it.

 Currently, I understand that the only outstanding issue with LDC for
 Windows is the debuginfo output? I think this is mainly with the LLVM
 crew, but is there anything we can do to help with this?


 One of the take-away quotes I think, was "D seems to be a language for
 people who actively want to go and look for it, and take the time to
 learn it. That's never going to be a commercial success."
 It's painful to accept the truth in that statement. Go and try and
 learn any other trendy language today. The homepage looks modern,
 there has been professional design, testing, and there are
 instructional videos recorded by a professional voice actor with that
 trendy bloody upbeat ukulele music in the background that's in all
 tech videos these days...

 I think we need a budget for presentation, and we need to pay money
 and hire some professionals to make the content. Is there a
 kickstarter campaign here? I'll contribute for sure.


No objections with presentation budget, although extending it to 
advertising in general might be a good idea.
Great example, how about separating out Walters website from D's? Or one 
Google indexed web interface to the news group.
Not to mention things like ApplyYourDLang (don't have time to do it / 
waiting for other projects).

If only we had the money.
Unfortunately I wish I could do a lot more.

I personally tried to improve the web situation, still waiting on a PR 
for another round of review/pull before I can even consider putting up 
the next version of Cmsed.
Now I'm back to the GUI situation. Maybe if I can get a Google Material 
design working, we can get some free advertising.

And I have to get a job sometime next month (graduated). I'm trying.
Dec 14 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 14 Dec 2014 22:13:13 +1300
Rikki Cattermole via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Now I'm back to the GUI situation.


talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD
and alot of other projects. they suck. they suck badly. there was a
great project once, "Harmonia", but it is dead. DWT suck being
java-rooted, and java GUI toolkits are piles of crap. other suck being
just a wrappers. there is no GUI toolkit that utilises some kind of
markup language, constraint engine (cassowary, anyone?), easy FX
without writing boilerplate code, theming and not being a fscking
wrapper.

yes, i know: "if you want to have something, stop ranting and just do
it!" yet i have alot of other hobby projects and only 24 hours in a
day. poor me.
Dec 14 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 14 Dec 2014 11:24:30 +0200
ketmar via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Sun, 14 Dec 2014 22:13:13 +1300
 Rikki Cattermole via Digitalmars-d <digitalmars-d puremagic.com> wrote:
=20

 Now I'm back to the GUI situation.


 talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD
 and alot of other projects. they suck. they suck badly. there was a
 great project once, "Harmonia", but it is dead. DWT suck being
 java-rooted, and java GUI toolkits are piles of crap. other suck being
 just a wrappers. there is no GUI toolkit that utilises some kind of
 markup language, constraint engine (cassowary, anyone?), easy FX
 without writing boilerplate code, theming and not being a fscking
 wrapper.
=20
 yes, i know: "if you want to have something, stop ranting and just do
 it!" yet i have alot of other hobby projects and only 24 hours in a
 day. poor me.


p.s. sorry for me being rude. DWT, GtkD and others are great project of
great value. it's not about "their authors doing wrong things", that's
about "i want something completely different!"
Dec 14 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/12/2014 10:27 p.m., ketmar via Digitalmars-d wrote:

 On Sun, 14 Dec 2014 11:24:30 +0200
 ketmar via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Sun, 14 Dec 2014 22:13:13 +1300
 Rikki Cattermole via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Now I'm back to the GUI situation.


 talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD
 and alot of other projects. they suck. they suck badly. there was a
 great project once, "Harmonia", but it is dead. DWT suck being
 java-rooted, and java GUI toolkits are piles of crap. other suck being
 just a wrappers. there is no GUI toolkit that utilises some kind of
 markup language, constraint engine (cassowary, anyone?), easy FX
 without writing boilerplate code, theming and not being a fscking
 wrapper.

 yes, i know: "if you want to have something, stop ranting and just do
 it!" yet i have alot of other hobby projects and only 24 hours in a
 day. poor me.


 p.s. sorry for me being rude. DWT, GtkD and others are great project of
 great value. it's not about "their authors doing wrong things", that's
 about "i want something completely different!"


Yeah they are great projects.
But they won't ever be what I'm looking for.

Personally?
- I want a gui toolkit that is accelerated e.g. OpenGL.
- That can be layered drawn on top of other OpenGL content.
- Completely configurable at runtime e.g. change of shaders.
- Centralized themeing.
- That works on all major platforms without heartache.

But here's the thing about guis in general.
Gui toolkits are not really designed to work with OpenGL like this.

If I want to fix this, I know I can't go around designing the controls 
for example. Luckily Google has already done this! Even defined default 
themes, and how controls should be drawn.

Now with how I want a gui toolkit to work, it has a lot of benefits.
First off, before I can even create a window, well I need a windowing 
library. Hello Devisualization.Window.

Next, okay I can create a window and a context as needed.
What about doing some actual drawing? Devisualization.Util:OpenGL

So drawing for OpenGL is easy, but that window could really do with an 
icon.. Devisualization.Image
Now lets draw some text! Devisualization.Font

Okay, now we are ready for actually ready for controls. Or are we? Nope!
Need a scenegraph to instruct when to draw each control. 
Devisualization.Scenegraph

Next step, lets start the actual controls! Well actually.. we already 
know we have separated out coordinates from events thanks to the 
scenegraph. So how about a scenegraph with eventing support.

Noticing something? That's about quarter of a game engine stack already 
made. Before even having GUI controls actually being used.
Highly modular and implementation replaceable, portable.

I'm already exhausted before even considering sound.
Also don't forget the colour paletted provided from Google is in either 
Photoshop or Illustrator formats. So if you want to use them.. hello 
parser (already made, Devisualization.Util:photoshop_aco).
Dec 14 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 14 Dec 2014 22:52:59 +1300
Rikki Cattermole via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 p.s. sorry for me being rude. DWT, GtkD and others are great project of
 great value. it's not about "their authors doing wrong things", that's
 about "i want something completely different!"


=20
 Yeah they are great projects.
 But they won't ever be what I'm looking for.
=20
 Personally?
 - I want a gui toolkit that is accelerated e.g. OpenGL.
 - That can be layered drawn on top of other OpenGL content.
 - Completely configurable at runtime e.g. change of shaders.
 - Centralized themeing.
 - That works on all major platforms without heartache.
=20
 But here's the thing about guis in general.
 Gui toolkits are not really designed to work with OpenGL like this.


GUI toolkits are not really designed. that is. a good GUI toolkit
should be able to use any backend the end user want. DirectFB? OpenGL?
custom framebuffer library? anything, it should not matter at all.

the abstraction GUI toolkint using should be designed like X server.
want anything? ask the underlying layer to do that. pixmap with
gradient? don't do that in control painting code, ask the underlying
pixmap layer to do that. want text output? don't do that, use the
underlying layer that does ALL text rendering. and so on. this way GUI
toolkit can use any acceleration the underlying layer can provide. and
writing new control is a matter of compositing some high-level calls.

and if we'll go to the design stage, we can find markup language
useful. with markup language and constraint engine we moving our
rendering code even further away. thus we need two layers: basic
rendering engine that can draw pixels, and markup processing engine
that convert our declarative GUI description to basic operations.

and then comes the things like OpenGL, shaders and so on. on the lower
level, which can be controlled from markup. do we have only framebuffer?
ok, ignore advanced styling and degrate to that. modern OpenGL with
shaders? ok, pass the necessary info down the pipe.

that's where Devisualisation comes into play. it provides mechanics we
need, with simple and well-defined interface. what we also need is
high-level engine that will convert our declarative GUI descriptions to
low-level calls. HTML is not the best language to build GUIs, but the
overall way Harmonia takes looking fine. declarative language for
high-level descriptions and translation layer for low-level calls.
Dec 14 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/12/2014 11:15 p.m., ketmar via Digitalmars-d wrote:

 On Sun, 14 Dec 2014 22:52:59 +1300
 Rikki Cattermole via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 p.s. sorry for me being rude. DWT, GtkD and others are great project of
 great value. it's not about "their authors doing wrong things", that's
 about "i want something completely different!"


 Yeah they are great projects.
 But they won't ever be what I'm looking for.

 Personally?
 - I want a gui toolkit that is accelerated e.g. OpenGL.
 - That can be layered drawn on top of other OpenGL content.
 - Completely configurable at runtime e.g. change of shaders.
 - Centralized themeing.
 - That works on all major platforms without heartache.

 But here's the thing about guis in general.
 Gui toolkits are not really designed to work with OpenGL like this.


 GUI toolkits are not really designed. that is. a good GUI toolkit
 should be able to use any backend the end user want. DirectFB? OpenGL?
 custom framebuffer library? anything, it should not matter at all.


Agreed and I know. I'm using OpenGL as an example. You'll notice heavily 
that I abstract interface from implementation to the point of there is 
literally a subpackage called opengl for the OpenGL implementation.


 the abstraction GUI toolkint using should be designed like X server.
 want anything? ask the underlying layer to do that. pixmap with
 gradient? don't do that in control painting code, ask the underlying
 pixmap layer to do that. want text output? don't do that, use the
 underlying layer that does ALL text rendering. and so on. this way GUI
 toolkit can use any acceleration the underlying layer can provide. and
 writing new control is a matter of compositing some high-level calls.

 and if we'll go to the design stage, we can find markup language
 useful. with markup language and constraint engine we moving our
 rendering code even further away. thus we need two layers: basic
 rendering engine that can draw pixels, and markup processing engine
 that convert our declarative GUI description to basic operations.

 and then comes the things like OpenGL, shaders and so on. on the lower
 level, which can be controlled from markup. do we have only framebuffer?
 ok, ignore advanced styling and degrate to that. modern OpenGL with
 shaders? ok, pass the necessary info down the pipe.

 that's where Devisualisation comes into play. it provides mechanics we
 need, with simple and well-defined interface. what we also need is
 high-level engine that will convert our declarative GUI descriptions to
 low-level calls. HTML is not the best language to build GUIs, but the
 overall way Harmonia takes looking fine. declarative language for
 high-level descriptions and translation layer for low-level calls.


Agreed, I hate to say it, because I'm basing off of Google Material 
design, I would have to use what ever Google does on Android out of pure 
ease of porting.
So its not something I'm able to create new. Just a new implementation.
Dec 14 2014
prev sibling next sibling parent reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
 - I want a gui toolkit that is accelerated e.g. OpenGL.
 - That can be layered drawn on top of other OpenGL content.
 - Completely configurable at runtime e.g. change of shaders.
 - Centralized themeing.
 - That works on all major platforms without heartache.

 But here's the thing about guis in general.
 Gui toolkits are not really designed to work with OpenGL like 
 this.


They had in D1 an awesome project fully written in D named rae:
http://www.dsource.org/projects/rae

all ui was possible by using openGL

but since the beginning all D project go to the death. Language
es not enough stable and maybe lot of others problem.

I become not anymore a D enthousiast.


erf…
Dec 17 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 18/12/2014 1:07 p.m., bioinfornatics wrote:

 - I want a gui toolkit that is accelerated e.g. OpenGL.
 - That can be layered drawn on top of other OpenGL content.
 - Completely configurable at runtime e.g. change of shaders.
 - Centralized themeing.
 - That works on all major platforms without heartache.

 But here's the thing about guis in general.
 Gui toolkits are not really designed to work with OpenGL like this.


 They had in D1 an awesome project fully written in D named rae:
 http://www.dsource.org/projects/rae

 all ui was possible by using openGL

 but since the beginning all D project go to the death. Language
 es not enough stable and maybe lot of others problem.

 I become not anymore a D enthousiast.


 erf…


I wonder what I can do with that for Devisualization.gmaterials thanks.
Dec 17 2014
prev sibling parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Sunday, 14 December 2014 at 09:53:06 UTC, Rikki Cattermole 
wrote:

 Yeah they are great projects.
 But they won't ever be what I'm looking for.

 Personally?
 - I want a gui toolkit that is accelerated e.g. OpenGL.
 - That can be layered drawn on top of other OpenGL content.
 - Completely configurable at runtime e.g. change of shaders.
 - Centralized themeing.
 - That works on all major platforms without heartache.

 But here's the thing about guis in general.
 Gui toolkits are not really designed to work with OpenGL like 
 this.


Hello,

I'm working on GUI toolkit DLangUI which meets almost all of your 
requirements

https://github.com/buggins/dlangui

Try demo app:

git clone git github.com:buggins/dlangui.git
dub run dlangui:example1

Native. Fully written in D. Widget set can be easy extended.
Look and feel is based on themes / styles similar to Android.
Scalable UI. Resources can be selected based on screen resolution.
Layouts similar to Android UI allow to adjust UI to different 
window sizes.
Cross platform.


 - I want a gui toolkit that is accelerated e.g. OpenGL.


Build it with USE_OPENGL to have OpenGL acceleration.


 - That can be layered drawn on top of other OpenGL content.


Additional development required.
a) To use in some custom environment (e.g. draw GUI in some 
gamedev engine), you need to implement Platform and Window 
classes to pass Mouse / Key event to UI, and to draw UI above 
other content when necessary.
b) Use DLangUI platform for event processing and context 
creation, just extend drawing functionality to draw custom 
content. (Easy to do).


 - Completely configurable at runtime e.g. change of shaders.


Internally it uses only two shaders.
For custom drawn GL scenes, just write your own code.


 - Centralized themeing.


Styles and themes are being defined in XML resources. Partially 
compatible with ones from Android. State aware drawables. 
Nine-patch drawables.
Theme can be switched in run time.


 - That works on all major platforms without heartache.


For most platforms, SLD2 backend can be used (version USE_SDL).
On Windows, you may use native Win32 backend (if not specified 
version USE_SDL).
XCB(X11) backend is suspended for now. Didn't manage to get 
OpenGL working under it.

For all platforms, OpenGL acceleration can be used (version 
USE_OPENGL).
If OpenGL context creation is failed, app just falls back to 
software renderer.

Development of the project is in progress. But it is getting more 
and more usable every day.

Best regards,
     Vadim (aka Buggins)
Dec 17 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 18 December 2014 at 06:01:34 UTC, Vadim Lopatin 
wrote:

 On Sunday, 14 December 2014 at 09:53:06 UTC, Rikki Cattermole 
 wrote:

 Yeah they are great projects.
 But they won't ever be what I'm looking for.

 Personally?
 - I want a gui toolkit that is accelerated e.g. OpenGL.
 - That can be layered drawn on top of other OpenGL content.
 - Completely configurable at runtime e.g. change of shaders.
 - Centralized themeing.
 - That works on all major platforms without heartache.

 But here's the thing about guis in general.
 Gui toolkits are not really designed to work with OpenGL like 
 this.


 Hello,

 I'm working on GUI toolkit DLangUI which meets almost all of 
 your requirements

 https://github.com/buggins/dlangui

 Try demo app:

 git clone git github.com:buggins/dlangui.git
 dub run dlangui:example1

 Native. Fully written in D. Widget set can be easy extended.
 Look and feel is based on themes / styles similar to Android.
 Scalable UI. Resources can be selected based on screen 
 resolution.
 Layouts similar to Android UI allow to adjust UI to different 
 window sizes.
 Cross platform.


 - I want a gui toolkit that is accelerated e.g. OpenGL.


 Build it with USE_OPENGL to have OpenGL acceleration.


 - That can be layered drawn on top of other OpenGL content.


 Additional development required.
 a) To use in some custom environment (e.g. draw GUI in some 
 gamedev engine), you need to implement Platform and Window 
 classes to pass Mouse / Key event to UI, and to draw UI above 
 other content when necessary.
 b) Use DLangUI platform for event processing and context 
 creation, just extend drawing functionality to draw custom 
 content. (Easy to do).


 - Completely configurable at runtime e.g. change of shaders.


 Internally it uses only two shaders.
 For custom drawn GL scenes, just write your own code.


 - Centralized themeing.


 Styles and themes are being defined in XML resources. Partially 
 compatible with ones from Android. State aware drawables. 
 Nine-patch drawables.
 Theme can be switched in run time.


 - That works on all major platforms without heartache.


 For most platforms, SLD2 backend can be used (version USE_SDL).
 On Windows, you may use native Win32 backend (if not specified 
 version USE_SDL).
 XCB(X11) backend is suspended for now. Didn't manage to get 
 OpenGL working under it.

 For all platforms, OpenGL acceleration can be used (version 
 USE_OPENGL).
 If OpenGL context creation is failed, app just falls back to 
 software renderer.

 Development of the project is in progress. But it is getting 
 more and more usable every day.

 Best regards,
     Vadim (aka Buggins)


Very good! I tried it and couldn't clone the repo (permission 
denied). Downloaded the master zip instead, ran the above command 
and got this message (dmd v2.066.0 64bit Linux):

Running dmd...
src/dlangui/dialogs/filedlg.d(86): Error: None of the overloads 
of 'rows' are callable using argument types (ulong), candidates 
are:
src/dlangui/widgets/grid.d(286):        
dlangui.widgets.grid.GridWidgetBase.rows()
src/dlangui/widgets/grid.d(288):        
dlangui.widgets.grid.GridWidgetBase.rows(int r)
src/dlangui/widgets/lists.d(105): Error: cannot implicitly 
convert expression (this._states.length) of type ulong to int
FAIL 
.dub/build/library-debug-linux.posix-x86_64-dmd_2066-A75BA498AEDB8
DC20AE1A4A96C79D4B/ 
dlanguilib staticLibrary
Error executing command run: dmd failed with exit code 1.

I'd really love to test your gui toolkit, something I've been 
dreaming of for a long time!
Dec 18 2014
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Thursday, 18 December 2014 at 11:00:43 UTC, Chris wrote:


 Very good! I tried it and couldn't clone the repo (permission 
 denied). Downloaded the master zip instead, ran the above 
 command and got this message (dmd v2.066.0 64bit Linux):


...

 Error executing command run: dmd failed with exit code 1.

 I'd really love to test your gui toolkit, something I've been 
 dreaming of for a long time!


Sorry, 64bit build has been broken by recent changes.
Fixed in v0.1.5

Https should be used instead of SSH to clone repository.

git clone https://github.com/buggins/dlangui.git
cd dlangui
dub run dlangui:example1
Dec 18 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 18 December 2014 at 11:50:46 UTC, Vadim Lopatin 
wrote:

 On Thursday, 18 December 2014 at 11:00:43 UTC, Chris wrote:


 Very good! I tried it and couldn't clone the repo (permission 
 denied). Downloaded the master zip instead, ran the above 
 command and got this message (dmd v2.066.0 64bit Linux):


 ...

 Error executing command run: dmd failed with exit code 1.

 I'd really love to test your gui toolkit, something I've been 
 dreaming of for a long time!


 Sorry, 64bit build has been broken by recent changes.
 Fixed in v0.1.5

 Https should be used instead of SSH to clone repository.

 git clone https://github.com/buggins/dlangui.git
 cd dlangui
 dub run dlangui:example1


This worked! Thanks. It's very good! Maybe we should think about 
writing a IDE based on dub and dlangui. What do you think?

If you need any help with the artwork, maybe next year I'll have 
some time to design icons etc.
Dec 18 2014
next sibling parent reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
please stop with this dub ....

It do not respect OS specification
Is a monolith application,inside they are at least 3 kinds of 
software:
- a builder
- a package manager
- a package indexer

In any case the :
  - no respect of OS specification and standard path
  - any discussion with OS packager or development with their needs

it is to me no dub!!!
Dec 18 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 18 December 2014 at 13:48:27 UTC, bioinfornatics 
wrote:

 please stop with this dub ....

 It do not respect OS specification
 Is a monolith application,inside they are at least 3 kinds of 
 software:
 - a builder
 - a package manager
 - a package indexer

 In any case the :
  - no respect of OS specification and standard path
  - any discussion with OS packager or development with their 
 needs

 it is to me no dub!!!


How do you intend to provide build tools and package distribution 
that work across all OS?

POSIX compatible OS each with its own format, Windows, mainframes 
and embedded OS?

Are you going to distribute packages for all of them?
Dec 18 2014
parent reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
 How do you intend to provide build tools and package 
 distribution that work across all OS?



split dub in smaller project as this packager could integrate 
tools inside Os themself.

python with his setup.py is to me a nice win
with it packager can configure it to fit right on Os
end user can use pip install
and pypi index package

That is soooo hard ...
Dec 18 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 18 December 2014 at 14:31:10 UTC, bioinfornatics 
wrote:

 How do you intend to provide build tools and package 
 distribution that work across all OS?



 split dub in smaller project as this packager could integrate 
 tools inside Os themself.

 python with his setup.py is to me a nice win
 with it packager can configure it to fit right on Os
 end user can use pip install
 and pypi index package

 That is soooo hard ...


So now you are making Python a dependency.

Besides porting D to a new platform, Python must also be ported.

Yes, there are computer systems without Python support.
Dec 18 2014
next sibling parent "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
 So now you are making Python a dependency.

 Besides porting D to a new platform, Python must also be ported.

 Yes, there are computer systems without Python support.


What ?
I took an example what is done in a close field .
I haven't said to put python as dependencies ...
Dec 18 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
How one can consider pip a good thing for packaging and blame dub 
at the same time is beyond my comprehensions. I have nothing but 
hatred against both pip and gems.
Dec 18 2014
parent "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
On Thursday, 18 December 2014 at 14:46:33 UTC, Dicebot wrote:

 How one can consider pip a good thing for packaging and blame 
 dub at the same time is beyond my comprehensions. I have 
 nothing but hatred against both pip and gems.


You missed the point:
- to me dub is a pip like

but in python they split into 3 software
- a builder (setuptool and newer version)
- a package manager (pip)
- a package index (pypi)

This is better to me, people which do not care about pip and 
other can to use only the builder.
End user to get their killer app working can use pip

with the same file setup.py they add many software level:
- end user do not care about standard path and want something 
easy to use
- packager need to insert correctly the software inside OS 
environment

With the json file for dub I think that is possible to get it
Dec 18 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 18 December 2014 at 13:48:27 UTC, bioinfornatics 
wrote:

 please stop with this dub ....

 It do not respect OS specification
 Is a monolith application,inside they are at least 3 kinds of 
 software:
 - a builder
 - a package manager
 - a package indexer

 In any case the :
  - no respect of OS specification and standard path
  - any discussion with OS packager or development with their 
 needs

 it is to me no dub!!!


There is nothing in dub which conflicts with doing solid 
packaging. Unless you miss `make install` of course. I don't.
Dec 18 2014
parent "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
On Thursday, 18 December 2014 at 14:32:03 UTC, Dicebot wrote:

 On Thursday, 18 December 2014 at 13:48:27 UTC, bioinfornatics 
 wrote:

 please stop with this dub ....

 It do not respect OS specification
 Is a monolith application,inside they are at least 3 kinds of 
 software:
 - a builder
 - a package manager
 - a package indexer

 In any case the :
 - no respect of OS specification and standard path
 - any discussion with OS packager or development with their 
 needs

 it is to me no dub!!!


 There is nothing in dub which conflicts with doing solid 
 packaging. Unless you miss `make install` of course. I don't.


I agree, after all , all is possible.
but maybe I missed a feature make generation with dub is not 
supported : 
https://github.com/D-Programming-Language/dub/issues/52

and some var like LIB_DIR, PREFIX, DFLAGS, INCLUDE_DIR will be 
required by packager to set correctly the package
Dec 18 2014
prev sibling parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Thursday, 18 December 2014 at 13:43:15 UTC, Chris wrote:

 On Thursday, 18 December 2014 at 11:50:46 UTC, Vadim Lopatin 
 wrote:

 On Thursday, 18 December 2014 at 11:00:43 UTC, Chris wrote:


 Very good! I tried it and couldn't clone the repo (permission 
 denied). Downloaded the master zip instead, ran the above 
 command and got this message (dmd v2.066.0 64bit Linux):


 ...

 Error executing command run: dmd failed with exit code 1.

 I'd really love to test your gui toolkit, something I've been 
 dreaming of for a long time!


 Sorry, 64bit build has been broken by recent changes.
 Fixed in v0.1.5

 Https should be used instead of SSH to clone repository.

 git clone https://github.com/buggins/dlangui.git
 cd dlangui
 dub run dlangui:example1


 This worked! Thanks. It's very good! Maybe we should think 
 about writing a IDE based on dub and dlangui. What do you think?


How did you guess? :)

git clone git github.com:buggins/dlangide.git
cd dlang ide
dub run

Recent changes are to be able writing IDE:
- Tree view (usable)
- FileOpen dialog (in progress)


 If you need any help with the artwork, maybe next year I'll 
 have some time to design icons etc.


UI theme itself now looks ugly - mix of resources from Android, 
gnome Oxygen, and hand drawn images. All of different styles and 
palette.

It will be great if someone could help to make them better.
(Mostly, editing on theme XML and PNGs is necessary).
Dec 18 2014
parent reply "Vadim Lopatin" <coolreader.org gmail.com> writes:
On Thursday, 18 December 2014 at 13:51:08 UTC, Vadim Lopatin 
wrote:

 git clone git github.com:buggins/dlangide.git
 cd dlang ide
 dub run


Sorry, it should be

git clone https://github.com/buggins/dlangide.git
cd dlangide
dub run
Dec 18 2014
parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 18 December 2014 at 13:52:58 UTC, Vadim Lopatin 
wrote:

 On Thursday, 18 December 2014 at 13:51:08 UTC, Vadim Lopatin 
 wrote:

 git clone git github.com:buggins/dlangide.git
 cd dlang ide
 dub run


 Sorry, it should be

 git clone https://github.com/buggins/dlangide.git
 cd dlangide
 dub run


Cool. A D IDE in D that integrates all the existing tools would 
be great (dscanner, dvm etc.)

Maybe it's time to pick people's brains for ideas and suggestions.
Dec 18 2014
prev sibling next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
Digitalmars-d wrote:

 Sadly, I failed to create a new commercial D user this week,  
 and I'm really disappointed.
 It was rejected for exactly the same practical reasons I've  
 been saying forever.

 There were a few contributing factors, but by far the most 
 significant
 factor was the extremely poor Windows environment support and 
 Visual Studio debugging experience.


I find exactly the same issue for every developer that I'm moving 
from C++ to D under Windows: the bar is very high here.


 We were trying to use vibe.d, and we encountered bugs.


We are using Vibe also here in Milan: it's maintained since a 
long time, and it has plenty of adopters, but... it's just too 
big.
Sönke is doing a remarkable job, but, for example, I've a mail 
server in production using vibe with an assert turned into an 
hard exit && restart: I was simply unable to debug it.

And it's also very picky about what compiler to use to have a 
proper build, at least, lately.
Actually I'm on a branch trying to have it run with master, as I 
need async-socker and C++ support for a product... *sigh*


 We were unable to build Win64 code (vibe.d doesn't support  
 Win64 it seems), and the 32bit compiler produces useless OMF 
 output. We
 couldn't link against any of our existing code which was a 
 serious inconvenience, but they were understanding and we 
 worked around it.


I tend to agree about debugging, we also need to keep a Win32 
application live, and it's a mess.
I know that there's some improvement over that lately, but 
practically we are developing and debugging it in linux and just 
running the unittests in Win32.

Regarding Vibe, why aren't you using linux for such a job? I 
think that's the right tool for that kind of services, and life 
is more easier in that land.


 The real trouble hit when vibe.d's WebSocket support didn't 
 work as
 advertised; it crashed in various circumstances, and debugging 
 was impossible.
 vibe.d uses exceptions everywhere, which caused an office full  
 of
 C/C++ programmers to explode with terror, and Visual Studio 
 completely craps itself when there are exceptions being thrown.


Yep, I can understand, and the documentation does not help a lot, 
I would say.
I think vibe is simply too ambitious: it should take the road of 
being split, with some pieces being somehow absorbed by Phobos 
(like the new concurrency).
I'm planning to switch to Etienne package for simple socket 
applications...


 We tried the VS debugger, and also Mago. Both presented  
 different
 kinds of issues, which lead to people seriously questioning the
 quality of the ecosystem, if 2 out of 2 available debug tools 
 don't work, and for different reasons.

 We had to revert to running without the debugger, and trying to
 printf() debug, but that proved to be a massive waste of time, 
 and caused enough distaste to the other engineers that it 
 shattered
 whatever confidence I had built up in D. The decision was made 
 to abandon ship and revert to node.js, which satisfied our 
 needs within a couple of hours.


That's the point...
I can simply impone to adopt D, because I've the power of doing 
that, but trying to evangelize bottom-up it seems to me a via 
crucis...


 The result was a bunch of die-hard native C programmers, 
 initially
 excited to use a native language to write a webserver, instead 
 saying stuff like "wow, node.js just worked! that's amazing, 
 javascript is awesome!"... and then mocking me about my D 
 language thing.


*sigh*, but hey: I really hate Javascript (but I'm using it with 
Meteor...)


 They then made HUGE noises about the quality of documentation.


<snip>

I don't agree here: just go with books.
Thanks to Ali, Andrej, Philippe and Adam for covering well that 
field.


 It's painful to accept the truth in that statement. Go and try  
 and
 learn any other trendy language today. The homepage looks 
 modern,
 there has been professional design, testing, and there are
 instructional videos recorded by a professional voice actor 
 with that trendy bloody upbeat ukulele music in the background 
 that's in all tech videos these days...

 I think we need a budget for presentation, and we need to pay 
 money
 and hire some professionals to make the content. Is there a 
 kickstarter campaign here? I'll contribute for sure.


I disagree here: the most beautiful advertising for D are 
concrete success stories out in the wilds.
So first, it needs to stop loosing commercial adopters: why they 
dropped it, that's the most valuable feedback for the D community.

And, IMHO, in THAT specific case, it was:

- debugging experience must be top class
- async-io as a "basic" operation, choosing vibe as the 
'de-facto' most suitable solution, it's not available for neither 
the big-two, Lin/Win (OS X is a no-go platform for D until the 
support to ObjC will be merged).

---
/Paolo
Dec 14 2014
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Sunday, 14 December 2014 at 10:31:29 UTC, Paolo Invernizzi 
wrote:

 We are using Vibe also here in Milan: it's maintained since a 
 long time, and it has plenty of adopters, but... it's just too 
 big.
 Sönke is doing a remarkable job, but, for example, I've a mail 
 server in production using vibe with an assert turned into an 
 hard exit && restart: I was simply unable to debug it.

 And it's also very picky about what compiler to use to have a 
 proper build, at least, lately.
 Actually I'm on a branch trying to have it run with master, as 
 I need async-socker and C++ support for a product... *sigh*


If you don't need high-performance, consider using DHSL:
https://github.com/canidae/DHSL

Example web-service here:
https://github.com/p0nce/leaderboard-d

Not an all in one solution, but single-file and that means you 
can use separate libraries for HTML templating, encryption, 
e-mail, MIME, serialization, etc...
Dec 14 2014
parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Sunday, 14 December 2014 at 12:38:00 UTC, ponce wrote:

 On Sunday, 14 December 2014 at 10:31:29 UTC, Paolo Invernizzi 
 wrote:

 And it's also very picky about what compiler to use to have a 
 proper build, at least, lately.
 Actually I'm on a branch trying to have it run with master, as 
 I need async-socket and C++ support for a product... *sigh*


 If you don't need high-performance, consider using DHSL:
 https://github.com/canidae/DHSL

 Example web-service here:
 https://github.com/p0nce/leaderboard-d

 Not an all in one solution, but single-file and that means you 
 can use separate libraries for HTML templating, encryption, 
 e-mail, MIME, serialization, etc...


Thank you for the suggestion ponce, but I need a little more 
(fibers, file, socket, timers, ...).
---
Paolo
Dec 14 2014
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
Thanks for the feedback.

On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
Digitalmars-d wrote:

 We were unable to build Win64 code (vibe.d doesn't support 
 Win64 it
 seems), and the 32bit compiler produces useless OMF output. We
 couldn't link against any of our existing code which was a 
 serious
 inconvenience, but they were understanding and we worked around 
 it.


Did you try the new 32-bit COFF support in dmd from git?


 The result was a bunch of die-hard native C programmers, 
 initially
 excited to use a native language to write a webserver, instead 
 saying
 stuff like "wow, node.js just worked! that's amazing, 
 javascript is
 awesome!"... and then mocking me about my D language thing.


"die-hard native C programmers" who are fine with javascript?  Is 
it one or two orders of magnitude slower than vibe.d? ;) I know 
v8 is fast for javascript, but it has to be significantly slower 
than C and D.


 What's the take-away here? Well, like I've been saying 
 endlessly for
 years now, *first impressions matter*, and quality of tooling 
 matters
 more than anything.


---snip---

 I want to see flawless debugging put on the road map as top 
 priority.
 We need a test environment for the windows installer and VS
 integration that is thorough and that we can depend on.
 It's 10 years overdue. We need to get this practical shit 
 together if
 people are going to take D seriously!


---snip---

 One of the take-away quotes I think, was "D seems to be a 
 language for
 people who actively want to go and look for it, and take the 
 time to
 learn it. That's never going to be a commercial success."
 It's painful to accept the truth in that statement. Go and try 
 and
 learn any other trendy language today. The homepage looks 
 modern,
 there has been professional design, testing, and there are
 instructional videos recorded by a professional voice actor 
 with that
 trendy bloody upbeat ukulele music in the background that's in 
 all
 tech videos these days...


There has never been a successful open source project without 
significant commercial support, going from linux to perl on down 
the line.  D's commercial support consists of some Facebook 
bounties, Sociomantic throwing out huge pulls occasionally that 
never get merged, and companies like EMSI chipping in where they 
can.  D will never have "commercial success" through the higher 
quality tooling and presentation you are calling for without more 
significant commercial involvement to fund it, period.

Right now, D is bleeding-edge technology.  You have to know how 
to stay away from the chipper blades of the D chainsaw or it 
could cut your arm open and you could bleed out.  Not a problem 
for hobbyists, but a big problem for companies, who are used to 
all the rough edges being sanded down and paying through the nose 
for such support.  If decision-makers at companies are hoping to 
get such polished work for free from a volunteer-oriented OSS 
project, they should have their heads examined.

On Sunday, 14 December 2014 at 09:13:20 UTC, Rikki Cattermole 
wrote:

 Great example, how about separating out Walters website from 
 D's? Or one Google indexed web interface to the news group.


Great idea, I mentioned this before and nothing was done:

http://forum.dlang.org/post/lqpwiaqeyartbsokdlnt forum.dlang.org

What's especially embarrassing is the old web archive will often 
garble posts and render them unreadable.
Dec 14 2014
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/12/2014 11:36 p.m., Joakim wrote:

 On Sunday, 14 December 2014 at 09:13:20 UTC, Rikki Cattermole wrote:

 Great example, how about separating out Walters website from D's? Or
 one Google indexed web interface to the news group.


 Great idea, I mentioned this before and nothing was done:

 http://forum.dlang.org/post/lqpwiaqeyartbsokdlnt forum.dlang.org

 What's especially embarrassing is the old web archive will often garble
 posts and render them unreadable.


IMO its an PR disaster. I wonder if somebody would be willing to lend 
Walter a hand with some redesigning. Although I think it would be a 
tough sell.
Dec 14 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 14 December 2014 at 10:36:27 UTC, Joakim wrote:

 Thanks for the feedback.

 On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
 Digitalmars-d wrote:

 We were unable to build Win64 code (vibe.d doesn't support 
 Win64 it
 seems), and the 32bit compiler produces useless OMF output. We
 couldn't link against any of our existing code which was a 
 serious
 inconvenience, but they were understanding and we worked 
 around it.


 Did you try the new 32-bit COFF support in dmd from git?


 The result was a bunch of die-hard native C programmers, 
 initially
 excited to use a native language to write a webserver, instead 
 saying
 stuff like "wow, node.js just worked! that's amazing, 
 javascript is
 awesome!"... and then mocking me about my D language thing.


 "die-hard native C programmers" who are fine with javascript?  
 Is it one or two orders of magnitude slower than vibe.d? ;) I 
 know v8 is fast for javascript, but it has to be significantly 
 slower than C and D.
 ...


I have seen this in every project where we replaced legacy C++ 
systems by new ones implemented in .NET and Java.

First people will complain that the performance isn't comparable, 
they are bloated, and so on.

The project goes forward, as it was a management decision.

Then it goes live, some hiccups that make existing C++ developers 
rejoice that they were right after all

Lots of bug reports get generated and application performance 
gets fine-tuned.

A few months later systems are running, end users barely see any 
difference and a few C++ developers saying that the new systems 
aren't that bad after all.

--
Paulo
Dec 14 2014
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 14 December 2014 at 11:53:56 UTC, Paulo Pinto wrote:

 I have seen this in every project where we replaced legacy C++ 
 systems by new ones implemented in .NET and Java.

 First people will complain that the performance isn't 
 comparable, they are bloated, and so on.

 The project goes forward, as it was a management decision.

 Then it goes live, some hiccups that make existing C++ 
 developers rejoice that they were right after all

 Lots of bug reports get generated and application performance 
 gets fine-tuned.

 A few months later systems are running, end users barely see 
 any difference and a few C++ developers saying that the new 
 systems aren't that bad after all.


I don't doubt that this has been your experience on enterprise 
projects with a known and stable userbase, but you can't tell me 
you were able to support the same amount of users per server 
using java/.net as C++.  Paying for more servers but less for 
java/.net development may be a worthwhile tradeoff for such 
stable enterprise rollouts, but any time you have to scale, I 
doubt java/.net can keep up.

As always, different tools for different uses.  Hopefully, D can 
one day be polished and mainstream enough for the enterprise use 
case and it will be efficient enough to be deployed at scale too. 
:)
Dec 14 2014
next sibling parent reply "yawniek" <yawniek nowhere.com> writes:
On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 As always, different tools for different uses.  Hopefully, D 
 can one day be polished and mainstream enough for the 
 enterprise use case and it will be efficient enough to be 
 deployed at scale too. :)


when will that be? windows version 25, sqlite version 1147?
in d everybody seem to tinker around - closing a little hole here 
and there - and forgetting, that this will never lead to a larger 
acception of the general programming community.
i want to use - not experiment or start to waste a lot of time in 
recreating the things that i get with all the other languages. 
it's kind funny to watch that excuse finding.
i think the leaders of this research project should find a way to 
make it usable to wider public instead of pursuing their pet 
projects.
Dec 14 2014
next sibling parent =?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote:

 On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 As always, different tools for different uses.  Hopefully, D 
 can one day be polished and mainstream enough for the 
 enterprise use case and it will be efficient enough to be 
 deployed at scale too. :)


 when will that be? windows version 25, sqlite version 1147?
 in d everybody seem to tinker around - closing a little hole 
 here and there - and forgetting, that this will never lead to a 
 larger acception of the general programming community.
 i want to use - not experiment or start to waste a lot of time 
 in recreating the things that i get with all the other 
 languages. it's kind funny to watch that excuse finding.
 i think the leaders of this research project should find a way 
 to make it usable to wider public instead of pursuing their pet 
 projects.


Yeah, I completely agree. We need something like a "D
foundation", with full time  workers, to get to the upper level.
Dec 14 2014
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote:

 On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 As always, different tools for different uses.  Hopefully, D 
 can one day be polished and mainstream enough for the 
 enterprise use case and it will be efficient enough to be 
 deployed at scale too. :)


 when will that be? windows version 25, sqlite version 1147?


As I said earlier, when D garners significant commercial support. 
  I suggested a commercial model of providing a paid compiler 
alongside the free compiler last year, but the D core team wasn't 
interested:

http://forum.dlang.org/post/sglcqsiphpntcdlhvwvn forum.dlang.org

There are other possible commercial models discussed in that 
thread.  D's bounty system was started soon afterwards, but 
probably isn't used as much as it could be.
Dec 14 2014
parent reply "yawniek" <yawniek nowhere.com> writes:
On Sunday, 14 December 2014 at 15:56:20 UTC, Joakim wrote:

 On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote:

 On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 As always, different tools for different uses.  Hopefully, D 
 can one day be polished and mainstream enough for the 
 enterprise use case and it will be efficient enough to be 
 deployed at scale too. :)


 when will that be? windows version 25, sqlite version 1147?


 As I said earlier, when D garners significant commercial 
 support.
  I suggested a commercial model of providing a paid compiler 
 alongside the free compiler last year, but the D core team 
 wasn't interested:

 http://forum.dlang.org/post/sglcqsiphpntcdlhvwvn forum.dlang.org

 There are other possible commercial models discussed in that 
 thread.  D's bounty system was started soon afterwards, but 
 probably isn't used as much as it could be.


well, i am not so sure that commercial models are needed, but 
instead of trying to invent a new gui library, make the os 
available for 32/64. fix all those projects that deal with db, 
gui etc. get rid of all those misleading, outdated projects with 
galloping consumption, since people find those projects with the 
result -> it given up, not working ....
all those little patches, and little add-on's are transformed 
into huge success stories on reddit - man is that getting 
embarrassing.

this language is developed now for over 7 years (i think) and it 
is still not mainstream usable. what has to be done?
Dec 14 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 14 Dec 2014 16:18:26 +0000
yawniek via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 well, i am not so sure that commercial models are needed, but=20
 instead of trying to invent a new gui library, make the os=20
 available for 32/64. fix all those projects that deal with db,=20
 gui etc. get rid of all those misleading, outdated projects with=20
 galloping consumption, since people find those projects with the=20
 result -> it given up, not working ....


will you pay for all that? 'cause, you know, if people don't get paid,
they tend to work on what *they* consider fun.
Dec 14 2014
prev sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 this language is developed now for over 7 years (i think) and 
 it is still not mainstream usable. what has to be done?


Could you elaborate why you think so? I consider D very usable.
Dec 18 2014
prev sibling parent reply "uri" <uri.grill gmail.com> writes:
On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote:

 On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 As always, different tools for different uses.  Hopefully, D 
 can one day be polished and mainstream enough for the 
 enterprise use case and it will be efficient enough to be 
 deployed at scale too. :)


 when will that be? windows version 25, sqlite version 1147?


...[snip]...

Perhaps when more people start helping out we'll see things 
progress more quickly.

D needs more than developers. Right now it needs a few volunteers 
who will update the web site; documentation, news feeds of recent 
PRs closed, recent PRs that are generating interesting 
discussion, roadmaps for the next 12 months indicating what core 
devs are working and status. Stuff that get's people excited 
about the next release and the future of D.

Cheers,
uri
Dec 14 2014
parent reply "NVolcz" <niklas.volcz gmail.com> writes:
On Sunday, 14 December 2014 at 23:25:24 UTC, uri wrote:

 On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote:

 On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 As always, different tools for different uses.  Hopefully, D 
 can one day be polished and mainstream enough for the 
 enterprise use case and it will be efficient enough to be 
 deployed at scale too. :)


 when will that be? windows version 25, sqlite version 1147?


 ...[snip]...

 Perhaps when more people start helping out we'll see things 
 progress more quickly.

 D needs more than developers. Right now it needs a few 
 volunteers who will update the web site; documentation, news 
 feeds of recent PRs closed, recent PRs that are generating 
 interesting discussion, roadmaps for the next 12 months 
 indicating what core devs are working and status. Stuff that 
 get's people excited about the next release and the future of D.

 Cheers,
 uri


Speaking of getting more people involve.
There are some great suggestions in this reddit thread and in the 
linked article:
https://www.reddit.com/r/programming/comments/2p9ff3/how_to_get_started_with_open_source/
Dec 14 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 15/12/2014 8:14 p.m., NVolcz wrote:

 On Sunday, 14 December 2014 at 23:25:24 UTC, uri wrote:

 On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote:

 On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 As always, different tools for different uses.  Hopefully, D can one
 day be polished and mainstream enough for the enterprise use case
 and it will be efficient enough to be deployed at scale too. :)


 when will that be? windows version 25, sqlite version 1147?


 ...[snip]...

 Perhaps when more people start helping out we'll see things progress
 more quickly.

 D needs more than developers. Right now it needs a few volunteers who
 will update the web site; documentation, news feeds of recent PRs
 closed, recent PRs that are generating interesting discussion,
 roadmaps for the next 12 months indicating what core devs are working
 and status. Stuff that get's people excited about the next release and
 the future of D.

 Cheers,
 uri


 Speaking of getting more people involve.
 There are some great suggestions in this reddit thread and in the linked
 article:
 https://www.reddit.com/r/programming/comments/2p9ff3/how_to_get_started_with_open_source/


For reference http://openhatch.org/ has no D projects.
Dec 14 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 On Sunday, 14 December 2014 at 11:53:56 UTC, Paulo Pinto wrote:

 I have seen this in every project where we replaced legacy C++ 
 systems by new ones implemented in .NET and Java.

 First people will complain that the performance isn't 
 comparable, they are bloated, and so on.

 The project goes forward, as it was a management decision.

 Then it goes live, some hiccups that make existing C++ 
 developers rejoice that they were right after all

 Lots of bug reports get generated and application performance 
 gets fine-tuned.

 A few months later systems are running, end users barely see 
 any difference and a few C++ developers saying that the new 
 systems aren't that bad after all.


 I don't doubt that this has been your experience on enterprise 
 projects with a known and stable userbase, but you can't tell 
 me you were able to support the same amount of users per server 
 using java/.net as C++.  Paying for more servers but less for 
 java/.net development may be a worthwhile tradeoff for such 
 stable enterprise rollouts, but any time you have to scale, I 
 doubt java/.net can keep up.

 As always, different tools for different uses.  Hopefully, D 
 can one day be polished and mainstream enough for the 
 enterprise use case and it will be efficient enough to be 
 deployed at scale too. :)



You mean scale like Twitter and LinkedIn?

On my case, two examples of such project was a software stack for 
network monitoring, data aggregation and monitoring for mobile 
networks all the way down to network elements.

The old system was a mix of Perl, C++/CORBA and Motif. The new 
system is all Java, with small C stack for resource constrained 
elements.

Another example was replacing C++ applications in medicine image 
analysis with  90% .NET stack and a mix of C++/Assembly for image 
filters and driver P/Invoke glue.

The problem is that the average coders don't learn to optimize 
code and in the end most business will just shell out money for 
more hardware than software development time.

We had high performance systems running with a stable GC cycles, 
after doing the required optimization work. That is why tools 
like VisualVM and Mission Control exist.


--
Paulo
Dec 14 2014
next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote:

 On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:

 I don't doubt that this has been your experience on enterprise 
 projects with a known and stable userbase, but you can't tell 
 me you were able to support the same amount of users per 
 server using java/.net as C++.  Paying for more servers but 
 less for java/.net development may be a worthwhile tradeoff 
 for such stable enterprise rollouts, but any time you have to 
 scale, I doubt java/.net can keep up.


 You mean scale like Twitter and LinkedIn?


Java NIO has the potential to be really scalable, and the new 
Netty apparently uses it to great effect.  You'll never be able 
to park as many connections using Java as you would in C, but 
concurrent throughput is probably pretty close when done properly.

My issue with Java is just that because of how the library is 
designed, you're fighting against it by trying to limit dynamic 
allocations, so it will probably never be a terribly natural 
experience.  At the same time, it is waaaaay easier to find 
competent Java programmers, which is a significant factor when 
making a business decision.

My personal preference is still for C++ done in a similar manner 
as vibe.d as I think it's the sweet spot between ease of use and 
scalability provided you have a talented team, but I've seen Java 
be used successfully for servicing hundreds of millions of users 
with a high concurrent throughput.
Dec 14 2014
parent reply "Atila Neves" <atila.neves gmail.com> writes:
 My personal preference is still for C++ done in a similar 
 manner as vibe.d as I think it's the sweet spot between ease of 
 use and scalability provided you have a talented team, but I've 
 seen Java be used successfully for servicing hundreds of 
 millions of users with a high concurrent throughput.


So, boost asio then? Miles away from the ease-of-use of vibe.d.

Atila
Dec 15 2014
parent "Sean Kelly" <sean invisibleduck.org> writes:
On Monday, 15 December 2014 at 11:32:30 UTC, Atila Neves wrote:

 My personal preference is still for C++ done in a similar 
 manner as vibe.d as I think it's the sweet spot between ease 
 of use and scalability provided you have a talented team, but 
 I've seen Java be used successfully for servicing hundreds of 
 millions of users with a high concurrent throughput.


 So, boost asio then? Miles away from the ease-of-use of vibe.d.


No, the vibe.d model in C++ using boost coroutines.
Dec 15 2014
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote:

 You mean scale like Twitter and LinkedIn?


Maybe that's why they still lose money hand over fist, especially 
Twitter, because of all the extra servers they have to buy. :p By 
comparison, Whatsapp was able to put millions of users on a 
server with erlang and become profitable with much less revenue:

http://forum.dlang.org/post/bmvwftlyvlgmuehrtvlg forum.dlang.org


 On my case, two examples of such project was a software stack 
 for network monitoring, data aggregation and monitoring for 
 mobile networks all the way down to network elements.

 The old system was a mix of Perl, C++/CORBA and Motif. The new 
 system is all Java, with small C stack for resource constrained 
 elements.

 Another example was replacing C++ applications in medicine 
 image analysis with  90% .NET stack and a mix of C++/Assembly 
 for image filters and driver P/Invoke glue.


It is instructive that you're dropping down to C/C++/Assembly in 
each of these examples: that's not really making the case for 
java/.net on their own.


 The problem is that the average coders don't learn to optimize 
 code and in the end most business will just shell out money for 
 more hardware than software development time.


Yeah, it's all about the particular job and what the tradeoffs 
are there.  Most online apps don't need to scale to extremes, 
which is why they're mostly not written in C++.
Dec 14 2014
next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Sunday, 14 December 2014 at 18:25:26 UTC, Joakim wrote:

 On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote:

 You mean scale like Twitter and LinkedIn?


 Maybe that's why they still lose money hand over fist, 
 especially Twitter, because of all the extra servers they have 
 to buy. :p By comparison, Whatsapp was able to put millions of 
 users on a server with erlang and become profitable with much 
 less revenue:

 http://forum.dlang.org/post/bmvwftlyvlgmuehrtvlg forum.dlang.org


I don't really understand how you can simultaneously advertise 
Erlang and bash Java for inefficiency.  I think the core 
concurrency model in Erlang is really great, and it scales 
horizontally to great effect, but it's a bear to do TCP work in 
and is far less efficient than Java, let alone C++.
Dec 14 2014
parent "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 14 December 2014 at 18:50:44 UTC, Sean Kelly wrote:

 On Sunday, 14 December 2014 at 18:25:26 UTC, Joakim wrote:

 On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote:

 You mean scale like Twitter and LinkedIn?


 Maybe that's why they still lose money hand over fist, 
 especially Twitter, because of all the extra servers they have 
 to buy. :p By comparison, Whatsapp was able to put millions of 
 users on a server with erlang and become profitable with much 
 less revenue:

 http://forum.dlang.org/post/bmvwftlyvlgmuehrtvlg forum.dlang.org


 I don't really understand how you can simultaneously advertise 
 Erlang and bash Java for inefficiency.  I think the core 
 concurrency model in Erlang is really great, and it scales 
 horizontally to great effect, but it's a bear to do TCP work in 
 and is far less efficient than Java, let alone C++.


I'm not trying to say erlang is much more efficient in the 
general case than Java, as I've heard it isn't, but that they 
chose a language and OS that was highly optimized for their use, 
concurrency, and were able to scale using fewer servers as a 
result, as opposed to just throwing general-purpose java/.net and 
more servers at the problem.  Just another example of right tool 
for the job.
Dec 14 2014
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 14 December 2014 at 18:25:26 UTC, Joakim wrote:

 On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote:

 You mean scale like Twitter and LinkedIn?


 Maybe that's why they still lose money hand over fist, 
 especially Twitter, because of all the extra servers they have 
 to buy. :p By comparison, Whatsapp was able to put millions of 
 users on a server with erlang and become profitable with much 
 less revenue:

 http://forum.dlang.org/post/bmvwftlyvlgmuehrtvlg forum.dlang.org


 On my case, two examples of such project was a software stack 
 for network monitoring, data aggregation and monitoring for 
 mobile networks all the way down to network elements.

 The old system was a mix of Perl, C++/CORBA and Motif. The new 
 system is all Java, with small C stack for resource 
 constrained elements.

 Another example was replacing C++ applications in medicine 
 image analysis with  90% .NET stack and a mix of C++/Assembly 
 for image filters and driver P/Invoke glue.


 It is instructive that you're dropping down to C/C++/Assembly 
 in each of these examples: that's not really making the case 
 for java/.net on their own.


I was expecting a comment like that. :)

On the first case, certain network elements are quite resource 
constrained,
so you just have a real time OS, doing SNMP stuff and other 
control operations. So only a small C library could bt delivered 
on those.

Everything else capable of running a JIT enabled JVM was doing so.

On the medicine example, the C++/Assembly code was being used in 
two cases:

- SIMD (maybe with the upcoming SIMD support on .NET, this 
wouldn't be needed any longer)

- COM, many manufacturers provide only COM drivers for their 
devices, no way around it. If the was public, .NET networking 
code could have been used instead as the devices used ethernet.



 The problem is that the average coders don't learn to optimize 
 code and in the end most business will just shell out money 
 for more hardware than software development time.


 Yeah, it's all about the particular job and what the tradeoffs 
 are there.  Most online apps don't need to scale to extremes, 
 which is why they're mostly not written in C++.


Yes, agreed there.

However, there are many places that developers use C and C++, not 
because of speed, rather because for the last decades all the 
other programming languages with native code compilers faded away.

With the current ahead of time native compilation renaissance and 
GPU support on other languages, the need for C and C++ in such 
use cases will decrease.

Still there are quite a few places where C and C++ will matter 
(e.g. embedded, OS drivers, HPC, AAA games, ...) in regards to 
overall computing landscape.

--
Paulo
Dec 14 2014
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
I agree about the general debugging experience on Windows. It's 
improving (at least with Mago), but still not where it should be. 
Partially this would be easy to remedy, such as in case of omitted stack 
frames in Phobos, as mentioned in Vladimir's recent thread that I just 
skimmed through.

Just quickly commenting on the vibe.d specific issues. If you have filed 
any recent bug reports and I didn't respond, this is because I way 
barely able to work on a computer at all during the past weeks. I'll try 
to start catching up a little bit now.

Am 14.12.2014 09:37, schrieb Manu via Digitalmars-d:

 We were trying to use vibe.d, and we encountered bugs.

 We were unable to build Win64 code (vibe.d doesn't support Win64 it
 seems), and the 32bit compiler produces useless OMF output. We
 couldn't link against any of our existing code which was a serious
 inconvenience, but they were understanding and we worked around it.


It does, either by using the "win32" configuration instead of 
"libevent", or by manually providing a pre-compiled version of libevent 
for Win64 (I'd be happy to accept a PR, too). I didn't build it for a 
while though, so it may be that something is broken.


 The real trouble hit when vibe.d's WebSocket support didn't work as
 advertised; it crashed in various circumstances, and debugging was
 impossible.
 vibe.d uses exceptions everywhere, which caused an office full of
 C/C++ programmers to explode with terror, and Visual Studio completely
 craps itself when there are exceptions being thrown.


If you set a breakpoint at __dthrow_c, at least you get a proper call 
stack. It still doesn't enable accessing the exception internals, but 
usually those are less important.

Regarding exceptions themselves, it looks like the mindset of those C++ 
programmers is quite fixed, not the best premise for embracing D (but 
yeah, changing this usually requires some time/effort). Coming from a C 
and C++ without exceptions/RTTI background myself, I understand very 
well where that reaction comes from. However, IMO exceptions as a 
mechanism are very well suited for server environments especially 
because they cannot be (accidentally) ignored, and they often help a lot 
to make the code more readable. In a language that has them as a 
mandatory feature and uses them extensively in its standard library, I 
simply saw no reason to carry the no-exception rule over to D.

Of course they must be used accordingly (only for exceptional 
situations) and the debugger has to properly support them to make the 
debugging experience bearable. Having said that, a call stack + error 
message dumped to stderr is usually all that is needed, so the last 
point is more of a convenience factor when running from within VS.

Lastly, when judging all these things, please always try to remember 
that almost all the work that goes into D (and vibe.d) is non-profit and 
everyone usually only contributes what (s)he is missing. If I would get 
payed through a support contract for my work on vibe.d, I could adjust 
my priorities to suit the requirements of others more, but like this I 
still have to somehow make sure to be able to pay my bills and can't 
just work full time to help other (commercial) projects (although I 
always try to help as far as possible).

Sönke
Dec 14 2014
next sibling parent reply "Nick B" <nick.barbalich gmail.com> writes:
On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote:


 Lastly, when judging all these things, please always try to 
 remember that almost all the work that goes into D (and vibe.d) 
 is non-profit and everyone usually only contributes what (s)he 
 is missing. If I would get payed through a support contract for 
 my work on vibe.d, I could adjust my priorities to suit the 
 requirements of others more, but like this I still have to 
 somehow make sure to be able to pay my bills and can't just 
 work full time to help other (commercial) projects (although I 
 always try to help as far as possible).


Sonke, Can you advise how much a support contract for a 
individual or company seriously interested in using vibe.d might 
cost ?
Dec 14 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 December 2014 at 07:19, Nick B via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote:


 Lastly, when judging all these things, please always try to remember that
 almost all the work that goes into D (and vibe.d) is non-profit and everyone
 usually only contributes what (s)he is missing. If I would get payed through
 a support contract for my work on vibe.d, I could adjust my priorities to
 suit the requirements of others more, but like this I still have to somehow
 make sure to be able to pay my bills and can't just work full time to help
 other (commercial) projects (although I always try to help as far as
 possible).



 Sonke, Can you advise how much a support contract for a individual or
 company seriously interested in using vibe.d might cost ?


Good point, I think you should really put a price on commercial
support if you want it to be taken seriously.
There are lots of companies that wouldn't seriously consider it if it
DIDN'T cost them some money. If they don't pay any money, it doesn't
look legit or professional ;)
Dec 14 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2014 9:10 PM, Manu via Digitalmars-d wrote:

 On 15 December 2014 at 07:19, Nick B via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Sonke, Can you advise how much a support contract for a individual or
 company seriously interested in using vibe.d might cost ?


 Good point, I think you should really put a price on commercial
 support if you want it to be taken seriously.
 There are lots of companies that wouldn't seriously consider it if it
 DIDN'T cost them some money. If they don't pay any money, it doesn't
 look legit or professional ;)



It does look like a great opportunity for Sönke! He gets paid, vibe.d gets 
better, the community gets another commercial user, it's a win all around!

(Of course, that applies to all of you folks working on open source D code - 
think about doing contract support for it.)
Dec 14 2014
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/15/14 12:10 AM, Manu via Digitalmars-d wrote:

 On 15 December 2014 at 07:19, Nick B via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote:


 Lastly, when judging all these things, please always try to remember that
 almost all the work that goes into D (and vibe.d) is non-profit and everyone
 usually only contributes what (s)he is missing. If I would get payed through
 a support contract for my work on vibe.d, I could adjust my priorities to
 suit the requirements of others more, but like this I still have to somehow
 make sure to be able to pay my bills and can't just work full time to help
 other (commercial) projects (although I always try to help as far as
 possible).



 Sonke, Can you advise how much a support contract for a individual or
 company seriously interested in using vibe.d might cost ?


 Good point, I think you should really put a price on commercial
 support if you want it to be taken seriously.
 There are lots of companies that wouldn't seriously consider it if it
 DIDN'T cost them some money. If they don't pay any money, it doesn't
 look legit or professional ;)


OH, it's not that AT ALL.

If I base my company, with real investors and people to be employed, on 
someone's code, and I cannot motivate the developers to support me with 
money, then I am in a shaky situation. It's not the lack of 
professionalism, it's the "I can't fix this, and I can't get the author 
to fix it, so we just have to sit on our thumbs until they do, or hire a 
team to figure out how to do it."

Note, this is not in relation to vibe.d, as we don't use it here, just a 
general view from someone who has used a "near-free" project and paid 
the developer to fix some issues/add features. The cost is so much lower 
than me figuring it out myself.

-Steve
Dec 15 2014
prev sibling parent =?UTF-8?B?IlPDtm5rZQ==?= Ludwig" <sludwig outerproduct.org> writes:
On Monday, 15 December 2014 at 05:10:25 UTC, Manu via 
Digitalmars-d wrote:

 On 15 December 2014 at 07:19, Nick B via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig 
 wrote:


 Lastly, when judging all these things, please always try to 
 remember that
 almost all the work that goes into D (and vibe.d) is 
 non-profit and everyone
 usually only contributes what (s)he is missing. If I would 
 get payed through
 a support contract for my work on vibe.d, I could adjust my 
 priorities to
 suit the requirements of others more, but like this I still 
 have to somehow
 make sure to be able to pay my bills and can't just work full 
 time to help
 other (commercial) projects (although I always try to help as 
 far as
 possible).



 Sonke, Can you advise how much a support contract for a 
 individual or
 company seriously interested in using vibe.d might cost ?


 Good point, I think you should really put a price on commercial
 support if you want it to be taken seriously.
 There are lots of companies that wouldn't seriously consider it 
 if it
 DIDN'T cost them some money. If they don't pay any money, it 
 doesn't
 look legit or professional ;)


I'll try to put something together in January.
Dec 17 2014
prev sibling parent "NVolcz" <niklas.volcz gmail.com> writes:
On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote:

 <snip />

 Lastly, when judging all these things, please always try to 
 remember that almost all the work that goes into D (and vibe.d) 
 is non-profit and everyone usually only contributes what (s)he 
 is missing. If I would get payed through a support contract for 
 my work on vibe.d, I could adjust my priorities to suit the 
 requirements of others more, but like this I still have to 
 somehow make sure to be able to pay my bills and can't just 
 work full time to help other (commercial) projects (although I 
 always try to help as far as possible).

 Sönke


How about adding a support section to vibed.org with possible 
support options you could consider? :-)
Dec 14 2014
prev sibling next sibling parent "Israel" <tl12000 live.com> writes:
Im sorry to hear that.

So many things went wrong here. This is the way i see it.

Basically what you did was introduce a friend of yours to your
colleagues with good impressions on just about everything. This
is like introducing a friend to me and telling me his a great
person even though you know deep down inside you know your friend
doesnt have the best personality in the world.

What you could have done was be sincere and told your colleagues
that D is a great person overall but he does have his drawbacks.
That way they know what to expect and are ready and prepared to
handle D.

Along with that you could have inspired them on a different point
of view. You guys are working with JavaScript :/. Doing something
with D would have been an extraordinary achievement. Thats like
accomplishing a task with a common method. But sometimes you have
to take a leap of faith and accomplish that task in a new way.
This would have given you and your team unique in a way and
probably have given you a good image.
Dec 14 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote:

 There were a few contributing factors, but by far the most significant
 factor was the extremely poor Windows environment support and Visual
 Studio debugging experience.


This is valuable information, while it's fresh in your mind can you please 
submit a bugzilla issue for each point?



 They then made HUGE noises about the quality of documentation. The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The formatting
 didn't help, there's a lot of noise and a lack of structure in the
 documentation's presentation that makes it hard to see the information
 through the layout and noise. As senior software engineers, they
 basically expected that they should be able to read and understand the
 docs, even if they don't really know the language, after all, "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a basic
 level by skimming the docs, but the D docs are an anomaly in this way;
 it seems you have to already know D to be able to understand it
 effectively. They didn't know javascript either, but skimming the
 node.js docs they got the job done in an hour or so, after having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.


I understand what you're saying, but I find it hard to figure out just what to 
do to change it. Any specific suggestions?
Dec 14 2014
next sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Sunday, 14 December 2014 at 19:40:16 UTC, Walter Bright wrote:

 On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote:

 There were a few contributing factors, but by far the most 
 significant
 factor was the extremely poor Windows environment support and 
 Visual
 Studio debugging experience.


 This is valuable information, while it's fresh in your mind can 
 you please submit a bugzilla issue for each point?



 They then made HUGE noises about the quality of documentation. 
 The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The 
 formatting
 didn't help, there's a lot of noise and a lack of structure in 
 the
 documentation's presentation that makes it hard to see the 
 information
 through the layout and noise. As senior software engineers, 
 they
 basically expected that they should be able to read and 
 understand the
 docs, even if they don't really know the language, after all, 
 "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a 
 basic
 level by skimming the docs, but the D docs are an anomaly in 
 this way;
 it seems you have to already know D to be able to understand it
 effectively. They didn't know javascript either, but skimming 
 the
 node.js docs they got the job done in an hour or so, after 
 having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.


 I understand what you're saying, but I find it hard to figure 
 out just what to do to change it. Any specific suggestions?


One thing I ran into often when I was inexperienced with D:
   the template constraints make some signatures extremely messy, 
and it takes a while to figure out when you have e.g. 3 template 
functions of the same name in
std.algorithm, all with crypric signatures.

Example:

ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack, 
Rs needles) if (isForwardRange!R && Rs.length > 0 && 
isForwardRange!(Rs[0]) == isInputRange!(Rs[0]) && 
is(typeof(startsWith!pred(haystack, needles[0]))) && (Rs.length 
== 1 || is(typeof(countUntil!pred(haystack, needles[1..$])))));
ptrdiff_t countUntil(alias pred = "a == b", R, N)(R haystack, N 
needle) if (isInputRange!R && 
is(typeof(binaryFun!pred(haystack.front, needle)) : bool));

countUntil is trivial to use, but the docs make it seem 
complicated
and it takes a while to read them.
(This is not really a good example as with countUntil it's not 
*that*
  bad, but I think it should be enough to show the problem)

In this specific case, it would be useful if the constraint was 
somehow separated from the rest of the signature and less 
emphasized (CSS).

Also, in this example, the documentation text itself immediately 
goes into  detail (e.g. mentioning startsWith!) instead of 
starting with a simple explanation of the concept.

I think this could be helped somewhat if the example

This is one example of "too much noise".


Example of 'not teaching the language':

For the first few months using D, I had no idea what D 'range' (I 
knew Python) is and it made the docs harder to understand.

I think most or all mentions of terms important in D such as 
'range' should link to a *simple* explanation of what a 
range/whatever is (maybe in Ali Cehreli's book?).


Also... some docs are just plain lazy ("does something similar 
but not the same as this C function we couldn't even be arsed to 
link to"), missing examples (or missing *useful* examples, etc.)
- A lot of docs assume the reader knows some specific other 
language, not only C


I occasionally try to push minor doc fixes but currently I'm 
rather swamped, may do some work on that next summer.
Dec 14 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2014 1:00 PM, Kiith-Sa wrote:

 I occasionally try to push minor doc fixes but currently I'm rather swamped,
may
 do some work on that next summer.


Any help is appreciated, even small things.
Dec 14 2014
parent reply "evenex" <vlevenfeld gmail.com> writes:
This is just my $0.02, not to ask for anything specific, but to 
add to the cross-section of perspectives on this topic, to whom 
it may concern:

A colleague and I are writing a framework for building and 
managing complex simulations and chose to implement in D for the 
modeling power that the template system brings, which allows us 
to make an expressive and fairly performant API that is also 
flexible and easily refactored thanks to static assert and 
unittest...

But we keep getting hamstrung by bugs; hitting compiler segfaults 
during template metaprogramming is a very common occurrence, and 
sometimes UFCS fails. We continue to make progress but lose a lot 
of time finding workarounds for apparently valid but noncompiling 
code. We are hoping that with the increased interest in D lately, 
the implementation will stabilize, but we are nervous about the 
long-term prospects.

This is a risk we knowingly undertake in exchange for the 
aforementioned advantages. A lot of cool stuff is possible with D 
that we can't do in other languages but I constantly work with 
the fear that we'll stumble upon some compiler bug in 6 months 
time that we can't find a way around. (I originally tried to 
write this system in C++ and I dread the idea of returning to it.)

One of our target use-cases is gaming, and to this end we hope 
that the difficulty we've had in getting D environments working 
in Windows will be alleviated soon so that we can confidently 
target that platform.

As typical college students (I am a senior, partner is recent 
grad) we can't afford to put up bounties or contract anyone but 
we put up bug reports when we can (this will be easier when dub 
dustmite functionality is fully implemented) and can poke around 
at dmd in gdb in the hopes of getting some useful info to the 
contributors (I have very little knowledge of compilers, though I 
have been gleaning details from running dmd in gdb. I'm not yet 
at the point where I can attempt my own fixes, though I hold out 
hope that some things will click soon and I can make a more 
active contribution effort).

We're willing to invest in D, in whatever way we can, and hope to 
someday (sooner rather than later) add ourselves to the list of D 
success stories.

But, our success depends on a stable, multi-platform 
implementation. So we are open to ways on how we might improve D 
more proactively. Right now we are developing on dmd git head 
(for the latest fixes) but would like to transition to ldc (for 
the optimization) as we solidify our design.
Dec 15 2014
next sibling parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Monday, 15 December 2014 at 20:40:29 UTC, evenex wrote:

 This is just my $0.02, not to ask for anything specific, but to 
 add to the cross-section of perspectives on this topic, to whom 
 it may concern:

 A colleague and I are writing a framework for building and 
 managing complex simulations and chose to implement in D for 
 the modeling power that the template system brings, which 
 allows us to make an expressive and fairly performant API that 
 is also flexible and easily refactored thanks to static assert 
 and unittest...

 But we keep getting hamstrung by bugs; hitting compiler 
 segfaults during template metaprogramming is a very common 
 occurrence, and sometimes UFCS fails. We continue to make 
 progress but lose a lot of time finding workarounds for 
 apparently valid but noncompiling code. We are hoping that with 
 the increased interest in D lately, the implementation will 
 stabilize, but we are nervous about the long-term prospects.

 This is a risk we knowingly undertake in exchange for the 
 aforementioned advantages. A lot of cool stuff is possible with 
 D that we can't do in other languages but I constantly work 
 with the fear that we'll stumble upon some compiler bug in 6 
 months time that we can't find a way around. (I originally 
 tried to write this system in C++ and I dread the idea of 
 returning to it.)

 One of our target use-cases is gaming, and to this end we hope 
 that the difficulty we've had in getting D environments working 
 in Windows will be alleviated soon so that we can confidently 
 target that platform.

 As typical college students (I am a senior, partner is recent 
 grad) we can't afford to put up bounties or contract anyone but 
 we put up bug reports when we can (this will be easier when dub 
 dustmite functionality is fully implemented) and can poke 
 around at dmd in gdb in the hopes of getting some useful info 
 to the contributors (I have very little knowledge of compilers, 
 though I have been gleaning details from running dmd in gdb. 
 I'm not yet at the point where I can attempt my own fixes, 
 though I hold out hope that some things will click soon and I 
 can make a more active contribution effort).

 We're willing to invest in D, in whatever way we can, and hope 
 to someday (sooner rather than later) add ourselves to the list 
 of D success stories.

 But, our success depends on a stable, multi-platform 
 implementation. So we are open to ways on how we might improve 
 D more proactively. Right now we are developing on dmd git head 
 (for the latest fixes) but would like to transition to ldc (for 
 the optimization) as we solidify our design.


Is your project open source?   If so as a student we will likely 
be looking for applications to the 2015 Google Summer of Code, if 
D is accepted as a mentoring organization.  I would need to 
investigate if having a student working on their existing project 
would be allowable, but it might be possible.  We would still 
have to find a mentor for you.

Alternately GSOC 2015 might be your chance to learn a bit more 
about compilers!
Dec 15 2014
parent reply "evenex" <vlevenfeld gmail.com> writes:
On Monday, 15 December 2014 at 21:15:21 UTC, CraigDillabaugh 
wrote:

 Is your project open source?   If so as a student we will 
 likely be looking for applications to the 2015 Google Summer of 
 Code, if D is accepted as a mentoring organization.  I would 
 need to investigate if having a student working on their 
 existing project would be allowable, but it might be possible.  
 We would still have to find a mentor for you.

 Alternately GSOC 2015 might be your chance to learn a bit more 
 about compilers!


It's not currently open source (I am hoping to use this software 
to help me support myself - maybe open-sourcing could open the 
door for that, but it's a one way trip so I am hesitant) but I do 
like the idea of doing GSOC and improving the D language. If it 
involves work with the compiler, I'd also come out better 
equipped to deal with related future issues... How do I find out 
more?
Dec 15 2014
parent "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Monday, 15 December 2014 at 22:23:17 UTC, evenex wrote:

 On Monday, 15 December 2014 at 21:15:21 UTC, CraigDillabaugh 
 wrote:

 Is your project open source?   If so as a student we will 
 likely be looking for applications to the 2015 Google Summer 
 of Code, if D is accepted as a mentoring organization.  I 
 would need to investigate if having a student working on their 
 existing project would be allowable, but it might be possible.
  We would still have to find a mentor for you.

 Alternately GSOC 2015 might be your chance to learn a bit more 
 about compilers!


 It's not currently open source (I am hoping to use this 
 software to help me support myself - maybe open-sourcing could 
 open the door for that, but it's a one way trip so I am 
 hesitant) but I do like the idea of doing GSOC and improving 
 the D language. If it involves work with the compiler, I'd also 
 come out better equipped to deal with related future issues... 
 How do I find out more?


The current state of things is summarized (sort of) in this
thread:

http://forum.dlang.org/thread/fpaxvelugeltxbfmzwqa forum.dlang.org

I am hoping to get some work done on the DWiki projects page over 
the
holidays, so you can look on there for ideas.  If we are accepted
as a mentoring organization then you could find a project on there
you are interested in working on, or come up with your own 
proposal.

Cheers,

Craig
Dec 16 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
On Monday, 15 December 2014 at 20:40:29 UTC, evenex wrote:

 This is just my $0.02, not to ask for anything specific, but to 
 add to the cross-section of perspectives on this topic, to whom 
 it may concern:

 A colleague and I are writing a framework for building and 
 managing complex simulations and chose to implement in D for 
 the modeling power that the template system brings, which 
 allows us to make an expressive and fairly performant API that 
 is also flexible and easily refactored thanks to static assert 
 and unittest...

 But we keep getting hamstrung by bugs; hitting compiler 
 segfaults during template metaprogramming is a very common 
 occurrence, and sometimes UFCS fails. We continue to make 
 progress but lose a lot of time finding workarounds for 
 apparently valid but noncompiling code. We are hoping that with 
 the increased interest in D lately, the implementation will 
 stabilize, but we are nervous about the long-term prospects.

 This is a risk we knowingly undertake in exchange for the 
 aforementioned advantages. A lot of cool stuff is possible with 
 D that we can't do in other languages but I constantly work 
 with the fear that we'll stumble upon some compiler bug in 6 
 months time that we can't find a way around. (I originally 
 tried to write this system in C++ and I dread the idea of 
 returning to it.)


I can understand all of the above. I'm in a similar situation. 
Fortunately, I've always been able to find a workaround - so far.


 One of our target use-cases is gaming, and to this end we hope 
 that the difficulty we've had in getting D environments working 
 in Windows will be alleviated soon so that we can confidently 
 target that platform.

 As typical college students (I am a senior, partner is recent 
 grad) we can't afford to put up bounties or contract anyone but 
 we put up bug reports when we can (this will be easier when dub 
 dustmite functionality is fully implemented) and can poke 
 around at dmd in gdb in the hopes of getting some useful info 
 to the contributors (I have very little knowledge of compilers, 
 though I have been gleaning details from running dmd in gdb. 
 I'm not yet at the point where I can attempt my own fixes, 
 though I hold out hope that some things will click soon and I 
 can make a more active contribution effort).

 We're willing to invest in D, in whatever way we can, and hope 
 to someday (sooner rather than later) add ourselves to the list 
 of D success stories.

 But, our success depends on a stable, multi-platform 
 implementation. So we are open to ways on how we might improve 
 D more proactively. Right now we are developing on dmd git head 
 (for the latest fixes) but would like to transition to ldc (for 
 the optimization) as we solidify our design.
Dec 15 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2014 12:40 PM, evenex wrote:

 But we keep getting hamstrung by bugs; hitting compiler segfaults during
 template metaprogramming is a very common occurrence, and sometimes UFCS fails.


We've made great progress fixing bugs - but if they aren't reported, they don't 
get fixed. Please make sure all the ones you encounter are filed on bugzilla.
Dec 15 2014
parent reply "evenex" <vlevenfeld gmail.com> writes:
On Monday, 15 December 2014 at 23:04:20 UTC, Walter Bright wrote:

 We've made great progress fixing bugs - but if they aren't 
 reported, they don't get fixed. Please make sure all the ones 
 you encounter are filed on bugzilla.


Yes, the reports are getting filed - I don't mean to suggest that 
bugs are not getting fixed (some I've filed have been already 
been fixed, and I usually at least hear back about them within a 
couple of days), just sharing my thoughts and experiences 
developing with D over the past 6 months. In all, the positives 
significantly outweigh the negatives and the situation continues 
to improve.
Dec 15 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2014 6:51 PM, evenex wrote:

 On Monday, 15 December 2014 at 23:04:20 UTC, Walter Bright wrote:

 We've made great progress fixing bugs - but if they aren't reported, they
 don't get fixed. Please make sure all the ones you encounter are filed on
 bugzilla.


 Yes, the reports are getting filed -


Thank you. This is critical.
Dec 15 2014
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/12/2014 9:40 a.m., evenex wrote:

 But we keep getting hamstrung by bugs; hitting compiler segfaults during
 template metaprogramming is a very common occurrence, and sometimes UFCS
 fails. We continue to make progress but lose a lot of time finding
 workarounds for apparently valid but noncompiling code. We are hoping
 that with the increased interest in D lately, the implementation will
 stabilize, but we are nervous about the long-term prospects.


Something I've learned while working with templates in D is, there is a 
very specific way to write them. Especially to work at compile time.
I'm wondering if you were fighting the compiler because of this.

Although by the sounds yes, it was bugs, so good thing they are getting 
fixed anyway.
Dec 15 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2014 4:32 PM, Rikki Cattermole wrote:

 Although by the sounds yes, it was bugs, so good thing they are getting fixed
 anyway.


They won't get fixed unless they get filed in bugzilla!
Dec 15 2014
prev sibling parent reply "evenex" <vlevenfeld gmail.com> writes:
On Tuesday, 16 December 2014 at 00:32:27 UTC, Rikki Cattermole 
wrote:

 Something I've learned while working with templates in D is, 
 there is a very specific way to write them. Especially to work 
 at compile time.
 I'm wondering if you were fighting the compiler because of this.


What specific way do you mean? I don't often get the feeling that 
I'm fighting the compiler (like I often do in C++), but it can be 
hard to say what's a compiler error and whats my own mistake.
Dec 15 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/12/2014 4:31 p.m., evenex wrote:

 On Tuesday, 16 December 2014 at 00:32:27 UTC, Rikki Cattermole wrote:

 Something I've learned while working with templates in D is, there is
 a very specific way to write them. Especially to work at compile time.
 I'm wondering if you were fighting the compiler because of this.


 What specific way do you mean? I don't often get the feeling that I'm
 fighting the compiler (like I often do in C++), but it can be hard to
 say what's a compiler error and whats my own mistake.


Its mostly for CTFE, not stuff your general dev will touch even in D.
Like generating javascript from data models or routes [0].

Summary:
"Helper functions" where by they have one task that does not change, and 
can be gained purely from the parameters given (mostly template args).
"Generator functions" where by they do some task that requires "helper 
functions" but cannot be ran at CTFE or generate code to be ran at runtime.

I started writing a small booklet on this, if you got an email if you're 
interested or some way to send you. Please let me know.

[0] 
https://github.com/rikkimax/Cmsed/tree/master/source/base/cmsed/base/internal/generators/js
Dec 15 2014
next sibling parent reply "MattCoder" <stopthespam mail.com> writes:
On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole 
wrote:

 I started writing a small booklet on this, if you got an email 
 if you're interested or some way to send you. Please let me 
 know.


Do you mind to share with us all? :)

Matheus.
Dec 15 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/12/2014 5:11 p.m., MattCoder wrote:

 On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole wrote:

 I started writing a small booklet on this, if you got an email if
 you're interested or some way to send you. Please let me know.


 Do you mind to share with us all? :)

 Matheus.


https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
No guarantees of how long it'll stay up there.

And to reiterate, its only just a start. And I don't know if I ever 
complete it. There isn't really enough material for an actual book. 
Maybe booklet but meh.
Dec 15 2014
next sibling parent "uri" <uri.grill gmail.com> writes:
On Tuesday, 16 December 2014 at 05:48:27 UTC, Rikki Cattermole 
wrote:

 On 16/12/2014 5:11 p.m., MattCoder wrote:

 On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole 
 wrote:

 I started writing a small booklet on this, if you got an 
 email if
 you're interested or some way to send you. Please let me know.


 Do you mind to share with us all? :)

 Matheus.


 https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
 No guarantees of how long it'll stay up there.

 And to reiterate, its only just a start. And I don't know if I 
 ever complete it. There isn't really enough material for an 
 actual book. Maybe booklet but meh.


This is a great start, keep going with it!!

A book that looked at the details of CTFE with examples and 
comparison of patterns implemented in CTFE vs. RT would be a 
really nice addition to the D books already available.
Dec 15 2014
prev sibling next sibling parent "Nick B" <nick.barbalich gmail.com> writes:
On Tuesday, 16 December 2014 at 05:48:27 UT

 https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
 No guarantees of how long it'll stay up there.

 And to reiterate, its only just a start.


Agreed its a great start.

Nick
Dec 15 2014
prev sibling next sibling parent "MattCoder" <stopthespam mail.com> writes:
On Tuesday, 16 December 2014 at 05:48:27 UTC, Rikki Cattermole 
wrote:

 https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
 No guarantees of how long it'll stay up there.

 And to reiterate, its only just a start. And I don't know if I 
 ever complete it. There isn't really enough material for an 
 actual book. Maybe booklet but meh.


Very good I liked and thank you for this!

Matheus.
Dec 16 2014
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/12/2014 6:48 p.m., Rikki Cattermole wrote:

 On 16/12/2014 5:11 p.m., MattCoder wrote:

 On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole wrote:

 I started writing a small booklet on this, if you got an email if
 you're interested or some way to send you. Please let me know.


 Do you mind to share with us all? :)

 Matheus.


 https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing

 No guarantees of how long it'll stay up there.

 And to reiterate, its only just a start. And I don't know if I ever
 complete it. There isn't really enough material for an actual book.
 Maybe booklet but meh.


Update, had a look into offerings for publishing, going with lulu.
It'll be a pocket book. Although won't publish to book format for a 
while (ebook only). Around 50 pages.
It won't be centered purely on D, more this is what could be available 
and this is how to deal with it in e.g. D.
Basically, I know there is very little resources on CTFE in any form 
published. So my goal is to get this authoritative as possible on the 
subject.
So with any luck, 50 years from now people will still be asking 
questions about what D was, and its state when it was written.

I have about 10 pages to go. Uses cases, 1 design pattern, bunch of 
exploring of language support (LISP) and some misc stuff. So maybe 
sooner rather then later there will be an announcement.
Dec 19 2014
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 19 December 2014 at 11:12:04 UTC, Rikki Cattermole 
wrote:

 Basically, I know there is very little resources on CTFE in any 
 form published. So my goal is to get this authoritative as 
 possible on the subject.
 So with any luck, 50 years from now people will still be asking 
 questions about what D was, and its state when it was written.

 I have about 10 pages to go. Uses cases, 1 design pattern, 
 bunch of exploring of language support (LISP) and some misc 
 stuff. So maybe sooner rather then later there will be an 
 announcement.


Do you have a repo for the work-in-progress, or some way to take 
patches?  (e.g. grammar fixes)

-Wyatt
Dec 19 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 20/12/2014 2:03 a.m., Wyatt wrote:

 On Friday, 19 December 2014 at 11:12:04 UTC, Rikki Cattermole wrote:

 Basically, I know there is very little resources on CTFE in any form
 published. So my goal is to get this authoritative as possible on the
 subject.
 So with any luck, 50 years from now people will still be asking
 questions about what D was, and its state when it was written.

 I have about 10 pages to go. Uses cases, 1 design pattern, bunch of
 exploring of language support (LISP) and some misc stuff. So maybe
 sooner rather then later there will be an announcement.


 Do you have a repo for the work-in-progress, or some way to take
 patches?  (e.g. grammar fixes)

 -Wyatt


Assuming your email that is appearing in Thunderbird is correct, I'll 
email you when MattCoder emails me (don't have his email).
That way, one email chain.
Dec 19 2014
prev sibling parent reply "MattCoder" <stopthespam mail.com> writes:
On Friday, 19 December 2014 at 11:12:04 UTC, Rikki Cattermole 
wrote:

 ...
 I have about 10 pages to go. Uses cases, 1 design pattern, 
 bunch of exploring of language support (LISP) and some misc 
 stuff. So maybe sooner rather then later there will be an 
 announcement.


Please let us know!

Matheus.
Dec 19 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 20/12/2014 2:54 a.m., MattCoder wrote:

 On Friday, 19 December 2014 at 11:12:04 UTC, Rikki Cattermole wrote:

 ...
 I have about 10 pages to go. Uses cases, 1 design pattern, bunch of
 exploring of language support (LISP) and some misc stuff. So maybe
 sooner rather then later there will be an announcement.


 Please let us know!

 Matheus.


Its hard to find your email!

Email me? alphaglosined // gmail // com
Dec 19 2014
parent "MattCoder" <stopthespam mail.com> writes:
On Friday, 19 December 2014 at 17:00:56 UTC, Rikki Cattermole 
wrote:

 Its hard to find your email!

 Email me? alphaglosined // gmail // com


Done! :)

Matheus.
Dec 19 2014
prev sibling parent "evenex" <vlevenfeld gmail.com> writes:
On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole 
wrote:

 Its mostly for CTFE, not stuff your general dev will touch even 
 in D.
 Like generating javascript from data models or routes [0].

 Summary:
 "Helper functions" where by they have one task that does not 
 change, and can be gained purely from the parameters given 
 (mostly template args).
 "Generator functions" where by they do some task that requires 
 "helper functions" but cannot be ran at CTFE or generate code 
 to be ran at runtime.

 I started writing a small booklet on this, if you got an email 
 if you're interested or some way to send you. Please let me 
 know.

 [0] 
 https://github.com/rikkimax/Cmsed/tree/master/source/base/cmsed/base/internal/generators/js


Thanks, I've sent you an email through github. I use the helper 
function pattern a regularly (I think Ali put it in his book) but 
I don't think I'm familiar with generators. Looks useful for 
implementing some lazy UFCS compute kernels I've been considering.
Dec 15 2014
prev sibling next sibling parent reply Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/14/14, Kiith-Sa via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Example:

 ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack,
 Rs needles) if (isForwardRange!R && Rs.length > 0 &&
 isForwardRange!(Rs[0]) == isInputRange!(Rs[0]) &&
 is(typeof(startsWith!pred(haystack, needles[0]))) && (Rs.length
 == 1 || is(typeof(countUntil!pred(haystack, needles[1..$])))));
 ptrdiff_t countUntil(alias pred = "a == b", R, N)(R haystack, N
 needle) if (isInputRange!R &&
 is(typeof(binaryFun!pred(haystack.front, needle)) : bool));


Yeah, this is still a problem even if you're experienced with
templates. It's a wall of text.

It seems like we're treating template constraints as an internal
feature (just to use them to limit the possible arguments or allow
overloading against other templates), but I think constraints should
also be looked at as a source of documentation ("Can I call this
template with this argument type? Let's see the constraint.. Whoa this
is complicated..").

CSS trickery might work, but I'd prefer if we didn't beat around the
bush and instead implemented constraits as separate templates if they
become too complicated, e.g. turn the above to:

ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack,
Rs needles) if (canCountUntil!(pred, R, Rs);

And then the canCountUntil template would be separately documented,
something like:

/** A range can be counted if:
- R is a forward range
- pred is a valid string comparison predicate, or a function that can
compare R.front with Rs.front
- ...
 */
template canCountUntil(alias pred, R, Rs...)
{
    ...
}

I mean the predicate itself kind of documents this, but it's very
unreadable despite the logic making sense.

We already have things like isInputRange, and functions with
constraints would likely look horrible if we copy-pasted the
isInputRange implementation directly into their constraints rather
than use a simple isInputRange!R check. In the same fashion the
countUntil (and other functions with complex constraints) should have
a helper template that's used as a constraint (like I've shown above).
Dec 14 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2014 2:59 PM, Andrej Mitrovic via Digitalmars-d wrote:

 CSS trickery might work, but I'd prefer if we didn't beat around the
 bush and instead implemented constraits as separate templates if they
 become too complicated, e.g. turn the above to:


I think this is a fine idea.
Dec 14 2014
prev sibling next sibling parent "NVolcz" <niklas.volcz gmail.com> writes:
On Sunday, 14 December 2014 at 21:00:13 UTC, Kiith-Sa wrote:

 On Sunday, 14 December 2014 at 19:40:16 UTC, Walter Bright 
 wrote:
 <snip />

 One thing I ran into often when I was inexperienced with D:
   the template constraints make some signatures extremely 
 messy, and it takes a while to figure out when you have e.g. 3 
 template functions of the same name in
 std.algorithm, all with crypric signatures.

 <snip />


Super nice idea!
Create a PR for this?
Dec 14 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-12-14 22:00, Kiith-Sa wrote:


 One thing I ran into often when I was inexperienced with D:
    the template constraints make some signatures extremely messy, and it
 takes a while to figure out when you have e.g. 3 template functions of
 the same name in
 std.algorithm, all with crypric signatures.

 Example:

 ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack, Rs
 needles) if (isForwardRange!R && Rs.length > 0 && isForwardRange!(Rs[0])
 == isInputRange!(Rs[0]) && is(typeof(startsWith!pred(haystack,
 needles[0]))) && (Rs.length == 1 || is(typeof(countUntil!pred(haystack,
 needles[1..$])))));
 ptrdiff_t countUntil(alias pred = "a == b", R, N)(R haystack, N needle)
 if (isInputRange!R && is(typeof(binaryFun!pred(haystack.front, needle))
 : bool));

 countUntil is trivial to use, but the docs make it seem complicated
 and it takes a while to read them.
 (This is not really a good example as with countUntil it's not *that*
   bad, but I think it should be enough to show the problem)

 In this specific case, it would be useful if the constraint was somehow
 separated from the rest of the signature and less emphasized (CSS).


I completely agree. Using default arguments with values like __FILE__ 
and __LINE__ makes it look complicated as well, and though those 
parameters are most likely never used. The upcoming std.log is perfect 
example of this issue [1].

[1] 


-- 
/Jacob Carlborg
Dec 15 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-12-14 22:00, Kiith-Sa wrote:


 One thing I ran into often when I was inexperienced with D:
    the template constraints make some signatures extremely messy, and it
 takes a while to figure out when you have e.g. 3 template functions of
 the same name in
 std.algorithm, all with crypric signatures.

 Example:

 ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack, Rs
 needles) if (isForwardRange!R && Rs.length > 0 && isForwardRange!(Rs[0])
 == isInputRange!(Rs[0]) && is(typeof(startsWith!pred(haystack,
 needles[0]))) && (Rs.length == 1 || is(typeof(countUntil!pred(haystack,
 needles[1..$])))));
 ptrdiff_t countUntil(alias pred = "a == b", R, N)(R haystack, N needle)
 if (isInputRange!R && is(typeof(binaryFun!pred(haystack.front, needle))
 : bool));

 countUntil is trivial to use, but the docs make it seem complicated
 and it takes a while to read them.
 (This is not really a good example as with countUntil it's not *that*
   bad, but I think it should be enough to show the problem)

 In this specific case, it would be useful if the constraint was somehow
 separated from the rest of the signature and less emphasized (CSS).


I made a suggestion for simplifying signatures in the documentation here [1]

[1] http://forum.dlang.org/thread/lt1hai$186b$1 digitalmars.com

-- 
/Jacob Carlborg
Dec 15 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2014 12:27 AM, Jacob Carlborg wrote:

 I made a suggestion for simplifying signatures in the documentation here [1]

 [1] http://forum.dlang.org/thread/lt1hai$186b$1 digitalmars.com



Please file as an enhancement request in bugzilla. Suggestions in the n.g. are 
likely to be forgotten.
Dec 15 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-12-15 10:13, Walter Bright wrote:


 Please file as an enhancement request in bugzilla. Suggestions in the
 n.g. are likely to be forgotten.


It looks like that has already been filed: 
https://issues.dlang.org/show_bug.cgi?id=13676

-- 
/Jacob Carlborg
Dec 15 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/15/2014 7:36 AM, Jacob Carlborg wrote:

 It looks like that has already been filed:
 https://issues.dlang.org/show_bug.cgi?id=13676


Thanks!
Dec 15 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 December 2014 at 07:00, Kiith-Sa via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 14 December 2014 at 19:40:16 UTC, Walter Bright wrote:

 On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote:

 There were a few contributing factors, but by far the most significant
 factor was the extremely poor Windows environment support and Visual
 Studio debugging experience.



 This is valuable information, while it's fresh in your mind can you please
 submit a bugzilla issue for each point?



 They then made HUGE noises about the quality of documentation. The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The formatting
 didn't help, there's a lot of noise and a lack of structure in the
 documentation's presentation that makes it hard to see the information
 through the layout and noise. As senior software engineers, they
 basically expected that they should be able to read and understand the
 docs, even if they don't really know the language, after all, "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a basic
 level by skimming the docs, but the D docs are an anomaly in this way;
 it seems you have to already know D to be able to understand it
 effectively. They didn't know javascript either, but skimming the
 node.js docs they got the job done in an hour or so, after having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.



 I understand what you're saying, but I find it hard to figure out just
 what to do to change it. Any specific suggestions?



 One thing I ran into often when I was inexperienced with D:
   the template constraints make some signatures extremely messy, and it
 takes a while to figure out when you have e.g. 3 template functions of the
 same name in
 std.algorithm, all with crypric signatures.

 Example:

 ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack, Rs
 needles) if (isForwardRange!R && Rs.length > 0 && isForwardRange!(Rs[0]) ==
 isInputRange!(Rs[0]) && is(typeof(startsWith!pred(haystack, needles[0]))) &&
 (Rs.length == 1 || is(typeof(countUntil!pred(haystack, needles[1..$])))));
 ptrdiff_t countUntil(alias pred = "a == b", R, N)(R haystack, N needle) if
 (isInputRange!R && is(typeof(binaryFun!pred(haystack.front, needle)) :
 bool));

 countUntil is trivial to use, but the docs make it seem complicated
 and it takes a while to read them.
 (This is not really a good example as with countUntil it's not *that*
  bad, but I think it should be enough to show the problem)

 In this specific case, it would be useful if the constraint was somehow
 separated from the rest of the signature and less emphasized (CSS).

 Also, in this example, the documentation text itself immediately goes into
 detail (e.g. mentioning startsWith!) instead of starting with a simple
 explanation of the concept.

 I think this could be helped somewhat if the example

 This is one example of "too much noise".


This is an excellent example. That wall of text is totally unacceptable.
It was the string functions that had my colleagues head spinning.
He wanted to do some extremely basic string operations, and
to!int(myString)... these things were all very hard for him to
understand from the docs.
Dec 17 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 December 2014 at 05:39, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/14/2014 12:37 AM, Manu via Digitalmars-d wrote:

 There were a few contributing factors, but by far the most significant
 factor was the extremely poor Windows environment support and Visual
 Studio debugging experience.



 This is valuable information, while it's fresh in your mind can you please
 submit a bugzilla issue for each point?


I'll probe for more feedback.
Sorry, I don't have work time allocated to this >_<



 They then made HUGE noises about the quality of documentation. The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The formatting
 didn't help, there's a lot of noise and a lack of structure in the
 documentation's presentation that makes it hard to see the information
 through the layout and noise. As senior software engineers, they
 basically expected that they should be able to read and understand the
 docs, even if they don't really know the language, after all, "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a basic
 level by skimming the docs, but the D docs are an anomaly in this way;
 it seems you have to already know D to be able to understand it
 effectively. They didn't know javascript either, but skimming the
 node.js docs they got the job done in an hour or so, after having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.



 I understand what you're saying, but I find it hard to figure out just what
 to do to change it. Any specific suggestions?


I don't really know either. I can recall my own experience that the
documentation was really confronting, but I'm used to it now, and I
don't refer it frequently enough to really care anymore.
I think any of us in this community will have trouble seeing the
problems with the presentation here.

One thing I know for sure, is when they are confronted with
constraints, especially on templates, they have absolutely no idea
what they're looking at... and even I find it hard to read them.
For my money, the constraints are less important information, and I
think it should be separated from the declaration in the docs.
Perhaps a better approach would be to convey that information in the
parameter descriptions; ie, "'A' must be a forwardRange".

I think there's also a lot of magic letters in function declarations,
especially in templates. I wonder if more meaningful names would help
in a lot of cases?

I think it would be a good idea to make the template args and the
runtime args look more visually distinct. D has a subtle template
syntax, and it would be good to have something that clarifies which
args are template or runtime args at a glance. It can look like quite
a confusing mess currently in many cases.


I'd suggest to look at high-quality commercial documentation, like
MSDN or wherever.
Here's one I'm familiar with:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh309466(v=vs.85).aspx
My feeling is the MS docs are well organised, there's always the lest
amount of text on a page at any given time.
It starts with 'getting started':
http://msdn.microsoft.com/en-us/library/windows/desktop/hh769064(v=vs.85).aspx
Then there is 'how to's for many common tasks:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh404569(v=vs.85).aspx
This is a reference for a class:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476379(v=vs.85).aspx
For comparison, our pages show reference for multiple classes, and you
can only tell that something is contained in a class with a subtle
indentation: (consider SList)
http://dlang.org/phobos/std_container.html

Each page only has one thing. It dynamically fetches bits of data as
you navigate, rather than reloading whole pages and assaulting you
with a wall of text.

Let's look at something else... Since none of us had ever written a
line of javascript, and we had to learn to write a node.js server in a
few hours, this came up: http://jquery.com/
They have interactive tutorials with video presentations and even a
theme song O_O: http://try.jquery.com/levels/1/sections/2
Their API reference is a bit lame compared to Microsoft, but the
function reference is pretty good:http://api.jquery.com/dequeue/
What's interesting about that link is they're doing something cool
that we already have; they have some example code, and they offer the
button to run it. We have that on the front page of dlang.com, but we
don't use it in the docs anywhere that I know of.

The node.js docs are disgraceful:
http://nodejs.org/api/child_process.html#child_process_event_disconnect
they're practically as bad as ours, but I find the styling much more
readable. Our docs are dominated by horizontal bars, weird colours,
random bold-ness, but no real distinctions in font size or style.
Their docs use text styling much more effectively than we do to my eye.

It's all subjective. My point is, the feeling I get from looking
around the big players docs, there is a clear difference in quality.
Past the installation process, and path to 'hello world', this is
probably the most important first impression the language will make.
Dec 17 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 17 Dec 2014 18:06:25 +1000
Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I'd suggest to look at high-quality commercial documentation, like
 MSDN or wherever.


please, no! the fact that you are used to it doesn't mean that msdn is
a quality dox.

besides, msdn references are exactly what phobos documentation is:
description of functions. will msdn reference dox help you to learn
msvc? yet you citing it as "high-quality" and blaming phobos dox for
doing (or, rather, not doing) the same.


 One thing I know for sure, is when they are confronted with
 constraints, especially on templates, they have absolutely no idea
 what they're looking at...


did they ever tried to learn the language? seems that you just throwed
phobos dox at them and expecting them to use that dox to learn D.
D is not C. D is not C++. one must learn it before using it. and phobos
documentation is not for learning the language, it's reference for
phobos.

i bet the story was like this: "guys, look at this cool language, it's
almost like C++, and has some great features! let's use it!" "ah,
almost like C++? so we don't have to learn? great, let's do it! but...
hey... what do all that gibberish in documentation mean? i've never
seen that is C++... screw it, this wannabe C++ language is awful!"
Dec 17 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 17 December 2014 at 10:16:22 UTC, ketmar via 
Digitalmars-d wrote:

 On Wed, 17 Dec 2014 18:06:25 +1000
 Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I'd suggest to look at high-quality commercial documentation,
 like MSDN or wherever.


 please, no! the fact that you are used to it doesn't mean that
 msdn is a quality dox.


Frankly, I think you're letting your prejudices against the 
source of the documentation cloud your judgement of the quality.  
Much as I hate to admit it, their _reference_ documentation is 
much more readable at the baseline.


 besides, msdn references are exactly what phobos documentation
 is: description of functions. will msdn reference dox help you
 to learn msvc? yet you citing it as "high-quality" and blaming
 phobos dox for doing (or, rather, not doing) the same.


And yet they have much better organisation and they're much _less 
noisy_.  This is what we mean when we talk about "quality" in 
documentation.  Hell, a lot of CPAN docs are easier to follow 
than the Phobos stuff, and that's _Perl_ for crissakes!


 One thing I know for sure, is when they are confronted with
 constraints, especially on templates, they have absolutely no
 idea what they're looking at...


 did they ever tried to learn the language? seems that you just
 throwed phobos dox at them and expecting them to use that dox to
 learn D.  D is not C. D is not C++. one must learn it before
 using it.  and phobos documentation is not for learning the
 language, it's reference for phobos.


Bull.  D isn't magic and expecting that people need to set aside 
a chunk of time to "learn" it is really silly.  But it's not as 
silly as the idea that you don't learn the language by diving in. 
  You know, by using it (and the standard library) to solve a 
problem?  This is simply how people pick up new programming 
languages.


 i bet the story was like this: "guys, look at this cool
 language, it's almost like C++, and has some great features!
 let's use it!" "ah, almost like C++? so we don't have to learn?
 great, let's do it!  but...  hey... what do all that gibberish
 in documentation mean? i've never seen that is C++... screw it,
 this wannabe C++ language is awful!"


It's more akin to the Haskell reaction: "This seems neat, but 
it's asking way too much of me and I don't have time for it."  We 
know this isn't how the language _actually_ is; that it's really 
quite forgiving and friendly if you know any other curly-braces 
language, but you'd never know by looking at the docs.

-Wyatt
Dec 17 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 17 Dec 2014 15:01:30 +0000
Wyatt via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 besides, msdn references are exactly what phobos documentation
 is: description of functions. will msdn reference dox help you
 to learn msvc? yet you citing it as "high-quality" and blaming
 phobos dox for doing (or, rather, not doing) the same.


 And yet they have much better organisation and they're much _less=20
 noisy_.


did you seen at least one template in winapi? and at least one
constrained template? it's easy to remove constraints from phobos dox.
guess what people will say then? "dox is awful, there are no clearly
seend constraints there!"


 This is what we mean when we talk about "quality" in=20
 documentation.  Hell, a lot of CPAN docs are easier to follow=20
 than the Phobos stuff, and that's _Perl_ for crissakes!


either i forgot something, or perl doesn't have templates too.


 Bull.  D isn't magic and expecting that people need to set aside=20
 a chunk of time to "learn" it is really silly.


i hope such people will never adopt D.


 But it's not as=20
 silly as the idea that you don't learn the language by diving in.


using the tools you never used before, without training, to solve
production tasks. this is what seems to be silly for me.


   You know, by using it (and the standard library) to solve a=20
 problem?  This is simply how people pick up new programming=20
 languages.


so i'm not a human then.


 It's more akin to the Haskell reaction: "This seems neat, but=20
 it's asking way too much of me and I don't have time for it."  We=20
 know this isn't how the language _actually_ is; that it's really=20
 quite forgiving and friendly if you know any other curly-braces=20
 language, but you'd never know by looking at the docs.


if people want to use reference documentation to learn the language, i
myself prefer this people to use anything except D. and i bet that php
is what they want.
Dec 17 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 17 December 2014 at 15:15:41 UTC, ketmar via 
Digitalmars-d wrote:

 On Wed, 17 Dec 2014 15:01:30 +0000
 Wyatt via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 besides, msdn references are exactly what phobos 
 documentation
 is: description of functions. will msdn reference dox help 
 you
 to learn msvc? yet you citing it as "high-quality" and 
 blaming
 phobos dox for doing (or, rather, not doing) the same.


 And yet they have much better organisation and they're much 
 _less noisy_.


 did you seen at least one template in winapi? and at least one
 constrained template? it's easy to remove constraints from 
 phobos dox.
 guess what people will say then? "dox is awful, there are no 
 clearly
 seend constraints there!"


 This is what we mean when we talk about "quality" in 
 documentation.  Hell, a lot of CPAN docs are easier to follow 
 than the Phobos stuff, and that's _Perl_ for crissakes!


 either i forgot something, or perl doesn't have templates too.


 Bull.  D isn't magic and expecting that people need to set 
 aside a chunk of time to "learn" it is really silly.


 i hope such people will never adopt D.


 But it's not as silly as the idea that you don't learn the 
 language by diving in.


 using the tools you never used before, without training, to 
 solve
 production tasks. this is what seems to be silly for me.


   You know, by using it (and the standard library) to solve a 
 problem?  This is simply how people pick up new programming 
 languages.


 so i'm not a human then.


 It's more akin to the Haskell reaction: "This seems neat, but 
 it's asking way too much of me and I don't have time for it."  
 We know this isn't how the language _actually_ is; that it's 
 really quite forgiving and friendly if you know any other 
 curly-braces language, but you'd never know by looking at the 
 docs.


 if people want to use reference documentation to learn the 
 language, i
 myself prefer this people to use anything except D. and i bet 
 that php
 is what they want.


Btw, a guy I know could go into a D program I had written and 
change things as needed by simply looking at the code and the 
library reference. He had no previous knowledge of D. It is 
possible to do that in D as well. In order to use the full power 
of the language, you have to invest time, however. Same goes for 
any of the more complex languages.
Dec 17 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 17 Dec 2014 16:08:43 +0000
Chris via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Btw, a guy I know could go into a D program I had written and=20
 change things as needed by simply looking at the code and the=20
 library reference. He had no previous knowledge of D. It is=20
 possible to do that in D as well. In order to use the full power=20
 of the language, you have to invest time, however. Same goes for=20
 any of the more complex languages.


yes, it is possible to make small hacks here and there. but in no way
it is possible to throw people writing production code without proper
training in new language. that code will barely work (if it is at all)
and will be unmaintainable mess.
Dec 17 2014
parent "David Eagen" <davideagen mailinator.com> writes:
The worst part of the docs is the mass of linked text at the top. 
When are we going to switch to the new layout? It's much better 
than the current layout.
Dec 17 2014
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 17 December 2014 at 15:15:41 UTC, ketmar via 
Digitalmars-d wrote:

 On Wed, 17 Dec 2014 15:01:30 +0000 Wyatt via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:


 And yet they have much better organisation and they're much
 _less noisy_.


 did you seen at least one template in winapi? and at least one
 constrained template?


Irrelevant to my point.


 it's easy to remove constraints from phobos dox.  guess what
 people will say then? "dox is awful, there are no clearly seend
 constraints there!"


Wooooah, hold up there, pal!  At no point has ANYONE advocated 
removing the constraints from the documentation entirely.  Could 
you please stop pretending that every suggestion for change 
involves a shift of extremes?


 This is what we mean when we talk about "quality" in
 documentation.  Hell, a lot of CPAN docs are easier to follow
 than the Phobos stuff, and that's _Perl_ for crissakes!


 either i forgot something, or perl doesn't have templates too.


Again, this is irrelevant to the topic, which is "Phobos 
documentation is accurate but often somewhat unreadable, and 
that's a bad thing".  I made this point to reiterate that even a 
language reviled for being "write once; read never" often has 
clearer documentation.


 Bull.  D isn't magic and expecting that people need to set
 aside a chunk of time to "learn" it is really silly.


 i hope such people will never adopt D.


It's too late; we're already here.  With a niche language like 
this (I hate to admit it, but that's how it is) that's probably 
most of the people that pick it up.


 But it's not as silly as the idea that you don't learn the
 language by diving in.


 using the tools you never used before, without training, to
 solve production tasks. this is what seems to be silly for me.


And over here, in reality, not every situation is optimal and we 
often find ourselves doing just-in-time learning.  Learn how to 
learn by doing and accept that you're going to exercise that 
skill.  A lot.  If you need a bunch of training up front just to 
get things done, you're probably in the wrong field.


   You know, by using it (and the standard library) to solve a
   problem?  This is simply how people pick up new programming
   languages.


 so i'm not a human then.


Well duh, you're a unicorn.  Didn't you get the memo? ;)


 if people want to use reference documentation to learn the
 language, i myself prefer this people to use anything except D.
 and i bet that php is what they want.


And I'm sincerely glad this sentiment isn't prevalent in the 
community.  Leave that attitude with C++.

-Wyatt
Dec 17 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 17 December 2014 at 17:36:50 UTC, Wyatt wrote:

<snip>


 Bull.  D isn't magic and expecting that people need to set
 aside a chunk of time to "learn" it is really silly.


 i hope such people will never adopt D.


 It's too late; we're already here.  With a niche language like 
 this (I hate to admit it, but that's how it is) that's probably 
 most of the people that pick it up.


 But it's not as silly as the idea that you don't learn the
 language by diving in.


 using the tools you never used before, without training, to
 solve production tasks. this is what seems to be silly for me.


 And over here, in reality, not every situation is optimal and 
 we often find ourselves doing just-in-time learning.  Learn how 
 to learn by doing and accept that you're going to exercise that 
 skill.  A lot.  If you need a bunch of training up front just 
 to get things done, you're probably in the wrong field.


<snip>


 -Wyatt


I think two things have been mixed up here. First, as a 
programmer you can of course make sense of and use languages you 
don't know, if needs be, simply because all languages share the 
same underlying logic (arrays, assoc arrays, functions etc.) In 
this respect, you can use and learn any language "on the fly". 
The only way to learn a language is to use it, of course. 
However, and this is the second point, if you want to use a 
language _properly_ and efficiently, you have to learn it in 
depth, no matter how advanced your skills as programmer are. You 
have to learn the concepts and ways that are peculiar to the 
language. Are you telling me that you never read TDPL or Ali's 
tutorial and that you grasped everything from templates and 
ranges to what you can do with D's structs immediately? If so, I 
doff my hat. I for my part had to ponder on the more advanced 
features of D and go back and rewrite some parts of my code in a 
better, more D-like style.

There is simply no other way for a complex, feature rich language 
like D. Look at D.learn. People who post there are often 
experienced programmers, yet they still have to ask questions 
about the best way to do something in D and the like. This 
doesn't mean that you cannot use D straight away as a newcomer, 
in fact, I could use it straight away and make sense of the 
documentation when the page background was still blue. But to 
throw a complex framework like vibed at people who have no 
experience with D whatsoever is not a good idea, even if (or 
because) they are all C++ guys.
Dec 17 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
Wow, uh...I didn't think I was saying anything particularly 
controversial, but I won a wall of text anyway.  But it's cool; 
turns out I've got one I can spare to reimburse you! :P  I don't 
think we fundamentally disagree, but I do think our differing 
experience has informed our view of the issue.

On Wednesday, 17 December 2014 at 22:47:21 UTC, Chris wrote:

 However, and this is the second point, if you want to use a 
 language _properly_ and efficiently, you have to learn it in 
 depth, no matter how advanced your skills as programmer are. 
 You have to learn the concepts and ways that are peculiar to 
 the language. Are you telling me that you never read TDPL or 
 Ali's tutorial and that you grasped everything from templates 
 and ranges to what you can do with D's structs immediately? If 
 so, I doff my hat. I for my part had to ponder on the more 
 advanced features of D and go back and rewrite some parts of my 
 code in a better, more D-like style.


See, when I started learning D, neither of those existed.  ;)  
No, really though: most of what I've learned has been from the 
docs, trying things to see what works, and the odd example 
snippet where I learn new tricks for things I already use or 
never noticed or have seen and then forgotten.  There weren't 
well-established idioms then or, in a lot of ways, now; the 
language to express the ones we think we want isn't even 
complete.  Whatever "proper" D is is all in a flux of 
multiparadigm soup (and by god, it's beautiful).  (In the now, 
I've skimmed sections of TDPL and use Ali's book a decent amount 
to refresh things I've forgotten.)

Sure, there are concepts that won't (didn't) come "immediately"; 
they take a little bit to think about and a bit more to play with 
and get the basics (a couple hours or so).  And then we apply 
what we've learned.  This is how learning works.  Later, when 
we've learned more, we might come back to something we wrote in 
the past and chide ourselves for all the "mistakes"; that's all 
normal.  But it worked then.  It works now.  And with a tweak 
there and a simple rewrite here...it works better than ever.  
Great!  That's what growth looks like.  Feels amazing.

We work in a discipline where no one ever writes gold on their 
first attempt, even in languages they've been using for a decade. 
  And our understanding of how features of the language can be 
used continues to grow, too, so it's not like there's a 
definitive point at which you "know" D (or any language).  
Because of these factors, I take serious issue with this attitude 
that you require a certain level of achievement before you're 
allowed to be productive (or even read the documentation).

And given the pitch for D, I think "you must be this tall to 
ride" is pretty much the antithesis of what we're after anyway.  
Realistically, people can and will use Google and they'll find 
what they need to get the job done, and then they will do the 
job.  (And this is a valuable trait because an engineer that 
won't sully themselves with doing work is kind of worthless.)  So 
it's a dangerous sort of hubris to assume that because they're 
"not for" the "basic" user that they won't be used.

(I want to be clear: if you're in a situation where you can 
dedicate even a moderate chunk of time to learning a new language 
or experimenting when there's work to do, more power to you!  I 
encourage you to treasure that privilege, because it's not common 
and it could be snatched away at any moment by a shift in the 
power structure of your firm.  Seriously, that's awesome; I'm 
pretty jealous.)

Better?

-Wyatt
Dec 18 2014
parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 18 December 2014 at 16:34:15 UTC, Wyatt wrote:

 Wow, uh...I didn't think I was saying anything particularly 
 controversial, but I won a wall of text anyway.  But it's cool; 
 turns out I've got one I can spare to reimburse you! :P  I 
 don't think we fundamentally disagree, but I do think our 
 differing experience has informed our view of the issue.

 On Wednesday, 17 December 2014 at 22:47:21 UTC, Chris wrote:

 However, and this is the second point, if you want to use a 
 language _properly_ and efficiently, you have to learn it in 
 depth, no matter how advanced your skills as programmer are. 
 You have to learn the concepts and ways that are peculiar to 
 the language. Are you telling me that you never read TDPL or 
 Ali's tutorial and that you grasped everything from templates 
 and ranges to what you can do with D's structs immediately? If 
 so, I doff my hat. I for my part had to ponder on the more 
 advanced features of D and go back and rewrite some parts of 
 my code in a better, more D-like style.


 See, when I started learning D, neither of those existed.  ;)  
 No, really though: most of what I've learned has been from the 
 docs, trying things to see what works, and the odd example 
 snippet where I learn new tricks for things I already use or 
 never noticed or have seen and then forgotten.  There weren't 
 well-established idioms then or, in a lot of ways, now; the 
 language to express the ones we think we want isn't even 
 complete.  Whatever "proper" D is is all in a flux of 
 multiparadigm soup (and by god, it's beautiful).  (In the now, 
 I've skimmed sections of TDPL and use Ali's book a decent 
 amount to refresh things I've forgotten.)

 Sure, there are concepts that won't (didn't) come 
 "immediately"; they take a little bit to think about and a bit 
 more to play with and get the basics (a couple hours or so).  
 And then we apply what we've learned.  This is how learning 
 works.  Later, when we've learned more, we might come back to 
 something we wrote in the past and chide ourselves for all the 
 "mistakes"; that's all normal.  But it worked then.  It works 
 now.  And with a tweak there and a simple rewrite here...it 
 works better than ever.  Great!  That's what growth looks like.
  Feels amazing.

 We work in a discipline where no one ever writes gold on their 
 first attempt, even in languages they've been using for a 
 decade.
  And our understanding of how features of the language can be 
 used continues to grow, too, so it's not like there's a 
 definitive point at which you "know" D (or any language).  
 Because of these factors, I take serious issue with this 
 attitude that you require a certain level of achievement before 
 you're allowed to be productive (or even read the 
 documentation).

 And given the pitch for D, I think "you must be this tall to 
 ride" is pretty much the antithesis of what we're after anyway.
  Realistically, people can and will use Google and they'll find 
 what they need to get the job done, and then they will do the 
 job.  (And this is a valuable trait because an engineer that 
 won't sully themselves with doing work is kind of worthless.)  
 So it's a dangerous sort of hubris to assume that because 
 they're "not for" the "basic" user that they won't be used.

 (I want to be clear: if you're in a situation where you can 
 dedicate even a moderate chunk of time to learning a new 
 language or experimenting when there's work to do, more power 
 to you!  I encourage you to treasure that privilege, because 
 it's not common and it could be snatched away at any moment by 
 a shift in the power structure of your firm.  Seriously, that's 
 awesome; I'm pretty jealous.)

 Better?

 -Wyatt


I completely agree, that's how we all learn new languages. That's 
how I've done it over the years. I never said that you're not 
allowed to write, unless you're an expert. I started straight 
away, like you, before there was TDPL (however, the book 
clarified a lot of things for me later). This also means that the 
doc can't be that bad after all!

"you must be this tall to ride" was never my attitude, else I 
would never have touched D. What I took issue with was that the 
developers where lead straight into the jungle (vibed :-) without 
ever being told which animals live there and how to handle them.

But that is irrelevant now, because the posts above made clear 
that there were far more things at play than the (perceived) bad 
tooling.
Dec 18 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 17 December 2014 at 15:01:32 UTC, Wyatt wrote:

 On Wednesday, 17 December 2014 at 10:16:22 UTC, ketmar via 
 Digitalmars-d wrote:

 On Wed, 17 Dec 2014 18:06:25 +1000
 Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I'd suggest to look at high-quality commercial documentation,
 like MSDN or wherever.


 please, no! the fact that you are used to it doesn't mean that
 msdn is a quality dox.


 Frankly, I think you're letting your prejudices against the 
 source of the documentation cloud your judgement of the 
 quality.  Much as I hate to admit it, their _reference_ 
 documentation is much more readable at the baseline.


Yep, MSDN is pretty good. I often end up there when other sources 
fail. They are also quite good at documenting what version you 
need to use a feature.


 _less noisy_.  This is what we mean when we talk about 
 "quality" in documentation.  Hell, a lot of CPAN docs are 
 easier to follow than the Phobos stuff, and that's _Perl_ for 
 crissakes!


I'd like to see the phobos documentation in a XML format. That 
would make it a lot easier to parse, analyse and generate 
improved extended documentation.


 aside a chunk of time to "learn" it is really silly.  But it's 
 not as silly as the idea that you don't learn the language by 
 diving in.
  You know, by using it (and the standard library) to solve a 
 problem?  This is simply how people pick up new programming 
 languages.


Commented code in tutorials and a collection of short idiomatic 
examples + good reference documentation with 
fast-easy-and-precise lookup goes a long way.


 It's more akin to the Haskell reaction: "This seems neat, but 
 it's asking way too much of me and I don't have time for it."


Yep, that is how I felt about Haskell when using the interpreter 
many years ago, but this:

https://tryhaskell.org/

is enough to get me beyond the initial "headache" that the 
weirder aspects of Haskell may cause (such as the function 
signatures).

Such interactive walk-throughs of the basics are really useful if 
you want to ease the learning curve in a fun way.
Dec 17 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 December 2014 at 20:16, ketmar via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wed, 17 Dec 2014 18:06:25 +1000
 Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I'd suggest to look at high-quality commercial documentation, like
 MSDN or wherever.


 please, no! the fact that you are used to it doesn't mean that msdn is
 a quality dox.

 besides, msdn references are exactly what phobos documentation is:
 description of functions. will msdn reference dox help you to learn
 msvc? yet you citing it as "high-quality" and blaming phobos dox for
 doing (or, rather, not doing) the same.


I was referring mostly to the organisation, which never assaults you
with a wall of text.
It's categorised nicely, and content is fetched dynamically.

That said, I would say MSDN is a good technical reference; short,
concise, well formatted, easy to understand. Phobos is not that.
In some cases, Phobos it's so 'concise' that the entire doc is 3 or 4
words repeating the function name but with spaces, and in other cases
it is a wall of text, with a bunch of cryptic template args and
constraints.


 One thing I know for sure, is when they are confronted with
 constraints, especially on templates, they have absolutely no idea
 what they're looking at...


 did they ever tried to learn the language? seems that you just throwed
 phobos dox at them and expecting them to use that dox to learn D.


I never threw phobos docs at them, they found that themselves. I was
actually kinda trying to steer them away from those docs in some
cases, by insisting they hack on the code while I was in the room...



 D is not C. D is not C++. one must learn it before using it. and phobos
 documentation is not for learning the language, it's reference for
 phobos.


I can safely say I never 'learned D' by your definition.
I brute forced my way with nothing more than the phobos reference, and
the parallel language reference.

A senior C/C++ programmer should DEFINITELY be able to learn D by osmosis.



 i bet the story was like this: "guys, look at this cool language, it's
 almost like C++, and has some great features! let's use it!" "ah,
 almost like C++? so we don't have to learn? great, let's do it! but...
 hey... what do all that gibberish in documentation mean? i've never
 seen that is C++... screw it, this wannabe C++ language is awful!"


Don't be insulting.
C++ programmers know exactly how bad C++ is. We've been discussing D's
alternative approaches to common C++ problems for months, many hours
wasted in front of the white board discussing the differences between
the languages.
They had a *lot* of background conversation to work with, much more
than I had when I learned D.
Dec 18 2014
parent reply "Ondra" <pokorny.ondrej gmail.com> writes:
What about stop flaming and do some research on this.
Create some questionnare of some sort and ask D lang developers 
what was hard for them while learning. What they found difficult 
about language and then try to improve based on some data instead 
of shooting blindly.
Dec 18 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 18 Dec 2014 10:23:32 +0000
Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 What about stop flaming and do some research on this.
 Create some questionnare of some sort and ask D lang developers=20
 what was hard for them while learning. What they found difficult=20
 about language and then try to improve based on some data instead=20
 of shooting blindly.


and the first questions should be "what other languages do you know?"
"what other languages do you like?"

i, for example, found compile-time code generation easy, as i love
Scheme. the same with "function (template, actually) should accept any
type which conforms to the protocol" conception.

some of my mates are hardcore C programmers, and i see that it's hard
for them to change their style: they tend to write "classic OOP" code
instead of "protocol contracts", avoid nested functions and delegates.

what i'm trying to say is that "language of choise" matters here, so
survey must clearly ask about that.
Dec 18 2014
parent reply "Ondra" <pokorny.ondrej gmail.com> writes:
On Thursday, 18 December 2014 at 11:09:23 UTC, ketmar via 
Digitalmars-d wrote:

 On Thu, 18 Dec 2014 10:23:32 +0000
 Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 What about stop flaming and do some research on this.
 Create some questionnare of some sort and ask D lang 
 developers what was hard for them while learning. What they 
 found difficult about language and then try to improve based 
 on some data instead of shooting blindly.


 and the first questions should be "what other languages do you 
 know?"
 "what other languages do you like?"

 i, for example, found compile-time code generation easy, as i 
 love
 Scheme. the same with "function (template, actually) should 
 accept any
 type which conforms to the protocol" conception.

 some of my mates are hardcore C programmers, and i see that 
 it's hard
 for them to change their style: they tend to write "classic 
 OOP" code
 instead of "protocol contracts", avoid nested functions and 
 delegates.

 what i'm trying to say is that "language of choise" matters 
 here, so
 survey must clearly ask about that.


I meant more to focus only on D. Like : "What do you have most 
difficulty with while learning language/you were learning 
langeuage?" "What do you consider most confusing part of D 
library/language features." etc...

I personally, have problems with: Endless confusion about 
class/struct. endless confussion about array slices. String 
details. Lack of enough practical examples on library packages...

On the other hand I don't feel that templates are so hard. That's 
actually why i started to learn D.
Dec 18 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 18 Dec 2014 11:43:43 +0000
Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I meant more to focus only on D. Like : "What do you have most=20
 difficulty with while learning language/you were learning=20
 langeuage?" "What do you consider most confusing part of D=20
 library/language features." etc...


that's what i'm talking about: people with different backgrounds find
different things difficult.


 I personally, have problems with: Endless confusion about=20
 class/struct. endless confussion about array slices. String=20
 details.


see? those was the things i got almost immediately. but it's not 'cause
i'm a kind of genious, i just used to concepts internally.


 Lack of enough practical examples on library packages...


yeah, having more practical samples is the most universal desire, i
believe. let's hope that someone will write "Phobos Cookbook". ;-)


 On the other hand I don't feel that templates are so hard. That's=20
 actually why i started to learn D.


i bet you didn't do alot of convoluted templates in C++, aren't you?
'cause people with that background tent to run away screaming when they
hear the word "template". ;-)
Dec 18 2014
parent reply "Ondra" <pokorny.ondrej gmail.com> writes:
On Thursday, 18 December 2014 at 11:54:52 UTC, ketmar via 
Digitalmars-d wrote:

 On Thu, 18 Dec 2014 11:43:43 +0000
 Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I meant more to focus only on D. Like : "What do you have most 
 difficulty with while learning language/you were learning 
 langeuage?" "What do you consider most confusing part of D 
 library/language features." etc...


 that's what i'm talking about: people with different 
 backgrounds find
 different things difficult.


 I personally, have problems with: Endless confusion about 
 class/struct. endless confussion about array slices. String 
 details.


 see? those was the things i got almost immediately. but it's 
 not 'cause
 i'm a kind of genious, i just used to concepts internally.


 Lack of enough practical examples on library packages...


 yeah, having more practical samples is the most universal 
 desire, i
 believe. let's hope that someone will write "Phobos Cookbook". 
 ;-)


 On the other hand I don't feel that templates are so hard. 
 That's actually why i started to learn D.


 i bet you didn't do alot of convoluted templates in C++, aren't 
 you?
 'cause people with that background tent to run away screaming 
 when they
 hear the word "template". ;-)


Well I have some and actually this was the reason I started 
looking for something better. I felt like C++ doesn't allow me to 
express myself. And I found D... which is awesome ;)
Dec 18 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 18 Dec 2014 12:07:53 +0000
Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On the other hand I don't feel that templates are so hard.=20
 That's actually why i started to learn D.


 i bet you didn't do alot of convoluted templates in C++, aren't=20
 you?
 'cause people with that background tent to run away screaming=20
 when they
 hear the word "template". ;-)


=20
 Well I have some and actually this was the reason I started=20
 looking for something better. I felt like C++ doesn't allow me to=20
 express myself. And I found D... which is awesome ;)


i believe that human-understandable templates and metaprogramming are
among the strongest D selling points. yet those are features that are
hard to understand for many people.
Dec 18 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 18 Dec 2014 20:13:33 +1000
Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 One thing I know for sure, is when they are confronted with
 constraints, especially on templates, they have absolutely no idea
 what they're looking at...


 did they ever tried to learn the language? seems that you just throwed
 phobos dox at them and expecting them to use that dox to learn D.


=20
 I never threw phobos docs at them, they found that themselves. I was
 actually kinda trying to steer them away from those docs in some
 cases, by insisting they hack on the code while I was in the room...


so no proper training at all? now it's completely clear why D was
dismissed.


 D is not C. D is not C++. one must learn it before using it. and phobos
 documentation is not for learning the language, it's reference for
 phobos.


=20
 I can safely say I never 'learned D' by your definition.
 I brute forced my way with nothing more than the phobos reference, and
 the parallel language reference.


are you writing the commercial production code in D at the same time?
experimenting is ok when you have limitless bugdet and/or no deadlines.
i love D and i was trying to gently push D in our workflow, but i never
thinking about doing that without training. i would fire myself if i'll
try to do that.


 A senior C/C++ programmer should DEFINITELY be able to learn D by osmosis.


...in his free time, doing pet projects and be dedicated to that. and
yet C++ templates are so bad that one has to forgot nearly everything
he knows in that field before going to D templates. and using D without
templates is like running with your legs tied together.


 i bet the story was like this: "guys, look at this cool language, it's
 almost like C++, and has some great features! let's use it!" "ah,
 almost like C++? so we don't have to learn? great, let's do it! but...
 hey... what do all that gibberish in documentation mean? i've never
 seen that is C++... screw it, this wannabe C++ language is awful!"


=20
 Don't be insulting.
 C++ programmers know exactly how bad C++ is. We've been discussing D's
 alternative approaches to common C++ problems for months, many hours
 wasted in front of the white board discussing the differences between
 the languages.
 They had a *lot* of background conversation to work with, much more
 than I had when I learned D.


i'm sorry. it's not about personal insulting or "C++ style of thinking",
it's about the directions. D IS NOT C/C++. i can't stress that harder.
expecting good C++ programmer to become good D programmer without proper
training (or alot of time spent doing pet projects in D) is simply
asking for troubles and frustration.
Dec 18 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-12-14 09:37, Manu via Digitalmars-d wrote:


 They immediately made comments about goto-definition not working, and
 auto-completion not working reliably.


I'm curious to know which tools they used to get autocompletion and 
go-to-definition to work with JavaScript.

-- 
/Jacob Carlborg
Dec 14 2014
next sibling parent "Gabor Mezo" <gabor.mezo outlook.com> writes:
On Sunday, 14 December 2014 at 20:44:17 UTC, Jacob Carlborg wrote:

 On 2014-12-14 09:37, Manu via Digitalmars-d wrote:


 They immediately made comments about goto-definition not 
 working, and
 auto-completion not working reliably.


 I'm curious to know which tools they used to get autocompletion 
 and go-to-definition to work with JavaScript.


It's Webstorm. There you get auto-completion, go-to-definition, 
refactor, insanely superior debugger, anything that you can dream 
of. I'm not a Jetbrains sales manager, I'm just doing Node.js 
coding at my work. :)
Dec 14 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 14 December 2014 at 20:44:17 UTC, Jacob Carlborg wrote:

 On 2014-12-14 09:37, Manu via Digitalmars-d wrote:


 They immediately made comments about goto-definition not 
 working, and
 auto-completion not working reliably.


 I'm curious to know which tools they used to get autocompletion 
 and go-to-definition to work with JavaScript.


On my area of work, for example Netbeans.

https://netbeans.org/features/html5/index.html

http://wiki.netbeans.org/NewAndNoteworthyNB80#JavaScript

https://netbeans.org/kb/73/ide/javascript-editor.html

Visual Studio Web Tools and InteliJ provide similar features.

Eclipse is quite bad in comparison.

--
Paulo
Dec 14 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 December 2014 at 06:44, Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2014-12-14 09:37, Manu via Digitalmars-d wrote:


 They immediately made comments about goto-definition not working, and
 auto-completion not working reliably.



 I'm curious to know which tools they used to get autocompletion and
 go-to-definition to work with JavaScript.


Well, since everything just worked, and we didn't need to try and
debug crashes in libraries... those things didn't really come up.
Our node.js code was only about 20-30 lines in the end.

Visual Studio does an okay job of .js too.
Dec 17 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 17 December 2014 at 08:09:10 UTC, Manu via 
Digitalmars-d wrote:

 On 15 December 2014 at 06:44, Jacob Carlborg via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 2014-12-14 09:37, Manu via Digitalmars-d wrote:


 They immediately made comments about goto-definition not 
 working, and
 auto-completion not working reliably.



 I'm curious to know which tools they used to get 
 autocompletion and
 go-to-definition to work with JavaScript.


 Well, since everything just worked, and we didn't need to try 
 and
 debug crashes in libraries... those things didn't really come 
 up.
 Our node.js code was only about 20-30 lines in the end.

 Visual Studio does an okay job of .js too.


Are you aware of node.js tooling support in Visual Studio?

http://nodejstools.codeplex.com/
Dec 17 2014
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 December 2014 at 18:36, Paulo  Pinto via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 17 December 2014 at 08:09:10 UTC, Manu via Digitalmars-d
 wrote:

 On 15 December 2014 at 06:44, Jacob Carlborg via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 2014-12-14 09:37, Manu via Digitalmars-d wrote:


 They immediately made comments about goto-definition not working, and
 auto-completion not working reliably.




 I'm curious to know which tools they used to get autocompletion and
 go-to-definition to work with JavaScript.



 Well, since everything just worked, and we didn't need to try and
 debug crashes in libraries... those things didn't really come up.
 Our node.js code was only about 20-30 lines in the end.

 Visual Studio does an okay job of .js too.



 Are you aware of node.js tooling support in Visual Studio?

 http://nodejstools.codeplex.com/


Good to see they recognised the importance of the effort ;)
Dec 17 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 17 Dec 2014 18:09:00 +1000
Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On 15 December 2014 at 06:44, Jacob Carlborg via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 2014-12-14 09:37, Manu via Digitalmars-d wrote:


 They immediately made comments about goto-definition not working, and
 auto-completion not working reliably.



 I'm curious to know which tools they used to get autocompletion and
 go-to-definition to work with JavaScript.


=20
 Well, since everything just worked, and we didn't need to try and
 debug crashes in libraries... those things didn't really come up.
 Our node.js code was only about 20-30 lines in the end.
=20
 Visual Studio does an okay job of .js too.


good luck then. i wish you never got into problems with node.js. no,
really. one of our customers once runned into problems with node.js...
he doesn't using node.js anymore. it was easier to rewrite the whole
thing than trying to dance around node.js.
Dec 17 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
Digitalmars-d wrote:

 We were trying to use vibe.d, and we encountered bugs.

 We were unable to build Win64 code ...


Here is exactly your problem - trying to do a web development on 
Windows :P Really I have never understood that counter-productive 
obsession with a habit that makes people differentiate 
development environments and production environments so much. You 
aren't going to use Windows servers, are you?

Well, that was somewhat off-topic grumpy remark. On actual 
marketing thing:

In my opinion biggest evangelist mistake everyone makes it trying 
to advertise D for something it simply isn't. Which inevitably 
fails and leaves people extremely frustrated with false 
advertising, like to remain there forever as a prejudice against 
D. Because you will have a better luck torturing kittens than try 
false advertising and get caught.

Idea that any D project can compete with node.js in "easy to jump 
in" domain is absolutely ridiculous. Attempting this is just 
dooming yourself to fail. Same is trying to advertise it is 
stable mature language - reality is it is simply not true and 
people will find out it sooner or later.

I think trying to sell D should look something like this "Yes, D 
is horrible because of X, Y and Z but here is why it doesn't 
matter for our case : A, B and C". Don't pretend perfection but 
explain trade-offs.

You won't beat node.js in getting started curve. You won't beat 
Java in designing huge complex systems (well, at least everyone 
says that). You won't beat C in raw low-level performance. But D 
will easily beat C in getting started curve and complex design, 
easily beat node.js in performance and complex design and 
(not-so-easily) beat Java in performance and overall versatility.

Remember the talk by Stephan 
(http://dconf.org/2014/talks/dilly.html) about their vibe.d usage 
in production and points he has made when comparing vs node.js? 
It was about performance, it was about resource overhead, it was 
about benefits of static type system and horrors of callback 
hell. It wasn't about how vibe.d is more shiny than node.js - and 
it was good.

If your colleagues went with node in the end and kept happy with 
it, quite likely they simple don't need advantages vibe.d can 
give to their project. There is no shame in it.
Dec 14 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2014 5:29 PM, Dicebot wrote:

 If your colleagues went with node in the end and kept happy with it, quite
 likely they simple don't need advantages vibe.d can give to their project.
There
 is no shame in it.


I also noted that none of the issues were the language itself.
Dec 14 2014
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 December 2014 at 11:35, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/14/2014 5:29 PM, Dicebot wrote:

 If your colleagues went with node in the end and kept happy with it, quite
 likely they simple don't need advantages vibe.d can give to their project.
 There
 is no shame in it.



 I also noted that none of the issues were the language itself.


Exactly! And I've been repeating this for some years now; I think D's
biggest 'issue' today is the environment.
The language can always be improved, but I think it's a bigger issue
that the tooling is, in my experience, the primary detail that
inhibits adoption.

How can we stimulate this area of development?
Companies will pay money for tooling, if it works! ;)

Do we have any vector's into Microsoft to get fixes for D'd debugging
experience into their debugger? Are there any sympathetic developers
at MS?
Dec 17 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 17 Dec 2014 18:41:06 +1000
Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Do we have any vector's into Microsoft to get fixes for D'd debugging
 experience into their debugger? Are there any sympathetic developers
 at MS?


haha. they can't do C99 for decades, so i bet that seeing Hell frozen
is much more realistic scenario.
Dec 17 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 17 December 2014 at 10:21:53 UTC, ketmar via 
Digitalmars-d wrote:

 On Wed, 17 Dec 2014 18:41:06 +1000
 Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Do we have any vector's into Microsoft to get fixes for D'd 
 debugging
 experience into their debugger? Are there any sympathetic 
 developers
 at MS?


 haha. they can't do C99 for decades, so i bet that seeing Hell 
 frozen
 is much more realistic scenario.


Why should they? The product is called Visual C++.

It is 30 years now, C++ compiler vendors don't need to sell their 
language to C developers any longer.

Microsoft already stated that C++ is the way forward and C is 
only for backwards compatibility.

http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/

Since Windows XP most new Windows APIs are COM based, good luck 
writing COM code in C.

As of Windows 7, the kernel started to accept C++ code.

http://msdn.microsoft.com/en-us/library/jj620896%28v=vs.110%29.aspx

Recently they added the C99 features required by the C++11 and 
C++14 standards. And stressed once again at Connect, that any 
remaining feature depends how relevant they are for Microsoft 
customers.

http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/029

If you want to still use a modern C compiler, there are third 
party compilers to choose from.

Personally I vote for Microsoft approach, C++ allows for much 
safer coding than C and the C subset is still there anyway.


--
Paulo
Dec 17 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 17 Dec 2014 10:44:25 +0000
Paulo  Pinto via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Wednesday, 17 December 2014 at 10:21:53 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Wed, 17 Dec 2014 18:41:06 +1000
 Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Do we have any vector's into Microsoft to get fixes for D'd=20
 debugging
 experience into their debugger? Are there any sympathetic=20
 developers
 at MS?


 haha. they can't do C99 for decades, so i bet that seeing Hell=20
 frozen
 is much more realistic scenario.


=20
 Why should they? The product is called Visual C++.


so why their c++ compiler still accepts c code? "for compatibility"?
oh, eah, it's very "compatible" to accept ancient C89 and to reject
C99.


 Microsoft already stated that C++ is the way forward and C is=20
 only for backwards compatibility.


idiots, that's it.


 Since Windows XP most new Windows APIs are COM based, good luck=20
 writing COM code in C.


i'm still succesfully using winapi. what am i doing wrong? ah, except
resisting to "platform lock-in" with all that COM BS.


 If you want to still use a modern C compiler, there are third=20
 party compilers to choose from.


and if i want a modern C++ compiler, i will not chose msvc, as my
workflow is already built around completely different tools. having in
mind that there are alot of C code around, msvc is the worst
possible choise. (ah, and visual studio sux too! ;-)


 Personally I vote for Microsoft approach, C++ allows for much=20
 safer coding than C and the C subset is still there anyway.


this is about consistency again. either stop accepting half-baked C and
go with pure C++ or fix the damn thing!

but this is ms... a long-time vendor of half-backed solutions for the
problems that shouldn't exist in the first place.
Dec 17 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 December 2014 at 01:30:00 UTC, Dicebot wrote:

 On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
 Digitalmars-d wrote:

 We were trying to use vibe.d, and we encountered bugs.

 We were unable to build Win64 code ...


 Here is exactly your problem - trying to do a web development 
 on Windows :P Really I have never understood that 
 counter-productive obsession with a habit that makes people 
 differentiate development environments and production 
 environments so much. You aren't going to use Windows servers, 
 are you?


Well, lots of Fortune 500 companies do.

If you want to appeal to those users, D has to be better than the 
whole .NET eco-system, specially now that static binaries are 
going to be supported as well.

Not to mention the C++ tooling which is just great.

--
Paulo
Dec 14 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 15 December 2014 at 07:48:37 UTC, Paulo  Pinto wrote:

 Well, lots of Fortune 500 companies do.


I have heard good enough first 9000 times, thanks.


 If you want to appeal to those users


No.
Dec 15 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 December 2014 at 08:13:33 UTC, Dicebot wrote:

 On Monday, 15 December 2014 at 07:48:37 UTC, Paulo  Pinto wrote:

 Well, lots of Fortune 500 companies do.


 I have heard good enough first 9000 times, thanks.


 If you want to appeal to those users


 No.


So how to you plan to make game developers adopt D?
Dec 15 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 15 December 2014 at 10:42:26 UTC, Paulo  Pinto wrote:

 On Monday, 15 December 2014 at 08:13:33 UTC, Dicebot wrote:

 On Monday, 15 December 2014 at 07:48:37 UTC, Paulo  Pinto 
 wrote:

 Well, lots of Fortune 500 companies do.


 I have heard good enough first 9000 times, thanks.


 If you want to appeal to those users


 No.


 So how to you plan to make game developers adopt D?


I don't plan it and don't realistically ever expect it. 
Considering the fact that game development industry is 
traditionally one of the worst in contributing upstream I also 
don't have any motivation to convince them adopt D.

If there ever appears a game development company / community 
interested in _investing_ into programming language that would be 
totally different story but also irrelevant to enterprise culture 
you refer to.
Dec 15 2014
next sibling parent reply "Mengu" <mengukagan gmail.com> writes:
On Monday, 15 December 2014 at 10:46:30 UTC, Dicebot wrote:

 On Monday, 15 December 2014 at 10:42:26 UTC, Paulo  Pinto wrote:

 On Monday, 15 December 2014 at 08:13:33 UTC, Dicebot wrote:

 On Monday, 15 December 2014 at 07:48:37 UTC, Paulo  Pinto 
 wrote:

 Well, lots of Fortune 500 companies do.


 I have heard good enough first 9000 times, thanks.


 If you want to appeal to those users


 No.


 So how to you plan to make game developers adopt D?


 I don't plan it and don't realistically ever expect it. 
 Considering the fact that game development industry is 
 traditionally one of the worst in contributing upstream I also 
 don't have any motivation to convince them adopt D.

 If there ever appears a game development company / community 
 interested in _investing_ into programming language that would 
 be totally different story but also irrelevant to enterprise 
 culture you refer to.


isn't that enterprise culture or communities/companies interested 

ruby mainstream?
Dec 15 2014
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 15 December 2014 at 11:25:43 UTC, Mengu wrote:

 isn't that enterprise culture or communities/companies 

 python and ruby mainstream?



the very start and designed from the very scratch as product to 
sell. Nothing in common with D.

Python / Ruby - pushed by community hype with some enterprise 
interest appearing only recently when those have been already 
established solutions

I am not sure what you were implying though.
Dec 15 2014
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Monday, 15 December 2014 at 10:46:30 UTC, Dicebot wrote:

 I don't plan it and don't realistically ever expect it. 
 Considering the fact that game development industry is 
 traditionally one of the worst in contributing upstream I also 
 don't have any motivation to convince them adopt D.

 If there ever appears a game development company / community 
 interested in _investing_ into programming language that would 
 be totally different story but also irrelevant to enterprise 
 culture you refer to.


We talk a lot of game developers here, and it's an interesting 
target but there are many other native programmers stuck with C++ 
and often unable to use anything else, in the many niches of the 
world.
Dec 15 2014
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 15 December 2014 at 11:42:31 UTC, ponce wrote:

 On Monday, 15 December 2014 at 10:46:30 UTC, Dicebot wrote:

 I don't plan it and don't realistically ever expect it. 
 Considering the fact that game development industry is 
 traditionally one of the worst in contributing upstream I also 
 don't have any motivation to convince them adopt D.

 If there ever appears a game development company / community 
 interested in _investing_ into programming language that would 
 be totally different story but also irrelevant to enterprise 
 culture you refer to.


 We talk a lot of game developers here, and it's an interesting 
 target but there are many other native programmers stuck with 
 C++ and often unable to use anything else, in the many niches 
 of the world.


What I mean is that the very approach of "how are you going to 
sell D to X" is doomed to fail because when there is no real 
product to sell. Proper question would be "how are you going to 
invite X to collaborate on D" and with such mentality it is only 
practical to think about interests of people that are expected to 
give something back.

At some point I have hoped that Facebook would take over D as 
commercial project but this train has long been gone by now. I 
consider is good platform for tinkerers, for those willing to 
take the risk and go for in-house innovation - nothing more, 
nothing less.
Dec 15 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 December 2014 at 20:46, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 15 December 2014 at 10:42:26 UTC, Paulo  Pinto wrote:

 On Monday, 15 December 2014 at 08:13:33 UTC, Dicebot wrote:

 On Monday, 15 December 2014 at 07:48:37 UTC, Paulo  Pinto wrote:

 Well, lots of Fortune 500 companies do.



 I have heard good enough first 9000 times, thanks.


 If you want to appeal to those users



 No.



 So how to you plan to make game developers adopt D?



 I don't plan it and don't realistically ever expect it. Considering the fact
 that game development industry is traditionally one of the worst in
 contributing upstream I also don't have any motivation to convince them
 adopt D.

 If there ever appears a game development company / community interested in
 _investing_ into programming language that would be totally different story
 but also irrelevant to enterprise culture you refer to.


So, in your world, D is a language for nerds (linux nerds at that!),
and not for serious productivity by enterprise?
Give me a break!
Dec 17 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 15 Dec 2014 07:48:36 +0000
Paulo  Pinto via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Well, lots of Fortune 500 companies do.


google? fb? twitter? instagram? watsapp? those are companies that
processes massive traffic. without windows. i prefer to look at them
instead of ACME Corp., which don't even know why it need a "web-site".

they made a mistake once choosing windows for web, but i don't want to
help their mistake to grow. sure, they will found somebody for that --
it's possible to found people to do *any* work, but this will not be
me. windows is a nightmare. windows server is a fiendish nightmare.

and btw, most windows-oriented software developers sux. "visual studio,
intellisense, debugger, bla-bla-bla". take anything of that out and
they can't do a smallest bit of work. phew.
Dec 15 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 December 2014 at 08:49:11 UTC, ketmar via 
Digitalmars-d wrote:

 On Mon, 15 Dec 2014 07:48:36 +0000
 Paulo  Pinto via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 Well, lots of Fortune 500 companies do.


 google? fb? twitter? instagram? watsapp?


Companies like those are a very small sample from Fortune 500 
companies, specially those whose main business has nothing to do 
with software.


 those are companies that
 processes massive traffic. without windows. i prefer to look at 
 them
 instead of ACME Corp., which don't even know why it need a 
 "web-site".

 they made a mistake once choosing windows for web, but i don't 
 want to
 help their mistake to grow. sure, they will found somebody for 
 that --
 it's possible to found people to do *any* work, but this will 
 not be
 me. windows is a nightmare. windows server is a fiendish 
 nightmare.

 and btw, most windows-oriented software developers sux. "visual 
 studio,
 intellisense, debugger, bla-bla-bla". take anything of that out 
 and
 they can't do a smallest bit of work. phew.


I could respond to this, but better leave as it is.
Dec 15 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 December 2014 at 11:29, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:

 We were trying to use vibe.d, and we encountered bugs.

 We were unable to build Win64 code ...



 Here is exactly your problem - trying to do a web development on Windows :P
 Really I have never understood that counter-productive obsession with a
 habit that makes people differentiate development environments and
 production environments so much. You aren't going to use Windows servers,
 are you?


Okay, you go and tell the CEO of my company that we're switching environments!
We'll need all new software licensing, we'll need to re-jig the
company server and IT infrastructure, we'll also need to retrain ALL
the staff.
Then we'll have to deal with the vast majority of staff who hate
linux, and refuse to work in that environment.

What's our budget for this process? A few million? Plus finding new
staff to replace the ones that quit because they don't like linux.



 Well, that was somewhat off-topic grumpy remark. On actual marketing thing:

 In my opinion biggest evangelist mistake everyone makes it trying to
 advertise D for something it simply isn't. Which inevitably fails and leaves
 people extremely frustrated with false advertising, like to remain there
 forever as a prejudice against D. Because you will have a better luck
 torturing kittens than try false advertising and get caught.


Actually, I recommended it because I had had a positive experience
with vibe.d in the past. It seemed pretty solid.
Gotta start somewhere. I've had success promoting D to commercial
users in the past.



 Idea that any D project can compete with node.js in "easy to jump in" domain
 is absolutely ridiculous. Attempting this is just dooming yourself to fail.
 Same is trying to advertise it is stable mature language - reality is it is
 simply not true and people will find out it sooner or later.


Sorry, maybe it wasn't clear, we never tried it out against node.js,
we tried it first, on my recommendation.
When it was rejected, someone else suggested to look at node.js. We
looked at that, it just worked.



 I think trying to sell D should look something like this "Yes, D is horrible
 because of X, Y and Z but here is why it doesn't matter for our case : A, B
 and C". Don't pretend perfection but explain trade-offs.

 You won't beat node.js in getting started curve. You won't beat Java in
 designing huge complex systems (well, at least everyone says that). You
 won't beat C in raw low-level performance. But D will easily beat C in
 getting started curve and complex design, easily beat node.js in performance
 and complex design and (not-so-easily) beat Java in performance and overall
 versatility.


We didn't want any of those things from .js though. We're all
low-level/native coders.
We don't have time to debug language and library issues though. If we
didn't have tooling/library issues, we would have been perfectly happy
writing whatever code we needed to do our job.



 Remember the talk by Stephan (http://dconf.org/2014/talks/dilly.html) about
 their vibe.d usage in production and points he has made when comparing vs
 node.js? It was about performance, it was about resource overhead, it was
 about benefits of static type system and horrors of callback hell. It wasn't
 about how vibe.d is more shiny than node.js - and it was good.


Yeah, we weren't interested in literally anything about node.js.
Actually, the concept repulsed us.
We just tried it, and it didn't crash. That is all.

If vibe.d didn't crash, *or* if the debugger actually worked (such
that we could have debugged the crash), then we would have surely
stuck with that.
But we couldn't get behind a solution that was impossible to debug.



 If your colleagues went with node in the end and kept happy with it, quite
 likely they simple don't need advantages vibe.d can give to their project.
 There is no shame in it.


Is not the case. We would have preferred write our code in a native
language, but we don't have working time allocated to debug library
problems with tools that don't work.
Dec 17 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 17 December 2014 at 08:30:59 UTC, Manu via 
Digitalmars-d wrote:

 Here is exactly your problem - trying to do a web development 
 on Windows :P
 Really I have never understood that counter-productive 
 obsession with a
 habit that makes people differentiate development environments 
 and
 production environments so much. You aren't going to use 
 Windows servers,
 are you?


 Okay, you go and tell the CEO of my company that we're 
 switching environments!
 We'll need all new software licensing, we'll need to re-jig the
 company server and IT infrastructure, we'll also need to 
 retrain ALL
 the staff.
 Then we'll have to deal with the vast majority of staff who hate
 linux, and refuse to work in that environment.


I expect you to go and do that. Well, actually, in any reasonable 
company I'd expect environment to be defined at the initial 
design document stage and always be the one fitting for the 
specific product. Choosing inferior tools (assuming those are 
proved inferior) simply because of some bullshit policies is just 
ridiculous.

This is exactly what happened on one of my old jobs - upon 
encountering some pressure from company management team leads 
just went there and said "Stop messing with our tool choices if 
you want this project live. Or start looking for new 
programmers." Worked like magic.

It is not like I think that web servers shouldn't work on Windows 
- it is just realistic to expect much less effort to be put into 
bringing it to production quality. And impractical to lobby for 
putting more (limited) effort there. Same applies to most server 
technology out there per my experience.


 Actually, I recommended it because I had had a positive 
 experience
 with vibe.d in the past. It seemed pretty solid.
 Gotta start somewhere. I've had success promoting D to 
 commercial
 users in the past.


Promoting to commercial users is indeed possible but one needs to 
explain risks and trade-offs straight. I wonder though how you 
have not noticed debugger issues before if there was some 
positive experience. There was nothing to debug? :)


 Idea that any D project can compete with node.js in "easy to 
 jump in" domain
 is absolutely ridiculous. Attempting this is just dooming 
 yourself to fail.
 Same is trying to advertise it is stable mature language - 
 reality is it is
 simply not true and people will find out it sooner or later.


 Sorry, maybe it wasn't clear, we never tried it out against 
 node.js,
 we tried it first, on my recommendation.
 When it was rejected, someone else suggested to look at 
 node.js. We
 looked at that, it just worked.


I mean that if "it just worked" was enough to make decision to 
use the node.js, then you didn't have any critical requirements 
that it fails to address (otherwise you would have looked for 
those first). Which means that pretty much any framework out 
there was suitable and ease of use was only truly important 
criteria.

Interesting part starts when you say "yeah, it have just worked, 
BUT.." and start evaluating if ease development will be enough to 
compensate for certain architectural issues in the long term 
(budget-wise).


 We didn't want any of those things from .js though. We're all
 low-level/native coders.
 We don't have time to debug language and library issues though. 
 If we
 didn't have tooling/library issues, we would have been 
 perfectly happy
 writing whatever code we needed to do our job.


If developer time is more expensive than server time in your 
project, most likely there is no point in going for native 
languages even if you prefer those. Otherwise debugger issues 
and/or necessity to switch the OS environment would not have 
stopped you.


 If there ever appears a game development company / community 
 interested in
 _investing_ into programming language that would be totally 
 different story
 but also irrelevant to enterprise culture you refer to.


 So, in your world, D is a language for nerds (linux nerds at 
 that!),
 and not for serious productivity by enterprise?
 Give me a break!


Of course it is language for nerds. Do you see a paid developer 
team working on D? At least ONE paid developer? Maybe someone of 
existing commercial users pays for adding tools / features? It is 
not a product, it is not funded and can't be anything but 
language for nerds unless YOU start paying for the change.

Which doesn't mean that it can be very productive language for 
serious projects. Nerds are pretty good at doing projects when 
there is no one from enterprise to create trouble. I think 
Sociomantic has proven quite strongly that such an attitude can 
work for successful business.

To start using D effectively in production one needs to stop 
considering himself a customer. This is absolutely critical.
Dec 17 2014
next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Wednesday, 17 December 2014 at 09:34:45 UTC, Dicebot wrote:

 To start using D effectively in production one needs to stop 
 considering himself a customer. This is absolutely critical.


This is a very interesting point: thanks you.
---
Paolo
Dec 17 2014
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 17 December 2014 at 09:48:43 UTC, Paolo Invernizzi 
wrote:

 On Wednesday, 17 December 2014 at 09:34:45 UTC, Dicebot wrote:

 To start using D effectively in production one needs to stop 
 considering himself a customer. This is absolutely critical.


 This is a very interesting point: thanks you.
 ---
 Paolo


I second this, it's a very good point. The customer attitude 
permeates this whole thread. D is not a framework for very 
specific tasks in limited domains like node.js. Is is a 
programming language that can be used to build frameworks (like 
e.g. vibe.d) If you only need a feature or two for a web project 
(as the 20-30 lines of JS that were mentioned suggest), you 
probably shouldn't use vibe.d. Only if you want to create 
something bigger, build an infrastructure from scratch say, or 
need high performance, should you consider vibe.d, which does 
have a certain learning curve, no doubt about it, as does D. I 
use vibe.d now but before I started to use it, I had tested it 
for a while to see, if it suited the project, which included 
playing around with it in my spare time. I did this with other D 
projects too.

I don't think it's a good idea to tell people about how great D 
is and then throw them right into it without any preliminary 
training. It is, after all, a fully fledged programming language, 
not an API for certain tasks like querying a web server. A 
language like D has to be _learned_, concepts have to be 
_understood_, even if you are already familiar with C++, Java or 

you that, regardless of how good the infrastructure may be, you 
couldn't just sit down and hack away without knowing the 

know about programming. If you did hack a web server together 
quickly, I'd be worried about the quality of the code.

JS and Python are "quick and dirty" languages in the sense that 
they were designed for people who are not really into 
programming, but want to get a task done quick (and dirty if 
needs be). You cannot compare them with D.
Dec 17 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 17 December 2014 at 20:34, Chris via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 17 December 2014 at 09:48:43 UTC, Paolo Invernizzi wrote:

 On Wednesday, 17 December 2014 at 09:34:45 UTC, Dicebot wrote:

 To start using D effectively in production one needs to stop considering
 himself a customer. This is absolutely critical.



 This is a very interesting point: thanks you.
 ---
 Paolo



 I second this, it's a very good point. The customer attitude permeates this
 whole thread. D is not a framework for very specific tasks in limited
 domains like node.js. Is is a programming language that can be used to build
 frameworks (like e.g. vibe.d) If you only need a feature or two for a web
 project (as the 20-30 lines of JS that were mentioned suggest), you probably
 shouldn't use vibe.d. Only if you want to create something bigger, build an
 infrastructure from scratch say, or need high performance, should you
 consider vibe.d, which does have a certain learning curve, no doubt about
 it, as does D. I use vibe.d now but before I started to use it, I had tested
 it for a while to see, if it suited the project, which included playing
 around with it in my spare time. I did this with other D projects too.


I think you've missed my entire point.
The summary is this:
Tried D, tried a very popular and often hyped D library/framework,
encountered bugs. There was friction along the way which undermines
confidence, but the critical point, the thing that caused the call to
be made, was that the debugger didn't work, and we were unable to
diagnose the bug with relative ease.
It's possible that wouldn't have inspired the call to be made if it
weren't for the prior friction... ie, if it were the first point of
friction, we might have persevered through that one, but the aggregate
prior to that point painted a clear picture, and that was the
proverbial straw.

Immaturity in the language seemed to allow for greater tolerance than
immaturity in the tooling.
This is the experience I was trying to convey... which was to be taken
as a case study, that is all.



 I don't think it's a good idea to tell people about how great D is and then
 throw them right into it without any preliminary training. It is, after all,
 a fully fledged programming language, not an API for certain tasks like
 querying a web server. A language like D has to be _learned_, concepts have



Again, you completely missed the problem. I haven't said anywhere that
the language itself raised any particular issues.
It was the *tooling*. There were also numerous complaints about the docs.



 The same is true of any of the more complex languages. I bet you that,
 regardless of how good the infrastructure may be, you couldn't just sit down

 how much you already know about programming. If you did hack a web server
 together quickly, I'd be worried about the quality of the code.


I would happily challenge that bet.

task done at work; expected to learn the languages within minutes and
produce a solution.
I never had any problems with this in the past.

The only language I've ever 'learned' was C, and that was 15-20 years ago.



 JS and Python are "quick and dirty" languages in the sense that they were
 designed for people who are not really into programming, but want to get a
 task done quick (and dirty if needs be). You cannot compare them with D.


I can and I did.
Dec 18 2014
next sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via 
Digitalmars-d wrote:

 On 17 December 2014 at 20:34, Chris via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Wednesday, 17 December 2014 at 09:48:43 UTC, Paolo 
 Invernizzi wrote:

 On Wednesday, 17 December 2014 at 09:34:45 UTC, Dicebot wrote:

 To start using D effectively in production one needs to stop 
 considering
 himself a customer. This is absolutely critical.



 This is a very interesting point: thanks you.
 ---
 Paolo



 I second this, it's a very good point. The customer attitude 
 permeates this
 whole thread. D is not a framework for very specific tasks in 
 limited
 domains like node.js. Is is a programming language that can be 
 used to build
 frameworks (like e.g. vibe.d) If you only need a feature or 
 two for a web
 project (as the 20-30 lines of JS that were mentioned 
 suggest), you probably
 shouldn't use vibe.d. Only if you want to create something 
 bigger, build an
 infrastructure from scratch say, or need high performance, 
 should you
 consider vibe.d, which does have a certain learning curve, no 
 doubt about
 it, as does D. I use vibe.d now but before I started to use 
 it, I had tested
 it for a while to see, if it suited the project, which 
 included playing
 around with it in my spare time. I did this with other D 
 projects too.


 I think you've missed my entire point.
 The summary is this:
 Tried D, tried a very popular and often hyped D 
 library/framework,
 encountered bugs. There was friction along the way which 
 undermines
 confidence, but the critical point, the thing that caused the 
 call to
 be made, was that the debugger didn't work, and we were unable 
 to
 diagnose the bug with relative ease.
 It's possible that wouldn't have inspired the call to be made 
 if it
 weren't for the prior friction... ie, if it were the first 
 point of
 friction, we might have persevered through that one, but the 
 aggregate
 prior to that point painted a clear picture, and that was the
 proverbial straw.

 Immaturity in the language seemed to allow for greater 
 tolerance than
 immaturity in the tooling.
 This is the experience I was trying to convey... which was to 
 be taken
 as a case study, that is all.


I didn't miss your point. I know you were going on about the 
tooling/infrastructure and not about the language. However, the 
approach of using a rather complex framework like vibed without 
giving your colleagues any hint about how D works is simply not a 
good idea and bound to fail. Of course they cannot find their way 
around, of course they have no clue where to start when they 
encounter a problem. And to use something like vibed for a 
trivial 20-30 line node.js solution is beyond comprehension for 
me. In doing so, you haven't done D a favor, and it's neither D's 
nor the tools' fault.


 I don't think it's a good idea to tell people about how great 
 D is and then
 throw them right into it without any preliminary training. It 
 is, after all,
 a fully fledged programming language, not an API for certain 
 tasks like
 querying a web server. A language like D has to be _learned_, 
 concepts have
 to be _understood_, even if you are already familiar with C++, 



 Again, you completely missed the problem. I haven't said 
 anywhere that
 the language itself raised any particular issues.
 It was the *tooling*. There were also numerous complaints about 
 the docs.


The docs ain't that bad. I've found my way around in worse docs 
than D's. I'm beginning to wonder, if the heavy reliance on tools 
doesn't spoil people. If it ain't served on a silver plate, bah, 
I won't eat it. Is that the attitude? I hope not.


 The same is true of any of the more complex languages. I bet 
 you that,
 regardless of how good the infrastructure may be, you couldn't 
 just sit down

 C++, no matter
 how much you already know about programming. If you did hack a 
 web server
 together quickly, I'd be worried about the quality of the code.


 I would happily challenge that bet.

 get a
 task done at work; expected to learn the languages within 
 minutes and
 produce a solution.
 I never had any problems with this in the past.


I honestly don't believe that you actually _learned_ all those 
languages in depth. I've used Lua, JS and Python too. I know how 
to use Lua but I cannot say I have _learned_ Lua to the extent 
that I can build complex systems with it without humbly going 
back and study some of its more advanced features and how to use 
them properly (e.g. metaprogramming). What you're saying is that 
you've _used_ the languages and found your way around to a 
certain extent, we all do that, and scripting languages are often 
quite limited, so it's easier to "learn" them.


 The only language I've ever 'learned' was C, and that was 15-20 
 years ago.



 JS and Python are "quick and dirty" languages in the sense 
 that they were
 designed for people who are not really into programming, but 
 want to get a
 task done quick (and dirty if needs be). You cannot compare 
 them with D.


 I can and I did.


Which is why this thread turned into a little flamewar. When you 
mix apples and oranges, people will take issue with it.

A note on "silver plate" frameworks. Without exception, I've 
found that every time one sets out with a "mature and tested" 
framework that has been around for a while, that has nice tools 
etc., is used by companies all over the world (because it saves 
time, not so much for reasons regarding its quality), it is to 
find out further down the road "Sh*t, that's not possible with 
xyz! What now, we cannot go back now, too much time invested. 
Well, we'll have to wait until they fix it, if they fix it at 
all." Little things developers might not think of when they set 
out, accessibility for example. It is dangerous to use something 
only because it seems easy to use at the beginning. It may cost 
you dearly further down the road. Before I decide to use a 
technology, I test it first, be it node.js, foundation framework, 
bootstrap or vibed.
Dec 18 2014
prev sibling parent reply "Mathias LANG" <geod24 gmail.com> writes:
On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via 
Digitalmars-d wrote:

 I think you've missed my entire point.
 The summary is this:
 Tried D, tried a very popular and often hyped D 
 library/framework,
 encountered bugs. There was friction along the way which 
 undermines
 confidence, but the critical point, the thing that caused the 
 call to
 be made, was that the debugger didn't work, and we were unable 
 to
 diagnose the bug with relative ease.
 It's possible that wouldn't have inspired the call to be made 
 if it
 weren't for the prior friction... ie, if it were the first 
 point of
 friction, we might have persevered through that one, but the 
 aggregate
 prior to that point painted a clear picture, and that was the
 proverbial straw.

 Immaturity in the language seemed to allow for greater 
 tolerance than
 immaturity in the tooling.
 This is the experience I was trying to convey... which was to 
 be taken
 as a case study, that is all.


What I'm wondering is how is it you didn't encounter this issue 
yourself before ? If you've been using D for 6 or 7 years, and it 
was a small project that was done in 20 to 30 lines of node.js ? 
So you clearly entered unknown territory and expected everything 
to be fine, despite your experience with D.

Can you link us to the issue(s) you created on Vibe.d's Github ?

We know some stuff sux. Just look at std.datetime's 
documentation. On my 15" laptop, the links take all the screen. 
And this part is totally useless, as no one is going to use it 
(beside ctrl + f, but you have to know what you are looking for). 
Not mentioning the size of enum (just look at how much space 
trivial enums such as "DayOfWeek" or "Month" takes).

However, many of us lack the time and interest to fix this, as we 
know our way around. The same goes for all the tooling/libraries, 
they were developped, and are maintained out of one's necessity, 
not because "we" need it.
Dec 18 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 18 December 2014 at 23:52, Mathias LANG via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via Digitalmars-d wrote:

 I think you've missed my entire point.
 The summary is this:
 Tried D, tried a very popular and often hyped D library/framework,
 encountered bugs. There was friction along the way which undermines
 confidence, but the critical point, the thing that caused the call to
 be made, was that the debugger didn't work, and we were unable to
 diagnose the bug with relative ease.
 It's possible that wouldn't have inspired the call to be made if it
 weren't for the prior friction... ie, if it were the first point of
 friction, we might have persevered through that one, but the aggregate
 prior to that point painted a clear picture, and that was the
 proverbial straw.

 Immaturity in the language seemed to allow for greater tolerance than
 immaturity in the tooling.
 This is the experience I was trying to convey... which was to be taken
 as a case study, that is all.


 What I'm wondering is how is it you didn't encounter this issue yourself
 before ? If you've been using D for 6 or 7 years, and it was a small project
 that was done in 20 to 30 lines of node.js ? So you clearly entered unknown
 territory and expected everything to be fine, despite your experience with
 D.


Simple, I never tried to use websockets in vibe.d
I had some past experience with vibe.d to do some web page stuff, and
my experience was practically flawless, which is why I had confidence
in it in the first place.

Other common language issues that I did anticipate, I expected to be
able to work through. I did know the debugger was an issue; it was
actually my biggest fear going in. It did turn out to be the thing
that bit me in the arse!
I just hoped/expected we wouldn't need the debugger in such a small
and simple program.
The debugger does work okay for certain tasks, particularly if you
control your coding style and make sure it's compatible with the
debugger. I didn't have that luxury though as I usually do, since we
were working on a foreign framework.



 Can you link us to the issue(s) you created on Vibe.d's Github ?


https://github.com/rejectedsoftware/vibe.d/issues/931

I can't really articulate the problem well. Google's Native Client is
a part of the puzzle, and that's a complex environment to get working.
We tested the NaCl client against some other websocket servers though,
and the problem didn't occur.

I want to try and isolate a test case if I ever get some free time at work :/


The other problem I can't isolate, it's just that the first file
that's requested from time to time locks up the browser... if I kill
the browser, reload and refresh, the problem goes away.
I'll also see if I can post some code that demonstrates that case, but
I have my suspicions that's client specific too.



 We know some stuff sux. Just look at std.datetime's documentation. On my 15"
 laptop, the links take all the screen. And this part is totally useless, as
 no one is going to use it (beside ctrl + f, but you have to know what you
 are looking for). Not mentioning the size of enum (just look at how much
 space trivial enums such as "DayOfWeek" or "Month" takes).

 However, many of us lack the time and interest to fix this, as we know our
 way around. The same goes for all the tooling/libraries, they were
 developped, and are maintained out of one's necessity, not because "we" need
 it.


I know. I only said that there were a lot of complaints relating to
the documentation, because there were.
Although that said, as far as I can tell, it wasn't a particularly
heavily weighting factor in the decision. Just worth noting; it wasn't
endearing to anyone.
Dec 18 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via 
Digitalmars-d wrote:

 On 18 December 2014 at 23:52, Mathias LANG via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via 
 Digitalmars-d wrote:

 I think you've missed my entire point.
 The summary is this:
 Tried D, tried a very popular and often hyped D 
 library/framework,
 encountered bugs. There was friction along the way which 
 undermines
 confidence, but the critical point, the thing that caused the 
 call to
 be made, was that the debugger didn't work, and we were 
 unable to
 diagnose the bug with relative ease.
 It's possible that wouldn't have inspired the call to be made 
 if it
 weren't for the prior friction... ie, if it were the first 
 point of
 friction, we might have persevered through that one, but the 
 aggregate
 prior to that point painted a clear picture, and that was the
 proverbial straw.

 Immaturity in the language seemed to allow for greater 
 tolerance than
 immaturity in the tooling.
 This is the experience I was trying to convey... which was to 
 be taken
 as a case study, that is all.


 What I'm wondering is how is it you didn't encounter this 
 issue yourself
 before ? If you've been using D for 6 or 7 years, and it was a 
 small project
 that was done in 20 to 30 lines of node.js ? So you clearly 
 entered unknown
 territory and expected everything to be fine, despite your 
 experience with
 D.


 Simple, I never tried to use websockets in vibe.d
 I had some past experience with vibe.d to do some web page 
 stuff, and
 my experience was practically flawless, which is why I had 
 confidence
 in it in the first place.

 Other common language issues that I did anticipate, I expected 
 to be
 able to work through. I did know the debugger was an issue; it 
 was
 actually my biggest fear going in. It did turn out to be the 
 thing
 that bit me in the arse!
 I just hoped/expected we wouldn't need the debugger in such a 
 small
 and simple program.
 The debugger does work okay for certain tasks, particularly if 
 you
 control your coding style and make sure it's compatible with the
 debugger. I didn't have that luxury though as I usually do, 
 since we
 were working on a foreign framework.



 Can you link us to the issue(s) you created on Vibe.d's Github 
 ?


 https://github.com/rejectedsoftware/vibe.d/issues/931

 I can't really articulate the problem well. Google's Native 
 Client is
 a part of the puzzle, and that's a complex environment to get 
 working.
 We tested the NaCl client against some other websocket servers 
 though,
 and the problem didn't occur.

 I want to try and isolate a test case if I ever get some free 
 time at work :/


 The other problem I can't isolate, it's just that the first file
 that's requested from time to time locks up the browser... if I 
 kill
 the browser, reload and refresh, the problem goes away.
 I'll also see if I can post some code that demonstrates that 
 case, but
 I have my suspicions that's client specific too.



 We know some stuff sux. Just look at std.datetime's 
 documentation. On my 15"
 laptop, the links take all the screen. And this part is 
 totally useless, as
 no one is going to use it (beside ctrl + f, but you have to 
 know what you
 are looking for). Not mentioning the size of enum (just look 
 at how much
 space trivial enums such as "DayOfWeek" or "Month" takes).

 However, many of us lack the time and interest to fix this, as 
 we know our
 way around. The same goes for all the tooling/libraries, they 
 were
 developped, and are maintained out of one's necessity, not 
 because "we" need
 it.


 I know. I only said that there were a lot of complaints 
 relating to
 the documentation, because there were.
 Although that said, as far as I can tell, it wasn't a 
 particularly
 heavily weighting factor in the decision. Just worth noting; it 
 wasn't
 endearing to anyone.


So to sum things up

1. you blindly walked into something you had no real experience 
with, apart from some vague memory that some parts of vibed 
worked for you a while ago.

2. you knew the debugger might be an issue, if not _the_ issue, 
but chose not to test it beforehand, or couldn't test it 
beforehand, because

3. you were working on a foreign framework (and simply hoped 
things would work out fine, fingers crossed!).

These are crucial bits of information that were missing from your 
first report.

Please try to be more accurate the next time. Holding back 
crucial information gets us nowhere. It only leaves the (false) 
impression that D is completely unusable.
Dec 18 2014
next sibling parent "Daniel Davidson" <nospam spam.com> writes:
 So to sum things up

 1. you blindly walked into something you had no real experience 
 with, apart from some vague memory that some parts of vibed 
 worked for you a while ago.


Pure bile. No - reread the thread.


 2. you knew the debugger might be an issue, if not _the_ issue, 
 but chose not to test it beforehand, or couldn't test it 
 beforehand, because

 3. you were working on a foreign framework (and simply hoped 
 things would work out fine, fingers crossed!).


Isn't that what you would hope? I would.


 These are crucial bits of information that were missing from 
 your first report.

 Please try to be more accurate the next time. Holding back 
 crucial information gets us nowhere. It only leaves the (false) 
 impression that D is completely unusable.


How can you read this thread and think he was holding back 
anything. Everything he says is *easily* relatable and 
understandable. Besides he is trying to provide valuable 
information in a way that is much less abusive than many of the 
threads in this community. What I read was not that "D is 
completely unusable" but rather "the D debug story on Windows is 
a big problem and it lost D some potential users".
Dec 18 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 December 2014 at 00:55, Chris via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via Digitalmars-d wrote:

 So to sum things up

 1. you blindly walked into something you had no real experience with, apart
 from some vague memory that some parts of vibed worked for you a while ago.

 2. you knew the debugger might be an issue, if not _the_ issue, but chose
 not to test it beforehand, or couldn't test it beforehand, because

 3. you were working on a foreign framework (and simply hoped things would
 work out fine, fingers crossed!).

 These are crucial bits of information that were missing from your first
 report.

 Please try to be more accurate the next time. Holding back crucial
 information gets us nowhere. It only leaves the (false) impression that D is
 completely unusable.


Fuck you guys.
I'm done here.
Dec 18 2014
next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Friday, 19 December 2014 at 06:47:31 UTC, Manu via 
Digitalmars-d wrote:

 On 19 December 2014 at 00:55, Chris via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via 
 Digitalmars-d wrote:

 So to sum things up

 1. you blindly walked into something you had no real 
 experience with, apart
 from some vague memory that some parts of vibed worked for you 
 a while ago.

 2. you knew the debugger might be an issue, if not _the_ 
 issue, but chose
 not to test it beforehand, or couldn't test it beforehand, 
 because

 3. you were working on a foreign framework (and simply hoped 
 things would
 work out fine, fingers crossed!).

 These are crucial bits of information that were missing from 
 your first
 report.

 Please try to be more accurate the next time. Holding back 
 crucial
 information gets us nowhere. It only leaves the (false) 
 impression that D is
 completely unusable.


 Fuck you guys.
 I'm done here.


I think it's a fair criticism that you knew D projects like 
vibe.d and perhaps the language itself tend to favor linux and 
that the tooling on Windows, ie linker and debugger, is not so 
great, yet jumped in and hoped it would work.  You took a 
low-odds gamble that it would all work and it crapped out.

Perhaps Chris is too accusatory and defensive about the language 
when pointing this out, but D has its weak spots and you walked 
into some of them.  Thanks for pointing them out, even if the 
core team already knew about most of them, as it's another 
anecdote to add to the list.

Perhaps this thread you started will spur people to work on some 
of these issues.
Dec 18 2014
prev sibling next sibling parent reply "ole" <ole ole.ole> writes:
On Friday, 19 December 2014 at 06:47:31 UTC, Manu via
Digitalmars-d wrote:

 On 19 December 2014 at 00:55, Chris via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via 
 Digitalmars-d wrote:

 So to sum things up

 1. you blindly walked into something you had no real 
 experience with, apart
 from some vague memory that some parts of vibed worked for you 
 a while ago.

 2. you knew the debugger might be an issue, if not _the_ 
 issue, but chose
 not to test it beforehand, or couldn't test it beforehand, 
 because

 3. you were working on a foreign framework (and simply hoped 
 things would
 work out fine, fingers crossed!).

 These are crucial bits of information that were missing from 
 your first
 report.

 Please try to be more accurate the next time. Holding back 
 crucial
 information gets us nowhere. It only leaves the (false) 
 impression that D is
 completely unusable.


 Fuck you guys.
 I'm done here.


me too. it's really disgusting how you guys treat (verbally
mistreat) others, who take a chance with D.
Good luck to you all on your pet project.
Dec 18 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote:

 me too. it's really disgusting how you guys treat (verbally
 mistreat) others, who take a chance with D.
 Good luck to you all on your pet project.


And how? Explaining mistakes and reasons why just taking a chance 
brings nothing (and can as well do a harm)?

Chris point was overblown, sure, but so was original post.

Manu has explained his case in great details and that was very 
good. However it was missing single most important part - 
explanation of what he wants to achieve, what actions he expects 
from community. So far it sounded like "hey guys I know you are 
nerds so go implement everything I need for my projects instead 
of working on yours". I'd be glad to be mistaken but it still 
looks like that so far.
Dec 18 2014
next sibling parent reply "ole" <ole ole.ole> writes:
On Friday, 19 December 2014 at 07:37:45 UTC, Dicebot wrote:

 On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote:

 me too. it's really disgusting how you guys treat (verbally
 mistreat) others, who take a chance with D.
 Good luck to you all on your pet project.


 And how? Explaining mistakes and reasons why just taking a 
 chance brings nothing (and can as well do a harm)?

 Chris point was overblown, sure, but so was original post.

 Manu has explained his case in great details and that was very 
 good. However it was missing single most important part - 
 explanation of what he wants to achieve, what actions he 
 expects from community. So far it sounded like "hey guys I know 
 you are nerds so go implement everything I need for my projects 
 instead of working on yours". I'd be glad to be mistaken but it 
 still looks like that so far.


i appreciate your try, but with ketmar and others a very special 
verbal abuse was introduced here. one thing is sure for me by now:
    NOBODY uses D for something serious and the reasons for that a 
plenty.

never the less - good luck.
Dec 18 2014
parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Friday, 19 December 2014 at 07:52:12 UTC, ole wrote:

 On Friday, 19 December 2014 at 07:37:45 UTC, Dicebot wrote:

 one thing is sure for me by now:
    NOBODY uses D for something serious and the reasons for that 
 a plenty.


You are plain wrong here.
---
Paolo
Dec 19 2014
prev sibling parent reply "uri" <uri.grill gmail.com> writes:
On Friday, 19 December 2014 at 07:37:45 UTC, Dicebot wrote:

 On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote:

 me too. it's really disgusting how you guys treat (verbally
 mistreat) others, who take a chance with D.
 Good luck to you all on your pet project.


 And how? Explaining mistakes and reasons why just taking a 
 chance brings nothing (and can as well do a harm)?

 Chris point was overblown, sure, but so was original post.

 Manu has explained his case in great details and that was very 
 good. However it was missing single most important part - 
 explanation of what he wants to achieve, what actions he 
 expects from community. So far it sounded like "hey guys I know 
 you are nerds so go implement everything I need for my projects 
 instead of working on yours". I'd be glad to be mistaken but it 
 still looks like that so far.


+1

What D needs right now is for people to stop complaining about 
the things that are wrong and start contributing.

Cheers,
uri
Dec 19 2014
parent "uri" <uri.grill gmail.com> writes:
On Friday, 19 December 2014 at 09:52:09 UTC, uri wrote:

 On Friday, 19 December 2014 at 07:37:45 UTC, Dicebot wrote:

 On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote:

 me too. it's really disgusting how you guys treat (verbally
 mistreat) others, who take a chance with D.
 Good luck to you all on your pet project.


 And how? Explaining mistakes and reasons why just taking a 
 chance brings nothing (and can as well do a harm)?

 Chris point was overblown, sure, but so was original post.

 Manu has explained his case in great details and that was very 
 good. However it was missing single most important part - 
 explanation of what he wants to achieve, what actions he 
 expects from community. So far it sounded like "hey guys I 
 know you are nerds so go implement everything I need for my 
 projects instead of working on yours". I'd be glad to be 
 mistaken but it still looks like that so far.


 +1

 What D needs right now is for people to stop complaining about 
 the things that are wrong and start contributing.

 Cheers,
 uri


And if you don't have time to contribute then submit an ER or bug 
report. Even that will be more constructive than having a pubilc 
tantrum when others disagree.

A bit embarrassing I'd say.


Cheers,
uri
Dec 19 2014
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 19 December 2014 at 06:47:31 UTC, Manu via 
Digitalmars-d wrote:

 On 19 December 2014 at 00:55, Chris via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via 
 Digitalmars-d wrote:

 So to sum things up

 1. you blindly walked into something you had no real 
 experience with, apart
 from some vague memory that some parts of vibed worked for you 
 a while ago.

 2. you knew the debugger might be an issue, if not _the_ 
 issue, but chose
 not to test it beforehand, or couldn't test it beforehand, 
 because

 3. you were working on a foreign framework (and simply hoped 
 things would
 work out fine, fingers crossed!).

 These are crucial bits of information that were missing from 
 your first
 report.

 Please try to be more accurate the next time. Holding back 
 crucial
 information gets us nowhere. It only leaves the (false) 
 impression that D is
 completely unusable.


 Fuck you guys.
 I'm done here.


"You guys"? Don't lump the rest of us in with one guy's ranting. 
What have the rest of us done to deserve a "fuck you"?
Dec 19 2014
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 19 December 2014 at 08:31:12 UTC, John Colvin wrote:

 "You guys"? Don't lump the rest of us in with one guy's 
 ranting. What have the rest of us done to deserve a "fuck you"?


While I'm not unsympathetic to your point, try to see things from 
Manu's position.  Every time I've seen him bring up an issue that 
he has experienced in reality, he's been told, variously:
a) You're doing it wrong
b) Your problem isn't real
c) Your use case doesn't exist
d) We don't need theoretical solutions
e) The things you want are niche and pointless

...and so on.

Despite this, he's persisted in trying to raise awareness and 
support for close-to-the-metal performance and control for 
_years_.  And then this thread happens after he was burned (yet 
again!) by the tooling and the "foolish" expectation that things 
would work as advertised in a situation where he lost face with 
his peers.

Can you really blame him for being frustrated?

-Wyatt
Dec 19 2014
parent "Joakim" <dlang joakim.fea.st> writes:
On Friday, 19 December 2014 at 14:50:48 UTC, Wyatt wrote:

 On Friday, 19 December 2014 at 08:31:12 UTC, John Colvin wrote:

 "You guys"? Don't lump the rest of us in with one guy's 
 ranting. What have the rest of us done to deserve a "fuck you"?


 While I'm not unsympathetic to your point, try to see things 
 from Manu's position.  Every time I've seen him bring up an


I'm not sympathetic to it, as Manu obviously wasn't talking about 
John but about the couple people he was frustrated with.  I 
realize everyone wants to start a flame war, but it's silly to 
take the most expansive possible meaning of every barb and then 
take haughty offense at it.
Dec 19 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 December 2014 at 18:31, John Colvin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 19 December 2014 at 06:47:31 UTC, Manu via Digitalmars-d wrote:

 On 19 December 2014 at 00:55, Chris via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via Digitalmars-d
 wrote:

 So to sum things up

 1. you blindly walked into something you had no real experience with,
 apart
 from some vague memory that some parts of vibed worked for you a while
 ago.

 2. you knew the debugger might be an issue, if not _the_ issue, but chose
 not to test it beforehand, or couldn't test it beforehand, because

 3. you were working on a foreign framework (and simply hoped things would
 work out fine, fingers crossed!).

 These are crucial bits of information that were missing from your first
 report.

 Please try to be more accurate the next time. Holding back crucial
 information gets us nowhere. It only leaves the (false) impression that D
 is
 completely unusable.



 Fuck you guys.
 I'm done here.



 "You guys"? Don't lump the rest of us in with one guy's ranting. What have
 the rest of us done to deserve a "fuck you"?


Sorry, there were 3 guys in particular who were ripping into me for
whatever reason. Sorry for the blanket statement, it was directed at
them. I don't really feel I need to be ripped apart for trying to
encourage D use in the office, and then reporting on our experience.
You were personally supportive, so to yourself (and others), thanks.
Dec 19 2014
parent reply "Atila Neves" <atila.neves gmail.com> writes:
FWIW, I'd like to thank you for taking the time (and putting up 
with some undeserved abuse for it) to write about your experience 
in trying to get other people to adopt D. For some they might be 
known issues, but the fact is these things matter, and knowing 
about them is part of fixing them.

Alas, I abandoned doing development on Windows ages ago, so it's 
not something I can help with. I don't rely on debuggers myself, 
but I do use them when it makes sense to me and it's annoying 
enough when gdb can't print things properly even with Iain's 
patched version.

As for the documentation, like others I don't mind it or have any 
problems with it, but that's not the point here. The point is 
that potential new users did, and so it needs to be improved.

Your problems are not issues I have or had; but others did and as 
much as like my Arch Linux some will prefer Windows and the 
experience has to be good for them as well.

Atila


 Sorry, there were 3 guys in particular who were ripping into me 
 for
 whatever reason. Sorry for the blanket statement, it was 
 directed at
 them. I don't really feel I need to be ripped apart for trying 
 to
 encourage D use in the office, and then reporting on our 
 experience.
 You were personally supportive, so to yourself (and others), 
 thanks.
Dec 20 2014
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 20 Dec 2014 20:40, "Atila Neves via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 FWIW, I'd like to thank you for taking the time (and putting up with some


undeserved abuse for it) to write about your experience in trying to get
other people to adopt D. For some they might be known issues, but the fact
is these things matter, and knowing about them is part of fixing them.

 Alas, I abandoned doing development on Windows ages ago, so it's not


something I can help with. I don't rely on debuggers myself, but I do use
them when it makes sense to me and it's annoying enough when gdb can't
print things properly even with Iain's patched version.


We should really put all debugging issues into (separate) bug reports and
tie them together with a keyword.

I use gdc compiled code for all my testing, so that is really the baseline
which I'm implementing against.

I will need to know whether it is reproducible with gdc, or is another
problem that needs to be fixed in dmd's dwarf-gen.

Iain.



 Dec 26 2014



prev sibling  parent  "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net>  writes:


On Thursday, 18 December 2014 at 14:55:19 UTC, Chris wrote:

 So to sum things up

 1. you blindly walked into something you had no real experience 
 with, apart from some vague memory that some parts of vibed 
 worked for you a while ago.

 2. you knew the debugger might be an issue, if not _the_ issue, 
 but chose not to test it beforehand, or couldn't test it 
 beforehand, because

 3. you were working on a foreign framework (and simply hoped 
 things would work out fine, fingers crossed!).

 These are crucial bits of information that were missing from 
 your first report.

 Please try to be more accurate the next time. Holding back 
 crucial information gets us nowhere. It only leaves the (false) 
 impression that D is completely unusable.


This is out of line.  It doesn't help anyone to throw around this 
kind of aggressive, blame-laden criticism, especially not towards 
someone who is trying to expand the professional developer uptake 
of D.

It's important that we all try and be constructive, sympathetic 
and helpful when offering advice, even (actually, especially) 
when suggesting to someone that they might have done things 
differently.



 Dec 19 2014



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 17 December 2014 at 19:48, Paolo Invernizzi via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 17 December 2014 at 09:34:45 UTC, Dicebot wrote:

 To start using D effectively in production one needs to stop considering
 himself a customer. This is absolutely critical.



 This is a very interesting point: thanks you.
 ---
 Paolo


I don't get it... I really can't understand this perspective at all.
We're not here to be a cool exclusive little club where super-nerdy
programmers can hang out and talk about advanced language concepts.
At least, that's absolutely not why I'm here.

A language end-user shouldn't require any personal involvement in the
development community. I don't hang out with stroustrup and sutter and
talk about C++.



 Dec 18 2014



prev sibling  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 17 December 2014 at 19:34, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wednesday, 17 December 2014 at 08:30:59 UTC, Manu via Digitalmars-d
 wrote:

 Actually, I recommended it because I had had a positive experience
 with vibe.d in the past. It seemed pretty solid.
 Gotta start somewhere. I've had success promoting D to commercial
 users in the past.



 Promoting to commercial users is indeed possible but one needs to explain
 risks and trade-offs straight. I wonder though how you have not noticed
 debugger issues before if there was some positive experience. There was
 nothing to debug? :)


I would never use exceptions. vibe.d uses exceptions extensively.
I have very little experience with exceptions in the debuggers.



 Idea that any D project can compete with node.js in "easy to jump in"
 domain
 is absolutely ridiculous. Attempting this is just dooming yourself to
 fail.
 Same is trying to advertise it is stable mature language - reality is it
 is
 simply not true and people will find out it sooner or later.



 Sorry, maybe it wasn't clear, we never tried it out against node.js,
 we tried it first, on my recommendation.
 When it was rejected, someone else suggested to look at node.js. We
 looked at that, it just worked.



 I mean that if "it just worked" was enough to make decision to use the
 node.js, then you didn't have any critical requirements that it fails to
 address (otherwise you would have looked for those first). Which means that
 pretty much any framework out there was suitable and ease of use was only
 truly important criteria.


Correct. Although as native programmers, we would have been much more
comfortable with an ecosystem we were familiar with given the choice.



 Interesting part starts when you say "yeah, it have just worked, BUT.." and
 start evaluating if ease development will be enough to compensate for
 certain architectural issues in the long term (budget-wise).


It's a fairly small project, that's why I promoted D in this context
in the first place.
I needed a small project to get people amongst it before we could
consider anything more ambitious.

It was just a good opportunity to get it into the company.



 We didn't want any of those things from .js though. We're all
 low-level/native coders.
 We don't have time to debug language and library issues though. If we
 didn't have tooling/library issues, we would have been perfectly happy
 writing whatever code we needed to do our job.



 If developer time is more expensive than server time in your project, most
 likely there is no point in going for native languages even if you prefer
 those. Otherwise debugger issues and/or necessity to switch the OS
 environment would not have stopped you.


We are native programmers, we know how to write native code, and we
understand the ecosystem.
That's good reason enough.

It's true, there was no compelling reason to choose any technology in
particular other than familiarity or ease of development.
It just would have been nice to create a context in the company where
people could have a go at D.



 If there ever appears a game development company / community interested
 in
 _investing_ into programming language that would be totally different
 story
 but also irrelevant to enterprise culture you refer to.



 So, in your world, D is a language for nerds (linux nerds at that!),
 and not for serious productivity by enterprise?
 Give me a break!



 Of course it is language for nerds. Do you see a paid developer team working
 on D? At least ONE paid developer? Maybe someone of existing commercial
 users pays for adding tools / features? It is not a product, it is not
 funded and can't be anything but language for nerds unless YOU start paying
 for the change.


Me? Personally?
Well Remedy kicked in quite substantially for dconf, but I think my
getting my company involved increases the chances for licensing and
monetisation than any amount I can donate from my own pocket...



 Which doesn't mean that it can be very productive language for serious
 projects. Nerds are pretty good at doing projects when there is no one from
 enterprise to create trouble. I think Sociomantic has proven quite strongly
 that such an attitude can work for successful business.

 To start using D effectively in production one needs to stop considering
 himself a customer. This is absolutely critical.


I am obviously personally capable of working around D's ecosystem
issues; I'm still here after 6 years.
What I am presenting here is an account on why my company rejected D,
despite a large number of staff being super excited and jazzed to try
it out.
I'd like to think there's something to learn from that.



 Dec 18 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 18 December 2014 at 09:56:07 UTC, Manu via 
Digitalmars-d wrote:

 Of course it is language for nerds. Do you see a paid 
 developer team working
 on D? At least ONE paid developer? Maybe someone of existing 
 commercial
 users pays for adding tools / features? It is not a product, 
 it is not
 funded and can't be anything but language for nerds unless YOU 
 start paying
 for the change.


 Me? Personally?
 Well Remedy kicked in quite substantially for dconf, but I 
 think my
 getting my company involved increases the chances for licensing 
 and
 monetisation than any amount I can donate from my own pocket...


And Remedy sponsorship was very helpful in allowing DConf to 
happen and greatly boosting communications as a result. Sadly we 
need much more than just one conference. When I am speaking about 
personal involvement I don't mean straightforward donation but 
efforts to convince companies in your industry to _invest_ into D 
ecosystem.

I keep repeating word "investment" and it is crucical. At this 
point we don't really need new users, those will come eventually 
if issues are fixed. We need more companies willing to dedicate 
time of its developers to work on compilers, tools and core 
projects of D ecosystem. That is the only way to get what you 
expect.

For example, consider your disappointment with Windows support. 
As far as I know, 3 largest commercial D users (EMSI, Facebook 
Sociomantic; in terms of D developer count) use Linux as 
foundation for their D projects. Not sure about EMSI but seems 
so. Why would any of those companies invest into making Windows 
support better?

You speak about increased chances for licensing and monetisation 
but there is not licensing in D world. And hardly any 
monetisation. Please take your time to actually understand it. 
The fact that your company would have started to use D didn't 
fucking matter to D development in general apart from some small 
marketing boost. No licenses they would buy to boost further 
development, no support contracts with similar benefit. You are 
asking for huge amount of combined effort from people that won't 
even slightly benefit from the success.

Sometimes I have a feeling that game developers consider 
open-source a magic box where you can just shout your complaints 
in and eventually put your hand inside and get something useful 
out of it. It doesn't work that way.


 To start using D effectively in production one needs to stop 
 considering
 himself a customer. This is absolutely critical.


 I am obviously personally capable of working around D's 
 ecosystem
 issues; I'm still here after 6 years.
 What I am presenting here is an account on why my company 
 rejected D,
 despite a large number of staff being super excited and jazzed 
 to try
 it out.
 I'd like to think there's something to learn from that.


I have hardly learned anything new from this story, it is mostly 
known points and issues. Instead of telling what needs to be done 
please try telling WHO needs to do it and maybe then you will 
realize why knowing it is only so useful.


 I don't get it... I really can't understand this perspective at 
 all.
 We're not here to be a cool exclusive little club where 
 super-nerdy
 programmers can hang out and talk about advanced language 
 concepts.
 At least, that's absolutely not why I'm here.
 
 A language end-user shouldn't require any personal involvement 
 in the
 development community. I don't hang out with stroustrup and 
 sutter and
 talk about C++.


Exactly what I have meant - we don't truly have END-users. There 
are more involved users and less involved users, each working on 
parts and tools he needs. Some of those users do it in spare time 
and for fun, few are paid programmers enhancing tools needed to 
use D in their company. But there is not a single person actually 
selling D or getting anything from its success, maybe apart from 
Walter himself. How can one have customers without having sellers?

We are all bunch of investors here.



 Dec 18 2014



  parent reply "Paolo Invernizzi" <paolo.invernizzi no.address>  writes:


On Thursday, 18 December 2014 at 11:21:09 UTC, Dicebot wrote:

 Exactly what I have meant - we don't truly have END-users. 
 There are more involved users and less involved users, each 
 working on parts and tools he needs. Some of those users do it 
 in spare time and for fun, few are paid programmers enhancing 
 tools needed to use D in their company. But there is not a 
 single person actually selling D or getting anything from its 
 success, maybe apart from Walter himself. How can one have 
 customers without having sellers?

 We are all bunch of investors here.


SR Labs is using D under Windows and linux in production, since a 
long time: for example, D will be present at CES this year, 
powering an eye-tracker linux kiosk from the ground-up.

Sadly, currently we have not a single minute to spare, 
contributing back to the D ecosystem, but I've more than a hope 
that we can change that in the near future... finger crossed...
---
Paolo



 Dec 18 2014



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/18/2014 5:24 AM, Paolo Invernizzi wrote:

 Sadly, currently we have not a single minute to spare, contributing back to the
 D ecosystem, but I've more than a hope that we can change that in the near
 future... finger crossed...


Even little things help like filing bug reports or documentation improvement
PR's.



 Dec 19 2014



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/17/2014 12:30 AM, Manu via Digitalmars-d wrote:

 If vibe.d didn't crash, *or* if the debugger actually worked (such
 that we could have debugged the crash), then we would have surely
 stuck with that.
 But we couldn't get behind a solution that was impossible to debug.


I've debugged a lot of D code with no debugger at all (how else could I port it 
to various platforms like Win64?).

I've actually not found debuggers to be of much use other than telling me where 
the seg fault was and giving a stack trace.



 Dec 19 2014



  parent reply "Sergei Nosov" <sergei.nosov gmail.com>  writes:


On Friday, 19 December 2014 at 08:57:56 UTC, Walter Bright wrote:

 I've debugged a lot of D code with no debugger at all (how else 
 could I port it to various platforms like Win64?).

 I've actually not found debuggers to be of much use other than 
 telling me where the seg fault was and giving a stack trace.


I think the most valuable point Manu made is that there are 
"excellent" and "good" programmers. The difference is not so much 
in the actual skills, but in the willing to spend time on 
programming.

"Excellent programmers" spend a great amount of time learning 
things. It takes a huge part of their free time and it really 
takes a lot of passion and diligence. But most of the 
professional programmers are simply "good". They code at work and 
that's it. They don't spend any time beyond that on programming 
and, especially, learning new things.

If we're speaking about "excellent programmers" category, then 
almost everything about D is already good enough for these 
people. You can tell it by a number of truly fascinating D 
projects.

And it looks like the guys who work on D are mostly "excellent 
programmers", which speak pretty different language compared to 
the "good programmers". Probably, this is the main cause of 
misunderstanding.

In the "debugger" case, Manu's point is that it's unusable. And 
Walter's implied point is "debuggers aren't that useful anyway, 
so why it was a showstopper?".

My personal observation is that "excellent programmers" share the 
Walter's point on debuggers - they practically don't use it. And 
the uselessness is so obvious, that there's nothing even to talk 
about. At the same time, "good programmers" use it extensively, 
especially on Windows. It is so useful to them, that there's 
nothing even to talk about!

So, Manu speaks from the "good programmer" position, and Walter 
speaks from the "excellent programmer" position, implying "if 
you'd become a better programmer, you wouldn't have no problems 
using D".

This implication is mostly true. But it's orthogonal to Manu's 
point - "good programmers" have troubles using D.

The probable solution to this is to attract some "good" 
programmers to point out and work on the aforementioned issues - 
site, documentation, tooling, etc. But I'm not sure it's possible 
to do this for D with volunteer efforts.



 Dec 19 2014



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/19/2014 2:47 AM, Sergei Nosov wrote:

 The probable solution to this is to attract some "good" programmers to point
out
 and work on the aforementioned issues - site, documentation, tooling, etc. But
 I'm not sure it's possible to do this for D with volunteer efforts.


Sure it's possible - but the issues have to be specific. "Need more examples", 
for example (!), is nice but not helpful to anyone trying to improve the 
documentation. Saying "I need an example for std.foo.bar()" is an actionable
item.



 Dec 19 2014



  parent  "Sergei Nosov" <sergei.nosov gmail.com>  writes:


On Friday, 19 December 2014 at 11:16:41 UTC, Walter Bright wrote:

 On 12/19/2014 2:47 AM, Sergei Nosov wrote:

 The probable solution to this is to attract some "good" 
 programmers to point out
 and work on the aforementioned issues - site, documentation, 
 tooling, etc. But
 I'm not sure it's possible to do this for D with volunteer 
 efforts.


 Sure it's possible - but the issues have to be specific. "Need 
 more examples", for example (!), is nice but not helpful to 
 anyone trying to improve the documentation. Saying "I need an 
 example for std.foo.bar()" is an actionable item.


I'm afraid, the answer to this specific question is - "Every 
function needs an example". Consider, e.g. 
http://en.cppreference.com/w/ or 
http://www.cplusplus.com/reference/ It's hard to find a function 
that doesn't have a usage example.

Granted, the mentioned references are most likely volunteer 
effort (are they?). But it took C++ something like 20 years and a 
wide corporate adoption for that to happen.

I guess, it took less time for other languages, like Python or 
Ruby, but that's, probably, because those languages looked really 
interesting and fun at their times. So they attracted a lot of 
"good" programmers.

D poses itself as a more serious language (at least it's how it 
looks like). And, probably, nobody will say that it's bad. But, 
as a consequence, it makes it less attractive to "good" 
programmers. Especially now, when there's lot of successful "toy" 
languages. D is not "flashy" enough these days.



 Dec 19 2014



prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 19 Dec 2014 10:47:27 +0000
Sergei Nosov via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 In the "debugger" case, Manu's point is that it's unusable. And=20
 Walter's implied point is "debuggers aren't that useful anyway,=20
 so why it was a showstopper?".
=20
 My personal observation is that "excellent programmers" share the=20
 Walter's point on debuggers - they practically don't use it. And=20
 the uselessness is so obvious, that there's nothing even to talk=20
 about. At the same time, "good programmers" use it extensively,=20
 especially on Windows. It is so useful to them, that there's=20
 nothing even to talk about!


one of the things one can do if he is in corresponding position is to
ban debuggers. i found that after month or two people start producing
better code with better documentation and "control knobs". and
surprisingly faster. debugger is just a kind of bad habit, and when
people faced the fact that they will not be payed for work simulation
(and why should we?), they either go or becomes more productive.



 Dec 19 2014



 next sibling parent  "Sergei Nosov" <sergei.nosov gmail.com>  writes:


On Friday, 19 December 2014 at 11:54:42 UTC, ketmar via 
Digitalmars-d wrote:

 On Fri, 19 Dec 2014 10:47:27 +0000
 Sergei Nosov via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 In the "debugger" case, Manu's point is that it's unusable. 
 And Walter's implied point is "debuggers aren't that useful 
 anyway, so why it was a showstopper?".
 
 My personal observation is that "excellent programmers" share 
 the Walter's point on debuggers - they practically don't use 
 it. And the uselessness is so obvious, that there's nothing 
 even to talk about. At the same time, "good programmers" use 
 it extensively, especially on Windows. It is so useful to 
 them, that there's nothing even to talk about!


 one of the things one can do if he is in corresponding position 
 is to
 ban debuggers. i found that after month or two people start 
 producing
 better code with better documentation and "control knobs". and
 surprisingly faster. debugger is just a kind of bad habit, and 
 when
 people faced the fact that they will not be payed for work 
 simulation
 (and why should we?), they either go or becomes more productive.


Exactly. But you also imply something like "it would be great if 
every good programmer became excellent", which is not very 
realistic.

The example is a little abstract, but smoking is also a bad 
habit. However, there's no way you can fight it and win for the 
observable future.



 Dec 19 2014



prev sibling  parent reply "uri" <uri.grill gmail.com>  writes:


On Friday, 19 December 2014 at 11:54:42 UTC, ketmar via 
Digitalmars-d wrote:

 On Fri, 19 Dec 2014 10:47:27 +0000
 Sergei Nosov via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 In the "debugger" case, Manu's point is that it's unusable. 
 And Walter's implied point is "debuggers aren't that useful 
 anyway, so why it was a showstopper?".
 
 My personal observation is that "excellent programmers" share 
 the Walter's point on debuggers - they practically don't use 
 it. And the uselessness is so obvious, that there's nothing 
 even to talk about. At the same time, "good programmers" use 
 it extensively, especially on Windows. It is so useful to 
 them, that there's nothing even to talk about!


 one of the things one can do if he is in corresponding position 
 is to
 ban debuggers. i found that after month or two people start 
 producing
 better code with better documentation and "control knobs". and
 surprisingly faster. debugger is just a kind of bad habit, and 
 when
 people faced the fact that they will not be payed for work 
 simulation
 (and why should we?), they either go or becomes more productive.


This is true. The first week for a new developer where I work is 
developing a better boot loader. The debugger is not allowed 
during this induction week and as a result our devs learn how to 
write better code first time through careful planning and 
understanding of what's going on at the machine level.


Cheers,
uri



 Dec 19 2014



  parent reply "Daniel Davidson" <nospam spam.com>  writes:


On Friday, 19 December 2014 at 12:52:32 UTC, uri wrote:

 This is true. The first week for a new developer where I work 
 is developing a better boot loader. The debugger is not allowed 
 during this induction week and as a result our devs learn how 
 to write better code first time through careful planning and 
 understanding of what's going on at the machine level.


As you beat your chest over your boot loader - consider both this 
example and in general Walter's lack of need for a debugger. 
Could this lack of need be attributable to understanding of the 
entire code base being used? I imagine you don't have many 
outside dependencies for your boot loader. I imagine most of what 
Walter works on involves an entire stack that he has either 
written from ground up or when pulling outside dependencies in 
has much less surface area to deal with that is new to him. 
Contrast that with someone wanting to tie into a framework 
(vibed) or use a sophisticated library (websockets). Yes, you can 
stick with the "real men don't use debuggers" line, but that is 
much easier to stomach when your outside dependencies are small 
in scope. Isn't one of the best ways to learn a new codebase to 
step through it in the debugger?

Maybe your devs learn how to write better code the first time 
through. But what happens when they are thrown new requirements 
on dependencies that are challenging to deal with?



 Dec 19 2014



 next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 19 Dec 2014 15:38:27 +0000
Daniel Davidson via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Friday, 19 December 2014 at 12:52:32 UTC, uri wrote:

 This is true. The first week for a new developer where I work=20
 is developing a better boot loader. The debugger is not allowed=20
 during this induction week and as a result our devs learn how=20
 to write better code first time through careful planning and=20
 understanding of what's going on at the machine level.


 As you beat your chest over your boot loader - consider both this=20
 example and in general Walter's lack of need for a debugger.=20
 Could this lack of need be attributable to understanding of the=20
 entire code base being used? I imagine you don't have many=20
 outside dependencies for your boot loader. I imagine most of what=20
 Walter works on involves an entire stack that he has either=20
 written from ground up or when pulling outside dependencies in=20
 has much less surface area to deal with that is new to him.=20
 Contrast that with someone wanting to tie into a framework=20
 (vibed) or use a sophisticated library (websockets). Yes, you can=20
 stick with the "real men don't use debuggers" line, but that is=20
 much easier to stomach when your outside dependencies are small=20
 in scope. Isn't one of the best ways to learn a new codebase to=20
 step through it in the debugger?
=20
 Maybe your devs learn how to write better code the first time=20
 through. But what happens when they are thrown new requirements=20
 on dependencies that are challenging to deal with?


one of the worst things one can do to understand some big codebase is
start it under debugger.

if that codebase is so shitty that you can't see the modules and
interfaces without tracing them in the debugger... well, in this case
debugger will not help, the codebase is crap.

if that codebase is well-documented and well-decoupled, you can get a
picture in your head by learning what each part of the system do and
then descend into various parts, learning APIs.

what "stepping through it in the debugger" does is effectively
simulates the work. and gives you a simulated understanding. i was
thrown into huge codebases with alot of dependencies for past decades
and "stepping through it in the debugger" was always just a waste of
time.

it's not the best way to understand how to use some engine by watching
how it's gears turning. it may be fun, but not very productive. first
you grok what that engine was designed for, and only then you may want
to see the gears. but it's often not necessary.



 Dec 19 2014



prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Fri, Dec 19, 2014 at 03:38:27PM +0000, Daniel Davidson via Digitalmars-d
wrote:

 On Friday, 19 December 2014 at 12:52:32 UTC, uri wrote:

This is true. The first week for a new developer where I work is
developing a better boot loader. The debugger is not allowed during
this induction week and as a result our devs learn how to write
better code first time through careful planning and understanding of
what's going on at the machine level.


 As you beat your chest over your boot loader - consider both this
 example and in general Walter's lack of need for a debugger. Could
 this lack of need be attributable to understanding of the entire code
 base being used?


Nope.

FWIW, I work with a large enterprise project that is far too large for
anyone to grasp in its entirety, yet I don't find debuggers that helpful
either.  Well, they *are* helpful in some cases, just not as many as
people often claim, as least not for me.  The oft-maligned
printf-debugging, when wisely used in a targeted way, is often better
IME because I'm dealing with an embedded environment, where it's a pain
to setup a debugger. Well, it *can't* run a full debugger; the best it
can so is to run gdbserver which I then have to connect to remotely.
Once that's setup, I run into the frustrating problem of gdb being
unable to find the requisite symbols, needing to be in the same
directory as the executable, being unable to locate the source file(s),
being unable to resolve library symbols, ad nauseaum.

With printf (well, fprintf to a debug log, to be precise), I can get a
trace of strategic points in the code in text format that I can peruse
at my leisure, rather than being stuck inside a debugger where rewinding
isn't possible. (Yes, I know gdb has recently acquired rewinding
capability, but that's no help in a tightly-controlled embedded
environment where every tool is locked to a specific version and
upgrading is not an option.)

This doesn't mean that debuggers are *useless*, which is a completely
different statement (and is patently false). Sometimes they can be
useful, e.g., for obtaining a stacktrace from a segfault, or to
ascertain exactly where a function pointer ends up when it's a generic
object that could in theory point anywhere, etc. (though even the latter
can be manually done by inserting an infinite loop into a suspected
target and then using `top` to see if the CPU usage is 100% -- a `kill
-11` afterwards usually also generates a stacktrace that confirms where
it ended up). It's just that debuggers aren't as universally useful as
proponents tend to make it out to be.



 I imagine you don't have many outside dependencies for your boot
 loader. I imagine most of what Walter works on involves an entire
 stack that he has either written from ground up or when pulling
 outside dependencies in has much less surface area to deal with that
 is new to him.


Unfortunately, your imagination isn't quite accurate in this case.



 Contrast that with someone wanting to tie into a framework (vibed) or
 use a sophisticated library (websockets).  Yes, you can stick with the
 "real men don't use debuggers" line, but that is much easier to
 stomach when your outside dependencies are small in scope.


That is a false assumption, based on my experience as described above.



 Isn't one of the best ways to learn a new codebase to step through it
 in the debugger?


[...]

Absolutely not. You'd get lost in the forest *really* quickly and lose
sight of the forest for the trees, especially in a large codebase where
each logical operation may involve a dozen layers of abstraction, and
lower-level code is all generic so you won't easily understand how it
concretely fits into the big picture. For this, I recommend reading the
source code instead(!). That's what the source code is for!!

Of course, none of this implies that we shouldn't work on making D work
better with debuggers; quite on the contrary, I found it very
frustrating sometimes when I *do* need to use the debugger but D support
for that is rather anemic. Fortunately, being a printf-debugging veteran
does help work around such limitations. :-P


T

-- 
Famous last words: I wonder what will happen if I do *this*...



 Dec 19 2014



  parent  "Daniel Davidson" <nospam spam.com>  writes:


On Friday, 19 December 2014 at 16:27:03 UTC, H. S. Teoh via 
Digitalmars-d wrote:


 Could
 this lack of need be attributable to understanding of the 
 entire code
 base being used?


 Nope.

 FWIW, I work with a large enterprise project that is far too 
 large for
 anyone to grasp in its entirety, yet I don't find debuggers 
 that helpful
 either.  Well, they *are* helpful in some cases, just not as 
 many as
 people often claim, as least not for me.  The oft-maligned
 printf-debugging, when wisely used in a targeted way, is often 
 better
 IME because I'm dealing with an embedded environment, where 
 it's a pain
 to setup a debugger. Well, it *can't* run a full debugger; the 
 best it
 can so is to run gdbserver which I then have to connect to 
 remotely.
 Once that's setup, I run into the frustrating problem of gdb 
 being
 unable to find the requisite symbols, needing to be in the same
 directory as the executable, being unable to locate the source 
 file(s),
 being unable to resolve library symbols, ad nauseaum.


I think that "at least not for me" is important there. 
Personally, I did not malign the printf debugging approach. 
However nothing is more painful than sitting through a printf 
debugging session with someone new to code who is using the 
printf to learn the code, when a perfectly good debugger is 
available. Is the embedded environment you describe the typical 
case?

I'm not advocating, not reading or attempting to understand the 
code. But, assume you have your best understanding at hand and 
still have questions and/or bugs; you drop a breakpoint in code 
that is new to you. What you get is much more than the 
documentation: you get the callstack allowing you to navigate the 
code, you get the data allowing you to see the structures and 
their content. Problems with gdb does not take away from the 
benefit debugging in general. Remember this thread was started 
with someone having bugs in a windows environment.

Not many advocate ignorance. Programmers do advocate laziness 
with good cause. In theory, if a person can successfully use code 
without understanding all details of its implementation then that 
person has made a mental cost savings. Maybe not so important to 
the set of coders here - but there is value in not being required 
to understand all details. One benefit of the separation of 
concerns between interfaces and implementation is the level of 
understanding required for the former might be significantly less 
than the latter.


 I imagine you don't have many outside dependencies for your 
 boot
 loader. I imagine most of what Walter works on involves an 
 entire
 stack that he has either written from ground up or when pulling
 outside dependencies in has much less surface area to deal 
 with that
 is new to him.


 Unfortunately, your imagination isn't quite accurate in this 
 case.


How so? Is the bootloader using vibed or websockets? Does dmd use 
vibed or websockets? Of course your next reply can be all the 
complex libraries dmd uses internally to which I'll reply that 
all of those are code that Walter is likely intimately familiar 
with making it easy for him with his vast experience to not use a 
debugger. No one has to use a debugger, but I'm in the camp that 
they can make life easier especially when getting familiar with 
new code. Maybe here I'm in the minority.


 Contrast that with someone wanting to tie into a framework 
 (vibed) or
 use a sophisticated library (websockets).  Yes, you can stick 
 with the
 "real men don't use debuggers" line, but that is much easier to
 stomach when your outside dependencies are small in scope.


 That is a false assumption, based on my experience as described 
 above.


How does your unfortunate situation of being "with a large 
enterprise project that is far too large for anyone to grasp in 
its entirety, yet I don't find debuggers that helpful" relate to 
the extent of dependencies and their impact on utility of a 
debugger? I get that in general you don't find debuggers useful, 
which is fine. When trying to understand a tangled mess of code 
that you did not write your preferred method is read the code and 
printf. Those are valuable. Maybe someone who rarely or never 
uses a debugger is not the best to gauge the benefit differential 
of a debugger on systems with few outside dependencies versus 
systems with heavy outside dependencies.


 Isn't one of the best ways to learn a new codebase to step 
 through it
 in the debugger?


 [...]

 Absolutely not. You'd get lost in the forest *really* quickly 
 and lose
 sight of the forest for the trees, especially in a large 
 codebase where
 each logical operation may involve a dozen layers of 
 abstraction, and
 lower-level code is all generic so you won't easily understand 
 how it
 concretely fits into the big picture. For this, I recommend 
 reading the
 source code instead(!). That's what the source code is for!!


More chest beating. I don't see how the *addition* of a debugger 
causes one to get lost. I'm in emacs trying to learn a new code 
base. Everything I could do before I can still do (including 
reading the source code) and I can look at real live data, 
examine structures with contents, quickly navigate the stack, 
etc. It only adds value IMO as it is not an either/or.


 Of course, none of this implies that we shouldn't work on 
 making D work
 better with debuggers; quite on the contrary, I found it very
 frustrating sometimes when I *do* need to use the debugger but 
 D support
 for that is rather anemic. Fortunately, being a 
 printf-debugging veteran
 does help work around such limitations. :-P


I guess that makes D's fast compile times all the more important 
to you.


 T





 Dec 19 2014



prev sibling next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 19 Dec 2014 08:24:49 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:


 This doesn't mean that debuggers are *useless*, which is a completely
 different statement (and is patently false). Sometimes they can be
 useful, e.g., for obtaining a stacktrace from a segfault, or to
 ascertain exactly where a function pointer ends up when it's a generic
 object that could in theory point anywhere, etc.


yes, debugger is *very* useful for inspecting core dumps. that is why
i still have gdb installed. ;-)



 Dec 19 2014



prev sibling next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 19 Dec 2014 08:24:49 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

p.s. and D support for generating extensive debug information is
important, 'cause we need it to do core dump inspection.



 Dec 19 2014



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/19/2014 7:38 AM, Daniel Davidson wrote:

  Could this lack of need be
 attributable to understanding of the entire code base being used?


No. It's attributable to I use different methods of debugging.

The dmd source code is littered with debugging aids I've written. The classic 
example is having a pretty-printer for each data structure. I don't find the 
typical debugger pretty-printer to be adequate at all - they never dump the
type 
in the way that I think about the type.



 Dec 19 2014



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2014-12-19 20:20, Walter Bright wrote:


 No. It's attributable to I use different methods of debugging.

 The dmd source code is littered with debugging aids I've written. The
 classic example is having a pretty-printer for each data structure. I
 don't find the typical debugger pretty-printer to be adequate at all -
 they never dump the type in the way that I think about the type.


It can still be handy with a debugger. If you have written a custom 
pretty-printer you can still call that one from the debugger.

In LLDB it's possible to write custom formatters/pretty-printer for your 
own types.

-- 
/Jacob Carlborg



 Dec 20 2014



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/20/2014 6:04 AM, Jacob Carlborg wrote:

 On 2014-12-19 20:20, Walter Bright wrote:


 No. It's attributable to I use different methods of debugging.

 The dmd source code is littered with debugging aids I've written. The
 classic example is having a pretty-printer for each data structure. I
 don't find the typical debugger pretty-printer to be adequate at all -
 they never dump the type in the way that I think about the type.


 It can still be handy with a debugger. If you have written a custom
 pretty-printer you can still call that one from the debugger.

 In LLDB it's possible to write custom formatters/pretty-printer for your own
types.


Often I'll pipe the pretty-printed debug output to a file, as it can be 
voluminous, and then actually edit the file to bring out what I need.

Not possible with a debugger.

(dmd can have pretty complex relationships between data structures and the path 
through the code. I might want to look at these fields of a type, but not those 
fields. Etc. I.e. I routinely build custom debugging aids for particular
problems.)



 Dec 28 2014



  parent  "Daniel Davidson" <nospam spam.com>  writes:


On Monday, 29 December 2014 at 05:43:13 UTC, Walter Bright wrote:

 Often I'll pipe the pretty-printed debug output to a file, as 
 it can be voluminous, and then actually edit the file to bring 
 out what I need.

 Not possible with a debugger.


I think it is. Here is a small adjustment to consider for your 
workflow. Continue instrumenting your code with capability to 
print things as you like - data structures, etc. Then when you 
need to debug something, rather than (throw in print, compile, 
run, diagnose repeat) drop into gdb judiciously and "call 
print....", examine the output. Need more data do it again with 
the same executable. The savings is no need to repeatedly 
build/litter code with prints and you would use the debugger and 
your current style.

I seriously doubt you would change your style as you appear quite 
fond of it - clearly it works for you. The point though is others 
do find value in the debugger and this is one reason. Also, there 
are pretty printers of data structures for gdb and if you don't 
like them you could write your own.


 (dmd can have pretty complex relationships between data 
 structures and the path through the code. I might want to look 
 at these fields of a type, but not those fields. Etc. I.e. I 
 routinely build custom debugging aids for particular problems.)





 Jan 01 2015



prev sibling  parent reply "Daniel Davidson" <nospam spam.com>  writes:


On Friday, 19 December 2014 at 19:20:15 UTC, Walter Bright wrote:

 On 12/19/2014 7:38 AM, Daniel Davidson wrote:

 Could this lack of need be
 attributable to understanding of the entire code base being 
 used?


 No. It's attributable to I use different methods of debugging.

 The dmd source code is littered with debugging aids I've 
 written. The classic example is having a pretty-printer for 
 each data structure. I don't find the typical debugger 
 pretty-printer to be adequate at all - they never dump the type 
 in the way that I think about the type.


Sure, sounds like a winning strategy. Probably not applicable, 
but were you to run into an issue with vibe or websockets would 
you proceed to write pretty printers for the supplied data 
structures, the returned data structures, etc, or would you live 
with the not so pretty gdb structures just to get your debug 
session over with?

The point is it seems like more of your work on code is working 
with your own code - i.e. fewer outside dependencies or outside 
dependencies that you are intimately familiar with due to years 
of experience. This reduces the benefit or need of the debugger.



 Dec 20 2014



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/20/2014 10:08 AM, Daniel Davidson wrote:

 Sure, sounds like a winning strategy. Probably not applicable, but were you to
 run into an issue with vibe or websockets would you proceed to write pretty
 printers for the supplied data structures, the returned data structures, etc,


probably yes, as I've done so when given someone else's program to debug. 
Writing a pretty-printer is often the first thing I do, as it also helps 
enormously in learning the data structures


 or would you live with the not so pretty gdb structures just to get your debug
 session over with?


unlikely



 Dec 28 2014



 next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 29 December 2014 at 15:44, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/20/2014 10:08 AM, Daniel Davidson wrote:

 Sure, sounds like a winning strategy. Probably not applicable, but were
 you to
 run into an issue with vibe or websockets would you proceed to write
 pretty
 printers for the supplied data structures, the returned data structures,
 etc,



 probably yes, as I've done so when given someone else's program to debug.
 Writing a pretty-printer is often the first thing I do, as it also helps
 enormously in learning the data structures


That if you don't have source to the library? (as is the overwhelming
standard in my line of work)
You can't instrument code that you don't have.



 Dec 29 2014



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/29/2014 5:14 PM, Manu via Digitalmars-d wrote:

 That if you don't have source to the library? (as is the overwhelming
 standard in my line of work)
 You can't instrument code that you don't have.


It's always a big problem debugging inside code you don't have the source to. 
How is a debugger going to display the source code to it? How are any of the 
debugger features you say are critical going to work with no source code?

Debugging such requires low level assembler debugging.



 Dec 29 2014



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 30 December 2014 at 11:14, Manu <turkeyman gmail.com> wrote:

 On 29 December 2014 at 15:44, Walter Bright via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 12/20/2014 10:08 AM, Daniel Davidson wrote:

 Sure, sounds like a winning strategy. Probably not applicable, but were
 you to
 run into an issue with vibe or websockets would you proceed to write
 pretty
 printers for the supplied data structures, the returned data structures,
 etc,



 probably yes, as I've done so when given someone else's program to debug.
 Writing a pretty-printer is often the first thing I do, as it also helps
 enormously in learning the data structures


 That if you don't have source to the library? (as is the overwhelming
 standard in my line of work)
 You can't instrument code that you don't have.


* what if...

Sorry, posting from a phone is really tedious! >_<

Anyway, I know you understand the debugging experience is very important.
You won't change our opinion on this matter with anecdote, it is immutable. ;)



 Dec 29 2014



prev sibling next sibling parent  Jeremy Powers via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, Dec 19, 2014 at 2:47 AM, Sergei Nosov via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Friday, 19 December 2014 at 08:57:56 UTC, Walter Bright wrote:


 I've actually not found debuggers to be of much use other than telling me
 where the seg fault was and giving a stack trace.


 I think the most valuable point Manu made is that there are "excellent"
 and "good" programmers.


This distinction may be valid in some instances, but I believe it is wrong
to use when talking about debuggers.



 In the "debugger" case, Manu's point is that it's unusable. And Walter's
 implied point is "debuggers aren't that useful anyway, so why it was a
 showstopper?".

 My personal observation is that "excellent programmers" share the Walter's
 point on debuggers - they practically don't use it.



Hyperbole follows: This is bullshit.

Yes, 'excellent' programmers write excellent software that can be debugged
without a debugger.  But 'excellent' programmers also have to debug code
written by others (or themselves in the past), in which case a debugger is
_incredibly_ useful.  Using a debugger can save hours or days in
diagnosing/solving a problem.



 And the uselessness is so obvious, that there's nothing even to talk about.



More hyperbole:  if a debugger is useless to you, you are not working on
very complex systems.



 It is so useful to them, that there's nothing even to talk about!


Yup, nothing to talk about.

Some/many people value a debugger as an essential development tool.  And
not having a usable debugger in D is a showstopper for them.


Kudos to Manu for trying to use D at work.  But the issues he identified
are essentially the same keeping me from pushing use of D professionally -
tooling is lacking.  And this is coming from someone on the opposite side
environment wise... I find Visual Studio atrocious, and believe those using
it suffer from stockholm syndrome.

And yes, I understand nothing will get better without volunteers working on
it... but it would be nice if we could talk about the problems without
mudslinging everywhere.  Acknowledging where work is needed is the first
step in getting said work done.



 Dec 19 2014



prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 19 December 2014 at 20:47, Sergei Nosov via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 19 December 2014 at 08:57:56 UTC, Walter Bright wrote:

 I've debugged a lot of D code with no debugger at all (how else could I
 port it to various platforms like Win64?).

 I've actually not found debuggers to be of much use other than telling me
 where the seg fault was and giving a stack trace.



 I think the most valuable point Manu made is that there are "excellent" and
 "good" programmers. The difference is not so much in the actual skills, but
 in the willing to spend time on programming.

 "Excellent programmers" spend a great amount of time learning things. It
 takes a huge part of their free time and it really takes a lot of passion
 and diligence. But most of the professional programmers are simply "good".
 They code at work and that's it. They don't spend any time beyond that on
 programming and, especially, learning new things.

 If we're speaking about "excellent programmers" category, then almost
 everything about D is already good enough for these people. You can tell it
 by a number of truly fascinating D projects.

 And it looks like the guys who work on D are mostly "excellent programmers",
 which speak pretty different language compared to the "good programmers".
 Probably, this is the main cause of misunderstanding.

 In the "debugger" case, Manu's point is that it's unusable. And Walter's
 implied point is "debuggers aren't that useful anyway, so why it was a
 showstopper?".

 My personal observation is that "excellent programmers" share the Walter's
 point on debuggers - they practically don't use it. And the uselessness is
 so obvious, that there's nothing even to talk about. At the same time, "good
 programmers" use it extensively, especially on Windows. It is so useful to
 them, that there's nothing even to talk about!

 So, Manu speaks from the "good programmer" position, and Walter speaks from
 the "excellent programmer" position, implying "if you'd become a better
 programmer, you wouldn't have no problems using D".

 This implication is mostly true. But it's orthogonal to Manu's point - "good
 programmers" have troubles using D.

 The probable solution to this is to attract some "good" programmers to point
 out and work on the aforementioned issues - site, documentation, tooling,
 etc. But I'm not sure it's possible to do this for D with volunteer efforts.


Thank you.

I get so frustrated by the apparent majority in this forum who seem to
think 'most' programmers are the type who would even read or post on a
forum like this. Or read a programming book! They must surely be the
overwhelming minority.
In my experience, that is, large companies, probably somewhere around
500 colleagues in almost 15 years, is that 90% of them are 'good' at
best. Nothing will be successful unless that silent majority can get
on board... and they will NOT exert any particular effort to do so,
unless it clearly advantages them somehow and/or the friction is
minimal.

D is a great language for enthusiasts, obviously. Andrei often talks
about a 7 digit userbase; he's presented on this in lectures. I don't
think think that number is even remotely possible unless we are able
to attract an overwhelming majority of 'average' to 'good'
programmers. I doubt there are that many 'excellent' programmers in
the world!
In my experience to date (presenting D to corporate colleagues, of
which is quite extensive), the main barrier remaining is
presentation... and for my particular user-base, rough edges in the
Windows experience; an ecosystem where the standard of tooling and
presentation is otherwise very high.
People call my industry niche, but I reckon gamedev's are among (if
not) the largest remaining community of native developers who embark
on new developments frequently (ie, annually). I see it as one of D's
most promising targets, but that will depend on getting the Windows
tooling across the line. Gamedev may have a larger number of 'average'
programmers than other industries (I can't say), but whatever, that's
just how it is.

That said, I'm not working in games at the moment. But I don't see any
difference in expectation in my new company than I did in games. If
anything, it's even more windows-centric, since the cross-platform
expectation (present in games), is not really with me now.



 Dec 19 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Saturday, 20 December 2014 at 07:26:30 UTC, Manu via 
Digitalmars-d wrote:

 Thank you.

 I get so frustrated by the apparent majority in this forum who 
 seem to
 think 'most' programmers are the type who would even read or 
 post on a
 forum like this. Or read a programming book! They must surely 
 be the
 overwhelming minority.


I am well-aware that people who actually have a passion for 
programming are tiny minority. Though many still read programming 
books because that adds some weight for career advancement 
requests.

But you call to support interests of those programmers at cost of 
interests of existing users - something absolutely impractical at 
current language development stage. Trying to explain why this 
expectation is not reasonable and not just is the least hostile 
reaction I can give.

Whatever Andrei says, there is no benefit in blindly pumping user 
base if you don't have resources to support it. I also remember 
him saying "want million users, build as if you had million 
users". Well, currently we don't truly build even for thousand 
users.

You have been stressing those cases for several years now. Have 
you actually contributed anything to DMD to improve debug symbol 
generation seeing how this is important to you?

I keep asking you simple question you avoid answering - who 
personally should work to address your concerns? Those are all 
legit concerns and I doubt anyone would willingly prefer to keep 
things as they are. But who will do it if apparently you are the 
person who needs it most and you don't want to do it?



 Dec 20 2014



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 20 December 2014 at 19:59, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Saturday, 20 December 2014 at 07:26:30 UTC, Manu via Digitalmars-d wrote:

 Thank you.

 I get so frustrated by the apparent majority in this forum who seem to
 think 'most' programmers are the type who would even read or post on a
 forum like this. Or read a programming book! They must surely be the
 overwhelming minority.



 I am well-aware that people who actually have a passion for programming are
 tiny minority. Though many still read programming books because that adds
 some weight for career advancement requests.

 But you call to support interests of those programmers at cost of interests
 of existing users - something absolutely impractical at current language
 development stage. Trying to explain why this expectation is not reasonable
 and not just is the least hostile reaction I can give.

 Whatever Andrei says, there is no benefit in blindly pumping user base if
 you don't have resources to support it. I also remember him saying "want
 million users, build as if you had million users". Well, currently we don't
 truly build even for thousand users.

 You have been stressing those cases for several years now. Have you actually
 contributed anything to DMD to improve debug symbol generation seeing how
 this is important to you?


Many bug reports and case studies, and often, a persistent voice for
minority issues that don't get enough attention. My time spent arguing
in this forum is substantial, and as annoying as it may seem, I think
if I didn't invest that time, there are things in the past 5-6 years
that would have moved in a different direction, and the language would
be less attractive to me and my industry as a result.

No, I'm not a compiler dev, and I feel like you're trying to discredit
me because I'm not.
I don't want to be a compiler dev. I want to *use* D to make my life
and work easier for my numerous existing projects and commercial
activity.
No other language community has ever demanded I contribute to the
compiler to be eligible to have my case considered relevant.

If I contributed code to DMD, I know it will become my life, and that
means I'm stepping away from my existing interests and areas of
development. I'm not interested in doing that.
Surely you can understand that my desire to *use* D as a tool is not
at odds with my desire to continue to work in the fields that I prefer
to work in?



 I keep asking you simple question you avoid answering - who personally
 should work to address your concerns? Those are all legit concerns and I
 doubt anyone would willingly prefer to keep things as they are. But who will
 do it if apparently you are the person who needs it most and you don't want
 to do it?


Any of the existing dev's that particularly care about the long-term
success of the language and the health of the ecosystem?
Perhaps new dev's will be attracted by making the ecosystem inclusive
of their work and development practice. That tends to be the way open
source works no?

The answer you're looking for is obviously 'I don't know', but
regardless, the things need to be on the list, and the list would
ideally be prioritised according to usage by the user base.
I report on usage relevant to my industry, and I feel I am quite an
effective advocate. I pioneered D in a major company, converted many
individuals, talk about it among my development community endlessly,
often give local demonstrations. I've raised a lot of interest, and I
already contribute more time than I can afford.

I'm glad you work on the compiler, the community needs people like you
more than anyone... although I'm not sure about your attitude. Right
now, I'm finding it quite corrosive.



 Dec 25 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Friday, 26 December 2014 at 01:11:42 UTC, Manu via 
Digitalmars-d wrote:

 Many bug reports and case studies, and often, a persistent 
 voice for
 minority issues that don't get enough attention. My time spent 
 arguing
 in this forum is substantial, and as annoying as it may seem, I 
 think
 if I didn't invest that time, there are things in the past 5-6 
 years
 that would have moved in a different direction, and the 
 language would
 be less attractive to me and my industry as a result.


Yes, I am doing pretty much the same. Does that mean I should be 
more friendly to your lobby of your industry/projects if it 
directly harms my interests? I have been supporting your push for 
better low-level control because it helps me too, not because I 
am kind person. Wasting effort of core contributors on a 
toolchain I will never use is against my interests and makes me 
naturally hostile about it.


 No, I'm not a compiler dev, and I feel like you're trying to 
 discredit
 me because I'm not.


It is exactly what I am trying to do and I am not hiding it.


 I don't want to be a compiler dev. I want to *use* D to make my 
 life
 and work easier for my numerous existing projects and commercial
 activity.


I wish I could do the same - I have never wanted to read compiler 
sources or be part of Phobos dev team. But I do recognize it is 
the only pragmatical way to make things work as per my needs and 
it is better to act according to how things are, not how things 
should have been.


 No other language community has ever demanded I contribute to 
 the
 compiler to be eligible to have my case considered relevant.


It is not about relevance but about priority. If you are willing 
to wait for something like 10 years it will surely be addressed 
at some point. But you demand it being addressed soon, right?

And yes, D is probably least staffed language development project 
among non-hobby projects.


 If I contributed code to DMD, I know it will become my life, 
 and that
 means I'm stepping away from my existing interests and areas of
 development. I'm not interested in doing that.


Then you will have to wait until someone appears who have same 
interests as you but IS willing to start contributing.


 Surely you can understand that my desire to *use* D as a tool 
 is not
 at odds with my desire to continue to work in the fields that I 
 prefer
 to work in?


I am simply telling that D is not ready to be used in your 
industry if you are adamant about such desire. Sad but true. And 
by complaining you don't improve situation as a whole but simply 
force redistribution of already existing set of limited resources.


 I keep asking you simple question you avoid answering - who 
 personally
 should work to address your concerns? Those are all legit 
 concerns and I
 doubt anyone would willingly prefer to keep things as they 
 are. But who will
 do it if apparently you are the person who needs it most and 
 you don't want
 to do it?


 Any of the existing dev's that particularly care about the 
 long-term
 success of the language and the health of the ecosystem?
 Perhaps new dev's will be attracted by making the ecosystem 
 inclusive
 of their work and development practice. That tends to be the 
 way open
 source works no?


No, not really. Open source is about people working to fulfill 
their own personal goals and not minding to share resulting code 
if it doesn't mean much added effort. Only few care about things 
like long-term success and only tiny minority will be interested 
in working on ecosystem they don't use.

Motivation you speak about has its place but it is more of a 
"luxury" contribution that only happens after primary concerns 
are dealt with. It just happens that if some open-source project 
is big and mature enough there is a very high chance that your 
problems are already addressed by someone else. That gives a 
wrong impression to those who mostly use open-source and rarely 
contribute.


 I'm glad you work on the compiler, the community needs people 
 like you
 more than anyone...


I don't really work on compiler, sorry :)


 although I'm not sure about your attitude. Right
 now, I'm finding it quite corrosive.


Being all kind and nice is not really in my skill set. I hope I 
have explained better my dislike for this specific set of 
complaints despite the fact I usually tend to support your cause.



 Dec 29 2014



 next sibling parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 29 December 2014 at 14:45:37 UTC, Dicebot wrote:

 On Friday, 26 December 2014 at 01:11:42 UTC, Manu via 
 Digitalmars-d wrote:

 Many bug reports and case studies, and often, a persistent 
 voice for
 minority issues that don't get enough attention. My time spent 
 arguing
 in this forum is substantial, and as annoying as it may seem, 
 I think
 if I didn't invest that time, there are things in the past 5-6 
 years
 that would have moved in a different direction, and the 
 language would
 be less attractive to me and my industry as a result.


 Yes, I am doing pretty much the same. Does that mean I should 
 be more friendly to your lobby of your industry/projects if it 
 directly harms my interests? I have been supporting your push 
 for better low-level control because it helps me too, not 
 because I am kind person. Wasting effort of core contributors 
 on a toolchain I will never use is against my interests and 
 makes me naturally hostile about it.


 No, I'm not a compiler dev, and I feel like you're trying to 
 discredit
 me because I'm not.


 It is exactly what I am trying to do and I am not hiding it.


 I don't want to be a compiler dev. I want to *use* D to make 
 my life
 and work easier for my numerous existing projects and 
 commercial
 activity.


 I wish I could do the same - I have never wanted to read 
 compiler sources or be part of Phobos dev team. But I do 
 recognize it is the only pragmatical way to make things work as 
 per my needs and it is better to act according to how things 
 are, not how things should have been.


 No other language community has ever demanded I contribute to 
 the
 compiler to be eligible to have my case considered relevant.


 It is not about relevance but about priority. If you are 
 willing to wait for something like 10 years it will surely be 
 addressed at some point. But you demand it being addressed 
 soon, right?

 And yes, D is probably least staffed language development 
 project among non-hobby projects.


 If I contributed code to DMD, I know it will become my life, 
 and that
 means I'm stepping away from my existing interests and areas of
 development. I'm not interested in doing that.


 Then you will have to wait until someone appears who have same 
 interests as you but IS willing to start contributing.


 Surely you can understand that my desire to *use* D as a tool 
 is not
 at odds with my desire to continue to work in the fields that 
 I prefer
 to work in?


 I am simply telling that D is not ready to be used in your 
 industry if you are adamant about such desire. Sad but true. 
 And by complaining you don't improve situation as a whole but 
 simply force redistribution of already existing set of limited 
 resources.


 I keep asking you simple question you avoid answering - who 
 personally
 should work to address your concerns? Those are all legit 
 concerns and I
 doubt anyone would willingly prefer to keep things as they 
 are. But who will
 do it if apparently you are the person who needs it most and 
 you don't want
 to do it?


 Any of the existing dev's that particularly care about the 
 long-term
 success of the language and the health of the ecosystem?
 Perhaps new dev's will be attracted by making the ecosystem 
 inclusive
 of their work and development practice. That tends to be the 
 way open
 source works no?


 No, not really. Open source is about people working to fulfill 
 their own personal goals and not minding to share resulting 
 code if it doesn't mean much added effort. Only few care about 
 things like long-term success and only tiny minority will be 
 interested in working on ecosystem they don't use.

 Motivation you speak about has its place but it is more of a 
 "luxury" contribution that only happens after primary concerns 
 are dealt with. It just happens that if some open-source 
 project is big and mature enough there is a very high chance 
 that your problems are already addressed by someone else. That 
 gives a wrong impression to those who mostly use open-source 
 and rarely contribute.


 I'm glad you work on the compiler, the community needs people 
 like you
 more than anyone...


 I don't really work on compiler, sorry :)


 although I'm not sure about your attitude. Right
 now, I'm finding it quite corrosive.


 Being all kind and nice is not really in my skill set. I hope I 
 have explained better my dislike for this specific set of 
 complaints despite the fact I usually tend to support your 
 cause.


This is probably the most disgusting, selfish and deluded posts 
i've read on this entire newsgroup.

If D is supposed to supplant C/C++, then the needs of those users 
*must* be met, especially without deriding those very users. Just 
because you work on the D ecosystem does not give you 'carte 
blanche' to tell a user to stop making enquiries into features 
that are promised by D.

The user is the entire goal of D! Forgetting this relegates D to 
obscurity and makes you look like an ass.


 No, not really. Open source is about people working to fulfill 
 their own personal goals and not minding to share resulting 
 code if it doesn't mean much added effort. Only few care about 
 things like long-term success and only tiny minority will be 
 interested in working on ecosystem they don't use.


With that paragraph, you've just dumped on Walter, Andrei's and 
all other open source contributor's efforts for the past n years!



 Dec 29 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby 
wrote:

 This is probably the most disgusting, selfish and deluded posts 
 i've read on this entire newsgroup.


I am pretty sure I have written worse.


 If D is supposed to supplant C/C++, then the needs of those 
 users *must* be met, especially without deriding those very 
 users. Just because you work on the D ecosystem does not give 
 you 'carte blanche' to tell a user to stop making enquiries 
 into features that are promised by D.

 The user is the entire goal of D! Forgetting this relegates D 
 to obscurity and makes you look like an ass.


This is widely advertised statement I can't agree with. For me 
goal is having working language that works. Getting users is 
indirect way to achieve that by attracting more contributions but 
user just by itself has not value to _me_. It is obviously 
important for Andrei and Walter as D is their project. There are 
some other contributors which keep being productive despite no 
obvious personal gain. I admire and respect them but I am not 
them.

And I really hate the culture of hiding own interests just to 
look all nice.


 No, not really. Open source is about people working to fulfill 
 their own personal goals and not minding to share resulting 
 code if it doesn't mean much added effort. Only few care about 
 things like long-term success and only tiny minority will be 
 interested in working on ecosystem they don't use.


 With that paragraph, you've just dumped on Walter, Andrei's and 
 all other open source contributor's efforts for the past n 
 years!


How so? Walter and Andrei are not open-source contributors - D is 
_their_ project. There are some incredible open-source 
contributors like Kenji, Martin, Vladimir, Daniel - guys with 
incredible productivity that don't mind help anyone. This is 
exactly the (awesome) minority. But most people just work on 
projects they are interested in and occasionally contribute stuff 
back.

Do you disagree that this is the model of D developer community? 
Or am I the ass because I write it down here instead of acting 
all idealistic and inspirational?



 Dec 29 2014



  parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net>  writes:


On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote:

 On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby 
 wrote:

 This is probably the most disgusting, selfish and deluded 
 posts i've read on this entire newsgroup.


 I am pretty sure I have written worse.


Time out, everyone.  I really don't see any benefit to throwing 
around any more personalized criticism; it achieves nothing other 
than demotivation.


 This is widely advertised statement I can't agree with. For me 
 goal is having working language that works. Getting users is 
 indirect way to achieve that by attracting more contributions 
 but user just by itself has not value to _me_.


An indirect benefit is still a benefit -- as I said in my 
previous post, these things aren't a zero-sum game.  Among other 
things, more users means not only the likelihood of more 
contributions, but also more bugs and points of failure 
identified, more experienced people to use as a sounding board 
for ideas, more people to call on for help when you have a 
problem, and so on.


 And I really hate the culture of hiding own interests just to 
 look all nice.


It's fine to be self-interested, but it is important to know 
where your _real_ self-interest lies, and that usually involves 
looking out for the interests of others too. :-)


 How so? Walter and Andrei are not open-source contributors - D 
 is _their_ project.


I think the better line to draw here is between project 
leadership and community contributions -- after all, everyone is 
contributing open source code here.


 Do you disagree that this is the model of D developer 
 community? Or am I the ass because I write it down here instead 
 of acting all idealistic and inspirational?


I think there is a lot of misunderstanding arising here, because 
I think you are saying "I think this is how things actually work 
in practice" (arguable in the case of D, but probably true for 
many open source projects) and that's being mistaken for "I think 
this is how things ought to work."

I guess what I'd say is that, yes, I get how the idealistic and 
inspirational stuff can be irritating and feel like delusion, but 
it can be a pretty powerful tool to help facilitate the process 
of cooperation between different people who do indeed all have 
different itches to scratch.  Being "nice" isn't just a matter of 
being liked or not (not the most important thing in the world); 
it's a really handy means of minimizing the amount of unnecessary 
friction in a community.  It doesn't need to involve any 
rose-tinted spectacles or illusions about people's motivations, 
just a recognition of what is going to help promote positive or 
negative reactions from other people.



 Dec 29 2014



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


On Monday, 29 December 2014 at 18:42:17 UTC, Joseph Rushton 
Wakeling wrote:

 On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote:

 This is widely advertised statement I can't agree with. For me 
 goal is having working language that works. Getting users is 
 indirect way to achieve that by attracting more contributions 
 but user just by itself has not value to _me_.


 An indirect benefit is still a benefit -- as I said in my 
 previous post, these things aren't a zero-sum game.  Among 
 other things, more users means not only the likelihood of more 
 contributions, but also more bugs and points of failure 
 identified, more experienced people to use as a sounding board 
 for ideas, more people to call on for help when you have a 
 problem, and so on.


It also means more people asking for stuff, then doing nothing to 
contribute towards it, as though the D community is their slave 
labor.  Not saying this about Manu, just that there are people 
with weird expectations of open source.


 I guess what I'd say is that, yes, I get how the idealistic and 
 inspirational stuff can be irritating and feel like delusion, 
 but it can be a pretty powerful tool to help facilitate the 
 process of cooperation between different people who do indeed 
 all have different itches to scratch.  Being "nice" isn't just 
 a matter of being liked or not (not the most important thing in 
 the world); it's a really handy means of minimizing the amount 
 of unnecessary friction in a community.  It doesn't need to 
 involve any rose-tinted spectacles or illusions about people's 
 motivations, just a recognition of what is going to help 
 promote positive or negative reactions from other people.


I'll add that a majority of contributors do not solely scratch 
their own itches, but contribute in other ways that do not 
directly benefit them.  Maybe that's because there are indirect 
benefits to having better docs, or they just become invested in 
the project over time.  Very few operate solely from 
self-interest, though most probably contribute a majority of 
their work for that reason.



 Dec 29 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/29/14 10:58 AM, Joakim wrote:

 On Monday, 29 December 2014 at 18:42:17 UTC, Joseph Rushton Wakeling wrote:

 On Monday, 29 December 2014 at 15:34:44 UTC, Dicebot wrote:

 This is widely advertised statement I can't agree with. For me goal
 is having working language that works. Getting users is indirect way
 to achieve that by attracting more contributions but user just by
 itself has not value to _me_.


 An indirect benefit is still a benefit -- as I said in my previous
 post, these things aren't a zero-sum game.  Among other things, more
 users means not only the likelihood of more contributions, but also
 more bugs and points of failure identified, more experienced people to
 use as a sounding board for ideas, more people to call on for help
 when you have a problem, and so on.


 It also means more people asking for stuff, then doing nothing to
 contribute towards it, as though the D community is their slave labor.


If we, the D community, want D to succeed, we must change this attitude. 
-- Andrei



 Dec 29 2014



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


On Monday, 29 December 2014 at 19:11:04 UTC, Andrei Alexandrescu 
wrote:

 On 12/29/14 10:58 AM, Joakim wrote:

 It also means more people asking for stuff, then doing nothing 
 to
 contribute towards it, as though the D community is their 
 slave labor.


 If we, the D community, want D to succeed, we must change this 
 attitude. -- Andrei


I was just going to let this go without answering, as it's 
ambiguous, but since Dicebot just said something similar to what 
I'd have said, I'll bite.  What do you mean by this?  That the 
people asking for stuff then doing nothing have to change their 
attitude or those in the D community, like Dicebot and me, who 
point out that their approach is unrealistic should change our 
attitude?

And regardless of your answer to that question, what do you see 
as "success" for D and how do you plan to get there, given what 
you know now?  It's possible that it's already a success for the 
community, as it works well enough for the thousands using and 
handful contributing to it, and they do not see your million-user 
goal as worth putting effort into.

I'll note that I'd like to see D reach a million users, and I'm 
doing my small part by trying to get it on the gigantic Android 
install base, but my desire and single new port doesn't mean much 
since those will not be enough to get D to a million, and I'm not 
interested in working on Windows tooling or some other issues 
that might get it there.

Similarly, whatever the definition of success is, whether yours 
or the community's, it's meaningless without a plan and a push to 
get there.  I know you can't make people follow your plan, 
assuming you have one (not a dig, you just may not know how to 
get to a million yet), but you can still sketch out some specific 
efforts that you'd like to enable (more user bounties or better 
ways to get input from commercial users or a much-improved GC, 
which you have said you'd push for in a reddit comment) or put 
out a public agenda/roadmap you'd like to see prioritized.

Without some purposeful steps in the direction of your "success," 
the D community is unlikely to randomly amble along towards where 
you're hoping, at least not in the next couple decades. ;)



 Jan 01 2015



 next sibling parent  "jack" <jack jack.com>  writes:


+1
you are wright. i think, on the chance of being "Willoughbeed",
that there needs to be a real plan.
It must include window users and a windows usable sdk.

On Thursday, 1 January 2015 at 10:48:10 UTC, Joakim wrote:

 On Monday, 29 December 2014 at 19:11:04 UTC, Andrei 
 Alexandrescu wrote:

 On 12/29/14 10:58 AM, Joakim wrote:

 It also means more people asking for stuff, then doing 
 nothing to
 contribute towards it, as though the D community is their 
 slave labor.


 If we, the D community, want D to succeed, we must change this 
 attitude. -- Andrei


 I was just going to let this go without answering, as it's 
 ambiguous, but since Dicebot just said something similar to 
 what I'd have said, I'll bite.  What do you mean by this?  That 
 the people asking for stuff then doing nothing have to change 
 their attitude or those in the D community, like Dicebot and 
 me, who point out that their approach is unrealistic should 
 change our attitude?

 And regardless of your answer to that question, what do you see 
 as "success" for D and how do you plan to get there, given what 
 you know now?  It's possible that it's already a success for 
 the community, as it works well enough for the thousands using 
 and handful contributing to it, and they do not see your 
 million-user goal as worth putting effort into.

 I'll note that I'd like to see D reach a million users, and I'm 
 doing my small part by trying to get it on the gigantic Android 
 install base, but my desire and single new port doesn't mean 
 much since those will not be enough to get D to a million, and 
 I'm not interested in working on Windows tooling or some other 
 issues that might get it there.

 Similarly, whatever the definition of success is, whether yours 
 or the community's, it's meaningless without a plan and a push 
 to get there.  I know you can't make people follow your plan, 
 assuming you have one (not a dig, you just may not know how to 
 get to a million yet), but you can still sketch out some 
 specific efforts that you'd like to enable (more user bounties 
 or better ways to get input from commercial users or a 
 much-improved GC, which you have said you'd push for in a 
 reddit comment) or put out a public agenda/roadmap you'd like 
 to see prioritized.

 Without some purposeful steps in the direction of your 
 "success," the D community is unlikely to randomly amble along 
 towards where you're hoping, at least not in the next couple 
 decades. ;)





 Jan 01 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/1/15 2:48 AM, Joakim wrote:

 On Monday, 29 December 2014 at 19:11:04 UTC, Andrei Alexandrescu wrote:

 On 12/29/14 10:58 AM, Joakim wrote:

 It also means more people asking for stuff, then doing nothing to
 contribute towards it, as though the D community is their slave labor.


 If we, the D community, want D to succeed, we must change this
 attitude. -- Andrei


 I was just going to let this go without answering, as it's ambiguous,
 but since Dicebot just said something similar to what I'd have said,
 I'll bite.  What do you mean by this?  That the people asking for stuff
 then doing nothing have to change their attitude or those in the D
 community, like Dicebot and me, who point out that their approach is
 unrealistic should change our attitude?


Heh, I now see how that's ambiguous. I'm saying we need to start owning 
D issues if we want D to succeed, as opposed to asking people to 
implement their own suggestions. That means taking feedback from folks 
like Manu or Dicebot as "things we should work on" as opposed to "if you 
want it done please do it".

I understand that's counterintuitive but I really think it's the way 
forward. We need to evolve from a tribe to an organization.


 And regardless of your answer to that question, what do you see as
 "success" for D and how do you plan to get there, given what you know
 now?


Success is like adult content - you know it when you see it :o). I don't 
think defining it by means of 1-2 simple proxies (downloads, companies 
using D, etc) is very meaningful but it's clear to me we're not 
successful yet.


 It's possible that it's already a success for the community, as it
 works well enough for the thousands using and handful contributing to
 it, and they do not see your million-user goal as worth putting effort
 into.


I'm sure most of us hope broader support for D is highly desirable.


 I'll note that I'd like to see D reach a million users, and I'm doing my
 small part by trying to get it on the gigantic Android install base, but
 my desire and single new port doesn't mean much since those will not be
 enough to get D to a million, and I'm not interested in working on
 Windows tooling or some other issues that might get it there.

 Similarly, whatever the definition of success is, whether yours or the
 community's, it's meaningless without a plan and a push to get there.  I
 know you can't make people follow your plan, assuming you have one (not
 a dig, you just may not know how to get to a million yet), but you can
 still sketch out some specific efforts that you'd like to enable (more
 user bounties or better ways to get input from commercial users or a
 much-improved GC, which you have said you'd push for in a reddit
 comment) or put out a public agenda/roadmap you'd like to see prioritized.

 Without some purposeful steps in the direction of your "success," the D
 community is unlikely to randomly amble along towards where you're
 hoping, at least not in the next couple decades. ;)


I agree, a plan is needed. Walter and I just had a long talk about this. 
We hope to flesh things out better soon.


Andrei



 Jan 02 2015



  parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 2/01/2015 9:55 p.m., Andrei Alexandrescu wrote:

 On 1/1/15 2:48 AM, Joakim wrote:

 On Monday, 29 December 2014 at 19:11:04 UTC, Andrei Alexandrescu wrote:

 On 12/29/14 10:58 AM, Joakim wrote:

 It also means more people asking for stuff, then doing nothing to
 contribute towards it, as though the D community is their slave labor.


 If we, the D community, want D to succeed, we must change this
 attitude. -- Andrei


 I was just going to let this go without answering, as it's ambiguous,
 but since Dicebot just said something similar to what I'd have said,
 I'll bite.  What do you mean by this?  That the people asking for stuff
 then doing nothing have to change their attitude or those in the D
 community, like Dicebot and me, who point out that their approach is
 unrealistic should change our attitude?


 Heh, I now see how that's ambiguous. I'm saying we need to start owning
 D issues if we want D to succeed, as opposed to asking people to
 implement their own suggestions. That means taking feedback from folks
 like Manu or Dicebot as "things we should work on" as opposed to "if you
 want it done please do it".

 I understand that's counterintuitive but I really think it's the way
 forward. We need to evolve from a tribe to an organization.


 And regardless of your answer to that question, what do you see as
 "success" for D and how do you plan to get there, given what you know
 now?


 Success is like adult content - you know it when you see it :o). I don't
 think defining it by means of 1-2 simple proxies (downloads, companies
 using D, etc) is very meaningful but it's clear to me we're not
 successful yet.


 It's possible that it's already a success for the community, as it
 works well enough for the thousands using and handful contributing to
 it, and they do not see your million-user goal as worth putting effort
 into.


 I'm sure most of us hope broader support for D is highly desirable.


 I'll note that I'd like to see D reach a million users, and I'm doing my
 small part by trying to get it on the gigantic Android install base, but
 my desire and single new port doesn't mean much since those will not be
 enough to get D to a million, and I'm not interested in working on
 Windows tooling or some other issues that might get it there.

 Similarly, whatever the definition of success is, whether yours or the
 community's, it's meaningless without a plan and a push to get there.  I
 know you can't make people follow your plan, assuming you have one (not
 a dig, you just may not know how to get to a million yet), but you can
 still sketch out some specific efforts that you'd like to enable (more
 user bounties or better ways to get input from commercial users or a
 much-improved GC, which you have said you'd push for in a reddit
 comment) or put out a public agenda/roadmap you'd like to see
 prioritized.

 Without some purposeful steps in the direction of your "success," the D
 community is unlikely to randomly amble along towards where you're
 hoping, at least not in the next couple decades. ;)


 I agree, a plan is needed. Walter and I just had a long talk about this.
 We hope to flesh things out better soon.


 Andrei


I for one will be looking forward to an announcement!



 Jan 02 2015



prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st>  writes:


On Monday, 29 December 2014 at 15:18:57 UTC, Gary Willoughby 
wrote:

 This is probably the most disgusting, selfish and deluded posts 
 i've read on this entire newsgroup.

 If D is supposed to supplant C/C++, then the needs of those 
 users *must* be met, especially without deriding those very 
 users. Just because you work on the D ecosystem does not give 
 you 'carte blanche' to tell a user to stop making enquiries 
 into features that are promised by D.

 The user is the entire goal of D! Forgetting this relegates D 
 to obscurity and makes you look like an ass.


 No, not really. Open source is about people working to fulfill 
 their own personal goals and not minding to share resulting 
 code if it doesn't mean much added effort. Only few care about 
 things like long-term success and only tiny minority will be 
 interested in working on ecosystem they don't use.


 With that paragraph, you've just dumped on Walter, Andrei's and 
 all other open source contributor's efforts for the past n 
 years!


I strongly disagree.  Dicebot's post is completely true, 
describing exactly how open source projects actually work, 
instead of some idealized notion of "Open source it and they will 
come!"  I think some people have unrealistic expectations of open 
source after the success of past large projects like the linux 
kernel, gcc, clang, Qt, etc., all of which had heavy commercial 
support from IBM, Red Hat, Apple, Trolltech/Nokia and so on.  D 
has not reached that stage of commercial support yet, so the 
expectation that good Windows tooling and support will just 
magically appear is unrealistic, particularly for free.

You are right that the user's needs will ultimately have to be 
met for D to ever take off to the next level, but I don't recall 
anyone ever "promising" a good Windows debugging experience, docs 
that you can learn the language from, or widespread Windows 
support for D libraries.  D is a community project: Manu can note 
those deficiencies, but as Dicebot said, unless someone wants to 
work on them or like-minded users pay for someone to do it, the 
community will generally not just do what he wants.

Saying that Dicebot's valid point, that everybody has different 
goals from open source and most only care about their narrow use 
case, is dumping on Walter and Andrei's efforts is going off the 
deep end a bit.  I'm sure they are very aware of this reality, 
and are thankful for the few steady contributors they have.



 Dec 29 2014



  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 29 December 2014 at 16:07:59 UTC, Joakim wrote:

 I strongly disagree.  Dicebot's post is completely true, 
 describing exactly how open source projects actually work,


No Dicebot described how open source projects *start*, big 
difference.

I don't want to get into a massive argument here, but viewing 
users as an inconvenience when developing a project that is (in 
it's very essence) supposed to be used by them, is a self 
defeating attitude and will ultimately lead to no-one using it.



 Dec 29 2014



  parent reply "Joakim" <dlang joakim.fea.st>  writes:


On Monday, 29 December 2014 at 16:19:35 UTC, Gary Willoughby 
wrote:

 On Monday, 29 December 2014 at 16:07:59 UTC, Joakim wrote:

 I strongly disagree.  Dicebot's post is completely true, 
 describing exactly how open source projects actually work,


 No Dicebot described how open source projects *start*, big 
 difference.

 I don't want to get into a massive argument here, but viewing 
 users as an inconvenience when developing a project that is (in 
 it's very essence) supposed to be used by them, is a self 
 defeating attitude and will ultimately lead to no-one using it.


That is a nice platitude, and one that I actually agreed with 
above and in general, but who is actually going to do the 
painstaking work that Windows tooling would require?  That is 
what Dicebot is getting at.

If anybody cared about good Windows debugging support or getting 
vibe.d working flawlessly on Windows, they'd have done it 
already.  Now, Manu might bring more attention to those issues 
through his post and someone may decide to work on them as a 
result- it has already spurred Walter to try and improve the 
phobos docs- which is why I have no problem with his criticism.

But Dicebot is right that "users" are not the concern of those 
outside a small core who contribute to D.  Most contributors are 
just scratching their own itch, and users are just potential 
suckers who might add other features I want. ;)

Also, even companies have to prioritize: they cannot just do 
whatever the user asks for.  Open source projects, which are 
usually much more resource-constrained, have to prioritize much 
more.  The features Manu asks for have not been deemed 
priorities.  The open source advantage is that the developer pool 
is potentially much wider, so someone out there may want the same 
features Manu wants and be willing to implement them.



 Dec 29 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:

 If anybody cared about good Windows debugging support or 
 getting vibe.d working flawlessly on Windows, they'd have done 
 it already.  Now, Manu might bring more attention to those 
 issues through his post and someone may decide to work on them 
 as a result- it has already spurred Walter to try and improve 
 the phobos docs- which is why I have no problem with his 
 criticism.


Criticism about documentation is actually very well-placed - it 
is an issue that affects everyone, can be fixed in small chunks 
and does not require huge effort investment for each chunk. No 
one loses, everyone wins, yay!



 Dec 29 2014



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/29/2014 8:51 AM, Dicebot wrote:

 On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:

 If anybody cared about good Windows debugging support or getting vibe.d
 working flawlessly on Windows, they'd have done it already.  Now, Manu might
 bring more attention to those issues through his post and someone may decide
 to work on them as a result- it has already spurred Walter to try and improve
 the phobos docs- which is why I have no problem with his criticism.


 Criticism about documentation is actually very well-placed - it is an issue
that
 affects everyone, can be fixed in small chunks and does not require huge effort
 investment for each chunk. No one loses, everyone wins, yay!


I am trying to lead by example, but so far I see only a couple pull requests 
from others improving the Phobos docs.

C'mon, guys, most fixes are pretty trivial, it's just that there's a lot of 
them. If everyone does one for a function they're already familiar with, we can 
get a lot done.



 Dec 29 2014



 next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Mon, Dec 29, 2014 at 04:25:20PM -0800, Walter Bright via Digitalmars-d wrote:

 On 12/29/2014 8:51 AM, Dicebot wrote:


[...]

Criticism about documentation is actually very well-placed - it is an
issue that affects everyone, can be fixed in small chunks and does
not require huge effort investment for each chunk. No one loses,
everyone wins, yay!


 
 I am trying to lead by example, but so far I see only a couple pull
 requests from others improving the Phobos docs.
 
 C'mon, guys, most fixes are pretty trivial, it's just that there's a
 lot of them. If everyone does one for a function they're already
 familiar with, we can get a lot done.


I was away on vacation for a week, so couldn't work on this. I'll see if
I can cook up a bunch of doc-related PR's this week. They *are* very
low-hanging fruit that even newbies can easily contribute to.


T

-- 
Why waste time learning, when ignorance is instantaneous? -- Hobbes, from
Calvin & Hobbes



 Dec 29 2014



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/29/2014 4:49 PM, H. S. Teoh via Digitalmars-d wrote:

 I was away on vacation for a week, so couldn't work on this.


What, not working on Christmas? How hard core are you? :-)


 I'll see if
 I can cook up a bunch of doc-related PR's this week. They *are* very
 low-hanging fruit that even newbies can easily contribute to.


Great! Looking forward to it.



 Dec 29 2014



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/29/14 4:25 PM, Walter Bright wrote:

 On 12/29/2014 8:51 AM, Dicebot wrote:

 On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:

 If anybody cared about good Windows debugging support or getting vibe.d
 working flawlessly on Windows, they'd have done it already.  Now,
 Manu might
 bring more attention to those issues through his post and someone may
 decide
 to work on them as a result- it has already spurred Walter to try and
 improve
 the phobos docs- which is why I have no problem with his criticism.


 Criticism about documentation is actually very well-placed - it is an
 issue that
 affects everyone, can be fixed in small chunks and does not require
 huge effort
 investment for each chunk. No one loses, everyone wins, yay!


 I am trying to lead by example, but so far I see only a couple pull
 requests from others improving the Phobos docs.

 C'mon, guys, most fixes are pretty trivial, it's just that there's a lot
 of them. If everyone does one for a function they're already familiar
 with, we can get a lot done.


I've also fixed a stray paren in std.algorithm 
(https://github.com/D-Programming-Language/phobos/pull/2824), which was 
diagnosed correctly every time the documentation was generated. During 
doc generation there are also a bunch of warnings about undocumented or 
mismatched params. It would be awesome if someone was on it.

I very much appreciate the folks who make it a point to contribute to 
the github repos in addition to helping out people on the forums. I've 
identified as a distinct task of mine for 2015 to improve my leadership 
skills, starting with convincing someone to literally remove one 
character :o).


Andrei



 Dec 29 2014



  parent reply Steven Schveighoffer <schveiguy yahoo.com>  writes:


On 12/29/14 8:54 PM, Andrei Alexandrescu wrote:

 On 12/29/14 4:25 PM, Walter Bright wrote:

 On 12/29/2014 8:51 AM, Dicebot wrote:

 On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:

 If anybody cared about good Windows debugging support or getting vibe.d
 working flawlessly on Windows, they'd have done it already.  Now,
 Manu might
 bring more attention to those issues through his post and someone may
 decide
 to work on them as a result- it has already spurred Walter to try and
 improve
 the phobos docs- which is why I have no problem with his criticism.


 Criticism about documentation is actually very well-placed - it is an
 issue that
 affects everyone, can be fixed in small chunks and does not require
 huge effort
 investment for each chunk. No one loses, everyone wins, yay!


 I am trying to lead by example, but so far I see only a couple pull
 requests from others improving the Phobos docs.

 C'mon, guys, most fixes are pretty trivial, it's just that there's a lot
 of them. If everyone does one for a function they're already familiar
 with, we can get a lot done.


 I've also fixed a stray paren in std.algorithm
 (https://github.com/D-Programming-Language/phobos/pull/2824), which was
 diagnosed correctly every time the documentation was generated. During
 doc generation there are also a bunch of warnings about undocumented or
 mismatched params. It would be awesome if someone was on it.

 I very much appreciate the folks who make it a point to contribute to
 the github repos in addition to helping out people on the forums. I've
 identified as a distinct task of mine for 2015 to improve my leadership
 skills, starting with convincing someone to literally remove one
 character :o).


Please, let's make the build of the documentation be an error on auto 
tester. I can say personally, there is so much more involved with 
building the docs than I care to deal with. You need all the 
repositories, and the dlang.org repository, which I rarely use. IIRC, 
you also need everything laid out in the right way to get that to work.

If the auto tester simply errored when the doc has issues, then at least 
someone would be aware of it.

-Steve



 Dec 30 2014



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/30/14 4:30 AM, Steven Schveighoffer wrote:

 Please, let's make the build of the documentation be an error on auto
 tester. I can say personally, there is so much more involved with
 building the docs than I care to deal with. You need all the
 repositories, and the dlang.org repository, which I rarely use. IIRC,
 you also need everything laid out in the right way to get that to work.


mkdir /dir/for/d/
cd /dir/for/d/
git clone https://github.com/D-Programming-Language/tools
tools/update.sh

... and you're there. This should be on a wiki page. Takers?


 If the auto tester simply errored when the doc has issues, then at least
 someone would be aware of it.


Agreed.


Andrei



 Dec 30 2014



prev sibling  parent  "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 30 December 2014 at 00:25:28 UTC, Walter Bright wrote:

 Criticism about documentation is actually very well-placed - 
 it is an issue that
 affects everyone, can be fixed in small chunks and does not 
 require huge effort
 investment for each chunk. No one loses, everyone wins, yay!


 I am trying to lead by example, but so far I see only a couple 
 pull requests from others improving the Phobos docs.

 C'mon, guys, most fixes are pretty trivial, it's just that 
 there's a lot of them. If everyone does one for a function 
 they're already familiar with, we can get a lot done.


I am personally scared of DDOC and unlikely to do any 
contributions to documentation that require more than just adding 
"Params:" while it is the only option. It is really that bad.

It is also much better when newcomers try proposing documentation 
changes as they have fresh understanding of what is wrong.



 Dec 31 2014



prev sibling  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:

 But Dicebot is right that "users" are not the concern of those 
 outside a small core who contribute to D.  Most contributors 
 are just scratching their own itch, and users are just 
 potential suckers who might add other features I want. ;)


*Stunned*

On Monday, 29 December 2014 at 17:57:42 UTC, Joseph Rushton 
Wakeling wrote:

 I don't think it needs to be a zero-sum game.  Removing 
 blockers to entry can make an orders-of-magnitude difference in 
 the number of users for a particular platform, and when you 
 gain users, you gain developers.  Paying now to remove basic 
 usability issues could well free up a lot of core contributor 
 time in future, by opening a door for Windows devs that makes 
 it worth their while to invest effort into the language and its 
 toolchain.


Yes, this is how i see things.



 Dec 29 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


I'd better respond when I will not be as angry and tempted to go 
into accusation mode.



 Dec 29 2014



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/29/14 11:59 AM, Dicebot wrote:

 I'd better respond when I will not be as angry and tempted to go into
 accusation mode.


Very much appreciated. All, please let's keep it civil. -- Andrei



 Dec 29 2014



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 30 December 2014 at 04:08, Gary Willoughby via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 29 December 2014 at 16:33:05 UTC, Joakim wrote:

 I don't think it needs to be a zero-sum game.  Removing blockers to entry
 can make an orders-of-magnitude difference in the number of users for a
 particular platform, and when you gain users, you gain developers.  Paying
 now to remove basic usability issues could well free up a lot of core
 contributor time in future, by opening a door for Windows devs that makes it
 worth their while to invest effort into the language and its toolchain.



 Yes, this is how i see things.


I think this is the most important point I (tried) to make; users are
only likely to contribute once they already have _significant_
investment.
First-impressions matter, a lot, and it has been my experience that
many (most?) users I have introduced to D (mainly from my own
industry) have been scared off by first-impressions, relating to the
points I've discussed.

Business commitment is even more significant than user commitment,
since if a business becomes committed and there is a block in the way,
something that needs to be fixed and nobody else is available to do
it, there is a heightened probability they will assign someone paid
working time to address the issue. Support for existing commitments is
not usually negotiable.
As such, I think commercial users are quite important, and perhaps
even in the traditional open-source sense that it may actually lead to
things being done.
Of course, businesses are more conservative than users, and will never
make a company commitment if the experience appears shaky right out of
the gate. Those first(/early) impressions really matter!



 Dec 29 2014



prev sibling  parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Mon, 29 Dec 2014 15:18:56 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 This is probably the most disgusting, selfish and deluded posts=20
 i've read on this entire newsgroup.


fsck. i was sure that this was written about me. i sucked again.


 If D is supposed to supplant C/C++, then the needs of those users=20
 *must* be met, especially without deriding those very users. Just=20
 because you work on the D ecosystem does not give you 'carte=20
 blanche' to tell a user to stop making enquiries into features=20
 that are promised by D.


but it gives! this is at least honest, unlike writing in bugzilla that
it is intended for patches and then telling "github or GTFO, nobody
will work with the code in bugzilla!" i prefer to read a honest truth,
not polite lies.


 The user is the entire goal of D!


i don't know what goal "D" has and how it can has any goals at all, but
now you are telling Dicebot that he must work *not* on what *he* wants,
but on something that some random user wants. more of it, you trying to
tell him that he should shut up. and all this without him even being
your employee. THIS is what i call "disgusting, selfish and deluded
post".


 No, not really. Open source is about people working to fulfill=20
 their own personal goals and not minding to share resulting=20
 code if it doesn't mean much added effort. Only few care about=20
 things like long-term success and only tiny minority will be=20
 interested in working on ecosystem they don't use.


 With that paragraph, you've just dumped on Walter, Andrei's and=20
 all other open source contributor's efforts for the past n years!


and again... maybe i didn't understand you right and "This is probably
the most disgusting, selfish and deluded posts i've read on this entire
newsgroup" was about your post i'm answering to? but why plurar "posts"
then?

please, explain me, *whose* exactly post was "disgusting, selfish and
deluded"? 'cause now i'm completely lost.



 Dec 29 2014



  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 29 December 2014 at 19:34:52 UTC, ketmar via 
Digitalmars-d wrote:

 please, explain me, *whose* exactly post was "disgusting, 
 selfish and
 deluded"? 'cause now i'm completely lost.


Ok, i will explain because i think my point should be made clear 
and because this thread is giving valuable feedback (from Manu) 
to the D community about a missed opportunity in industry!

I have no argument with people contributing to D to further their 
interests. That is what (i'm guessing) pushes most open source 
projects forward. What i firmly object to and what i find very 
degrading is that because certain people make contributions to D 
it gives them such arrogance as to espouse their personal 
motivations as the overall goal and motivations of D. Also in the 
process trying to persuade other (non-contributing) users that 
their expectations are illegitimate or somehow lesser in 
importance.

D, as a project, already has a firmly entrenched goal and it's 
motivation is to reach that goal. Anyone contributing to D must 
acknowledge that goal and be prepared to sustain it through their 
contributions. The goal is set by Walter and Andrei. The goals 
are (mostly) outlined here: http://dlang.org/overview.html

When someone enquires about the progress of a particular feature 
they do not need to hear "contribute or gtfo". What they need is 
a civil answer preferably pointing to a roadmap.

Some recent users are becoming very vocal, especially regarding 
memory allocation regarding GC, RC, etc. because D is being 
pushed towards the C++ crowd and this is what they expect to be 
able to control. It is marketed as a system programming language, 
like it or not.  These users expect full control. Of course this 
is a work in progress. ( nogc, etc.) I know that, you know that, 
but they don't. Please don't say "I contribute and you don't so 
shut up". It make the entire community look like massive dicks.

Yes, i know that some users are always pushing for the same 
features to be implemented and others just what some features to 
be actually finished, me too! but this is no reason to give them 
attitude and tell them to contribute or gtfo. Some people just 
aren't capable of contributing (me included). But that doesn't 
render their requests moot! Especially when their expectations 
are included in the goals of D.

I want to contribute, i want to push D forward, i'm slowly 
educating myself to a standard where i'm comfortable to be able 
to do so. This constant attitude however just makes me want to 
concentrate on other languages.



 Dec 29 2014



 next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Mon, 29 Dec 2014 20:09:08 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 D, as a project, already has a firmly entrenched goal and it's=20
 motivation is to reach that goal. Anyone contributing to D must=20
 acknowledge that goal and be prepared to sustain it through their=20
 contributions. The goal is set by Walter and Andrei. The goals=20
 are (mostly) outlined here: http://dlang.org/overview.html


1. i can't see anything about "user-oriented" there.
2. if i don't care about anything written there, i should not
contribute? you keep saying "do as we say or GTFO"...


 When someone enquires about the progress of a particular feature=20
 they do not need to hear "contribute or gtfo". What they need is=20
 a civil answer preferably pointing to a roadmap.


...and that roadmap has only three words on it: "contribute or GTFO".


 Please don't say "I contribute and you don't so=20
 shut up". It make the entire community look like massive dicks.


it's better to be dick than to be a liar. it's obvious that we haven't
enough resources to comply with all user requests, so it's honest to
say: "if you want it -- DIY! otherwise it's unlikely to happen soon".
we are not a bunch of marketing shitheads, we MUST tell people the
truth, not tricking people so they will wait for something to happen
and then will go out frustrated by lies.


 Some people just=20
 aren't capable of contributing (me included). But that doesn't=20
 render their requests moot!


anyone is capable of contributing, it's not necessary about writing
a code. if enough people want some feature that developers aren't able
to deliver now, those people can cooperate and hire some programmer(s)
to implement the feature. i can assure you that this way they will get
their beloved feature much faster than by simply talking about how it's
missing. open-source is not about shouting in the box and then
magically getting result out of it. to get something you have either to
put something in or just silently wait until someone else will put
something into the box. shouting in the box will do nothing.


 I want to contribute, i want to push D forward, i'm slowly=20
 educating myself to a standard where i'm comfortable to be able=20
 to do so. This constant attitude however just makes me want to=20
 concentrate on other languages.


ah, the question is WHY do you want to contribute? what output you want
to get from being a contributor? i'm not trying to insult you here,
it's really important.



 Dec 29 2014



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


So, getting back to this. What do I see wrong in this thread? It 
creates a clear message : you don't really want to be a D 
contributor.

Once you start doing it, all privileges of doubt that belong to 
"user" are lost and bunch of obligations suddenly appears. And of 
all obligation worst offender written by Gary is requirement to 
strongly identify oneself with a D project.

Let's get it straight : I don't want to ever be associated with D 
upstream. I have never wanted to be part of Phobos development 
team. Only reason I have write access is that last time I 
complained about issues in pull request management Andrei has 
suddenly given me write access and asked to fix it myself. 
Probably my biggest mistake was agreeing to do it instead of 
answering "fuck you" like Manu did.

And I find this comment by Manu absolutely outrageous:


 Surely you can understand that my desire to *use* D as a tool 
 is not
 at odds with my desire to continue to work in the fields that I 
 prefer
 to work in?


You can hardly even imagine how angry I was when reading it and 
amount of spoken swearwords that have never reached the NG. Here 
I am just being told in most straightforward way "I don't want to 
work on things I need because I have better things to do so you 
must do those things instead as you can't do anything better 
anyway".

Yes, there was an argument about long-term profit caring about 
users from other fields bring. Sorry, but D community is simply 
not big enough to afford such long-term investments. To make work 
on Windows toolchain of any interest to me following future 
assumption would need to hold true:

- it will actually help to attract new users
- at least some portion of this added user base will decide to 
contribute back, directly or indirectly
- some of resulting contributions will benefit Linux ecosystem too
- that final added value will be higher than original investment

It will take quite a while. I appreciate feedback about what is 
wrong but not _demands_ about what to work on. If kind acceptance 
of any demands is considered inherent duty of anyone it least a 
bit associated with D dev team I kindly ask to remove any access 
from me to avoid any further confusion. There is no way I will 
oblige to image written down by Gary in this thread.



 Dec 31 2014



  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Wednesday, 31 December 2014 at 21:05:41 UTC, Dicebot wrote:

 So, getting back to this. What do I see wrong in this thread? 
 It creates a clear message : you don't really want to be a D 
 contributor.

 Once you start doing it, all privileges of doubt that belong to 
 "user" are lost and bunch of obligations suddenly appears. And 
 of all obligation worst offender written by Gary is requirement 
 to strongly identify oneself with a D project.

 Let's get it straight : I don't want to ever be associated with 
 D upstream. I have never wanted to be part of Phobos 
 development team. Only reason I have write access is that last 
 time I complained about issues in pull request management 
 Andrei has suddenly given me write access and asked to fix it 
 myself. Probably my biggest mistake was agreeing to do it 
 instead of answering "fuck you" like Manu did.

 And I find this comment by Manu absolutely outrageous:


 Surely you can understand that my desire to *use* D as a tool 
 is not
 at odds with my desire to continue to work in the fields that 
 I prefer
 to work in?


 You can hardly even imagine how angry I was when reading it and 
 amount of spoken swearwords that have never reached the NG. 
 Here I am just being told in most straightforward way "I don't 
 want to work on things I need because I have better things to 
 do so you must do those things instead as you can't do anything 
 better anyway".

 Yes, there was an argument about long-term profit caring about 
 users from other fields bring. Sorry, but D community is simply 
 not big enough to afford such long-term investments. To make 
 work on Windows toolchain of any interest to me following 
 future assumption would need to hold true:

 - it will actually help to attract new users
 - at least some portion of this added user base will decide to 
 contribute back, directly or indirectly
 - some of resulting contributions will benefit Linux ecosystem 
 too
 - that final added value will be higher than original investment

 It will take quite a while. I appreciate feedback about what is 
 wrong but not _demands_ about what to work on. If kind 
 acceptance of any demands is considered inherent duty of anyone 
 it least a bit associated with D dev team I kindly ask to 
 remove any access from me to avoid any further confusion. There 
 is no way I will oblige to image written down by Gary in this 
 thread.


Just because you contribute to D it doesn't give you any 
authority to get angry at users or:

* Pull rank just because you contribute
* refusing to take seriously requests for features to be 
implemented/finished
* trying to belittle user requests
* treating non-contributing users as lesser than you
* propagating an attitude of 'contribute or gtfo'

The vast majority of users of D will *never* contribute anything 
*ever* but they will (from time to time) ask for something. Just 
deal with it. Add it to an issue tracker and triage. Users should 
be put first in all cases, period! Especially if they are 
experiencing problems or shortcomings from 'your' product. Just 
because it's free doesn't mean users needs should be disregarded 
or that support should not be given.

I'm seriously considering writing a new blog article for reddit, 
highlighting the attitudes in this discussion because they are so 
seriously anti-success.



 Jan 01 2015



 next sibling parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


On Thursday, 1 January 2015 at 12:55:29 UTC, Gary Willoughby 
wrote:

 On Wednesday, 31 December 2014 at 21:05:41 UTC, Dicebot wrote:

 So, getting back to this. What do I see wrong in this thread? 
 It creates a clear message : you don't really want to be a D 
 contributor.

 Once you start doing it, all privileges of doubt that belong 
 to "user" are lost and bunch of obligations suddenly appears. 
 And of all obligation worst offender written by Gary is 
 requirement to strongly identify oneself with a D project.

 Let's get it straight : I don't want to ever be associated 
 with D upstream. I have never wanted to be part of Phobos 
 development team. Only reason I have write access is that last 
 time I complained about issues in pull request management 
 Andrei has suddenly given me write access and asked to fix it 
 myself. Probably my biggest mistake was agreeing to do it 
 instead of answering "fuck you" like Manu did.

 And I find this comment by Manu absolutely outrageous:


 Surely you can understand that my desire to *use* D as a tool 
 is not
 at odds with my desire to continue to work in the fields that 
 I prefer
 to work in?


 You can hardly even imagine how angry I was when reading it 
 and amount of spoken swearwords that have never reached the 
 NG. Here I am just being told in most straightforward way "I 
 don't want to work on things I need because I have better 
 things to do so you must do those things instead as you can't 
 do anything better anyway".

 Yes, there was an argument about long-term profit caring about 
 users from other fields bring. Sorry, but D community is 
 simply not big enough to afford such long-term investments. To 
 make work on Windows toolchain of any interest to me following 
 future assumption would need to hold true:

 - it will actually help to attract new users
 - at least some portion of this added user base will decide to 
 contribute back, directly or indirectly
 - some of resulting contributions will benefit Linux ecosystem 
 too
 - that final added value will be higher than original 
 investment

 It will take quite a while. I appreciate feedback about what 
 is wrong but not _demands_ about what to work on. If kind 
 acceptance of any demands is considered inherent duty of 
 anyone it least a bit associated with D dev team I kindly ask 
 to remove any access from me to avoid any further confusion. 
 There is no way I will oblige to image written down by Gary in 
 this thread.


 Just because you contribute to D it doesn't give you any 
 authority to get angry at users or:


He does not need any permission to get angry. Don't forget that he
remains civil despite being angry.

 * refusing to take seriously requests for features to be 
 implemented/finished


Actually he does not need authority for this, because he isn't 
obliged
to do this in the first place.

 * trying to belittle user requests


He didn't. All he's doing is to point out that to put something 
onto the agenda
of the D community, doing it yourself is the most effective way. 
The only other way is to wait for someone else doing it which 
might never happen at all.

 * treating non-contributing users as lesser than you


He does not.

 * propagating an attitude of 'contribute or gtfo'


He does not. It's totally appropriate to point out that no one is 
or will be working on something someone requests. Manu's work to 
promote D to his colleagues is very welcome and I am sure 
everyone does acknowledge it. His feedback form doing so is 
noted, some action to improve the documentation is already 
underway.


 This and that didn't work ootb, this was a hindrance, because 
 of that we're using node.js now.


---> Okay


 It's this way for years now, what the fuck are you guys doing? 
 I won't be doing anything, but you guys have to.


---> Getting angry is totally natural.



 Jan 01 2015



 next sibling parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Thursday, 1 January 2015 at 13:20:46 UTC, Tobias Pankrath 
wrote:

 It's this way for years now, what the fuck are you guys doing? 
 I won't be doing anything, but you guys have to.


 ---> Getting angry is totally natural.


True. I hate seeing threads like this when Manu brings some 
really useful and important feedback from industry about his 
experiences promoting D to the very people D's creators are 
trying to cater for and it just turns into a major flamefest.

If Manu is not to be listened to regarding his experiences then 
who *do* we listen to?



 Jan 01 2015



  parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


On Thursday, 1 January 2015 at 13:25:53 UTC, Gary Willoughby 
wrote:

 On Thursday, 1 January 2015 at 13:20:46 UTC, Tobias Pankrath 
 wrote:

 It's this way for years now, what the fuck are you guys 
 doing? I won't be doing anything, but you guys have to.


 ---> Getting angry is totally natural.


 True. I hate seeing threads like this when Manu brings some 
 really useful and important feedback from industry about his 
 experiences promoting D to the very people D's creators are 
 trying to cater for and it just turns into a major flamefest.

 If Manu is not to be listened to regarding his experiences then 
 who *do* we listen to?


I agree that Manu wasn't treated in a fair manner, but Dicebot is 
not to blame. He is just pointing out the obvious.



 Jan 01 2015



  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 1 January 2015 at 23:54, Tobias Pankrath via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 1 January 2015 at 13:25:53 UTC, Gary Willoughby wrote:

 On Thursday, 1 January 2015 at 13:20:46 UTC, Tobias Pankrath wrote:

 It's this way for years now, what the fuck are you guys doing? I won't
 be doing anything, but you guys have to.



 ---> Getting angry is totally natural.



 True. I hate seeing threads like this when Manu brings some really useful
 and important feedback from industry about his experiences promoting D to
 the very people D's creators are trying to cater for and it just turns into
 a major flamefest.

 If Manu is not to be listened to regarding his experiences then who *do*
 we listen to?



 I agree that Manu wasn't treated in a fair manner, but Dicebot is not to
 blame. He is just pointing out the obvious.


I just want to say that I think you guys are getting even more
invested in this conversation than I am at this stage. I'm a bit
discouraged by the tone that arose, but regardless, I think the
outcome has been as good as it could have been, there has already been
some great action; Walter has taken a look at some debugger related
issues already, and documentation has spawned a lot of conversation.
I'm actually quite happy with the practical outcomes here so far, and
appreciate the effort.



 Jan 01 2015



prev sibling  parent  "dajones" <dajones sharklasers.com>  writes:


On Thursday, 1 January 2015 at 13:20:46 UTC, Tobias Pankrath 
wrote:

 On Thursday, 1 January 2015 at 12:55:29 UTC, Gary Willoughby 
 wrote:

 Just because you contribute to D it doesn't give you any 
 authority to get angry at users or:


 He does not need any permission to get angry. Don't forget that 
 he
 remains civil despite being angry.


Even he didnt think he'd been civil or else he wouldnt be making 
excuses like (paraphrased) "being nice is not in my skill set", 
or "i've probably written worse."

Actually that's past uncivil and pretty close to asshole IMO.



 Jan 01 2015



prev sibling next sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 01/01/15 13:55, Gary Willoughby via Digitalmars-d wrote:

 I'm seriously considering writing a new blog article for reddit, highlighting
 the attitudes in this discussion because they are so seriously anti-success.


I think that would be a bad idea, because the most likely result would be only 
to further inflame bad feeling that is currently starting to calm down, and to 
result in people outside the D community being put off from attempting to take
part.

I also think that, regardless of the broader issues, there is no excuse for 
throwing around the kind of accusations you threw at Dicebot.  Even if you most 
sincerely believe that someone is behaving badly, that kind of vituperative 
personal attack has no place in any responsible community.

There's more than one way to be "anti-success", and one sadly-too-common way is 
to indulge in such personal attacks, which don't just cause bad feeling for the 
recipient but for plenty of other community members who have to read them, and 
wonder whether they too will be attacked for venturing an opinion.



 Jan 01 2015



  parent  "Gary Willoughby" <dev nomad.so>  writes:


On Thursday, 1 January 2015 at 14:24:36 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

 On 01/01/15 13:55, Gary Willoughby via Digitalmars-d wrote:

 I'm seriously considering writing a new blog article for 
 reddit, highlighting
 the attitudes in this discussion because they are so seriously 
 anti-success.


 I think that would be a bad idea, because the most likely 
 result would be only to further inflame bad feeling that is 
 currently starting to calm down, and to result in people 
 outside the D community being put off from attempting to take 
 part.

 I also think that, regardless of the broader issues, there is 
 no excuse for throwing around the kind of accusations you threw 
 at Dicebot.  Even if you most sincerely believe that someone is 
 behaving badly, that kind of vituperative personal attack has 
 no place in any responsible community.

 There's more than one way to be "anti-success", and one 
 sadly-too-common way is to indulge in such personal attacks, 
 which don't just cause bad feeling for the recipient but for 
 plenty of other community members who have to read them, and 
 wonder whether they too will be attacked for venturing an 
 opinion.


Probably. I'll leave it here and as Manu has said maybe this 
conversation is past its usefulness now. I'll go cool off.



 Jan 01 2015



prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Thu, 01 Jan 2015 12:55:28 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Just because you contribute to D it doesn't give you any=20
 authority to get angry at users or:


that's really great. Dicebot wrote a long text explaining that he is
not a D dev team representative, he doesn't want to be one and he want
his commit right to be taken away so others will stop seeing him as
"official person", and then you demand from him to behave like
"official person".

that's incredible, really incredible! did you even read his post?


 Users should be put first in all cases, period!


you know what... Dicebot IS USER. and now you oppressing him, doing
exatly what you told him not to do.


 I'm seriously considering writing a new blog article for reddit,=20
 highlighting the attitudes in this discussion because they are so=20
 seriously anti-success.


but please don't forget to give direct link to discussion. 'cause you
somehow managed to read the things Dicebot never wrote.



 Jan 01 2015



 next sibling parent reply "pops" <nopoop yahoo.com>  writes:


   Regarding debuggers: keep in mind, windows debuggers
are light years ahead of GDB and friends.

   What Linux people refer to as a debugger looks like a stone age
tool to me.



 Jan 01 2015



 next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 02 Jan 2015 05:12:27 +0000
pops via Digitalmars-d <digitalmars-d puremagic.com> wrote:


    Regarding debuggers: keep in mind, windows debuggers
 are light years ahead of GDB and friends.
=20
    What Linux people refer to as a debugger looks like a stone age
 tool to me.


...and we, *nix people, thinking the same... about windows debuggers.
so please, don't call the tool you aren't familiar with "stone age
tool".



 Jan 01 2015



  parent reply "pops" <nopoop yahoo.com>  writes:


 ...and we, *nix people, thinking the same... about windows 
 debuggers.
 so please, don't call the tool you aren't familiar with "stone 
 age
 tool".


https://anteru.net/2014/12/13/2596/

  Talks about switching from windows to Linux. There are 
positives, but the debugging is not one of them.



 Jan 01 2015



  parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 02 Jan 2015 05:49:45 +0000
pops via Digitalmars-d <digitalmars-d puremagic.com> wrote:


   Talks about switching from windows to Linux. There are=20
 positives, but the debugging is not one of them.


*nix cultire and windows culture are very different. when "switcher"
tries to use his windows habits in *nix world, he found himself
frustrated by "inconvenient tools" and such. the same is true for *nix
guy trying windows.

i can say that visual studio suxalot. it's one of the worst things i
ever used in my life. but you know why? 'cause it's doing everything
not in the way i used to.

for windows folks "integration" is "having everything in one big app".
for *nix folks "integration" is "having alot of reusable parts that can
be combined to create any necessary tool". gdb is such part. using that
part alone can be painful.

that's why *nix folks don't like IDEs. they have their vim/emacs, and
just extending that to get what they need. so they looking at visual
studio, for example, and see very inflexible tool: it doesn't even have
built-in scripting language, which is the key component of
"integration" as *nix folks see it!

*nix is not windows. windows is not *nix. they are two different
cultures. so when you saying that "*nix debugger expirience reminds me
of stone age", most *nix folks immediately thinks: "ah, another dumb
switcher who cannot understand that not everything in the world is
windows". please, don't be one of that dumbs.



 Jan 01 2015



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 2 January 2015 at 15:12, pops via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

   Regarding debuggers: keep in mind, windows debuggers
 are light years ahead of GDB and friends.

   What Linux people refer to as a debugger looks like a stone age
 tool to me.


I'm pretty sure this is almost entirely a problem with typical linux
IDE's UIs. Most of them are just pretty thin, inflexible, or awkward.
I think GDB actually has more features than VC's debugger(?). At
least, they should be basically the same with a sufficient UI.

GDB actually knows about D thanks to a bunch of work Iain has done...
I don't think we're gonna get that from MS any time soon.
I'm hoping LLDB will support coff+pdb in time, only then do I imagine
we'll have a hope at robust debugging of D code in windows.



 Jan 02 2015



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


Please let it go. There has been said enough to represent views 
of different parties, and argument for the sake of the argument 
is counterproductive.



 Jan 01 2015



prev sibling  parent reply "dajones" <dajones sharklasers.com>  writes:


On Friday, 2 January 2015 at 01:17:32 UTC, ketmar via 
Digitalmars-d wrote:

 On Thu, 01 Jan 2015 12:55:28 +0000
 Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 Just because you contribute to D it doesn't give you any 
 authority to get angry at users or:


 that's really great. Dicebot wrote a long text explaining that 
 he is
 not a D dev team representative, he doesn't want to be one and 
 he want
 his commit right to be taken away so others will stop seeing 
 him as
 "official person", and then you demand from him to behave like
 "official person".


He did not demand that dicebot "act like an official 
representative"

He said that just because he contributes that does not give him 
the authority to "act like an official representative"

Actually almost the polar opposite of what you think he said.



 Jan 02 2015



  parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 02 Jan 2015 10:36:14 +0000
dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Friday, 2 January 2015 at 01:17:32 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Thu, 01 Jan 2015 12:55:28 +0000
 Gary Willoughby via Digitalmars-d <digitalmars-d puremagic.com>=20
 wrote:


 Just because you contribute to D it doesn't give you any=20
 authority to get angry at users or:


 that's really great. Dicebot wrote a long text explaining that=20
 he is
 not a D dev team representative, he doesn't want to be one and=20
 he want
 his commit right to be taken away so others will stop seeing=20
 him as
 "official person", and then you demand from him to behave like
 "official person".


=20
 He did not demand that dicebot "act like an official=20
 representative"
=20
 He said that just because he contributes that does not give him=20
 the authority to "act like an official representative"
=20
 Actually almost the polar opposite of what you think he said.


show me where Dicebot did, please.



 Jan 02 2015



  parent reply "dajones" <dajones sharklasers.com>  writes:


On Friday, 2 January 2015 at 10:44:44 UTC, ketmar via 
Digitalmars-d wrote:

 On Fri, 02 Jan 2015 10:36:14 +0000
 dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Friday, 2 January 2015 at 01:17:32 UTC, ketmar via 
 Digitalmars-d wrote:

 On Thu, 01 Jan 2015 12:55:28 +0000
 Gary Willoughby via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:


 Just because you contribute to D it doesn't give you any 
 authority to get angry at users or:


 that's really great. Dicebot wrote a long text explaining 
 that he is
 not a D dev team representative, he doesn't want to be one 
 and he want
 his commit right to be taken away so others will stop seeing 
 him as
 "official person", and then you demand from him to behave 
 like
 "official person".


 
 He did not demand that dicebot "act like an official 
 representative"
 
 He said that just because he contributes that does not give 
 him the authority to "act like an official representative"
 
 Actually almost the polar opposite of what you think he said.


 show me where Dicebot did, please.


I didnt claim to agree with him, I just pointed out that you 
completely misconstrued what he said.

A civil response would have been, "oops thank you for pointing 
that out".

But instead you look for some means of attack. That's ok, I 
understand, you and diceboot are like a couple of young cocks 
who's hackles fly up at the slightest sniff of a challenge. And 
you cant back down because your honour is at stake!

Jeez I feel old.



 Jan 02 2015



  parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 02 Jan 2015 13:29:45 +0000
dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Jeez I feel old.


then you'd better don't know how old i am...



 Jan 02 2015



  parent reply "dajones" <dajones sharklasers.com>  writes:


On Friday, 2 January 2015 at 13:46:00 UTC, ketmar via 
Digitalmars-d wrote:

 On Fri, 02 Jan 2015 13:29:45 +0000
 dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Jeez I feel old.


 then you'd better don't know how old i am...


There I was trying to excuse you for being full of youthful zeal 
and you go and spoil it by admitting you're a curmudgeonly old 
cnut.



 Jan 02 2015



 next sibling parent reply "anonymous" <anonymous example.com>  writes:


On Friday, 2 January 2015 at 16:35:17 UTC, dajones wrote:

 On Friday, 2 January 2015 at 13:46:00 UTC, ketmar via 
 Digitalmars-d wrote:

 On Fri, 02 Jan 2015 13:29:45 +0000
 dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Jeez I feel old.


 then you'd better don't know how old i am...


 There I was trying to excuse you for being full of youthful 
 zeal and you go and spoil it by admitting you're a curmudgeonly 
 old cnut.


Well said. ketmar is the most guilty for degrading the quality of
dialogue in this group.



 Jan 02 2015



 next sibling parent reply "Vlad Levenfeld" <vlevenfeld gmail.com>  writes:


Reading this thread, one gets the impression that Dconf 2015 is 
better off taking place in an octagon-shaped cage than a 
university lecture hall...



 Jan 02 2015



 next sibling parent  "dajones" <dajones sharklasers.com>  writes:


On Friday, 2 January 2015 at 19:24:59 UTC, Vlad Levenfeld wrote:

 Reading this thread, one gets the impression that Dconf 2015 is 
 better off taking place in an octagon-shaped cage than a 
 university lecture hall...


Nerd cage fighting... now there's a reality TV show I would watch.



 Jan 03 2015



prev sibling  parent  "eles" <eles eles.com>  writes:


On Friday, 2 January 2015 at 19:24:59 UTC, Vlad Levenfeld wrote:

 Reading this thread, one gets the impression that Dconf 2015 is 
 better off taking place in an octagon-shaped cage than a 
 university lecture hall...


Is not that bad. People here make sometimes a lot of noise, but 
they never hold grudges.



 Jan 03 2015



prev sibling  parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 02 Jan 2015 18:45:49 +0000
anonymous via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Friday, 2 January 2015 at 16:35:17 UTC, dajones wrote:

 On Friday, 2 January 2015 at 13:46:00 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Fri, 02 Jan 2015 13:29:45 +0000
 dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Jeez I feel old.


 then you'd better don't know how old i am...


 There I was trying to excuse you for being full of youthful=20
 zeal and you go and spoil it by admitting you're a curmudgeonly=20
 old cnut.


=20
 Well said. ketmar is the most guilty for degrading the quality of
 dialogue in this group.


my pleasure. glad you enjoyed it.



 Jan 02 2015



prev sibling  parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 02 Jan 2015 16:35:15 +0000
dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Friday, 2 January 2015 at 13:46:00 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Fri, 02 Jan 2015 13:29:45 +0000
 dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Jeez I feel old.


 then you'd better don't know how old i am...


=20
 There I was trying to excuse you for being full of youthful zeal=20
 and you go and spoil it by admitting you're a curmudgeonly old=20
 cnut.


i can't remember where i was asking for your excuses.



 Jan 02 2015



  parent  "dajones" <dajones sharklasers.com>  writes:


On Saturday, 3 January 2015 at 02:22:32 UTC, ketmar via 
Digitalmars-d wrote:

 On Fri, 02 Jan 2015 16:35:15 +0000
 dajones via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Friday, 2 January 2015 at 13:46:00 UTC, ketmar via 
 Digitalmars-d wrote:

 On Fri, 02 Jan 2015 13:29:45 +0000
 dajones via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 Jeez I feel old.


 then you'd better don't know how old i am...


 
 There I was trying to excuse you for being full of youthful 
 zeal and you go and spoil it by admitting you're a 
 curmudgeonly old cnut.


 i can't remember where i was asking for your excuses.


Aww you sound a bit grumpy, is everything ok? Been grounded for 
not cleaning your room?



 Jan 03 2015



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/1/15 4:55 AM, Gary Willoughby wrote:

 The vast majority of users of D will *never* contribute anything *ever*
 but they will (from time to time) ask for something. Just deal with it.
 Add it to an issue tracker and triage. Users should be put first in all
 cases, period!


I agree. But please, all, let's take the heat out of it. Surely these 
are things in which reasonable people may disagree. -- Andrei



 Jan 02 2015



prev sibling  parent  "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net>  writes:


On Monday, 29 December 2014 at 14:45:37 UTC, Dicebot wrote:

 Wasting effort of core contributors on a toolchain I will
 never use is against my interests and makes me naturally
 hostile about it.


I don't think it needs to be a zero-sum game.  Removing blockers 
to entry can make an orders-of-magnitude difference in the number 
of users for a particular platform, and when you gain users, you 
gain developers.  Paying now to remove basic usability issues 
could well free up a lot of core contributor time in future, by 
opening a door for Windows devs that makes it worth their while 
to invest effort into the language and its toolchain.



 Dec 29 2014



prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 19 December 2014 at 18:56, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/17/2014 12:30 AM, Manu via Digitalmars-d wrote:

 If vibe.d didn't crash, *or* if the debugger actually worked (such
 that we could have debugged the crash), then we would have surely
 stuck with that.
 But we couldn't get behind a solution that was impossible to debug.



 I've debugged a lot of D code with no debugger at all (how else could I port
 it to various platforms like Win64?).

 I've actually not found debuggers to be of much use other than telling me
 where the seg fault was and giving a stack trace.


Perhaps this is habit, retained from a time where the tooling was
unreliable? You probably haven't spent the majority of your career in
an environment where you could reliably rely on them, and then as a
result, never came to rely on them?
Debuggers are for quickly verifying code flows as expected, and
inspecting the broader state at a point of failure. Stepping through
code and watching as it goes, quickly and easily validating that all
the variables are in their appropriate states, etc, is invaluable.

Surely you can't argue that halting at point of crash, then
immediately being able to comprehensively inspect the surrounding
context, identifying things that were outside of the expected state,
etc, is going to be faster and easier than crashing, making some
guesses as to what the problem may have been, inserting a bunch of
logs to print out the values of stuff (rather than just inspecting
them in-situ), and running again, hoping that the crash is reliably
reproducible, and that you instrumented the right stuff.

It might be too that realtime software devs come to rely on debuggers
more than others?
Execution is completely non-deterministic. Bugs are often not reliably
reproducible, tend not to manifest in the same places at the same
times. It could be too that leading the program into the state where
the crash occurs takes a great deal of time, such that killing the
program, adding logs, hoping you catch the right stuff, then spending
the time to run around and try and invoke the bug again burns a lot
more time than actually finding and fixing it.

It's also a very common issue that the problem details that you need
to inspect are of a very high frequency nature. Logging may produce
100,000 lines of output per frame. This will interfere with the
framerate, and there are many forms of bugs that are temporally
invoked. Running at low framerate may cause the bug to disappear...
Perhaps you suggest filtering the output, or triggering it at certain
times... but how do you know what parameters to base that on? You
could spend hours just trying to understand in what situation a bug
manifests such that you are able to instrument the build to produce
the information you need.

I would never work professionally in an environment without a quality
debugger. I'm not unique.



 Dec 19 2014



  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-12-20 08:46, Manu via Digitalmars-d wrote:


 Perhaps this is habit, retained from a time where the tooling was
 unreliable? You probably haven't spent the majority of your career in
 an environment where you could reliably rely on them, and then as a
 result, never came to rely on them?


I have tried debugging DMD using Xcode. Very often when I inspect 
variables the debugger thinks they're null when they're not. Quite often 
I don't have access to all variables I thought I would have access to.

I don't know if it's something special about the DMD code base, I have 
always thought of it as quite simple, no templates or use of the C++ 
standard library. Perhaps the Visual Studio debugger would work better.

But when it do work it can be very handy.

At work I have used a debugger, although this is for Ruby, which is a 
lot more reliable and a real pleasure to use. I can navigate inside 
objects, inspect their private state, call private methods and other 
more fancy stuff. Very handy.

-- 
/Jacob Carlborg



 Dec 20 2014



prev sibling  parent  "Dicebot" <public dicebot.lv>  writes:


On Friday, 19 December 2014 at 10:47:28 UTC, Sergei Nosov wrote:

 I think the most valuable point Manu made is that there are 
 "excellent" and "good" programmers. The difference is not so 
 much in the actual skills, but in the willing to spend time on 
 programming.


I would avoid calling those groups "good" and "excellent". This 
sounds dangerously elitist with no actual data to back it up - it 
is not uncommon to find better programmers in group you call 
"good" then some of those you call "excellent".

Calling them "not nerds" and "nerds" is better way to get 
straight to the fundamentals :) And yes, I believe currently any 
effective usage of D requires at least one nerd in a team to act 
as a proxy for the rest.



 Dec 20 2014



prev sibling  parent reply "bioinfornatics" <bioinfornatics fedoraproject.org>  writes:


On Monday, 15 December 2014 at 01:30:00 UTC, Dicebot wrote:

 On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
 Digitalmars-d wrote:

 We were trying to use vibe.d, and we encountered bugs.

 We were unable to build Win64 code ...


 Here is exactly your problem - trying to do a web development 
 on Windows :P Really I have never understood that 
 counter-productive obsession with a habit that makes people 
 differentiate development environments and production 
 environments so much. You aren't going to use Windows servers, 
 are you?


Completely, I agree with dicebot.

For a webserver usually is a Linux for many reason not a windows.
Guy who want to use a windows as server :
case 1 is a noob
case 2 is a specifics needs

Even microsoft use some linux server for his resources.

So to me the problem of D that is the waste of energy.
D exist since 1999, if we look behind, what is done?
We have :
- a huge cimetery of project
- no D killer application
- miss the goal what to do to improve D experience
- each new D release your application is broken and often with
some D compiler bugs
With around 15 years of works we are at same state as the
beginning.
What to de:
   - Stop to add new feature in D (new annotation or whatever is
not an urgent needs)
   - Get a compiler and a language stable
   - When this is done work on some free (libre) framework in some
specific fields
      * grid computing (sub-field: data-computing)
      * web-server
      * graphics conputing (sub-field: gui )
And not more, not to disperse …

But after ) years in D i start to doubt …



 Dec 18 2014



  parent  "Nemanja Boric" <4burgos gmail.com>  writes:


On Thursday, 18 December 2014 at 09:12:54 UTC, bioinfornatics 
wrote:

 Completely, I agree with dicebot.

 For a webserver usually is a Linux for many reason not a 
 windows.
 Guy who want to use a windows as server :
 case 1 is a noob
 case 2 is a specifics needs


http://meta.stackexchange.com/questions/10369/which-tools-and-technologies-are-used-to-build-the-stack-exchange-network



 Dec 18 2014



prev sibling next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:

 The real trouble hit when vibe.d's WebSocket support didn't work as
 advertised; it crashed in various circumstances, and debugging was
 impossible.


Please file that one https://github.com/rejectedsoftware/vibe.d/issues.
What browser did you use?



 Dec 14 2014



  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 15 December 2014 at 14:46, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:

 The real trouble hit when vibe.d's WebSocket support didn't work as
 advertised; it crashed in various circumstances, and debugging was
 impossible.



 Please file that one https://github.com/rejectedsoftware/vibe.d/issues.
 What browser did you use?


Native Client, PNaCL build, under Chrome, Windows.
WebSockets lock up randomly, data stream hangs.

We also have a problem with a super-basic server where the first file
after booting the server seems to fail, page fails to load, refreshing
hangs chrome. Kill Chrome in task manager, restart, reload the page,
and it usually works fine thereafter.

We're also using a lot of range GET's, those seemed to be a bit
fragile. I'm not sure why.



 Dec 17 2014



prev sibling next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:

 Sadly, I failed to create a new commercial D user this week, and I'm
 really disappointed.
 It was rejected for exactly the same practical reasons I've been saying
forever.


Doesn't surprise me too much to be honest. We aren't there yet and I'm 
always a bit uneasy when someone runs around advertising D to 
professional users.



 Dec 14 2014



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 15 December 2014 at 14:51, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:

 Sadly, I failed to create a new commercial D user this week, and I'm
 really disappointed.
 It was rejected for exactly the same practical reasons I've been saying
 forever.



 Doesn't surprise me too much to be honest. We aren't there yet and I'm
 always a bit uneasy when someone runs around advertising D to professional
 users.


Well... when? I've been here 6 years. When can I start to use D for my work?
Other languages seem to have a higher velocity. Are we fighting a losing battle?



 Dec 17 2014



  parent reply Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:

 Well... when? I've been here 6 years. When can I start to use D for my work?
 Other languages seem to have a higher velocity. Are we fighting a losing
battle?


Other languages do much less than D which is a full-blown C++ replacement.
We've made huge progress in the past few years, look at the number of 
bugfixes and enhancements http://dlang.org/changelog.html and we 
introduced or finished several language features, that make D even more 
powerful (e.g. UFCS, UDA, alias this...). Still only very few people 
actually work on the compiler and we're also pretty bad in coordinating 
contributions.



 Dec 20 2014



 next sibling parent  Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 12/20/2014 06:12 PM, Martin Nowak wrote:

 On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:
 Other languages do much less than D which is a full-blown C++ replacement.
 We've made huge progress in the past few years


Most important, we started to grow an ecosystem.
http://code.dlang.org/



 Dec 20 2014



prev sibling next sibling parent  "Joakim" <dlang joakim.fea.st>  writes:


On Saturday, 20 December 2014 at 17:13:04 UTC, Martin Nowak wrote:

 On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:

 Well... when? I've been here 6 years. When can I start to use 
 D for my work?
 Other languages seem to have a higher velocity. Are we 
 fighting a losing battle?


 Other languages do much less than D which is a full-blown C++ 
 replacement.
 We've made huge progress in the past few years, look at the 
 number of bugfixes and enhancements 
 http://dlang.org/changelog.html and we introduced or finished 
 several language features, that make D even more powerful (e.g. 
 UFCS, UDA, alias this...). Still only very few people actually 
 work on the compiler and we're also pretty bad in coordinating 
 contributions.


One move that might work is providing help to those who want to 
get started on compiler hacking, by letting them know who those 
knowledgeable about dmd are and providing a venue for them to ask 
questions when getting started, ie some sort of mentoring into 
dmd hacking.  It's a bit alarming how few people dominate dmd 
development, especially compared to phobos:

https://github.com/D-Programming-Language/dmd/graphs/contributors

The dmd project needs to do a better job of growing more 
contributors, this is one good way to do it.  The alternative is 
to just let people jump in and sink or swim on their own, which 
might be a good filter to weed out the truly committed and 
capable from the rest, but also risks losing those who are 
capable but need some initial guidance.

For example, there could be a note on the README that says you 
should contact Kenji, Walter, Dan, or Martin if you need some 
help getting started with contributing to dmd, along with contact 
info (I assume Don and Brad might not be as interested).  You may 
say that all those people are reachable now, but without explicit 
permission like that, some people get intimidated about bothering 
someone like Walter.

Another suggestion is to actually write some docs for dmd, 
perhaps starting with frontend source layout and organization, 
similar to the brief list for the backend:

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

Of course, writing docs is always a tall order, but if it leads 
to more contributors, it can pay off in spades.



 Dec 20 2014



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 21 December 2014 at 03:12, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/17/2014 09:45 AM, Manu via Digitalmars-d wrote:

 Well... when? I've been here 6 years. When can I start to use D for my
 work?
 Other languages seem to have a higher velocity. Are we fighting a losing
 battle?



 Other languages do much less than D which is a full-blown C++ replacement.
 We've made huge progress in the past few years, look at the number of
 bugfixes and enhancements http://dlang.org/changelog.html and we introduced
 or finished several language features, that make D even more powerful (e.g.
 UFCS, UDA, alias this...). Still only very few people actually work on the
 compiler and we're also pretty bad in coordinating contributions.


I totally appreciate all this. My feeling today is that the language
is more-or-less fine. Sure there are a few areas of development where
I have an interest or some stake in, but at this point, I've come to
consider all further language development to have a significantly
lower importance than the overall experience as presented to users.
Tooling and ecosystem is the biggest hurdle to launch D to "a million
users" right now.

Where is libdlang? We need to have the front-end proper available as a
library for parsing/syntax hilighting/refactoring, etc. People are
frequently re-inventing d language parsers, and they're getting
better... but they only work properly 'most of the time'. The work
distracts from the actual goal of those projects though, which is to
provide quality tooling inside IDE's.
There should be a standard go-to for performing this work, and common
sense suggests that it would share code with the frontend. libclang
exists, and everyone's using it these days with great results.

I would make libdlang top priority. Or perhaps one notch below the
ongoing GC related work.
I strongly feel it should be owned by the compiler team though, since
they are the ones that know how to parse the language correctly, and
already maintain the most comprehensive code for parsing D that we
have; DMD.



 Dec 25 2014



prev sibling next sibling parent reply "Kagamin" <spam here.lot>  writes:


On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
Digitalmars-d wrote:

 They then made HUGE noises about the quality of documentation. 
 The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The formatting
 didn't help, there's a lot of noise and a lack of structure in 
 the
 documentation's presentation that makes it hard to see the 
 information
 through the layout and noise. As senior software engineers, they
 basically expected that they should be able to read and 
 understand the
 docs, even if they don't really know the language, after all, 
 "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a 
 basic
 level by skimming the docs, but the D docs are an anomaly in 
 this way;
 it seems you have to already know D to be able to understand it
 effectively. They didn't know javascript either, but skimming 
 the
 node.js docs they got the job done in an hour or so, after 
 having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.


Comparing node.js to D? You probably speak about vibe, not D?


 One of the take-away quotes I think, was "D seems to be a 
 language for
 people who actively want to go and look for it, and take the 
 time to
 learn it. That's never going to be a commercial success."


O_O Huh? Your team really didn't learn C++?



 Dec 15 2014



  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 16 December 2014 at 00:04, Kagamin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:

 They then made HUGE noises about the quality of documentation. The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The formatting
 didn't help, there's a lot of noise and a lack of structure in the
 documentation's presentation that makes it hard to see the information
 through the layout and noise. As senior software engineers, they
 basically expected that they should be able to read and understand the
 docs, even if they don't really know the language, after all, "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a basic
 level by skimming the docs, but the D docs are an anomaly in this way;
 it seems you have to already know D to be able to understand it
 effectively. They didn't know javascript either, but skimming the
 node.js docs they got the job done in an hour or so, after having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.



 Comparing node.js to D? You probably speak about vibe, not D?


The majority of hours spent were not really related to vibe.d so much
as trying to wrangle the tooling, debugging crashes, and understand
the docs to get some very basic things done.
These are 'D' experience if you ask me.



 One of the take-away quotes I think, was "D seems to be a language for
 people who actively want to go and look for it, and take the time to
 learn it. That's never going to be a commercial success."



 O_O Huh? Your team really didn't learn C++?


We didn't 'learn' javascript, or python, or html, or whatever else you
pick up on the job.
The investment in learning 'programming' is decades behind us, and I
think it's a reasonable expectation that a language present itself in
such a way that it's intuitive and easy to get some basic things
going.
Leveraging small example snippets from the docs, etc. D is very easy
for a C/C++ programmer, but the docs don't make it appear that way,
and they give the wrong impression.
The overpowering presence of templates in the docs give a first
impression that reminds people of everything that's wrong with C++,
which I suspect most C++ programmers looking into D are actively
trying to escape!

There simply can't be friction on step 1! There can be friction on
step 4 or 5 when you've already made some minor achievements, and have
a good few hours invested.
Any friction on step 1 or 2 will lead to an almost immediate rejection.



 Dec 17 2014



 next sibling parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


 We didn't 'learn' javascript, or python, or html, or whatever 
 else you
 pick up on the job.
 The investment in learning 'programming' is decades behind us, 
 and I
 think it's a reasonable expectation that a language present 
 itself in
 such a way that it's intuitive and easy to get some basic things
 going.
 Leveraging small example snippets from the docs, etc. D is very 
 easy
 for a C/C++ programmer, but the docs don't make it appear that 
 way,
 and they give the wrong impression.
 The overpowering presence of templates in the docs give a first
 impression that reminds people of everything that's wrong with 
 C++,
 which I suspect most C++ programmers looking into D are actively
 trying to escape!

 There simply can't be friction on step 1! There can be friction 
 on
 step 4 or 5 when you've already made some minor achievements, 
 and have
 a good few hours invested.
 Any friction on step 1 or 2 will lead to an almost immediate 
 rejection.


I second this. I remember very well that the docs really annoyed 
me
when I was starting with D. Sadly I can't see the issues I had
any more, because I'm used to it now, so it's kind of hard to
improve in a meaningful way.

But two things come to mind. The first is that the language 
documentation actually is a very dense language specification. If 
you look at the rust documentation you'll find a ‘Guide’ and a 
‘Reference’. We need such a tutorial as well. Just linking to 
some books is not enough.

Second thing is template arguments and constraints. For example 
std.container.Array has a specialization for bool. That looks 
like this in the docs:

std.container.Array(T) if(is(Unqual!T == bool)) vs.
std.container.Array(T) if(!is(Unqual!T == bool)).

That's super unhelpful for newcomers. The difference is hard to 
spot, newcomer don't know what a qualified or unqualified type is 
and they won't recognize the is-expression.

I think the documentation should call those to overloads Array!T 
and Array!bool.



 Dec 17 2014



 next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Wed, 17 Dec 2014 09:48:26 +0000
Tobias Pankrath via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 std.container.Array(T) if(is(Unqual!T =3D=3D bool)) vs.
 std.container.Array(T) if(!is(Unqual!T =3D=3D bool)).
=20
 That's super unhelpful for newcomers.


that's why newcomers should NOT try to learn the language using
reference documentation for standard library.

when i started to learn D, i found and read Andrei's book, Ali's book
and Philippe's "template tutorial". and i never complained that phobos
reference documentation is "hostile to beginners" -- 'cause it's NOT
for beginners. you are expected to learn the language before reading
reference dox.

yet i agree that formatting can be better. but as i tend to produce
completely unreadable mess when i trying to fix any formatting, i
didn't do anything in that direction.



 Dec 17 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 17 December 2014 at 10:33:34 UTC, ketmar via 
Digitalmars-d wrote:

 when i started to learn D, i found and read Andrei's book, 
 Ali's book
 and Philippe's "template tutorial". and i never complained that 
 phobos
 reference documentation is "hostile to beginners" -- 'cause 
 it's NOT
 for beginners. you are expected to learn the language before 
 reading
 reference dox


I wonder how much of a loss it would be to Andrei to publish TDPL 
for free on dlang.org and link it from a front page as newcomer 
starting point. I don't know if there are still many people who 
buy it though.



 Dec 17 2014



  parent  Andre Kostur <andre kostur.net>  writes:


On 2014-12-17, 2:41 AM, Dicebot wrote:

 On Wednesday, 17 December 2014 at 10:33:34 UTC, ketmar via Digitalmars-d
 wrote:

 when i started to learn D, i found and read Andrei's book, Ali's book
 and Philippe's "template tutorial". and i never complained that phobos
 reference documentation is "hostile to beginners" -- 'cause it's NOT
 for beginners. you are expected to learn the language before reading
 reference dox


 I wonder how much of a loss it would be to Andrei to publish TDPL for
 free on dlang.org and link it from a front page as newcomer starting
 point. I don't know if there are still many people who buy it though.


I bought my copy just under 1 year ago (2 copies really, print + kindle).



 Dec 17 2014



prev sibling  parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


On Wednesday, 17 December 2014 at 10:33:34 UTC, ketmar via 
Digitalmars-d wrote:

 On Wed, 17 Dec 2014 09:48:26 +0000
 Tobias Pankrath via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 std.container.Array(T) if(is(Unqual!T == bool)) vs.
 std.container.Array(T) if(!is(Unqual!T == bool)).
 
 That's super unhelpful for newcomers.


 that's why newcomers should NOT try to learn the language using
 reference documentation for standard library.

 when i started to learn D, i found and read Andrei's book, 
 Ali's book
 and Philippe's "template tutorial". and i never complained that 
 phobos
 reference documentation is "hostile to beginners" -- 'cause 
 it's NOT
 for beginners. you are expected to learn the language before 
 reading
 reference dox.

 yet i agree that formatting can be better. but as i tend to 
 produce
 completely unreadable mess when i trying to fix any formatting, 
 i
 didn't do anything in that direction.


I don't think we should require newcomers to understand the 
is-expression (Even now I have to look it up now and then) and 
notion of a qualified type and to look of what that Unqual(T) 
template actually is, just to understand the documentation of an 
simple container, something that many newcomers will use to write 
small programs while learning the language.

Learning the language and programming in the language are not two 
different stages.



 Dec 17 2014



  parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Wed, 17 Dec 2014 10:49:19 +0000
Tobias Pankrath via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Wednesday, 17 December 2014 at 10:33:34 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Wed, 17 Dec 2014 09:48:26 +0000
 Tobias Pankrath via Digitalmars-d <digitalmars-d puremagic.com>=20
 wrote:


 std.container.Array(T) if(is(Unqual!T =3D=3D bool)) vs.
 std.container.Array(T) if(!is(Unqual!T =3D=3D bool)).
=20
 That's super unhelpful for newcomers.


 that's why newcomers should NOT try to learn the language using
 reference documentation for standard library.

 when i started to learn D, i found and read Andrei's book,=20
 Ali's book
 and Philippe's "template tutorial". and i never complained that=20
 phobos
 reference documentation is "hostile to beginners" -- 'cause=20
 it's NOT
 for beginners. you are expected to learn the language before=20
 reading
 reference dox.

 yet i agree that formatting can be better. but as i tend to=20
 produce
 completely unreadable mess when i trying to fix any formatting,=20
 i
 didn't do anything in that direction.


=20
 I don't think we should require newcomers to understand the=20
 is-expression (Even now I have to look it up now and then) and=20
 notion of a qualified type and to look of what that Unqual(T)=20
 template actually is, just to understand the documentation of an=20
 simple container, something that many newcomers will use to write=20
 small programs while learning the language.


that is exactly why i'm telling that reference documentation is not for
beginners at all. it has some sample code, but you are expected to
understant the language first.

what we really need is more "intermediate level" books that will teach
people how to "think functionally" and use various Phobos modules.
something like Adam's cookbook, maybe, but dedicated to Phobos, and
promoting "everything is a range" style of thinking. ;-)

reference documentation can never be such book, 'cause it will be
unusable as *reference* in that case.



 Dec 17 2014



prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 17 December 2014 at 20:33, ketmar via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wed, 17 Dec 2014 09:48:26 +0000
 Tobias Pankrath via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 std.container.Array(T) if(is(Unqual!T == bool)) vs.
 std.container.Array(T) if(!is(Unqual!T == bool)).

 That's super unhelpful for newcomers.


 that's why newcomers should NOT try to learn the language using
 reference documentation for standard library.

 when i started to learn D, i found and read Andrei's book, Ali's book
 and Philippe's "template tutorial". and i never complained that phobos
 reference documentation is "hostile to beginners" -- 'cause it's NOT
 for beginners. you are expected to learn the language before reading
 reference dox.


I couldn't disagree more. People aren't allocated work time to read books.
Books are for students or language enthusiasts who want to learn about
programming in their home time. That doesn't apply to most
professional programmers I've ever worked with.
Most people just want to go home to their wives and kids.

Docs need to have examples which are plain and obvious, and the
language will be absorbed by osmosis.



 Dec 18 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 18 December 2014 at 10:24:46 UTC, Manu via 
Digitalmars-d wrote:

 People aren't allocated work time to read books.


Wait, really? X_X The more you tell about game dev culture and 
your work experience there the more I feel sorry for people who 
work there.



 Dec 18 2014



  parent  Rikki Cattermole <alphaglosined gmail.com>  writes:


On 19/12/2014 12:23 a.m., Dicebot wrote:

 On Thursday, 18 December 2014 at 10:24:46 UTC, Manu via Digitalmars-d
 wrote:

 People aren't allocated work time to read books.


 Wait, really? X_X The more you tell about game dev culture and your work
 experience there the more I feel sorry for people who work there.


I know of atleast one company in New Zealand who do major game 
development work whose managers(are programmers) believe that being able 
to use a professional game engine to make a game is more important in 
fact expected over knowing the basics of OpenGL.
Yes it gets work done. But when things go wrong.. You can't exactly drop 
down to the low level and fix things yourself.

I'm fascinated and love the graphical world. Absolutely would not want 
to work in it.



 Dec 18 2014



prev sibling next sibling parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Thursday, 18 December 2014 at 10:24:46 UTC, Manu via 
Digitalmars-d wrote:

 On 17 December 2014 at 20:33, ketmar via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Wed, 17 Dec 2014 09:48:26 +0000
 Tobias Pankrath via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:


 std.container.Array(T) if(is(Unqual!T == bool)) vs.
 std.container.Array(T) if(!is(Unqual!T == bool)).

 That's super unhelpful for newcomers.


 that's why newcomers should NOT try to learn the language using
 reference documentation for standard library.

 when i started to learn D, i found and read Andrei's book, 
 Ali's book
 and Philippe's "template tutorial". and i never complained 
 that phobos
 reference documentation is "hostile to beginners" -- 'cause 
 it's NOT
 for beginners. you are expected to learn the language before 
 reading
 reference dox.


 People aren't allocated work time to read books.


That sucks. It's not universally true though: I have friends in 
finance and in scientific programming who are allowed to spend 
work time reading books, testing out new ideas, exploring new 
techniques and the background behind them. One guy even has 1 
(paid) day off a fortnight to go to universities and meet with 
academics to discuss techniques and work on problems.



 Dec 18 2014



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 Docs need to have examples which are plain and obvious, and the
 language will be absorbed by osmosis.


I agree. Can you point to specific cases that need an example?



 Dec 19 2014



  parent reply "Kiith-Sa" <kiithsacmp gmail.com>  writes:


On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 Docs need to have examples which are plain and obvious, and the
 language will be absorbed by osmosis.


 I agree. Can you point to specific cases that need an example?


If it doesn't have an example, it needs an example, no matter how 
trivial it is. That's a good place to start. Of course, then 
there are lazy examples that don't really help in real use. These 
need to be identified and rewritten.



 Dec 19 2014



  parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


On Friday, 19 December 2014 at 12:44:26 UTC, Kiith-Sa wrote:

 On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright 
 wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 Docs need to have examples which are plain and obvious, and 
 the
 language will be absorbed by osmosis.


 I agree. Can you point to specific cases that need an example?


 If it doesn't have an example, it needs an example, no matter 
 how trivial it is. That's a good place to start. Of course, 
 then there are lazy examples that don't really help in real 
 use. These need to be identified and rewritten.


• If you look up how to do $x in the documentation and it is 
takes you time to figure that out, consider to add an example for 
$x to the documentation.

• If you answer/ask a question in D.learn on how to do $x, 
consider to add an example for $x to the documentation.

This way we should build up exactly those examples that are 
useful.



 Dec 19 2014



 next sibling parent  "uri" <uri.grill gmail.com>  writes:


On Friday, 19 December 2014 at 12:53:32 UTC, Tobias Pankrath 
wrote:

 On Friday, 19 December 2014 at 12:44:26 UTC, Kiith-Sa wrote:

 On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright 
 wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 Docs need to have examples which are plain and obvious, and 
 the
 language will be absorbed by osmosis.


 I agree. Can you point to specific cases that need an example?


 If it doesn't have an example, it needs an example, no matter 
 how trivial it is. That's a good place to start. Of course, 
 then there are lazy examples that don't really help in real 
 use. These need to be identified and rewritten.


 • If you look up how to do $x in the documentation and it is 
 takes you time to figure that out, consider to add an example 
 for $x to the documentation.

 • If you answer/ask a question in D.learn on how to do $x, 
 consider to add an example for $x to the documentation.

 This way we should build up exactly those examples that are 
 useful.


+1

No different to adding unit tests where possible for each 
reported bug.



 Dec 19 2014



prev sibling  parent  "Kiith-Sa" <kiithsacmp gmail.com>  writes:


On Friday, 19 December 2014 at 12:53:32 UTC, Tobias Pankrath 
wrote:

 On Friday, 19 December 2014 at 12:44:26 UTC, Kiith-Sa wrote:

 On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright 
 wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 Docs need to have examples which are plain and obvious, and 
 the
 language will be absorbed by osmosis.


 I agree. Can you point to specific cases that need an example?


 If it doesn't have an example, it needs an example, no matter 
 how trivial it is. That's a good place to start. Of course, 
 then there are lazy examples that don't really help in real 
 use. These need to be identified and rewritten.


 • If you look up how to do $x in the documentation and it is 
 takes you time to figure that out, consider to add an example 
 for $x to the documentation.

 • If you answer/ask a question in D.learn on how to do $x, 
 consider to add an example for $x to the documentation.

 This way we should build up exactly those examples that are 
 useful.


Turned into an issue (not really a traditional issue since it's 
never "solved", but to hopefully remind people). Also mentioned 
in the wiki(Get involved):

https://issues.dlang.org/show_bug.cgi?id=13876
http://wiki.dlang.org/Get_involved



 Dec 19 2014



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 People aren't allocated work time to read books.


This can't be generally true. Most people who attend programming conferences, 
for example, are attending on their employer's dime.



 Dec 19 2014



 next sibling parent reply "Wyatt" <wyatt.epp gmail.com>  writes:


On Friday, 19 December 2014 at 09:15:18 UTC, Walter Bright wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 People aren't allocated work time to read books.


 This can't be generally true. Most people who attend 
 programming conferences, for example, are attending on their 
 employer's dime.


Are you _quite_ sure about that?  Because all my experience 
agrees with Manu.  If any of us (I think we have about 400 
developers here?) have need of a book, we're skimming it and 
cherry-picking the important bits to what needs done _right now_. 
  This is part of why I really appreciate that Andrei had a proper 
index written for TDPL; it makes it fit into "real world" 
workflows (as I know them) much better.

The class of people who attend programming conferences is an 
extreme minority of our field.  They're about as representative 
of our industry as you believe the posters on these newsgroups 
are of the D userbase.

-Wyatt



 Dec 19 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Friday, 19 December 2014 at 13:33:08 UTC, Wyatt wrote:

 On Friday, 19 December 2014 at 09:15:18 UTC, Walter Bright 
 wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 People aren't allocated work time to read books.


 This can't be generally true. Most people who attend 
 programming conferences, for example, are attending on their 
 employer's dime.


 Are you _quite_ sure about that?  Because all my experience 
 agrees with Manu.  If any of us (I think we have about 400 
 developers here?) have need of a book, we're skimming it and 
 cherry-picking the important bits to what needs done _right 
 now_.
  This is part of why I really appreciate that Andrei had a 
 proper index written for TDPL; it makes it fit into "real 
 world" workflows (as I know them) much better.

 The class of people who attend programming conferences is an 
 extreme minority of our field.  They're about as representative 
 of our industry as you believe the posters on these newsgroups 
 are of the D userbase.


New D developers at Sociomantic are given "Learn Tango with D" 
book and time to investigate it in details before starting any 
real work. Job I had before was crappy enterprise mess but there 
still was time reserved for books in a developer schedule. I'd 
expect it from any half-decent job.



 Dec 19 2014



  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 19 December 2014 at 23:45, Dicebot via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 19 December 2014 at 13:33:08 UTC, Wyatt wrote:

 On Friday, 19 December 2014 at 09:15:18 UTC, Walter Bright wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 People aren't allocated work time to read books.



 This can't be generally true. Most people who attend programming
 conferences, for example, are attending on their employer's dime.



 Are you _quite_ sure about that?  Because all my experience agrees with
 Manu.  If any of us (I think we have about 400 developers here?) have need
 of a book, we're skimming it and cherry-picking the important bits to what
 needs done _right now_.
  This is part of why I really appreciate that Andrei had a proper index
 written for TDPL; it makes it fit into "real world" workflows (as I know
 them) much better.

 The class of people who attend programming conferences is an extreme
 minority of our field.  They're about as representative of our industry as
 you believe the posters on these newsgroups are of the D userbase.



 New D developers at Sociomantic are given "Learn Tango with D" book and time
 to investigate it in details before starting any real work. Job I had before
 was crappy enterprise mess but there still was time reserved for books in a
 developer schedule. I'd expect it from any half-decent job.


Sociomantic is obviously already married to D. You're in such a tiny
niche it's crazy, it's no wonder they find it necessary to give
training material to new starts.
I challenge you to convince management to give the new starts a
Haskell book instead, and also have a talk about how Haskell is really
cool, it's the way of the future, we should look into switching some
time! That's where the rest of us are at by comparison.

Are you also arguing that's a reasonable expectation for any 'half decent job'?
Well, apparently most of the world aren't entitled to 'half decent
jobs'. People have whatever jobs they can get.
For what it's worth, I enjoy working in games and realtime/embedded
software. I have never felt hard-done-by because I'm not awarded 10's
of hours to read books in my work time.



 Dec 25 2014



prev sibling  parent  Andre Kostur <andre kostur.net>  writes:


On 2014-12-19, 5:33 AM, Wyatt wrote:

 On Friday, 19 December 2014 at 09:15:18 UTC, Walter Bright wrote:



 The class of people who attend programming conferences is an extreme
 minority of our field.  They're about as representative of our industry
 as you believe the posters on these newsgroups are of the D userbase.


Yay, I'm in the minority!  My CEO was somewhat disappointed that I 
didn't ask to go to the most recent DConf, even though we so far have 
_no_ D development in house yet.  (I do get sent to C++ and Beyond...)



 Dec 19 2014



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 19 December 2014 at 19:15, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 People aren't allocated work time to read books.



 This can't be generally true. Most people who attend programming
 conferences, for example, are attending on their employer's dime.


In my experience, only a select few highly privileged developers tend
to have the opportunity to attend conferences, and such opportunities
may be years apart. I don't think that's the 'general' case.
The general case from my perspective, is people who go to work to get
paid to pay their bills and enjoy their lives in whatever way they
prefer to do that. They may or may not be good at their job, but the
point is about their life's priorities.

They're not necessarily 'bad' programmers; they may be perfectly
capable of learning any new material they require to do their job on
the fly... but if there's a significantly greater degree of friction
than they expect (a precedent defined by competitors which we have no
real control over), they will complain, and probably won't look again
in the future.
It takes a special kind of programmer who will continue to contribute
substantial time to their skillset in their own time after they have
already been reliably employed for a decent number of years.

Those people are already here. Andrei's 'million users' are not, and
those people are will largely be the people I describe, and most of
them will learn on the fly, while on the job.



 Dec 19 2014



prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Thu, 18 Dec 2014 20:24:36 +1000
Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On 17 December 2014 at 20:33, ketmar via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Wed, 17 Dec 2014 09:48:26 +0000
 Tobias Pankrath via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 std.container.Array(T) if(is(Unqual!T =3D=3D bool)) vs.
 std.container.Array(T) if(!is(Unqual!T =3D=3D bool)).

 That's super unhelpful for newcomers.


 that's why newcomers should NOT try to learn the language using
 reference documentation for standard library.

 when i started to learn D, i found and read Andrei's book, Ali's book
 and Philippe's "template tutorial". and i never complained that phobos
 reference documentation is "hostile to beginners" -- 'cause it's NOT
 for beginners. you are expected to learn the language before reading
 reference dox.


=20
 I couldn't disagree more. People aren't allocated work time to read books.
 Books are for students or language enthusiasts who want to learn about
 programming in their home time. That doesn't apply to most
 professional programmers I've ever worked with.


that's right: most "professional programmes" i've seen simply can't
program. i wouldn't allow them to wash my dishes.


 Most people just want to go home to their wives and kids.


that's why the whole software industry sux nowdays. if one doesn't like
his work he shouldn't do that work. simple as it is.

(just for info: i'm near my 40 and i still love to spend sleepless
nights writing interesting code or learning something new)


 Docs need to have examples which are plain and obvious, and the
 language will be absorbed by osmosis.


but phobos dox are exactly like this! i was never puzzled by phobos
documentation, and it has alot of samples which illustrates various
things. reader just expected to know D, it's template system and some
basic "idiomatic" things like ranges.



 Dec 18 2014



  parent reply "Ondra" <pokorny.ondrej gmail.com>  writes:


 Most people just want to go home to their wives and kids.


 that's why the whole software industry sux nowdays. if one 
 doesn't like
 his work he shouldn't do that work. simple as it is.


While in other industries it is different.


 (just for info: i'm near my 40 and i still love to spend 
 sleepless
 nights writing interesting code or learning something new)


 Docs need to have examples which are plain and obvious, and the
 language will be absorbed by osmosis.


 but phobos dox are exactly like this! i was never puzzled by 
 phobos
 documentation, and it has alot of samples which illustrates 
 various
 things. reader just expected to know D, it's template system 
 and some
 basic "idiomatic" things like ranges.


No. There are almost no examples on practical usage of packages. 
Have you tried to use e.g.: std.json from scratch with only 
reading documentation without googling forums for help how to 
actually use it? I am not clairvoyant so I really don't know what 
was author's intention on how to use this package. And there is 
zero information about it in docs. Same holds for other parts of 
docs.



 Dec 18 2014



 next sibling parent  "bioinfornatics" <bioinfornatics fedoraproject.org>  writes:


they are in same way mmfile module which is deprecated since many 
years, xml was in same case



 Dec 18 2014



prev sibling  parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Thu, 18 Dec 2014 10:54:22 +0000
Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 No. There are almost no examples on practical usage of packages.=20
 Have you tried to use e.g.: std.json from scratch with only=20
 reading documentation without googling forums for help how to=20
 actually use it?


yes. strange thing is that i had zero troubles with that. it's kind of
thing that "just works". and reference dox doing exactly what i want:
gives me names i need.

i can't see what can be so hard with simple recursive data structure
implementation.

the same for 'std.mmfile', by the way.



 Dec 18 2014



  parent reply "Ondra" <pokorny.ondrej gmail.com>  writes:


On Thursday, 18 December 2014 at 11:19:11 UTC, ketmar via 
Digitalmars-d wrote:

 On Thu, 18 Dec 2014 10:54:22 +0000
 Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 No. There are almost no examples on practical usage of 
 packages. Have you tried to use e.g.: std.json from scratch 
 with only reading documentation without googling forums for 
 help how to actually use it?


 yes. strange thing is that i had zero troubles with that. it's 
 kind of
 thing that "just works". and reference dox doing exactly what i 
 want:
 gives me names i need.


Strange is that you don't understand that beginner to D have 
different problems than guy who actively develop D 
library/language itself.


 i can't see what can be so hard with simple recursive data 
 structure
 implementation.
 the same for 'std.mmfile', by the way.


mmfile is way easier and simpler to use from scratch. And I agree 
on this with you, both docs pages are very brief.



 Dec 18 2014



  parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Thu, 18 Dec 2014 12:03:55 +0000
Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Thursday, 18 December 2014 at 11:19:11 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Thu, 18 Dec 2014 10:54:22 +0000
 Ondra via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 No. There are almost no examples on practical usage of=20
 packages. Have you tried to use e.g.: std.json from scratch=20
 with only reading documentation without googling forums for=20
 help how to actually use it?


 yes. strange thing is that i had zero troubles with that. it's=20
 kind of
 thing that "just works". and reference dox doing exactly what i=20
 want:
 gives me names i need.


=20
 Strange is that you don't understand that beginner to D have=20
 different problems than guy who actively develop D=20
 library/language itself.


how many times i have to say that phobos reference documentation is not
for beginners?

i agree that we need "Phobos Cookbook", and what i want to stress is
that trying to use phobos reference dox as such cookbook is doomed to
fail.



 Dec 18 2014



  parent  "Tobias Pankrath" <tobias pankrath.net>  writes:


 how many times i have to say that phobos reference 
 documentation is not
 for beginners?


Let us agree to disagree on that point.



 Dec 18 2014



prev sibling next sibling parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 18 December 2014 at 20:38, ketmar via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thu, 18 Dec 2014 20:24:36 +1000
 Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On 17 December 2014 at 20:33, ketmar via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Wed, 17 Dec 2014 09:48:26 +0000
 Tobias Pankrath via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 std.container.Array(T) if(is(Unqual!T == bool)) vs.
 std.container.Array(T) if(!is(Unqual!T == bool)).

 That's super unhelpful for newcomers.


 that's why newcomers should NOT try to learn the language using
 reference documentation for standard library.

 when i started to learn D, i found and read Andrei's book, Ali's book
 and Philippe's "template tutorial". and i never complained that phobos
 reference documentation is "hostile to beginners" -- 'cause it's NOT
 for beginners. you are expected to learn the language before reading
 reference dox.


 I couldn't disagree more. People aren't allocated work time to read books.
 Books are for students or language enthusiasts who want to learn about
 programming in their home time. That doesn't apply to most
 professional programmers I've ever worked with.


 that's right: most "professional programmes" i've seen simply can't
 program. i wouldn't allow them to wash my dishes.


This is even more offensive; suggesting that professional engineers
aren't entitled to lives?
'Excellent' programmers are fairly rare, and often come at the expense
of other pursuits in their lives.
You have to get work done with the resources available.



 Most people just want to go home to their wives and kids.


 that's why the whole software industry sux nowdays. if one doesn't like
 his work he shouldn't do that work. simple as it is.


I'm not sure how having a life outside of work implies not liking your work?



 (just for info: i'm near my 40 and i still love to spend sleepless
 nights writing interesting code or learning something new)


Good for you.



 Docs need to have examples which are plain and obvious, and the
 language will be absorbed by osmosis.


 but phobos dox are exactly like this! i was never puzzled by phobos
 documentation, and it has alot of samples which illustrates various
 things. reader just expected to know D, it's template system and some
 basic "idiomatic" things like ranges.


Congratulations, but my case study demonstrated otherwise.



 Dec 18 2014



prev sibling  parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Thu, 18 Dec 2014 21:15:25 +1000
Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 I couldn't disagree more. People aren't allocated work time to read bo=






oks.

 Books are for students or language enthusiasts who want to learn about
 programming in their home time. That doesn't apply to most
 professional programmers I've ever worked with.


 that's right: most "professional programmes" i've seen simply can't
 program. i wouldn't allow them to wash my dishes.


=20
 This is even more offensive; suggesting that professional engineers
 aren't entitled to lives?


i can't do anything with that: the facts i see the facts i'm speaking
of.


 'Excellent' programmers are fairly rare, and often come at the expense
 of other pursuits in their lives.


i'm not talking about "excellent" programmes, i'm talking about basic
CS knowledge. "why crc32 is bad hashing function?" "how to negate
machine integer without using unary minus operator?" "what is closure,
what is continuation and how they differ?" and so on. those are basic
questions, yet i was forced to add those to my interviews.


 You have to get work done with the resources available.


sometimes it's better to not start at all than trying to do something
with inappropriate/lack of resources.


 Most people just want to go home to their wives and kids.


 that's why the whole software industry sux nowdays. if one doesn't like
 his work he shouldn't do that work. simple as it is.


=20
 I'm not sure how having a life outside of work implies not liking your wo=


rk?
maybe i misunderstood you, but "most people just want to go home to
their wives and kids" for me looks like "i don't want to think about
ANYTHING related to my work after my work hours are done".


 Docs need to have examples which are plain and obvious, and the
 language will be absorbed by osmosis.


 but phobos dox are exactly like this! i was never puzzled by phobos
 documentation, and it has alot of samples which illustrates various
 things. reader just expected to know D, it's template system and some
 basic "idiomatic" things like ranges.


=20
 Congratulations, but my case study demonstrated otherwise.


did your mates really invested time to LEARN D? not in the form "ok, it
looks like C++, and i know C++, so it will be enough to spend a hour to
become D programmer", but really reading at least Philippe's "template
tutorial"? i bet i know the answer.



 Dec 18 2014



  parent reply "Atila Neves" <atila.neves gmail.com>  writes:


 i'm not talking about "excellent" programmes, i'm talking about 
 basic
 CS knowledge. "why crc32 is bad hashing function?" "how to 
 negate
 machine integer without using unary minus operator?" "what is 
 closure,
 what is continuation and how they differ?" and so on. those are 
 basic
 questions, yet i was forced to add those to my interviews.


I sincerely have no idea why you consider this to be basic 
knowledge. If we're talking C programmers, the vast majority 
won't know what a closure or a continuation is. Maybe the working 
environments you've been exposed to are drastically different 
from the ones I have. I've been interviewing a ton of candidates 
at work recently, and in my experience your expectations are way 
off.

People like us that even bother to learn D or be in this forum 
are not average programmers. I don't mean that in an elitist 
sense, I mean we're weird and expecting the rest of the world to 
be like us is, IMHO, silly.

I stay up at night watching programming conference videos. Nobody 
else where I work does. Oh, and this is coming from me, a person 
who was recently told had too high expectations of what basic C++ 
knowledge should be only weeks ago.

Atila



 Dec 20 2014



 next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 20 Dec 2014 20:29:34 +0000
Atila Neves via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 i'm not talking about "excellent" programmes, i'm talking about=20
 basic
 CS knowledge. "why crc32 is bad hashing function?" "how to=20
 negate
 machine integer without using unary minus operator?" "what is=20
 closure,
 what is continuation and how they differ?" and so on. those are=20
 basic
 questions, yet i was forced to add those to my interviews.


=20
 I sincerely have no idea why you consider this to be basic=20
 knowledge. If we're talking C programmers, the vast majority=20
 won't know what a closure or a continuation is.


so they aren't programmers, they are coders. cheap expendable resource.
yet they somehow believe that they are programmers and wants
programmers' salary. but we aren't rich enough to hire coders as
programmers.


 People like us that even bother to learn D or be in this forum=20
 are not average programmers. I don't mean that in an elitist=20
 sense, I mean we're weird and expecting the rest of the world to=20
 be like us is, IMHO, silly.


yes, there is nothing elitist in knowing the basics. and there is
nothing bad in not knowing the basics too... unless that person doesn't
pretend to know the things. we have some tasks for coders too.



 Dec 20 2014



prev sibling  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 19 December 2014 at 19:12, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:

 Docs need to have examples which are plain and obvious, and the
 language will be absorbed by osmosis.



 I agree. Can you point to specific cases that need an example?


In this case, my colleague felt it was hard to understand the string
functions, but he got through it (after sending me txt messages to ask
questions).
I recall making the same comments when I first started trying to do
string manipulation in D. My personal take is, string functions are
all templates, which makes them look more complex than they are, and
for me, it was really hard to understand where to look for certain
functions; they're spread fairly evenly across 5 or so different
modules. Algorithm, range, ascii, uni, utf. Some of the most important
functions are in range and algorithm. Perhaps those that are fairly
string specific from range/algorithm should have aliases in
std.string, or std.string might public import some of the minor
modules, like ascii/uni/utf?

Like I said in the first post, documentation wasn't a deal breaker,
but it was the source of the most commentary. I think it's an area for
general improvement, and I would start by reconsidering the basic
formatting for reducing noise and improving clarity of the simple
details, while the advances and less important details (like
contracts) may fade into the background a little.

I think a good goal is:
At a glance, the function reference that stands out is the name,
summary, and what arguments it accepts. The next thing is the detail
for each argument and return value.
Template args, which throughout phobos are rarely of any 'functional'
relevance, need to be toned down so they don't interfere with your
initial glance to understand the function and what it does.
Most of the time the template args are just some 'T', allowing the
function to work with multiple types - particular on strings and
algorithms. This is not particularly interesting information, and it
shouldn't distract from the important details.

Occasionally, there is a template arg that IS a relevant part of the
API... I'm not sure how this should be highlighted. Perhaps a subtle
visual distinction could be made for template args like 'T' which are
just used in the runtime arg list, and template args that don't appear
anywhere else, ie, they supply important function arguments. I think
there's probably room for some clever design in that space.

Finally, contracts are overwhelming, and it's also a feature of D that
nobody has seen before. When someone new to D encounters a contract in
the docs, they no longer trust their ability to usefully interpret the
documentation, and almost certainly become confused; nobody expects to
see an 'if' statement in a function declaration.
I think that's a shame. The contract usually has no impact on using
the function, or how it should be understood, is just applies some
limitations to it's genericity.
I think contracts should be disconnected and listed separately, as
additional information, or with some subtext that makes it obvious
what that often confusing bit of text actually means.

Ironically, the string and algorithm functions are probably the worst
offenders, but coincidentally, there is a high chance that these are
the first functions anyone will ever reach for, so they present a
terrible first impression.



 Dec 25 2014



 next sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com>  writes:


 Finally, contracts are overwhelming, and it's also a feature of 
 D that
 nobody has seen before. When someone new to D encounters a 
 contract in
 the docs, they no longer trust their ability to usefully 
 interpret the
 documentation, and almost certainly become confused; nobody 
 expects to
 see an 'if' statement in a function declaration.
 I think that's a shame. The contract usually has no impact on 
 using
 the function, or how it should be understood, is just applies 
 some
 limitations to it's genericity.
 I think contracts should be disconnected and listed separately, 
 as
 additional information, or with some subtext that makes it 
 obvious
 what that often confusing bit of text actually means.

 Ironically, the string and algorithm functions are probably the 
 worst
 offenders, but coincidentally, there is a high chance that 
 these are
 the first functions anyone will ever reach for, so they present 
 a
 terrible first impression.


I think you mean constraints, not contracts.



 Dec 25 2014



  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 26 December 2014 at 11:11, Kiith-Sa via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Finally, contracts are overwhelming, and it's also a feature of D that
 nobody has seen before. When someone new to D encounters a contract in
 the docs, they no longer trust their ability to usefully interpret the
 documentation, and almost certainly become confused; nobody expects to
 see an 'if' statement in a function declaration.
 I think that's a shame. The contract usually has no impact on using
 the function, or how it should be understood, is just applies some
 limitations to it's genericity.
 I think contracts should be disconnected and listed separately, as
 additional information, or with some subtext that makes it obvious
 what that often confusing bit of text actually means.

 Ironically, the string and algorithm functions are probably the worst
 offenders, but coincidentally, there is a high chance that these are
 the first functions anyone will ever reach for, so they present a
 terrible first impression.



 I think you mean constraints, not contracts.


Sorry, you're absolutely correct >_<



 Dec 25 2014



prev sibling next sibling parent reply Mike Parker <aldacron gmail.com>  writes:


On 12/26/2014 9:48 AM, Manu via Digitalmars-d wrote:


 Ironically, the string and algorithm functions are probably the worst
 offenders, but coincidentally, there is a high chance that these are
 the first functions anyone will ever reach for, so they present a
 terrible first impression.


+1

When I first made the move from D1 to D2, this caused me no end of 
frustration. The docs were quite unhelpful in this regard. It irked me 
enough that I wrote a rant about it on my old blog. It doesn't bother me 
anymore, so I haven't thought about it in years. This post brings it back.



 Dec 25 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/25/14 5:18 PM, Mike Parker wrote:

 On 12/26/2014 9:48 AM, Manu via Digitalmars-d wrote:


 Ironically, the string and algorithm functions are probably the worst
 offenders, but coincidentally, there is a high chance that these are
 the first functions anyone will ever reach for, so they present a
 terrible first impression.


 +1

 When I first made the move from D1 to D2, this caused me no end of
 frustration. The docs were quite unhelpful in this regard. It irked me
 enough that I wrote a rant about it on my old blog. It doesn't bother me
 anymore, so I haven't thought about it in years. This post brings it back.


I thought the std.algorithm stuff is decently documented. What would be 
the major pain points? -- Andrei



 Dec 26 2014



 next sibling parent reply "Mike Parker" <aldacron gmail.com>  writes:


On Friday, 26 December 2014 at 16:21:24 UTC, Andrei Alexandrescu 
wrote:

 I thought the std.algorithm stuff is decently documented. What 
 would be the major pain points? -- Andrei


It's fine for someone who is familiar enough with D to decipher 
it. Consider the documentation for sum. The first thing you see 
is the declaration.

auto sum(R)(R r) if (isInputRange!R && !isInfinite!R && 
is(typeof(r.front + r.front)));
auto sum(R, E)(R r, E seed) if (isInputRange!R && !isInfinite!R 
&& is(typeof(seed = seed + r.front)));

I promise you, if you haven't familiarized yourself enough with 
D's templates, template constraints and ranges, this may as well 
be Martian. Then in the description of the function we see this:

If ElementType!R is a floating-point type and R is a 
random-access range with length and slicing, then sum uses the 
pairwise summation algorithm.

Wtf is ElementType? Where is R defined? Searching the site for 
"random-access range" will eventually bear fruit, it doesn't help 
in understanding the whole function.

Then there's a matter of consistency. Where as sum is documented 
with 'R' as a type parameters, others use 'Range'. To the 
hypothetical noob, it's unclear if there is a difference. Little 
things like this add to the frustration level.

The proverbial straw that prompted my blog rant back then was to 
do with std.string. I wanted to split a string on a specific 
character. So I looked in the std.string docs for a split 
function. There wasn't one. There's a 'splitLines' -- I don't 
recall if it existed then, but it wouldn't have been what I was 
looking for anyway. So I searched the docs and found 
std.array.split. I don't recall what the docs looked like then, 
but now this is what we have.

pure  safe S[] split(S)(S s) if (isSomeString!S);

This above is grokkable -- it's fairly clear that S is a string 
and that an array of strings is returned. Then we get these next 
two versions:

auto split(R, E)(R r, E delim) if (isForwardRange!R && 
is(typeof(ElementType!R.init == E.init)));
auto split(alias isTerminator, R)(R r) if (isForwardRange!R && 
is(typeof(unaryFun!isTerminator(r.front))));

Umm... all I want is to split a string on a specific character. 
What's all this mess about ElementTypes and Rs and Es and 
unaryFuns and....

The description, "Eagerly splits s into an array, using delim as 
the delimiter." suggests this is what I'm looking for. I suppose 
I can just pass it a string and a character and see what happens. 
But, that's just trial and errro. The docs don't help me 
understand it. I don't like using functions I don't understand. 
Heaven help me if I find a need for std.array.join:

ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, R 
sep) if (isInputRange!RoR && 
isInputRange!(Unqual!(ElementType!RoR)) && isInputRange!R && 
is(Unqual!(ElementType!(ElementType!RoR)) == 
Unqual!(ElementType!R)));
ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror) if 
(isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)));

So the function to split a string on line breaks, which is 
string-specific, is in std.string. The function to split a string 
on whitespace, again string-specific, is in std.array. The 
function to split any range on any element is in std.array. Which 
means I have to think of strings not just as arrays, but as 
ranges, and have to understand that some range functions are in 
std.range, others in std.array and still others in std.algorithm. 
That means that I don't always know where to look when I want to 
do something I've not done before. Even if I do manage to find 
what I'm looking for, I then may discover that it doesn't work 
because I want an array, but the function returns a range and I 
need to convert it to an array, which means arrays aren't really 
ranges like I thought and...

Again, once one is familiar with ranges, template constraints and 
everything that ties all these modules together, the docs are 
very useful. It's the new user experience that sucks. Even for 
those with experience under their belts. I think many programmers 
learn new languages by hacking stuff together and looking through 
the reference documentation as they go. The current state of D's 
documentation is not conducive to that sort of learning. It 
requires a significant investment of time to read up on major D 
features in order to make sense of the docs.

The python docs have been mentioned before and I think it's a 
good example. In addition to the reference, there's a Beginner's 
Guide and a Developer's Guide. We could use that here. It would 
also be extremely beneficial to eliminate the wall of template 
constraints from the function signatures in the reference, be 
consistent with template type parameters (Range,R,S, and so on), 
and make the reference link to relevant sections of the guides. 
For example, it would be great to have every mention of /forward 
range/ or /input range/ and such link to a page on ranges. Or, if 
that's not practical, having a list of links at the top of the 
page.

"std.algorithm makes heavy use of ranges. See link-to-range-page 
in the developer's guide."

It would also be nice to anticipate that people looking to 
operate on strings would look in std.string for things that are 
elsewhere. Once upon a time, the std.string docs actually did 
have a table of links for functions that had been moved to other 
pages. That was convenient and shouldn't have been removed, IMO.

Anything that can be done to minimize the time required to get up 
to speed is going to help. And it has to be self-contained, all 
in the same site. It's easy to answer posts in D.learn by 
pointing people to TDPL, or Ali's book, or even the wiki, but 
it's much more productive for people to be able to easily find 
what they need by following links in the documentation.



 Dec 27 2014



 next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Mike Parker"  wrote in message news:wwonahubwyixrseqbrpq forum.dlang.org...


 ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, R sep) if 
 (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) && 
 isInputRange!R && is(Unqual!(ElementType!(ElementType!RoR)) == 
 Unqual!(ElementType!R)));
 ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror) if 
 (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)));


I agree, the signatures are basically unreadable.

I usually just skip over them and look at the examples, which most functions 
thankfully have.

eg for join:
const string[] arr = ["apple", "banana"];
assert(arr.join(",") == "apple,banana");
assert(arr.join() == "applebanana"); 



 Dec 27 2014



 next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


Daniel Murphy:


 I agree, the signatures are basically unreadable.


In Scala they have added the  usecase annotation to face this 
problem:
https://wiki.scala-lang.org/display/SW/Tags+and+Annotations

 From that page:

 usecase <simple definition> In case the method definition is too 
complex, you can add simple aliasing definition as a usecase. It 
will create another entry in the scaladoc page as if the <simple 
definition> actually existed. The description for the newly 
created entry is the same as the one for the current symbol, just 
that it's preceded by [use case] to signal it's not a real entry. 
An example can be seen in the ++ method of 
scala.collections.immutable.Set.


Elsewhere there is written:

the usecases inherit the comments from their parents, such
as the explanation and the annotations:  param,  tparam,  return, 
etc.

Bye,
bearophile



 Dec 27 2014



prev sibling  parent reply Mike Parker <aldacron gmail.com>  writes:


On 12/27/2014 6:27 PM, Daniel Murphy wrote:

 "Mike Parker"  wrote in message
 news:wwonahubwyixrseqbrpq forum.dlang.org...


 ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, R sep)
 if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) &&
 isInputRange!R && is(Unqual!(ElementType!(ElementType!RoR)) ==
 Unqual!(ElementType!R)));
 ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror) if
 (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)));


 I agree, the signatures are basically unreadable.

 I usually just skip over them and look at the examples, which most
 functions thankfully have.

 eg for join:
 const string[] arr = ["apple", "banana"];
 assert(arr.join(",") == "apple,banana");
 assert(arr.join() == "applebanana");


Me, too. I haven't been put off by the docs in years (has it really been 
*years*?). But you and I are hardly new to D :)



 Dec 27 2014



  parent  "dajones" <dajones sharklasers.com>  writes:


docs...

SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy
ss = SwapStrategy.unstable, Range)(Range r) if ((ss ==
SwapStrategy.unstable && (hasSwappableElements!Range ||
hasAssignableElements!Range) || ss != SwapStrategy.unstable &&
hasAssignableElements!Range) && isRandomAccessRange!Range &&
hasSlicing!Range && hasLength!Range);

vs code..

SortedRange!(Range, less)
sort(alias less = "a < b", SwapStrategy ss =
SwapStrategy.unstable,
          Range)(Range r)
      if (((ss == SwapStrategy.unstable &&
(hasSwappableElements!Range ||

hasAssignableElements!Range)) ||
           (ss != SwapStrategy.unstable &&
hasAssignableElements!Range)) &&
          isRandomAccessRange!Range &&
          hasSlicing!Range &&
          hasLength!Range)

Why would you make the documentation less clear than the actual
code? If somebody submitted code formatted like your docs they'd
be hung drawn and quartered.

It'd also be nice if you could click on things like SwapStrategy
and isRandomAccessRange. If you can click, read, and click back,
you can grep things so much faster than if you have to manually
look everything up.

It'd also help if there was a bit more structure conveyed in the
formating. For example the only difference between a class member
and the class is the indentation. Same font, same colours, same
underline.



 Dec 27 2014



prev sibling next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/27/2014 12:32 AM, Mike Parker wrote:

 On Friday, 26 December 2014 at 16:21:24 UTC, Andrei Alexandrescu wrote:

 I thought the std.algorithm stuff is decently documented. What would be the
 major pain points? -- Andrei


 [...]


Thank you for taking the time for a detailed accounting. This is very helpful.



 Dec 27 2014



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2014-12-27 09:32, Mike Parker wrote:


 The proverbial straw that prompted my blog rant back then was to do with
 std.string. I wanted to split a string on a specific character. So I
 looked in the std.string docs for a split function. There wasn't one.
 There's a 'splitLines' -- I don't recall if it existed then, but it
 wouldn't have been what I was looking for anyway. So I searched the docs
 and found std.array.split. I don't recall what the docs looked like
 then, but now this is what we have.

 pure  safe S[] split(S)(S s) if (isSomeString!S);

 This above is grokkable -- it's fairly clear that S is a string and that
 an array of strings is returned. Then we get these next two versions:

 auto split(R, E)(R r, E delim) if (isForwardRange!R &&
 is(typeof(ElementType!R.init == E.init)));
 auto split(alias isTerminator, R)(R r) if (isForwardRange!R &&
 is(typeof(unaryFun!isTerminator(r.front))));

 Umm... all I want is to split a string on a specific character. What's
 all this mess about ElementTypes and Rs and Es and unaryFuns and....

 The description, "Eagerly splits s into an array, using delim as the
 delimiter." suggests this is what I'm looking for. I suppose I can just
 pass it a string and a character and see what happens. But, that's just
 trial and errro. The docs don't help me understand it. I don't like
 using functions I don't understand. Heaven help me if I find a need for
 std.array.join:

 ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, R sep) if
 (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) &&
 isInputRange!R && is(Unqual!(ElementType!(ElementType!RoR)) ==
 Unqual!(ElementType!R)));
 ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror) if
 (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)));

 So the function to split a string on line breaks, which is
 string-specific, is in std.string. The function to split a string on
 whitespace, again string-specific, is in std.array. The function to
 split any range on any element is in std.array. Which means I have to
 think of strings not just as arrays, but as ranges, and have to
 understand that some range functions are in std.range, others in
 std.array and still others in std.algorithm. That means that I don't
 always know where to look when I want to do something I've not done
 before. Even if I do manage to find what I'm looking for, I then may
 discover that it doesn't work because I want an array, but the function
 returns a range and I need to convert it to an array, which means arrays
 aren't really ranges like I thought and...


There's also "split" vs "splitter" and "join" vs "joiner". This doesn't 
make it easier.

-- 
/Jacob Carlborg



 Dec 27 2014



 next sibling parent  "ixid" <nuaccount gmail.com>  writes:


On Saturday, 27 December 2014 at 11:42:45 UTC, Jacob Carlborg 
wrote:

 On 2014-12-27 09:32, Mike Parker wrote:


 The proverbial straw that prompted my blog rant back then was 
 to do with
 std.string. I wanted to split a string on a specific 
 character. So I
 looked in the std.string docs for a split function. There 
 wasn't one.
 There's a 'splitLines' -- I don't recall if it existed then, 
 but it
 wouldn't have been what I was looking for anyway. So I 
 searched the docs
 and found std.array.split. I don't recall what the docs looked 
 like
 then, but now this is what we have.

 pure  safe S[] split(S)(S s) if (isSomeString!S);

 This above is grokkable -- it's fairly clear that S is a 
 string and that
 an array of strings is returned. Then we get these next two 
 versions:

 auto split(R, E)(R r, E delim) if (isForwardRange!R &&
 is(typeof(ElementType!R.init == E.init)));
 auto split(alias isTerminator, R)(R r) if (isForwardRange!R &&
 is(typeof(unaryFun!isTerminator(r.front))));

 Umm... all I want is to split a string on a specific 
 character. What's
 all this mess about ElementTypes and Rs and Es and unaryFuns 
 and....

 The description, "Eagerly splits s into an array, using delim 
 as the
 delimiter." suggests this is what I'm looking for. I suppose I 
 can just
 pass it a string and a character and see what happens. But, 
 that's just
 trial and errro. The docs don't help me understand it. I don't 
 like
 using functions I don't understand. Heaven help me if I find a 
 need for
 std.array.join:

 ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, 
 R sep) if
 (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) &&
 isInputRange!R && is(Unqual!(ElementType!(ElementType!RoR)) ==
 Unqual!(ElementType!R)));
 ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror) if
 (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)));

 So the function to split a string on line breaks, which is
 string-specific, is in std.string. The function to split a 
 string on
 whitespace, again string-specific, is in std.array. The 
 function to
 split any range on any element is in std.array. Which means I 
 have to
 think of strings not just as arrays, but as ranges, and have to
 understand that some range functions are in std.range, others 
 in
 std.array and still others in std.algorithm. That means that I 
 don't
 always know where to look when I want to do something I've not 
 done
 before. Even if I do manage to find what I'm looking for, I 
 then may
 discover that it doesn't work because I want an array, but the 
 function
 returns a range and I need to convert it to an array, which 
 means arrays
 aren't really ranges like I thought and...


 There's also "split" vs "splitter" and "join" vs "joiner". This 
 doesn't make it easier.


Having array in std.array is also rather confusing for a newbie, 
it's an extra complication in their fight with lazy when they 
will be trying to use std.algorithm.



 Dec 27 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/27/14 3:42 AM, Jacob Carlborg wrote:

 There's also "split" vs "splitter" and "join" vs "joiner". This doesn't
 make it easier.


Not to mention findSplit - my all-times favorite. -- Andrei



 Dec 27 2014



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/27/2014 2:57 PM, Andrei Alexandrescu wrote:

 On 12/27/14 3:42 AM, Jacob Carlborg wrote:

 There's also "split" vs "splitter" and "join" vs "joiner". This doesn't
 make it easier.


 Not to mention findSplit - my all-times favorite. -- Andrei


Just a minute Doc lets not start splitting hares!

http://wiseacre-gardens.com/sound/bugs_minute.wav



 Dec 27 2014



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2014-12-27 09:32, Mike Parker wrote:


 auto split(R, E)(R r, E delim) if (isForwardRange!R &&
 is(typeof(ElementType!R.init == E.init)));
 auto split(alias isTerminator, R)(R r) if (isForwardRange!R &&
 is(typeof(unaryFun!isTerminator(r.front))));

 Umm... all I want is to split a string on a specific character. What's
 all this mess about ElementTypes and Rs and Es and unaryFuns and....


What we need is simplified signatures in the documentation. The template 
constrains could be hidden, then have a button to show them. Same thing 
with special default values, i.e. __FILE__, __LINE__ and so on.

https://issues.dlang.org/show_bug.cgi?id=13676

-- 
/Jacob Carlborg



 Dec 27 2014



  parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 27 Dec 2014 12:46:09 +0100
Jacob Carlborg via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 What we need is simplified signatures in the documentation. The template=


=20

 constrains could be hidden, then have a button to show them. Same thing=20
 with special default values, i.e. __FILE__, __LINE__ and so on.


i agree, but the direction is slightly different: we should have a
script which hides them after the page is loaded and creates
corresponding buttons.



 Dec 27 2014



prev sibling next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/27/2014 12:32 AM, Mike Parker wrote:

 Wtf is ElementType? Where is R defined? Searching the site for "random-access
 range" will eventually bear fruit, it doesn't help in understanding the whole
 function.


A token improvement:

https://github.com/D-Programming-Language/phobos/pull/2812



 Dec 27 2014



prev sibling next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/27/14 12:32 AM, Mike Parker wrote:

 On Friday, 26 December 2014 at 16:21:24 UTC, Andrei Alexandrescu wrote:

 I thought the std.algorithm stuff is decently documented. What would
 be the major pain points? -- Andrei


 It's fine for someone who is familiar enough with D to decipher it.
 Consider the documentation for sum.


[snip]

Great ideas, thanks. I created 
https://issues.dlang.org/show_bug.cgi?id=13901 -- Andrei



 Dec 27 2014



prev sibling  parent reply "ponce" <contact gam3sfrommars.fr>  writes:


On Saturday, 27 December 2014 at 08:32:29 UTC, Mike Parker wrote:

 It would also be nice to anticipate that people looking to 
 operate on strings would look in std.string for things that are 
 elsewhere. Once upon a time, the std.string docs actually did 
 have a table of links for functions that had been moved to 
 other pages. That was convenient and shouldn't have been 
 removed, IMO.


Finding a string in another comes to mind. Is it "countUntil"?
I'm still unsure if there is a min/max function I could use for 
builtin types in Phobos.

I've found myself several times searching the following in 
Rosetta Code, and wished there was a site for common idioms.



 Dec 29 2014



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/29/14 2:12 AM, ponce wrote:

 On Saturday, 27 December 2014 at 08:32:29 UTC, Mike Parker wrote:

 It would also be nice to anticipate that people looking to operate on
 strings would look in std.string for things that are elsewhere. Once
 upon a time, the std.string docs actually did have a table of links
 for functions that had been moved to other pages. That was convenient
 and shouldn't have been removed, IMO.


 Finding a string in another comes to mind. Is it "countUntil"?


std.algorithm.find


 I'm still unsure if there is a min/max function I could use for builtin
 types in Phobos.


std.algorithm.min, std.algorithm.max


 I've found myself several times searching the following in Rosetta Code,
 and wished there was a site for common idioms.


Point taken.


Andrei



 Dec 29 2014



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 12/26/2014 8:21 AM, Andrei Alexandrescu wrote:

 I thought the std.algorithm stuff is decently documented. What would be the
 major pain points? -- Andrei


A large number of the algorithms lack one or more of:

1. examples

2. any mention of what they return, and if they do, they do not use a Returns: 
section

3. almost none have a Params: section

4. some terms need exposition, like: "Implements the homonym function present
in 
various programming languages of functional flavor." I have no idea what that 
means. Googling "homonym function" doesn't produce anything that looks
relevant. 
A link to an entry in http://dlang.org/glossary.html would be good.



 Dec 27 2014



  parent reply "David Nadlinger" <code klickverbot.at>  writes:


On Saturday, 27 December 2014 at 20:24:27 UTC, Walter Bright 
wrote:

 4. some terms need exposition, like: "Implements the homonym 
 function present in various programming languages of functional 
 flavor." I have no idea what that means. Googling "homonym 
 function" doesn't produce anything that looks relevant. A link 
 to an entry in http://dlang.org/glossary.html would be good.


"Homonym" is just a fancy way of saying "with the same name". But 
I agree:
  1) The docs should avoid overly fancy language.
  2) Analogies to other languages should never be the primary 
means of explanation.

David



 Dec 27 2014



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/27/2014 2:14 PM, David Nadlinger wrote:

 On Saturday, 27 December 2014 at 20:24:27 UTC, Walter Bright wrote:

 4. some terms need exposition, like: "Implements the homonym function present
 in various programming languages of functional flavor." I have no idea what
 that means. Googling "homonym function" doesn't produce anything that looks
 relevant. A link to an entry in http://dlang.org/glossary.html would be good.


 "Homonym" is just a fancy way of saying "with the same name". But I agree:
   1) The docs should avoid overly fancy language.
   2) Analogies to other languages should never be the primary means of
explanation.


Clearly, this should instead be a link to this:

    http://en.wikipedia.org/wiki/Filter_(higher-order_function)

Ironically, that article refers to std.algorithm.filter!



 Dec 27 2014



prev sibling  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 27 December 2014 at 02:21, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/25/14 5:18 PM, Mike Parker wrote:

 On 12/26/2014 9:48 AM, Manu via Digitalmars-d wrote:


 Ironically, the string and algorithm functions are probably the worst
 offenders, but coincidentally, there is a high chance that these are
 the first functions anyone will ever reach for, so they present a
 terrible first impression.


 +1

 When I first made the move from D1 to D2, this caused me no end of
 frustration. The docs were quite unhelpful in this regard. It irked me
 enough that I wrote a rant about it on my old blog. It doesn't bother me
 anymore, so I haven't thought about it in years. This post brings it back.



 I thought the std.algorithm stuff is decently documented. What would be the
 major pain points? -- Andrei


The first line of text respectively:


  public static void Sort<T>(T[] array)

D:
  SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy ss
= SwapStrategy.unstable, Range)(Range r) if ((ss ==
SwapStrategy.unstable && (hasSwappableElements!Range ||
hasAssignableElements!Range) || ss != SwapStrategy.unstable &&
hasAssignableElements!Range) && isRandomAccessRange!Range &&
hasSlicing!Range && hasLength!Range);


I'm sure you can see the problem...



 Dec 28 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 12/28/14 6:43 PM, Manu via Digitalmars-d wrote:

 On 27 December 2014 at 02:21, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 12/25/14 5:18 PM, Mike Parker wrote:

 On 12/26/2014 9:48 AM, Manu via Digitalmars-d wrote:


 Ironically, the string and algorithm functions are probably the worst
 offenders, but coincidentally, there is a high chance that these are
 the first functions anyone will ever reach for, so they present a
 terrible first impression.


 +1

 When I first made the move from D1 to D2, this caused me no end of
 frustration. The docs were quite unhelpful in this regard. It irked me
 enough that I wrote a rant about it on my old blog. It doesn't bother me
 anymore, so I haven't thought about it in years. This post brings it back.



 I thought the std.algorithm stuff is decently documented. What would be the
 major pain points? -- Andrei


 The first line of text respectively:


    public static void Sort<T>(T[] array)

 D:
    SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy ss
 = SwapStrategy.unstable, Range)(Range r) if ((ss ==
 SwapStrategy.unstable && (hasSwappableElements!Range ||
 hasAssignableElements!Range) || ss != SwapStrategy.unstable &&
 hasAssignableElements!Range) && isRandomAccessRange!Range &&
 hasSlicing!Range && hasLength!Range);


 I'm sure you can see the problem...


Thanks, following your feedback I have recently submitted an enhancement 

arrays whereas D's sort (a) returns a statically-informed sorted range 
with specific primitives, (b) is configurable to use a custom predicate, 
(c) allows stability selection, (d) works for any range satisfying 
certain requirements. Yay...? :o)

Andrei



 Dec 28 2014



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 12/28/2014 7:52 PM, Andrei Alexandrescu wrote:

 Thanks, following your feedback I have recently submitted an enhancement

 whereas D's sort (a) returns a statically-informed sorted range with specific
 primitives, (b) is configurable to use a custom predicate, (c) allows stability
 selection, (d) works for any range satisfying certain requirements. Yay...? :o)


sort() could sure use a [Params:] section!

For example, the parameter 'ss' is never mentioned in the description.



 Dec 28 2014



prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 29 December 2014 at 03:52, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/28/14 6:43 PM, Manu via Digitalmars-d wrote:

 On 27 December 2014 at 02:21, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 12/25/14 5:18 PM, Mike Parker wrote:

 On 12/26/2014 9:48 AM, Manu via Digitalmars-d wrote:


 Ironically, the string and algorithm functions are probably the worst
 offenders, but coincidentally, there is a high chance that these are
 the first functions anyone will ever reach for, so they present a
 terrible first impression.


 +1

 When I first made the move from D1 to D2, this caused me no end of
 frustration. The docs were quite unhelpful in this regard. It irked me
 enough that I wrote a rant about it on my old blog. It doesn't bother me
 anymore, so I haven't thought about it in years. This post brings it
 back.




 I thought the std.algorithm stuff is decently documented. What would be
 the
 major pain points? -- Andrei


 The first line of text respectively:


    public static void Sort<T>(T[] array)

 D:
    SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy ss
 = SwapStrategy.unstable, Range)(Range r) if ((ss ==
 SwapStrategy.unstable && (hasSwappableElements!Range ||
 hasAssignableElements!Range) || ss != SwapStrategy.unstable &&
 hasAssignableElements!Range) && isRandomAccessRange!Range &&
 hasSlicing!Range && hasLength!Range);


 I'm sure you can see the problem...



 Thanks, following your feedback I have recently submitted an enhancement

 whereas D's sort (a) returns a statically-informed sorted range with
 specific primitives, (b) is configurable to use a custom predicate, (c)
 allows stability selection, (d) works for any range satisfying certain
 requirements. Yay...? :o)

 Andrei


The new layout solves half the problem in that it hides the template
constraints.

http://dlang.org/library/std/algorithm/sort.html

Shouldn't our focus also be to get the new layout out of "preview"
mode and do our standardization of documentation from there?

By the way, I would also nick pick on top of Manu's suggestion that
the short description for sort() is just "Sorts".  I'm sure this can
be expanded to more than one word and less than twelve.

Iain.



 Dec 29 2014



  parent  "Mathias LANG" <geod24 gmail.com>  writes:


On Monday, 29 December 2014 at 09:35:25 UTC, Iain Buclaw via
Digitalmars-d wrote:

 The new layout solves half the problem in that it hides the 
 template
 constraints.

 http://dlang.org/library/std/algorithm/sort.html

 Shouldn't our focus also be to get the new layout out of 
 "preview"
 mode and do our standardization of documentation from there?

 Iain.


Couldn't agree more.

It also scales way better than DDOC at the module level
(http://dlang.org/library/std/datetime.html VS
http://dlang.org/phobos/std_datetime.html).
Additionally, it could allow us to have multiple version of the
doc supported, which is quite useful when migrating stuff /
working with an older release.

What is missing / required to definitely switch ?



 Dec 29 2014



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 29 December 2014 at 13:52, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 12/28/14 6:43 PM, Manu via Digitalmars-d wrote:

 On 27 December 2014 at 02:21, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 12/25/14 5:18 PM, Mike Parker wrote:

 On 12/26/2014 9:48 AM, Manu via Digitalmars-d wrote:


 Ironically, the string and algorithm functions are probably the worst
 offenders, but coincidentally, there is a high chance that these are
 the first functions anyone will ever reach for, so they present a
 terrible first impression.


 +1

 When I first made the move from D1 to D2, this caused me no end of
 frustration. The docs were quite unhelpful in this regard. It irked me
 enough that I wrote a rant about it on my old blog. It doesn't bother me
 anymore, so I haven't thought about it in years. This post brings it
 back.




 I thought the std.algorithm stuff is decently documented. What would be
 the
 major pain points? -- Andrei


 The first line of text respectively:


    public static void Sort<T>(T[] array)

 D:
    SortedRange!(Range, less) sort(alias less = "a < b", SwapStrategy ss
 = SwapStrategy.unstable, Range)(Range r) if ((ss ==
 SwapStrategy.unstable && (hasSwappableElements!Range ||
 hasAssignableElements!Range) || ss != SwapStrategy.unstable &&
 hasAssignableElements!Range) && isRandomAccessRange!Range &&
 hasSlicing!Range && hasLength!Range);


 I'm sure you can see the problem...



 Thanks, following your feedback I have recently submitted an enhancement

 whereas D's sort (a) returns a statically-informed sorted range with
 specific primitives, (b) is configurable to use a custom predicate, (c)
 allows stability selection, (d) works for any range satisfying certain
 requirements. Yay...? :o)


I'm not making any comment on the quality of the implementation (I
agree, it's awesome), but the prototype as presented in the docs is
seriously intimidating.
I think careful consideration to design/layout/formatting of the docs
in general could alleviate a lot of the perceived noise alone. More
breathing room (whitespace), typeface, colour coding,
bold/italic/etc...
It probably wouldn't wouldn't be hard to be known for excellent docs.
Many other competing ecosystems have horrific documentation
experiences.

It'd be nice to get an experienced designer to invent a really
professional and quality style guide for the docs. Any designer mates
anyone?
This is probably the most important user-facing experience in the
ecosystem, so it can't hurt to get a bang-up design by someone really
experienced.



 Dec 29 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-12-26 01:48, Manu via Digitalmars-d wrote:


 In this case, my colleague felt it was hard to understand the string
 functions, but he got through it (after sending me txt messages to ask
 questions).
 I recall making the same comments when I first started trying to do
 string manipulation in D. My personal take is, string functions are
 all templates, which makes them look more complex than they are, and
 for me, it was really hard to understand where to look for certain
 functions; they're spread fairly evenly across 5 or so different
 modules. Algorithm, range, ascii, uni, utf. Some of the most important
 functions are in range and algorithm. Perhaps those that are fairly
 string specific from range/algorithm should have aliases in
 std.string, or std.string might public import some of the minor
 modules, like ascii/uni/utf?


Don't forget about std.array as well ;)

-- 
/Jacob Carlborg



 Dec 27 2014



prev sibling next sibling parent  "Paulo  Pinto" <pjmlp progtools.org>  writes:


On Wednesday, 17 December 2014 at 09:05:58 UTC, Manu via 
Digitalmars-d wrote:

 On 16 December 2014 at 00:04, Kagamin via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
 Digitalmars-d wrote:

 They then made HUGE noises about the quality of 
 documentation. The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The 
 formatting
 didn't help, there's a lot of noise and a lack of structure 
 in the
 documentation's presentation that makes it hard to see the 
 information
 through the layout and noise. As senior software engineers, 
 they
 basically expected that they should be able to read and 
 understand the
 docs, even if they don't really know the language, after all, 
 "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a 
 basic
 level by skimming the docs, but the D docs are an anomaly in 
 this way;
 it seems you have to already know D to be able to understand 
 it
 effectively. They didn't know javascript either, but skimming 
 the
 node.js docs they got the job done in an hour or so, after 
 having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.



 Comparing node.js to D? You probably speak about vibe, not D?


 The majority of hours spent were not really related to vibe.d 
 so much
 as trying to wrangle the tooling, debugging crashes, and 
 understand
 the docs to get some very basic things done.
 These are 'D' experience if you ask me.



 One of the take-away quotes I think, was "D seems to be a 
 language for
 people who actively want to go and look for it, and take the 
 time to
 learn it. That's never going to be a commercial success."



 O_O Huh? Your team really didn't learn C++?


 We didn't 'learn' javascript, or python, or html, or whatever 
 else you
 pick up on the job.
 The investment in learning 'programming' is decades behind us, 
 and I
 think it's a reasonable expectation that a language present 
 itself in
 such a way that it's intuitive and easy to get some basic things
 going.
 Leveraging small example snippets from the docs, etc. D is very 
 easy
 for a C/C++ programmer, but the docs don't make it appear that 
 way,
 and they give the wrong impression.
 The overpowering presence of templates in the docs give a first
 impression that reminds people of everything that's wrong with 
 C++,
 which I suspect most C++ programmers looking into D are actively
 trying to escape!


This is something I also felt like when dabbled with D.

There is a lot of meta-programming going on the JVM and .NET 
worlds. Depending on the language, it comes via AST manipulation, 
attributes, compiler plugins, bytecode manipulation and macros.

However it tend to be used mostly for frameworks of some sort, 
not across all the APIs.

With the two toy projects I used D for, a toy compiler and a A* 
search implementation, I got the idea that there is a template 
for everything.

Granted, D's approach with templates and mixin makes it very easy 
to write such code.


--
Paulo



 Dec 17 2014



prev sibling  parent  "Mengu" <mengukagan gmail.com>  writes:


On Wednesday, 17 December 2014 at 09:05:58 UTC, Manu via 
Digitalmars-d wrote:

 On 16 December 2014 at 00:04, Kagamin via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
 Digitalmars-d wrote:

 They then made HUGE noises about the quality of 
 documentation. The
 prevailing opinion was that the D docs, in the eyes of a
 not-a-D-expert, are basically unreadable to them. The 
 formatting
 didn't help, there's a lot of noise and a lack of structure 
 in the
 documentation's presentation that makes it hard to see the 
 information
 through the layout and noise. As senior software engineers, 
 they
 basically expected that they should be able to read and 
 understand the
 docs, even if they don't really know the language, after all, 
 "what is
 the point of documentation if not to teach the language..."
 I tend to agree, I find that I can learn most languages to a 
 basic
 level by skimming the docs, but the D docs are an anomaly in 
 this way;
 it seems you have to already know D to be able to understand 
 it
 effectively. They didn't know javascript either, but skimming 
 the
 node.js docs they got the job done in an hour or so, after 
 having
 wasted *2 days* trying to force their way through the various
 frictions presented but their initial experience with D.



 Comparing node.js to D? You probably speak about vibe, not D?


 The majority of hours spent were not really related to vibe.d 
 so much
 as trying to wrangle the tooling, debugging crashes, and 
 understand
 the docs to get some very basic things done.
 These are 'D' experience if you ask me.


very well said. it's not about just the environment, the language 
or phobos. it is about the experience that we provide to a new 
comer to D.

i remember walter said "build it and they will come is a lie." 
well, how about it "give a better experience and they will come?"


 One of the take-away quotes I think, was "D seems to be a 
 language for
 people who actively want to go and look for it, and take the 
 time to
 learn it. That's never going to be a commercial success."



 O_O Huh? Your team really didn't learn C++?


 We didn't 'learn' javascript, or python, or html, or whatever 
 else you
 pick up on the job.
 The investment in learning 'programming' is decades behind us, 
 and I
 think it's a reasonable expectation that a language present 
 itself in
 such a way that it's intuitive and easy to get some basic things
 going.
 Leveraging small example snippets from the docs, etc. D is very 
 easy
 for a C/C++ programmer, but the docs don't make it appear that 
 way,
 and they give the wrong impression.
 The overpowering presence of templates in the docs give a first
 impression that reminds people of everything that's wrong with 
 C++,
 which I suspect most C++ programmers looking into D are actively
 trying to escape!

 There simply can't be friction on step 1! There can be friction 
 on
 step 4 or 5 when you've already made some minor achievements, 
 and have
 a good few hours invested.
 Any friction on step 1 or 2 will lead to an almost immediate 
 rejection.


i am a python, ruby and groovy developer. D was very easy also 
for a programmer like me. every time i come back, i find comfort 
at D. honestly, D is python on stereoids for me. till i look at 
the docs and see all those things that doesn't mean anything at 
first sight. then i spend some time to understand the signatures, 
the bodies.

maybe, generated docs are not a good idea and hand-written, more 
explanatory docs are better for d?



 Dec 17 2014



prev sibling next sibling parent  "Ilya Yaroshenko" <ilyayaroshenko gmail.com>  writes:


On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via
Digitalmars-d wrote:


 We were unable to build Win64 code (vibe.d doesn't support 
 Win64 it
 seems), and the 32bit compiler produces useless OMF output. We
 couldn't link against any of our existing code which was a 
 serious
 inconvenience, but they were understanding and we worked around 
 it.


I had the same situation in my work half year ago.


 I think most importantly though, we need LDC! Assuming those 
 other
 things come good, we need a compiler with a backend to produce 
 the
 expected performance, and which integrates in a well known way 
 with
 the ecosystem around it.


+1, LDC is very good backend.

DMD has commutative floating point optimisation.
So I can not use it for some math functions :-(, for example for
fsum or ported Netlib routines.
fsum: https://github.com/D-Programming-Language/phobos/pull/2513



 Dec 15 2014



prev sibling  parent  "Piotrek" <none nowhere.pl>  writes:


On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via 
Digitalmars-d wrote:

 I think we need a budget for presentation, and we need to pay 
 money and hire some professionals to make the content. Is there 
 a
 kickstarter campaign here? I'll contribute for sure.


Count me in. Money is not the last thing D needs.

Piotrek



 Dec 15 2014