Blaming the D language

[via Digitalmars-d]

On Wednesday, 22 October 2014 at 08:27:53 UTC, bearophile wrote:
> Ola Fosheim Grøstad:
>
>> 2. Easy to write ugly code: It suffers from the same issues as 
>> macros.
>
> Do you mean C macros? I think this is not true.

Not C macros, because they are free form and happen before 
parsing.

On the other hand, C macros can be expanded and then you do 
source-to-source translation. With D mixins you might have to 
evaluate CTFE first? That's a source-to-source killer.

I also think AST macros is a bad idea. It works well for Lisp 
where you have a clean minimal language.

>> 3. Language integration: It is desirable to have an 
>> application level language that can integrate well with a low 
>> level language when calling out to system level libraries.
>
> I don't understand.

Let's say you create a tight new language "APP-C" that is easy to 
write application code in, but you use libraries written in a 
system level language "D" when the more restricted new language 
falls short. Then you want to call into the D libraries using 
lambdas written in "APP-C". If those libraries (built on top of 
phobos) take string mixins, then you have to know both "APP-C" 
and "D" in order to write an application.

What you want is this:

1. Compile APP-C => common IR
2. Resolve dependencies
3. Compile D => common IR
4. Resolve lambda optimization/inlining on the common IR

With string mixins you get: eh…?

>> 4. Uniform conventions: a lambda is more generic.
>
> What's bad in using something less generic?

It is bad when you get the disadvantages that lambdas do not have 
(in an optimizing compiler), but don't get advantages?!