Grafting Functional Support on Top of an Imperative Language
Jarrod
qwerty at ytre.wq
Fri Apr 4 22:14:01 PDT 2008
On Fri, 04 Apr 2008 14:46:26 -0700, Walter Bright wrote:
> Andrei Alexandrescu's talk just given at ACCU:
>
> http://www.digitalmars.com/d/2.0/accu-functional.pdf
I'm going to get grilled for this post.
D is a great imperative language.
D is a terrible functional language.
This might sound harsh, but it's true. Functional languages need a lot of
special features to be what they are. They need to have statements that
work as expressions, unique data structures like chained lists, the
ability to heavily compress statements so as to prevent using temporary
values that us imperative programmers do enjoy so very much. Some
functional languages (in fact, arguably the 'cleanest' functional
languages like forth and joy) require the use of a special 'stack' to
manage data.
D does not have these features, and unless you want to completely change
what D is, D cannot have these features.
Now, I'm all for the non-breaking things that functional languages have
graced us: map, filter and range, tail recursion optimization, even
simple forms of 'pure' functions are nice as well.
But this whole const and pure thing is looking pretty ugly.
Imperative programmers use const/invariant datasets as a contract; a way
to set out guidelines for how their data should be used. Functional
languages take it a step further and force all data to be immutable,
making it a rule, not a guideline to use immutable data.
The meaning of const changes between these two paradigms, and I think
it's going to cause a lot of problems within D when they mix, especially
when functional languages keep all this immutable stuff conveniently
hidden away inside lists and stacks that the programmer doesn't have to
worry about.
I guess what I'm trying to say is functional languages are good at what
they do because they are functional languages. D is not a functional
language, and as such trying to use it as one is probably just going to
end up painful. If you want D to work like a functional language, turn it
into a functional language Walter. Force all data to be immutable by
default, all functions to be pure unless they prove otherwise, add native
support for lists and tuples and add a bunch of list manipulation
functions..
Heck, why not make a functional dialect of D? Call it "D flat" and have
it compile alongside D or something. No need to mix the two.
The current imperative/OO style of D is brilliant, fun to use, flexible
and just packed with lovely features. Please don't go killing it on me by
trying to make it an ugly jack of all trades.
More information about the Digitalmars-d
mailing list