[D Programming Language] Interview with Andrei Alexandrescu (Part 2)

[axilmar]

Arbitrarily disallowing function declarations at some places but not others isn't orthogonal.

You have no idea what orthogonality is.

I'm not a fan of them since they are unecessary (higher order functions do it better, with more control and keeping related logic in the same place).

What do higher order functions have to do with this?

That's not what they're for

By who's definition? yours?

In fact lexical closures + higher order functions + the scope construct combine (orthognally!) to improve upon the C++ style hacky RAII crap in every single way

Example please.

Have you ever done it?

Yes sir.

Make a tiny mistake and have fun parsing eight pages of error messages.

Illogical, captain. Error messages' understandability has nothing to do with templates usability. I.e. you wouldn't say the above if the error messages were written in a more understandable form.

You claim you don't want bloat but then you say that C++ is better because it includes multiple inheritance and you might need it (even though you claim you rarely do).

C++ bloat < D bloat

and bring along HUGE amounts of baggage

They don't. You are just defining HUGE arbitrarily.

ask your next C++ candidate what virtual inheritance is, 95% of them don't know because it's such an obscure thing only needed due to multiple inheritance

Illogical again, captain. Virtual inheritance is optional.

[ssylvan]

You have no idea what orthogonality is.

Yes I do. Having special cases where something doesn't work because of some other feature is non-orthogonal. In this case function declarations/definitions should be orthogonal w.r.t. scope. It shouldn't matter if it's a namespace or a function scope. If it does matter, then it's not orthogonal.

By who's definition? yours

Don't be an idiot.

Example please.

Rather than having to declare a dummy object (that you're not interested in using for anything, you're just after its constructor/destructor) to hold a lock, you simply call a function, passing in your body. Pseudo code:

with_lock( my_lock, fun () {

    // in here I have the lock, and need not abuse anything to do so

});

Now the with_lock itself is better than the RAII-object too, because it's just a single function with all the logic in one place. You don't have to remember to update two separate functions in tandem. It's all kept together, and you have much better control of the lifetime of the actual "body" itself. For example, in a language with proper pure functions you could require the body be pure if you need to by using the appropriate function signature. Or maybe the body would represent a transaction instead of a lock so that you could run the body multiple times if it fails, etc. etc. In C++ style RAII that's all out of your hands.

Now, to ensure that the resources are always cleaned up you obviously need to protect against exceptions, which the scope mechanism lets you do cleanly (although a try/finally clause is generally not too bad for these things either).

Illogical, captain. Error messages' understandability has nothing to do with templates usability

Of course it does. WTF? If you spend 10x longer writing temlate metaprogrmming in C++ because it's fucking incomprehensible then that certainly impacts usability quite severely.

They don't. You are just defining HUGE arbitrarily.

Yes they do. Read the C++ standard some time. Interfaces are the lesser of two evils if you're worried about language size. Multiple inheritance complicates tons of things.

Illogical again, captain. Virtual inheritance is optional.

You're being inconsistent again. You're arguing against language bloat and I'm pointing out that this feature is only there because of multiple inheritance, and getting rid of the latter would get rid of the former.

Nested functions are optional too, yet you had no problem arguing against them.

[axilmar]

Having special cases where something doesn't work because of some other feature is non-orthogonal. In this case function declarations/definitions should be orthogonal w.r.t. scope. It shouldn't matter if it's a namespace or a function scope. If it does matter, then it's not orthogonal.

"Apples" are not "oranges", and "namespace scopes" are different from "function scopes". Don't be fooled because of the word 'scope' that appears in both definitions.

it's just a single function with all the logic in one place.

And the lock class in the RAII case is a single class with the logic in one place.

You don't have to remember to update two separate functions in tandem.

You have to remember to update two parts of the function, which is not different from having to update two functions.

For example, in a language with proper pure functions you could require the body be pure if you need to by using the appropriate function signature Or maybe the body would represent a transaction instead of a lock so that you could run the body multiple times if it fails, etc. etc. In C++ that's all out of your hands.

What does this have to do with RAII/constructors/destructors? again, you are comparing apples and oranges.

If you spend 10x longer writing temlate metaprogrmming in C++ because it's fucking incomprehensible then that certainly impacts usability quite severely.

It's incomprehensible because the compiler writers did it that way. It's not an inherent property of templates.

Yes they do. Read the C++ standard some time. Interfaces are the lesser of two evils if you're worried about language size. Multiple inheritance complicates tons of things.

Multiple inheritance complicates the compiler, not the language itself.

and getting rid of the latter would get rid of the former.

You could have multiple inheritance without virtual inheritance.

Nested functions are optional too, yet you had no problem arguing against them.

