On Wednesday, 31 July 2019 at 18:38:02 UTC, Alexandre wrote:
> Should I go for C and then when I become a better programmer change to D?
> Should I start with D right now?

In my view, the most important thing is the decision you've already made - to pick a programming language and learn it in a reasonable bit of depth. Which programming language you choose is less important. No matter which choice you make you'll have the opportunity to learn skills that will transfer to other programming languages.

As you can tell from the other responses, the pros and cons of a learning a specific language depend quite a bit on what you hope to get out of it, and are to a fair extent subjective. But both C and D provide meaningful opportunities to gain worthwhile experience.

A couple reasons for considering learning D over C are its support for functional programming and templates. These were also mentioned by a few other people. These are not really "beginner" topics, but as one moves past the beginner stage they are really quite valuable techniques to start mastering. For both D is the far better option, and it's not necessary to use either when starting out.

--Jon

On Friday, August 2, 2019 11:05:13 AM MDT Russel Winder via Digitalmars-d- learn wrote:
> On Fri, 2019-08-02 at 10:25 -0600, Jonathan M Davis via Digitalmars-d-learn wrote:
>
> […]
>
> > My feeling is that functional languages are likely to be a very poor place for most folks to start learning, much as I think that they're great for someone to learn and work with at some point. I have heard of beginning programming classes using functional languages and having it go very well, but it seems hard to believe to me. Imperative programming can already be a lot for beginners, but most people really don't think even vaguely in a functional manner. Even simple recursion tends to be a bit of a mind-bender for people at first.
>
> […]
>
> At UCL in the late 1980s and early 1990s, we used a functional programming language in the first term and C++ in the second term for teaching programming. Initially Scheme was the functional programming language but we then switched to Miranda (which was a pre-cursor to Haskell).
>
> This deep immersion in two totally different programming paradigms worked very well. The mid/late 1990s mad rush to Java everywhere in teaching (of which I was a part) was in hindsight madness (of a global sort). The move by many institutions to using Python first and then Java rebalances somewhat but is missing the point – it's about the paradigms. I have retrenched as a believer in the Haskell/C++, or Prolog/Java, or some such. In the new era with new undergraduates already knowing Scratch and Python, universities should really go the whole hog in getting programming paradigms and programming as a skill as well as knowledge, with all the tools,fair and square into the first year curriculum.
>
> Of course I have been out of academia for 20 years, and am now out of employment, so my views have no impact. :-)

The university I went to had an undergrad class on programming paradigms that I _think_ was required (maybe two even), but it was definitely just the focus of a small number of classes, whereas my experience is that you get a lot more out of it when you actually use a language with a different paradigm for a while rather than just doing one group of assignments in it - and when the class covers multiple programming paradigms, that also dilutes how much you get out of each. On some level, as with many things, a lot of it depends on how much the students decide to put into it on their own.

I still find it funny that the class that got me started with Haskell was the grad version of the programming paradigms course, and we used Haskell only because the teacher was always using Scheme (in fact, he was a developer for Dr. Scheme IIRC) and felt like doing something different. So, while I'd used Scheme some in an undergrad course, I ended up using Haskell in the course with the teacher who was majorly into Scheme. It seemed a bit like if one of the major D contributors decided to use Rust for a bit just to try something different.

Of course, I haven't done anywhere near as good a job at learning new
languages for a while now, because I've been focused enough on D that I
haven't really wanted to spend time writing programs in something else. And
I don't think that it works very well to really learn a language if you
don't use it as your go-to language for a while (at least if you want to
be good at more than the basics). There's no question though that I'm better
at D thanks to the time I spent on languages such as Haskell.

- Jonathan M Davis

On Fri, 2019-08-02 at 17:25 +0000, berni via Digitalmars-d-learn wrote:
> […]
> 
> Yes, that was intentional. What I wanted to say is, that I think, that it would have been better, if C was never invented at all... In that case, there would have been space for an other language for writing operating systems, without that much bugs in its design. (But one never knows afterwards...)

