John Carmack on Eclipse performance

[deadalnix]

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.