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
signature.asc
Description: This is a digitally signed message part