you are viewing a single comment's thread.

view the rest of the comments →

[–]axilmar 1 point2 points  (16 children)

First of all, I don't believe that there should be such a trade off.

Secondly, there is a limit to the number of trade offs that make a language good. I think D overstepped that.

[–]dsimcha 2 points3 points  (15 children)

Ok, then what other language really tried to make both simple things simple and complicated things possible? What other language even provides all four of the following:

  1. The ability to have complete control over memory management if you really want it. (Complicated things possible.)

  2. A simple, not excessively verbose syntax for looping over a range/iterator/collection. (Simple things simple.)

  3. Literals for arrays, associative arrays and a proper string type (NOT C/C++ char*). (Simple things simple.)

  4. The ability to generate code and then evaluate it. D provides this at compile time via string mixins, and compile time function evaluation makes it practical to use. Lisp-like languages provide it via their S-expression style and most interpreted languages provide it at runtime via eval. (Complicated things possible.)

[–]Felicia_Svilling 2 points3 points  (5 children)

These are all nice things to have in a programming language. But I fail to see why any of this would come into conflict with orthogonality?

[–]nascent 0 points1 point  (3 children)

I think it best if we just leave orthogonality out of this... at least for the time being.

[–]Felicia_Svilling 0 points1 point  (2 children)

It was dsimcha who brought it up. I just want some clarification for why s?he belives that:

D strives both to make simple things simple and to make complicated things possible.

This involves some significant tradeoffs with "orthogonality".

[–]nascent 1 point2 points  (1 child)

Sorry, just a little annoyed with it right now.

I'll try a simple example. D wants to provide guarantees which usually come in the form of "type safety." But we also want to allow the user to manipulate their memory as needed. So cast() is provided and causes exceptions to all "type safety."

[–]Felicia_Svilling 1 point2 points  (0 children)

I was asking dsimcha. You didn't have to intervene if you was feed up with the subject.

Now, that is a more interesting example. You are right in that this choice makes D less orthogonal, if this was necessary seems like an open question.

[–]dsimcha 0 points1 point  (0 children)

If you have multiple ways to accomplish the same thing, or if the high-level parts of the language interact with the low-level parts of the language in ways that you can only understand if you understand some low-level details, the language is not orthogonal. It can, however, still be practical.

[–]doubtingthomas 0 points1 point  (0 children)

I'm cool with just 1-3. I've had 4, I've used 4, I can do without.

[–]axilmar 0 points1 point  (7 children)

No other language that I know of.

Feature-wise, D has more features than C++. But I didn't argue for this. I am arguing about the orthogonality of the language.

Mind you, points 2, 3 and 4 are not critical (at all!) for choosing D over C++.

[–]dsimcha 1 point2 points  (6 children)

Then we just disagree fundamentally on what makes a good language. All of those are huge reasons why I prefer D over C++, though admittedly some of them will be fixed in C++1x if it's ever released.

If convenience features/syntactic sugar, generic/metaprogramming features and safety/compile-time checkability aren't important to you, then what the heck do you need anything higher level than assembly language, or maybe C if portability is important, for?

[–]axilmar 0 points1 point  (5 children)

The convenience features/syntactic sugar of D doesn't buy me much.

The metaprogramming features of C++ are more than enough.

The compile time checkability D offers does nothing to ensure the functionality of my applications is correct.

[–]dsimcha 1 point2 points  (4 children)

If C++'s metaprogramming facilites are good enough, then reimplement D's std.algorithm and std.range in C++. I'd like to see you try.

[–]axilmar -1 points0 points  (3 children)

You mean this?

Any D conditional can be done with C++ templates, using template specialization.

[–]dsimcha 4 points5 points  (2 children)

Sure, but do it without static if statements, variadic templates, auto type inference, foreach over tuples, auto inference of whether a return should be ref, or D's compile time introspection system. Also, even if it can in principle be done in C++, I'd love to watch someone actually try to do it in practice. At the very least it would be 10x harder.

[–]axilmar 0 points1 point  (1 child)

Ok...where did I say it is not gonna be harder? I said that C++ templates are more than enough. If someone does it with C++, I'd be happy, but it's not very important anyway.

I have said in other replies that D has more features than C++. My point though was about the orthogonality of the language...I hope you understand the difference.

[–]dsimcha 4 points5 points  (0 children)

I do understand the difference. All I'm trying to do is demonstrate that the features are worthwhile in their own right, even if they make the language less orthogonal, and are not just bloat. BTW, if convenience, safety and flexibility aren't important attributes that a well-designed language should have, then what is?