If C had not been invented by Ritchie, Thompson, et al., something very like it would have been invented by someone else. BCPL and B were not really gaining the traction they perhaps should have had, and Algol, Algol68, FORTRAN, PL/1, COBOL, etc. were not really designed for writing operating systems.

https://en.wikipedia.org/wiki/Timeline_of_programming_languages

The problem was not the invention of C, the problem was all those programmers who stopped thinking about using the right tool for a given task in a given context, and started using C for all programming situations. But it happened, it is read-only history. Rust, D, and Go are the current ways out of the tragedy that was using C for applications programming. C++ is finally catching up.

-- 
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

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

On Fri, 2019-08-02 at 23:24 -0600, Jonathan M Davis via Digitalmars-d-learn
wrote:
[…]
> The university I went to had an undergrad class on programming paradigms that I _think_ was required (maybe two even), but it was definitely just the focus of a small number of classes, whereas my experience is that you get a lot more out of it when you actually use a language with a different paradigm for a while rather than just doing one group of assignments in it - and when the class covers multiple programming paradigms, that also dilutes how much you get out of each. On some level, as with many things, a lot of it depends on how much the students decide to put into it on their own.
[…]

UCL used to have a 10 week module that tried to do three language to show that different programming languages were best for different problems. Prolog, Snobol, and ??? were the trio when we terminated the module as not being effective. This reinforced having a third programming language module in the compulsory programming sequence so as to have 10 weeks per language rather than three. Still not really long enough but it worked a lot better.

I think universities will be far better able to teach programming now that
entrants already know Python (to a greater or lesser extent). The single
biggest problem will be (has always been) having academics on the staff
competent and willing to put on programming courses. Far too many academics in
universities are truly crap programmers and are the last people you want to
show their crapness to students.


-- 
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

On Fri, 2019-08-02 at 20:24 +0000, Jon Degenhardt via Digitalmars-d-learn
wrote:
[…]
> In my view, the most important thing is the decision you've already made - to pick a programming language and learn it in a reasonable bit of depth. Which programming language you choose is less important. No matter which choice you make you'll have the opportunity to learn skills that will transfer to other programming languages.
> 
[…]

Knowing what a given programming language is best for is core here: so no using Prolog to try and write an operating system on real hardware.

Knowing many paradigms well is proven experimentally (see the work by Petre, Green, Gilmore, and others) to improve capability in any given language. So knowing Java, Prolog, Lisp, Python, SQL, C, Go, Rust, D, Kotlin, Groovy, Ruby to a goodly level of competence makes you a better programmer in any one of them.

So no matter which language you learn always plan to learn others. In this sense C and D are equal, but for applications I'd choose D over C.


-- 
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

On Saturday, 3 August 2019 at 12:29:18 UTC, Russel Winder wrote:

>
> Knowing many paradigms well is proven experimentally (see the work by Petre, Green, Gilmore, and others) to improve capability in any given language. So knowing Java, Prolog, Lisp, Python, SQL, C, Go, Rust, D, Kotlin, Groovy, Ruby to a goodly level of competence makes you a better programmer in any one of them.


Thank you Russel Winder. Thanks to your comment, I was able to find the book you spoke of and ordered it immediately.
For those who may be interested, here it is:
Psychology of Programming (Computers and People Series), written by J-M Hoc, T.R.G. Green, R. samurcay, & D. Gilmore, published in 1991 by Academic Press.

As for me, it is interesting to notice that the authors of this book work for Inria, the same French Institute who created F* language in partnership with Microsoft Research, along with Low*, a subset of F* language and its librairies, focused on C features (e.g. the C memory model, stack and heap-allocated arrays, machine integers, C string literals, etc.).
See https://fstarlang.github.io/lowstar/html/Introduction.html for more details.

It is really refreshing for the community to have someone like you who keep connections with other languages, technologies and paradigms.

I wish you the best!