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.

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.

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.

> 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.

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.

>> 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.

they are in same way mmfile module which is deprecated since many years, xml was in same case

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.
> 
> 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.
> 
> 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!"
> 
> 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.

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-A75BA498AEDB85DC20AE1A4A96C79D4B/ 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!

> 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.

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.