On Friday, 4 October 2013 at 23:38:17 UTC, Joseph Rushton
Wakeling wrote:
On 01/10/13 14:14, Dicebot wrote:
On Tuesday, 1 October 2013 at 12:02:29 UTC, w0rp wrote:
I'm waiting for Carmack to adopt D already. Barring some
implementation
details (GC issues, shared libraries, bla bla) it's pretty
much the perfect
language for what he wants to do. (Fast and functional in
parts.) Plus, if
anyone could work around issues or figure out how to do
really cool things
with D, it would be Carmack.
He is familiar with D and has shown appreciation for D `pure`
functions in his
twitter posts.
One thing that I noted in his QuakeCon talk was his remarks
about multiparadigm languages versus strictly functional
languages, and how the former while they seem superior have the
problem that, because you _can_ break the paradigm, you _do_.
I rather suspected he might have had D partially in mind with
that remark, although he was gracious enough to not single out
any languages.
That said, although I don't feel experienced enough in
functional programming to comment with any authority, my
impression is that D lets you be as strictly functional as you
want to be, and has enough to let software architects impose
strict purity etc. on a codebase. But it is arguably less nice
to have to keep marking "pure const nothrow ..." everywhere,
plus const/immutable parameters, compared to something like
Haskell where everything is that way by default.
I don't suppose it's possible to do that either by scope or
even by module?
module my.module const nothrow pure @safe
or
const nothrow pure @safe
{
// my code here ...
}
D has some really serious flaw when it come to functionnal style.
- Function aren't first class.
- Delegates break type system.
- Immutable object have identity issue that wouldn't show up in
a functional language. It is unsure what the semantic around them
is (and if identity must be preserved, then functional style is
badly impaired).
- Many qualifier do start to not make any sense when using
functions as arguments (inout for instance).
- Expect for type qualifier, it is impossible to express return
qualification depending on the input(s qualification (and see
point above, that do not work when using first class
functions/delegates).
On implementation side, heap allocated values aren't optimized to
go on the stack, ever. And the GC is unable to take advantage of
immutability. Note that because everything is immutable in
functional programming, both are mandatory if you don't want to
trash your performances.
