Hello,
I want to become fluent in the use of functional programming techniques in D (as well as the use of ranges) using std.functional (and std.algorithm and whatever else is relevant). Is there anything out there that isn't just module documentation that covers the full scope of this?

On Wednesday, 9 October 2019 at 14:26:53 UTC, NonNull wrote:
> Hello,
> I want to become fluent in the use of functional programming techniques in D (as well as the use of ranges) using std.functional (and std.algorithm and whatever else is relevant). Is there anything out there that isn't just module documentation that covers the full scope of this?

I had this same feeling about wanting to learn `std.functional` a bit more, so I decided to do https://adventofcode.com/ with additional constraints that the code would be functional D with as many unit tests as I could manage.  I learned a bunch and had a lot of fun with it.

On Wed, Oct 09, 2019 at 05:41:02PM +0000, Jonathan Gerlach via Digitalmars-d-learn wrote:
> On Wednesday, 9 October 2019 at 14:26:53 UTC, NonNull wrote:
> > Hello,
> > I want to become fluent in the use of functional programming
> > techniques in D (as well as the use of ranges) using std.functional
> > (and std.algorithm and whatever else is relevant). Is there anything
> > out there that isn't just module documentation that covers the full
> > scope of this?
> 
> I had this same feeling about wanting to learn `std.functional` a bit more, so I decided to do https://adventofcode.com/ with additional constraints that the code would be functional D with as many unit tests as I could manage.  I learned a bunch and had a lot of fun with it.

Actually, std.functional is somewhat of a misnomer. It mostly deals with higher-order functions, i.e., functions that return functions, currying, that sort of thing.  These are part of functional programming, but there's more to functional programming than that.  I'd say std.range and std.algorithm are another major part of functional-style programming support in D, along with the purity system.

Here are some resources that might help get you started:

	https://klickverbot.at/blog/2012/05/purity-in-d/
	https://tour.dlang.org/tour/en/basics/ranges
	http://ddili.org/ders/d.en/ranges.html
	http://dconf.org/2015/talks/davis.html
	http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1
	http://wiki.dlang.org/Component_programming_with_ranges


T

-- 
What did the alien say to Schubert? "Take me to your lieder."

https://garden.dlang.io/

On Wednesday, 9 October 2019 at 18:57:01 UTC, SrMordred wrote:
> https://garden.dlang.io/

This should be more prominent. Very nice.

On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via Digitalmars-d-learn wrote: […]
> Actually, std.functional is somewhat of a misnomer. It mostly deals with higher-order functions, i.e., functions that return functions, currying, that sort of thing.  These are part of functional programming, but there's more to functional programming than that.  I'd say std.range and std.algorithm are another major part of functional-style programming support in D, along with the purity system.
[…]

I feel that it is best to leave functional programming to functional programming language, e.g. Haskell, Scheme, etc. rather than try to do functional programming in imperative languages, e.g. Java, C++, Rust, D. The reason is things like lazy evaluation and the consistency of everything being a function, etc. The underlying computational models of functional programming languages and imperative programming languages need different mindsets to use well. Witness the issues in using Scala.

Having said this, declarative programming can be pursued in functional languages, logic languages (e.g. Prolog), and imperative languages. Tools such as higher order functions are crucial to this, but currying is not, unless it is core to partial evaluation as it is in Haskell.

Modern C++, D, Rust – but not Go – all admit programming using a declarative way of working just as Haskell and Scheme do. My experience of emphasising declarative programming in imperative languages is that people build smaller, more comprehensible, and maintainable code that achives the goal compared with using tradition imperative programming.

-- 
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 Thu, Oct 10, 2019 at 09:59:49AM +0100, Russel Winder via Digitalmars-d-learn wrote:
> On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via Digitalmars-d-learn wrote: […]
> > Actually, std.functional is somewhat of a misnomer. It mostly deals with higher-order functions, i.e., functions that return functions, currying, that sort of thing.  These are part of functional programming, but there's more to functional programming than that. I'd say std.range and std.algorithm are another major part of functional-style programming support in D, along with the purity system.
> […]
> 
> I feel that it is best to leave functional programming to functional programming language, e.g. Haskell, Scheme, etc. rather than try to do functional programming in imperative languages, e.g. Java, C++, Rust, D.
[...]

