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.

> 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

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.

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

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.

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.

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.

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

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.

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