Blog post: What D got wrong

Russel Winder russel at winder.org.uk
Tue Dec 18 08:17:28 UTC 2018


On Mon, 2018-12-17 at 12:16 -0800, Walter Bright via Digitalmars-d-announce
wrote:
> […]
> 
> Going pure, however, is much harder (at least for me) because I'm not used
> to 
> programming that way. Making a function pure often requires reorganization
> of 
> how a task is broken up into data structures and functions.
> 
> […]

I can recommend a short period of working only with Haskell. And then a short
period working only with Prolog. Experience with Java and Python people trying
to get them to internalise the more declarative approach to software, shows
that leaving their programming languages of choice behind for a while is
important in improving their use of their languages of choice.

For Java people this is quite easy since there is Frege (an implementation of
Haskell on the JVM) and Clojure (a Lisp on the JVM). They do not have to leave
the comfort of their JVM to get away from Java. On return to Java, people's
use of Option<T>, and lambda expressions, etc. was markedly different – and a
lot more declarative, making testing as well as comprehensibility of their
much better.

For Python people you have to play slightly different games, such as requiring
no use of for and while loops, since there is no pure declarative language on
the PVM – the computational model of the PVM actually makes declarative
programming quite hard, but it is possible, and it improves code
comprehensibility and testability.

The problem for people immersed in the C, and C++ world is internalising
declarative as a concept. I have tried, and failed a few times, as well as
succeeding some. As C++ evolves towards being more and more declarative, it
seems hard for the average C++ programmer to really move on from "old style
C++", despite all the literature on "modern C++". But as the standards
committee drag C++ along the increasingly declarative code route, things
change, albeit relatively slowly. 

Rust I feel has a pivotal role in all this. By emphasising the ML view on
mixed declarative and imperative programming, it has found an interesting
middle ground that seems to work very well. Many of the C programmers who
though C++ overcomplicated and not worth looking at, are taking to Rust and in
doing so leaving C behind.

On a personal level, I am now doing most of my programming in Rust rather than
D, but this is as much to do with the GStreamer community choosing Rust as the
replacement for C for GStreamer. But this is from a library implementers
perspective, rather than an application perspective – but the choice pushes
through. D (with GtkD and GStreamerD) is in many ways as good a choice as gtk-
rs and gstreeamer-rs for writing applications – except:

– documentation for gtk-rs and gstreamer-rs is better than for GtkD and
GStreamerD; and
– the standard Rust executor and futures system has been integrated into gtk-
rs, something not present in GtkD.
– GStreamer core developers have an obsessive fear of the word "garbage
collector".

I did a lightning talk at the GStreamer conference in Edinburgh a couple of
months ago, concluding that I think D (which about half the audience knew of)
is overall better than Rust for GTK+ and GStreamer applications, but
recognising that Rust is actually the replacement for C and C++ for GTK+ and
GStreamer applications. (Obviously Python has an ongoing role in all this as
well.)

I think D has missed the opportunity to get significant traction in the GTK+
and GStreamer milieus. :-(
 

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20181218/52a8989c/attachment.sig>


More information about the Digitalmars-d-announce mailing list