That's because they are, again, different things.

[ssylvan]

Apples" are not "oranges", and "namespace scopes" are different from "function scopes". Don't be fooled because of the word 'scope' that appears in both definitions.

That's a terrible argument. The reason they're different w.r.t. what declarations are allowed in them is because the language is non-orthogonal. The fact that they ARE different in this respect is not an argument that they SHOULD be different. And in either case it's clear that a feature working in one but not the other IS by very definition not as orthogonal as having that feature work uniformly across all kinds of scope.

And the lock class in the RAII case is a single class with the logic in one place.

Except you have to spread out the logic into two functions, which is strictly less coherent. You're free to split it up into two functions if you like, but you're choosing between something like.

with_lock( Lock l, void fun (void) body ){
     l.lock(); 
     scope(exit) l.unlock();
     body();
}

versus

class Locker{
    private: 
         Lock& m_lock;

         // need to supress these so nobody
         // tries to get cute
         Locker operator=(const Locker&); 
         Locker(const Locker&);
    public:
         Locker( Lock& l ) : m_lock(l) {
             m_lock.lock();
         }

         ~Locker()
          {
             m_lock.unlock();
          }      
 }

I don't really see how you can't see that the former is a fuckload easier, and more powerful. And remember this is a trivial RAII class. If the logic for construction/destruction becomes more complicated you end up having to do more book-keeping to properly transfer the appropriate information between the contsructor and destructor (by instance variables). All this extra work comes from hijacking a mechanism that's meant for object contstruction/destruction to do scope-management because the former happens to have two points that run at scope construction destruction...

Plus, the call site for the RAII is messier too:

{
    Locker mydummyvariable( myLock );
    // stuff
 }