Note this is why I wrote "functional-style programming" w.r.t. D, rather than "functional programming". Clearly, what D has isn't "real" functional programming in the strict sense, but it does share similar characteristics when written in that style.


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton

On Thu, 2019-10-10 at 03:08 -0700, H. S. Teoh via Digitalmars-d-learn wrote: […]
> Note this is why I wrote "functional-style programming" w.r.t. D, rather than "functional programming". Clearly, what D has isn't "real" functional programming in the strict sense, but it does share similar characteristics when written in that style.

Indeed, I was trying to support that view. I think declarative rather than
functional-style is a better label for this since it avoids the functional vs
imperative paradigm conflict left over from the late 1980s and 1990s.

-- 
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 Thursday, 10 October 2019 at 10:08:14 UTC, H. S. Teoh wrote:
> On Thu, Oct 10, 2019 at 09:59:49AM +0100, Russel Winder via Digitalmars-d-learn wrote:
>> On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via Digitalmars-d-learn wrote: […]
>> > Actually, std.functional is somewhat of a misnomer. It mostly deals with higher-order functions, i.e., functions that return functions, currying, that sort of thing.  These are part of functional programming, but there's more to functional programming than that. I'd say std.range and std.algorithm are another major part of functional-style programming support in D, along with the purity system.
>> […]
>> 
>> I feel that it is best to leave functional programming to functional programming language, e.g. Haskell, Scheme, etc. rather than try to do functional programming in imperative languages, e.g. Java, C++, Rust, D.
> [...]
>
> Note this is why I wrote "functional-style programming" w.r.t. D, rather than "functional programming". Clearly, what D has isn't "real" functional programming in the strict sense, but it does share similar characteristics when written in that style.

I did programming in Smalltalk for about 10 years. Smalltalk has all those things that are now called "functional-style programming" or even IMHO incorrectly "functional programming" that are about applying operations on collections. In Smalltalk these functions (like collect, map, reject, detect, inject, etc.) are simply called "collection iterators". They already exist in Smalltalk-80, which is called that way, because it was published in 1980. To verify this you can download the Smalltalk-80 "blue book" from here and do a text search on these function names: http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

In those 10 years where I did Smalltalk development I met no one who called making use of those collection iterators functional programming. There are several books about Smalltalk who have some importance in CS, because Smalltalk was the first truly useable OO language afer Simula. I don't think the term functional programming is ever used there.

Calling collection iterators functional programming opened Pandoras box of mixing up things. I fear it is too late to explain to people that functional progeramming is what is done in Haskel and Lisp and related languages and nothing else.

Collection iterators carry some aspects of functional programming such as non-destructive programming as the result of applying a function on a call returns a new collection leaving the original collection unchanged, but that alone is not enogh for things to be called functional programming. It is merely simply making use of closures.

On Thursday, 10 October 2019 at 10:08:14 UTC, H. S. Teoh wrote:
> On Thu, Oct 10, 2019 at 09:59:49AM +0100, Russel Winder via Digitalmars-d-learn wrote:
>> On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via Digitalmars-d-learn wrote: […]
>> > Actually, std.functional is somewhat of a misnomer. It mostly deals with higher-order functions, i.e., functions that return functions, currying, that sort of thing.  These are part of functional programming, but there's more to functional programming than that. I'd say std.range and std.algorithm are another major part of functional-style programming support in D, along with the purity system.
>> […]
>> 
>> I feel that it is best to leave functional programming to functional programming language, e.g. Haskell, Scheme, etc. rather than try to do functional programming in imperative languages, e.g. Java, C++, Rust, D.
> [...]
>
> Note this is why I wrote "functional-style programming" w.r.t. D, rather than "functional programming". Clearly, what D has isn't "real" functional programming in the strict sense, but it does share similar characteristics when written in that style.
>
>
> T

An even better phrase is simply "good programming practice". Avoiding global mutable state, writing pure functions, passing around functions as arguments, and letting the language handle iteration rather than using for loops and related outdated constructs is good practice. You might need to make exceptions for performance reasons, but then you're in the realm of hacks rather than practices.