There are some misconceptions, I think, here.

1. People learn more than 1 language. What I'm referring to here is complete beginners who need to learn -how- to program. Once they grok that, it's not difficult to move to other languages, obviously with some exceptions.

2. It's not the job of a -language- to teach everything about programming or networking or computers or various protocols. That's the job of a curriculum.

3. There are way more $major_lang jobs than jobs for D, Clojure, Lisp, Crystal, or any of the other languages that are significantly less used. The sky is the limit for how many languages people want to play around with and learn, once they know enough to start learning other languages by themselves. No recruiter is gonna be like "oh, you learned $major_lang... Even though you likely applied to this role because our stack involves $major_lang and that's a language that you know well..."

4. Help, resources, meetups etc for $major_lang are orders of magnitude more plentiful than for D, etc. Imagine telling a student "no, no, you need to prove yourself by making forum posts for <niche language that I personally like and use> instead of having stackoverflow questions or tutorials to follow" in the case of getting stuck. Of course students should strive to do as much as they can themselves, but you would be surprised to see what beginners get stuck on and just need a gentle push to get going again.

5. Being able to be independent is more engaging than having to constantly pester a teacher or a forum. If a student wants to be a go-getter with e.g. python or lua, there are communities and resources to build games or websites, etc. And those already have had common stumbling block questions answered because they have large communities around them.

For the goal of teaching someone how to program, any language other than the major ones like python, javascript, ruby, c++ strictly make it more difficult for students because of the smaller ecosystem, lesser amount of documentation, and smaller community in general. I have nothing against D or other niche languages, but I'm against picking languages just because I'm familiar with them.

It can be difficult for experienced programmers & power users to remember that there's a sheer amount of information that needs to be learned in. There is no reason to make that more difficult for students.

I don't buy learning D is more difficult. Everything needed is available, for free. Once a certain threshold is met, more doesn't add much of anything.

It's easier to transition from D to C++, or D to Python, than to transition from C++ to Python or vice versa.

You're right, it's not the job of a language to teach everything. But since D supports multi-paradigm, it's easier to use D to teach it.

I mean this with all due respect, but you are far too biased. It's fair for you to state that D makes solid efforts to be approachable and easy to learn, but you cannot claim it is easy to learn:

you don't have the data, and you invented the language.

> Everything needed is available, for free.

This is a moot point. I struggle to think of another language for which this is not true.

> But since D supports multi-paradigm, it's easier to use D to teach it.

You've confused learning to program and learning a paradigm with learning a language. They are not the same thing.

For one, multi-paradigm languages hinder comprehension for newcomers as there are too many ways to do things. It's too easy and convenient to be impure with respect to a paradigm. Multi-paradigm languages are mostly useful after you understand the individual paradigms well, but you will surely disagree with me here. We're all entitled to be wrong from time to time :)

I respect you and your work but you're missing the forest for the trees here.

When I've taught people to program, the simplest environments are the most effective. Basic, C, Lua, Processing, Lisp, etc. By comparison, C++ and Python are full of difficult-to-grasp footguns, I'd strongly avoid them (or comparisons to them) in this day and age.

> you are far too biased

Keep in mind that I created D because I wanted to program in it. It is based on my decades of experience with other languages and supporting those languages and knowing where people go wrong with them and where the problems are.

> C

C is a simple language, but grasping how it works is not simple. To get C you need to understand assembler, which is not simple at all. The misunderstandings novices have about pointers, for example, are misunderstandings about how computers work.

C is loaded with legacy problems, too, like uninitialized variables containing garbage. There's all that confusion between prototypes and non-prototypes. Implicit coercion of 2 to a pointer:

    int *p = 2;

The C preprocessor is nowhere near as simple as it appears. Arrays are determined to decay to uncontrolled pointers. Buffer overflows are pervasive, even among the most professional programs.

D (as Better C) is a very C-like language, but minus those problems. It's reasonable to say it is much more easily learned. It has far fewer footguns.

> You've confused

I may have been unclear, but I am not confused.

I've written two C compilers from scratch, and 3 C preprocessors. I know every last dirty detail of C.

Basic, however, we can agree is a simple language. But it teaches bad habits, which have to be unlearned.

Another issue with C being an allegedly good beginner language is strings. C is simply terrible at handling strings. Let's say I want to concatenate two strings:

    char *concat(char *p, char *q)
    {
        size_t plen = strlen(p);
        size_t qlen = strlen(q);
        char *r = (char*)malloc(plen + qlen + 1);
        assert(r);
        memcpy(r, p, plen);
        memcpy(r + plen, q, qlen + 1);
        return r;
    }

And never mind the issue of when to free() r. Contrast with D:

    string concat(string p, string q)
    {
        return p ~ q;
    }

P.S. Yes, I know about the potential overflow problem with `plen + qlen + 1`.

I get that C tries to be incredibly barebones, but operations on strings are so common that it's crazy how bad the string handling in C is. It seems like it was designed under the assumption that all of your strings are stored in fixed-size buffers.

I might not pick D as a beginner language simply because it unfortunately isn't very popular, but I certainly wouldn't pick C as a beginner language.

> Implicit coercion of 2 to a pointer:

    int *p = 2;

Look, you and I know this is horrible and should probably be a war crime, but you have to admit: it's elegant. The ability to pierce the abstraction with C is the only reason it's on that list. I can teach people how computers actually work without getting to assembly (though it's usually a good idea to go there). It all depends on the goal. If your goal is to understand how computers execute programs, then a little C doesn't hurt.

> But it teaches bad habits, which have to be unlearned.

Apologies, but you're confused again: you've conflated learning how to code, with learning to be a software engineer. They're related, but less so than you think.

In my experience, it is impossible to teach a student a lesson that requires experience without providing them the opportunity to experience it. Teach someone Basic, let them do bad things, then show them the light.

"If you give a man a fish" and all that.

Telling me again that I'm confused and telling me what I think and what I have to admit is rather presumptuous. You can make all your points just fine without that.

When I see `int *p = 2;`, "elegant" is not at all what comes to mind. "Bug" is what comes to mind.

Reminds me of my wood shop teacher. He showed me the right way to use hand tools, from the start, which pays off every time since that I use one. He also showed how to use power tools, and never failed to show us the missing finger on his hand - the price for taking shortcuts.

Whenever I use the table saw, I think of his finger stub and slow down, take my time, and do it right.

I've tried D after programming in Perl and wish it had existed when I was in highschool and in my first uni year, so that I could have been taught D instead of Borland C.

It's too bad it didn't make its way into embedded programming where we still have to use C or C++ or dumbed down high level languages, even if it was just for the BetterC part. D-style OOP would be nice as well, though. Maybe LDC and GDC would change that by targeting more platforms and ARM eating the world.

Thank you for creating the language.

You say it as if stackoverflow is a silver bullet. I searched for "why my program doesn't work" and this is what I got: https://stackoverflow.com/questions/32335245/

A novice stands no chance to figure out anything with this.

Same result for javascript: https://stackoverflow.com/questions/8290710/

And python: https://stackoverflow.com/questions/50510291/ (this one got downvoted, awesome experience for a novice, some people argue abusive nature of stackoverflow is intended so that people learn hard all its ins and outs before touching it or get abused)

Hiding what's going on (e.g. details related to real hardware like machine integers) is arguably pretty good for teaching a complete beginner about what this "code" thing even is.

Though I guess the classic workaround for that is to carefully construct the course such that these details are revealed gradually, without being overwhelming.