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] http://burner.github.io/phobos/phobos-prerelease/std_logger_core.html#.logc -- /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 in investing in programming languages made java, c#, python and 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 
 interested in investing in programming languages made java, c#, 
 python and ruby mainstream?
Java / C# - huge amount of enterprise money invested into it from 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 C#. 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 and hack away without knowing the language, be it Java, C# or 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. 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
 to be _understood_, even if you are already familiar with C++, Java or 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 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
 and hack away without knowing the language, be it Java, C# or 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. I've learned Java, C#, python, js, lua, ..., by being told to 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. 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++, 
 Java or 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
 and hack away without knowing the language, be it Java, C# or 
 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. I've learned Java, C#, python, js, lua, ..., by being told to 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: C#: 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: C#: 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 request. Just for the sake of humblebragging, C#'s sort works only on 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
 request. Just for the sake of humblebragging, C#'s sort works only on 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)
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: C#: 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 request. Just for the sake of humblebragging, C#'s sort works only on 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
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: C#: 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 request. Just for the sake of humblebragging, C#'s sort works only on 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)
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