Help me decide D or C

Sat Aug 3 12:08:16 UTC 2019

On Fri, 2019-08-02 at 16:49 +0000, Alexandre via Digitalmars-d-learn wrote:
[…]
> 
> Do you thing D would be the right tool for the job at this point 
> for me? Assuming I have 2 goals in mind: 1) become a better 
> programmer and 2) want to make fun writing software for myself 
> and if possible show something I might be proud of.
> I thought C would be a better choice for the 1), because everyone 
> says it's great to see whats behind the hood and things like 
> that. My experience with C btw is CS50 course, plus around 
> 200/300 pages of some books, still reading and a few toy 
> projects. So, basically 0 knowledge. haha. But after reading your 
> opinion, I guess C might not be the right tool for me, since I 
> wont be doing any kind of thing related to hardware (I think).

Seeing what is behind the hood was important in the 1970s and 1980s because
the hardware was constrained and programming languages (other than perhaps
Lisp) were still trying to provide abstractions over the extant hardware. In
the 2000s and 2010s "seeing what is under the hood" is more or less irrelevant
for most applications programmers – this does not include people for whom hard
real time factors are critical to their software. Most application programmers
should be focusing on using the right algorithms and data structures for the
task and letting the compilers and their code generators worry about what is
"under the hood".

Programming for microcontrollers is a different game and C dominates there
still (I assume, it is over a decade since I was doing that stuff), and for
good reason, the algorithms and data structures are hardware oriented rather
than being abstract. And when your hardware has bit data structures, so does
your programming language: C compilers for 8051 and AVR chips have special
extensions to allow bit access.

As for your 2, what do you find fun to create software for? It is then a
question of choosing the language that best enables you to simply and easily
create the data structures and thence the algorithms for those problems. Being
able to show off software and be proud of it revolves around having the
simplest and most understandable expressions of the best data structures and
algorithms for the problem addressed.

C can be used for this but you end up hacking this very badly, and opening
yourself up to horrors such as buffer overrun. 

My pet project of the moment is a DVB player (Me TV). It was originally a C
program authored by someone else who then began transforming it to a mixed
C/C++ system. It's original goal was to compete with MythTV and Kodi, but it
lost. When I picked it up I decided to strip it all back so as to be a
lightweight player to complement rather than compete with MythTV and Kodi. It
became very clear, very quickly that C++11 and indeed C++14 were not the right
tools for the job (poor support for messaging between threads being the single
biggest problem). I decided to do a re-write from scratch in D using GtkD and
GStreamerD. It all went well, D provided all the tools for creating the right
abstractions; the right data structures and algorithms were easy to express
and the libraries gave really good access to the underlying C libraries.

But… the GStreamer folk had rejected D as an officially supported language for
plugins and official API wrapper/binding support. Does this matter given
Mike's efforts keeping GtkD and GStreamerD up to date? In my case yes. I had
to get involved in amendments to GStreamer itself and developing new API
wrapper. I guess I could have kept going with D as the implementation language
for Me TV, but it seemed right to switch to Rust, which is officially
supported by the GStreamer folk, so lots of extra support for GStreamer
changes and wrapper writing (I guess I will end up doing a D version for Mike
to add to GStreamerD). It turns out that Rust is actually the wrong tool for
the job of working with GObject systems and yet the GStreamer folk chose Rust
because they abhorred C++ and assumed D always came with a garbage collector
(which is true in this case) and they have a morbid hatred of garbage
collection (true for some bits of GStreamer which are hard real time). What
the gtk-rs people have done though is to provide an excellent (albeit not
totally complete as yet) Rust inheritance system for GObject-based code. Of
course D has inheritance and so no problem, D is better than Rust for this.
Objectively D is the better language for GObject-based software, and yet Rust
is in the driving seat.

Is this another "everyone used C for applications programming but shouldn't
have done" moment? Almost. Rust is fine for those cases where composition is
the right abstraction approach. D can also do this, ditto Go, and indeed Java,
Kotlin, etc. Where a core abstraction requirement is inheritance, as in
GObject-based systems, D beats Rust. And yet the gtk-rs folk have used Rust
anyway and created the abstractions.

What is the moral behind this story of mixed messages? There are many, some
are: prejudices can make people make the wrong choices and then patch things
up; using the right libraries is always a good idea; sometime you make a
choice based on accepting some negative aspects just trying to maximise the
positive ones.   

What I haven't mentioned as yet is editor/IDE support, this must not be
underestimated. Support for writing Go, Rust, C, C++, Java, Kotlin, etc. code
is very strong. Originally a vi person I switched to Emacs and have been an
Emacs addict since the mid 1980s. The came the IDE, and I have become a bit of
a JetBrains fan. CLion, Goland, IntelliJIDEA, and PyCharm are sponditious.
They make Emacs seem a bit pathetic for developing Go, Rust, C, C++, Java,
Kotlin, Groovy, etc. code.

CLion support for Rust makes writing Rust code easier.

There is a the beginnings of a D plugin (indeed I ought to be helping work on
it but am failing to do that), but the Rust plugin is already wonderful. This
is mostly because JetBrains see an income stream form supporting Rust, but see
no such income stream from supporting D. This is arguably D biggest problem,
the editor and IDE supprt for D is second, even third, rate compared to the
support available for Go, Rust, Java, Kotlin, Groovy, C, and C++. No matter
how good a language is, it is only as good as the editor and IDE support.

So despite D being better than Rust for Me TV, I use Rust because the
inheritance issue is patched up in the gtk-rs library, and I can develp the Me
TV software, and especially debug SIGSEGV, far better in CLion using Rust than
trying to use D. Sadly there seems to be a inherent belief in the D community
at large that VIM (or Emacs) is all you need. For those individuals that may
be true. However Visual Studio and CLion is where the native code development
action is for programmers who want an easier life.

> I have receive so many good opinions so far. I realize there is 
> no consensus what so ever. As I was suggested Haskell, Python, D, 
> C etc. It's a good thing, but hard to make a decision.

Lots of people means lots of opinions! But the arguments were sensible and
presented in good faith: they just reflected the variables: what programming
do you already know; what is the software being written for; and what is the
execution platform of the software once written. This must lead to many
variations, and so in the end an individual in a given situation has to
"plump" for a choice, and then follow through.

Without knowing the problem that are fun for you it is difficult to pin things
down further than D, Go, Rust, Java, and Kotlin are all good languages for
writing applications. 

-- 
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-learn/attachments/20190803/458de77a/attachment.sig>