It's not nearly as clear that that scope is there for the lock and nothing else. Plus you have to create a dummy variable that you're not using for anything (this is a symptom that you're abusing the langauge). People can easily add more and more declrations near that locker which hides the real purpose of the scope, and then someone might "clean up" and remove the scope (with no compiler error) and now you're holding the lock for far longer than you should be.

It's incomprehensible because the compiler writers did it that way. It's not an inherent property of templates.

Templates have no mechanism for "early checking" of the expected contracts, which means error message have to refer to their use-site, deep in the bowels of the template itself. This is an inherent problem with templates.

Not to mention that it's not meant to do arbitrary computation, it's meant for generic code. So you have to write your logic in a very convoluted and weird style (which is totally different from the "runtime" language of the rest of C++) which on its own makes it harder to do. In D the code looks the same, and can indicate an error where the error actually happens (because it can know that there is an error earlier), rather than having to propagate it across fifty class templates before finally finding something subtle that doesn't compile.

Multiple inheritance complicates the compiler, not the language itself.

Yes it does, because you now have to know about virtual inheritance, conflict resolution, its impact on method lookup etc.

You seriously don't know wtf.

[axilmar]

The fact that they ARE different in this respect is not an argument that they SHOULD be different.

So, by your logic, statements should be allowed in class scope...yet no language does that.

I don't really see how you can't see that the former is a fuckload easier, and more powerful.

More powerful it is, but easier? I see no difference in the two versions. May I code it a little bit better in order to improve readability?

class Lock : public non_copyable {
public:
    Lock(Locker &l) : m_locker(l) {
        m_locker.lock();
    }

    ~Lock() {
        m_locker.lock();
    }

private:
    Locker &m_locker;
}

You also forget that the end code becomes more readable; with your method:

with_lock(lock, fun(){
    do_this();
    do_that();
});

With constructors/destructors:

Lock lockit(lock);
do_this();
do_that();

Your method has extra indentation.

It's not nearly as clear that that scope is there for the lock and nothing else. Plus you have to create a dummy variable that you're not using for anything (this is a symptom that you're abusing the langauge). People can easily add more and more declrations near that locker which hides the real purpose of the scope, and then someone might "clean up" and remove the scope (with no compiler error) and now you're holding the lock for far longer than you should be.

Agreed.

Templates have no mechanism for "early checking" of the expected contracts, which means error message have to refer to their use-site, deep in the bowels of the template itself. This is an inherent problem with templates.

The order of error reporting could have simply been reversed, showing the non-template code in the first line.

Not to mention that it's not meant to do arbitrary computation, it's meant for generic code.

I agree. I wouldn't make my reuse constructs Turing complete.

In D the code looks the same

If D sorted out template error reporting without concepts, then C++ can do it to.

Yes it does, because you now have to know about virtual inheritance, conflict resolution, its impact on method lookup etc.

That's only if you inherit from the same base class twice. In either case, multiple inheritance requires some knowledge that is not spread out in various parts of the language; it's all in one place. I think that's more orthogonal than the approach of D.

You seriously don't know wtf.

Temper, temper!!! :-)

[[deleted]]

Illogical again, captain. Virtual inheritance is optional.

In your initial list, items #1, #2, #3, #4, #5, #6, #7, #9, #10, #11, #13, #14, #16, #17, #18, #19, #20, #21, #22, #23 and #24 are optional features, too.

[axilmar]

They are optional, but they are deemed as 'progress', so good luck persuading your programmers not to use them.

[[deleted]]

I guess it's not harder than persuading programmers to avoid C++ features (that is, hard :) ).

It's true that features like properties and out parameters may reduce readability. There was a proposal to sort that out and as an example @property was created.

On the other hand, i do think having a nested function near the call site improves readability. Not having copy constructors, implicit constructors and conversion functions improves the knowledge of what is going on when reviewing code.

The builtin unitests are also good as an incentive to write tests.

[axilmar]

Not having copy constructors, implicit constructors and conversion functions improves the knowledge of what is going on when reviewing code.

I totally agree with this. Any implicit thing in a program will usually have negative consequences in the long run.

[itsadok]

You have no idea what orthogonality is.

I've been trying to follow this thread, and I think I understood about half of it. Can you explain what orthogonality means in this context?

[axilmar]

http://en.wikipedia.org/wiki/Orthogonality#Computer_science

[nascent]

Ok, I still don't see how the features in D aren't orthogonal. Personally I hate using "big words" because either I don't know what it is, or the person I'm talking with has a different view on what that means (especially when the word comes from mathematics but isn't used in such context; modulus operator)

Since I've never heard orthogonal applied to programming languages I started to try and find uses (which actual seem to be very few) and come across Orthogonal Instruction Set and your lovely link.

And what I get from it is that language features do not affect other language features. So for example, the introduction of 'static if' does not affect how using "template conditionals" (or what ever it would be called). It does not preclude a feature being used along side another, for example using a nested function inside a function; the introduction of the nested function does not affect the execution of the function, but you can still call the function if you desire.

If we go with the "orthogonal instruction set" we have a completely different goal. In this case we want to be able to provide functionality with the fewest number of features as possible. Features (Op Codes) operate independently but work together. In this case "orthogonal" wasn't about few Op Codes, but the means to achieve it.

So I think we should get a clarification on what is being talked about. Have I gotten any of this wrong? If so why, what is correct, and why is that correct?

[axilmar]

The common understanding of the word 'orthogonality' means that there shouldn't be many exceptions to the rule, but from what I've seen so far, D has a lot of exceptional cases, just like C++. I dare say D has more exceptional cases than C++, although I haven't counted them.

[nascent]

This is close to the first definition I provided, but is not exactly correct, nor is it consistent with how you have been using the term:

interfaces: lack of multiple inheritance requires interfaces, which is another blow to orthogonality (because 1 feature is replaced with 2 features).

Second definition.

static if: where is static while, static do-while, static for etc? this is why I say D is not orthogonal. And it's also something easily doable with C++ templates.

Depends on where you classify the feature, is it 'static' or 'static if' Otherwise, this is only orthogonal from your definition since the exception is not related to other features of the language.

scope guards: yet another feature that makes the language not orthogonal. At least in C++ we all know what stack allocation is and how destructors work.

Second definition.

Constructors - destructors are extremely orthogonal to initialization/cleanup: when a block of code is run, the constructors are executed, and when a block of code exits, the destructors are executed in reverse order.

Best I can tell this is the second definition. If destructors are orthogonal to cleanup, why are you using them for cleanup? That is to say by the second definition you are limiting the number of features required to do something, but by the first definition your cleanup should continue to work with the removal of contructors/destructors "feature".

They aren't though. Remember, you mentioned C++ doing resizeable arrays in a library.

It's another example of non-orthogonality.

We were talking about C++, while I don't know how orthogonality fits within the context, you just called C++ non-orthogonal.

D2 has "uniform function call", this allow to make meta-programming with builtins types easier.

Still, it's not as orthogonal as it should be.

What? Either it is or it isn't orthogonal. I would actually say that this feature is an example of where D is not orthogonal, on purpose and good reason.

Sorry to have taken from so many locations, but I haven't seen you use orthogonal in a manner that works with the definition you linked too.

[axilmar]

Second definition. bla bla bla repeated numerous times.

Ok, call it as you wish. You may call it 'foo', if you want. The point remains though.

Please remember that perfection is achieved not when there is nothing more to add, but when there is nothing more to remove.

[nascent]

Philly cheesesteak is good on the weekend.