What is the right level of abstractions for D?

[Danni Coy via Digitalmars-d]

I am going to talk as a person who mostly works with group 3 languages
but will use whatever they need to use to get the job done (tm).

> The reason for the split is that there are different levels of software
> expertise and performance needs, and each of those groups is geared for a
> different level.  Show templates to a scripting user and they probably run
> away screaming.

The bit that sends group 3 people off screaming is static typing, once
you have accepted the need to explicitly type everything then Template
functions are pretty straight forward in D.

> D can probably do well with groups 1 and 2, but the level
> of power and expertise that is needed for those lower levels will scare away
> people from 3.  Those already using it for 1 and 2 may also be comfortable
> with reusing D for scripting, but that's not attracting people from group 3,
> ie those who only want something easy to use and don't want to know the
> difference between a static and dynamic array.

Again this boils down to static typing, once your group 3 programmer
has accepted this then is is a minor issue. At worst case I could see
a grumble then avoiding static arrays.

>
>> I've noticed that, for many of the people who don't "get" D, the problem
>> they're hitting is that they're minds are so twisted around by the
>> "polyglot" culture, that they're looking for "the one" tiny little niche
>> that D is for, not seeing that, and thus missing the whole entire point.
>
>
> Yes, this has definitely hurt D, being stuck between 1 and 2.  People from 2
> probably look at D and think it's too low-level.  People from 1 are always
> looking to squeeze out _more_ performance, so the GC is a way for them to
> just write off D.  You and I think they're making a mistake, but maybe
> they're not wrong for their own uses.
>
> As I said, the recent push for @nogc and C++ compatibility suggests that a
> renewed effort is being made to focus on group 1, particularly when combined
> with the D benchmarks for regex and recently math.  I'm happy in that space
> between 1 and 2, and the recent push to move languages from 2 to AoT
> compilation suggests that is a good place to be.  So maybe group 2 will also
> come to us. :)

Apart from in application scripting, I have replaced python with D at
work. (I was largely using python because my brain and shell scripting
are largely incompatible). The reasons for this was mostly because
with D I can compile and distribute the binary without having to worry
if the right version of python was installed on the target machine.

For this whip up a tool to automate some file processing quickly I
found D as pleasant as anything else I have used.
The only thing missing are bindings for a high quality crossplatform
gui toolkit.

Where I see the future potential of D in regards to the levels 1,2 and
3 is having a team where different programmers are working at
different levels within the same language on the same project. Take a
game engine, typically you have low level engine guys (level 1) some
guys on the engine team who aren't quite as good but don't have to be
(effectively level 2) and the guys who do the level / ai scripting
(level 3). I would quite happily use D as a high level language in a
team where I had a good lower level team designing most of the stuff I
use with my level of expertise in mind as they designed it.

To this end the really critical things for me are that my level 1 guys
can create code that performs in low latency environments without
missing deadlines and can present their APIs in such a way that is
easy/enjoyable for us level 3 guys to use (see the batch processing
thread a little while back).