Help here: How did you get started with D.

[H. S. Teoh]

> On Saturday, 4 July 2020 at 10:32:12 UTC, aberba wrote:
> > I'm looking to do a general but brief post on getting started with
> > D.  Not everything will be written by me since I'm aware there's
> > several existing resources...more of creating an entry point to all
> > those resources (and writing more only when necessary). I'm looking
> > to cover areas such as:
> > 
> > * Pros of D... general D's strength kind of getting you excited.

Where do I even begin... :-P  When I first found D, I was looking for a
better programming language than C/C++.  Had been using C/C++ for at
least a decade by then, but was becoming increasingly dissatisfied.

Initial impressions (in no particular order):
- Pros:
   - Compiled language (I was, and still am, skeptical of VMs).
   - Cleaner template syntax.
   - Built-in AA's.
   - Sane string handling.
   - Syntactic similarity to C/C++.
   - Binary compatibility with C/C++.
- Cons:
   - GC: having been burned by early, poorer GC implementations in Java
     way back when, and having acquired tons of GC Phobia from C/C++, I
     was a big skeptic of GCs.

Later impressions (also in no particular order):
- Pros:
   - Metaprogramming: the biggest reason I still use D in spite of its
     flaws.
   - GC: yeah, I had an about-face on this one. Andrei's article about
     GC performance convinced me to at least give D a try. Gradually I
     discovered the advantages of GC and have been loving it ever since.
   - Arrays & slicing.  Strings as arrays: not perfect, but practical,
     convenient, powerful.
   - Ranges.
   - Built-in unittests.  The quality of my code improved by leaps and
     bounds because of this one feature alone.
   - Delegates: used correctly, they can really clean up your code by
     minimizing unnecessary dependencies.
   - foreach
   - final switch
   - compile speed
   - `dmd -`, the single best thing that's ever happened to DMD, which
     allows D one-liners to replace messy shell scripts.
   - The smooth transformation from throw-away script to full-fledged
     program over time.
   - Multi-paradigm: fit the language to your problem domain, rather
     than contorting your problem to fit the language's straitjacket.
   - Many others too numerous to list.
- Cons:
   - Corner-case inconsistencies in the language, like the haphazard
     is() expressions, shared, ref, etc.. Fortunately these are
     relatively rare.
   - C-style integer promotion. Esp. auto-promotion from narrow ints to
     int, which are an annoyance.
   - Old Phobos modules that aren't up to the standard of modern D.
   - Mismanaged/missed opportunities and indecisions due to community
     disagreements.
   - dub: really needs to either embrace and allow easy interop with
     existing build frameworks like make, scons, etc., or else provide a
     big enough value in functionality and QoI to provide a compelling
     reason to adopt its mode of usage. Currently it tries to do what
     e.g. Gradle does, but poorly, so it neither satisfies interop with
     make-likes nor does what it does well enough that one might find a
     compelling reason to switch.


[...]
> > * Leaning resources.

TDPL: the one reason I dived deep into using D instead of just wading on
the shallow end of the pool writing hello world programs.

Also dlang.org docs. For all of its flaws, the online docs have come a
long way, and definitely better than when I first started (there was
almost no docs, and what was there was incomplete, outdated, and
generally not very useful).

The forums/mailing lists. People are generally very helpful.

Reading Phobos source code is also highly recommended for the serious
programmer -- except for a few dirty/ugly corners, it's generally a lot
more readable than other languages' standard lib source code. (Try
reading glibc source code, for example. Or ncurses. Or maybe, don't;
they will give you a splitting headache for days.)


[...]
> > * Development tools available in D Window, Linux, Mac

Linux: dmd, ldc2 are really all I need. Linux is my IDE. :-D

For editing code, I use vim.  For builds, any sane build system would
do, like tup or scons.  If you must, use dub for fetching dependencies,
but personally I'd just use a dummy empty project just for pulling in
dependencies, and doing the actual build with a real build system
instead.

For profiling, I recommend google-perftools.


> > * Setting up a development environment

	apt-get install vim scons gdb

Ready! ;-)


[...]
> > * Resources for game and graphics developers

For simple casual 2D games, I highly recommend using Adam Ruppe's arsd.*
libraries.  No fuss, no muss, they get right on the job, have no frilly
dependencies, and generally work great for getting things up and
running immediately.

For larger projects, though, it's true there's somewhat of a vacuum.
There's Derelict (which I've been meaning to try but never got around to
is for, oh, a decade now :-/).  If you want a full-fledged modern 3D
engine, consider using D's C interop features to interface with an
existing one, like Unity. (No idea how well that works in practice,
though.)


[...]
> > * How and where to get help

This forum, and the D.learn forum.  Apparently some helpful people like
Adam are on IRC as well, and apparently also on Reddit.  Don't use those
places myself, though.


[...]
> > * How to contribute to D

1. Discover a problem (e.g., in Phobos).

2. File a bug.

3. Get impatient with slow response (or total lack thereof), and go read
   Phobos source code yourself.

4. Discover how readable Phobos source code is, fix the bug yourself,
   submit a PR.

5. Take a good, long nap.  Well, more like hibernation, until some kind
   reviewer soul takes pity on your languishing PR and gives feedback.

6. Fix all issues raised, take another good, winter-long nap as the
   autotester churns along its days-long backlog.

7. Wake up to find PR merged. Profit!

;-)

(Alternative to step 5: raise holy hell in the forums until enough
people pay attention to your PR, then go to step 6.)


Or, another scenario:

1. Discover some missing functionality that you need.

2. File an enhancement request / beg for somebody to write this for you
   on the forum.

3. Lose patience over the lack of change/progress / get tired of the
   never-ending debates that never result in any actual work getting
   done, and proceed to write the darned thing yourself.

4. Publish the code on github / code.dlang.org, brag about it on the
   forums, and earn lots of gratitude and praise.

5. Profit!

;-)


T

-- 
EMACS = Extremely Massive And Cumbersome System