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