Andrei Alexandrescu:

>you seem to expose a false dichotomy: "simple" versus "allows power"/"allows STL".
For all I know, much of Walter's claim to fame with D is that he proved that power/efficiency and ease of use are not an either-or choice as most people thought.<

I have given a hand developing a Python => C++ compiler, "ShedSkin", that contains a complex type inferencer. It compiles a large subset of Python code in quite efficient code. That project has shown me for the first time that it can exist a very clean language that's rather efficient too.

So I know that in theory it's often a false dichotomy, but in practice if you look at languages around, you generally have to pay for increased efficiency with uglier syntax, more complex language, more bug-prone language, etc.


>D is meant to be a systems-level programming language, and as such one clear goal of it is to obviate a need for C++.<

C and BitC too are system languages, but they don't try to be as C++. There are many projects today that use C instead of C++, for example Perl/Ruby/Python source code is in C, etc.

I like D to be a system language but I don't think it's wise for D to try to become a full replacement for C++. I think of D like a C/Java cross, with OOP, generic programming, more sugar and built-in safeties :-)


>In the inner circles of C++ there's often talk about how a replacement for C++ looks like, and to quote a classic who reflects the general opinion: "Whatever replaces C++ should be at least as good as C++ at whatever C++ is good at, and better than C++ at whatever C++ is bad at."<

That idea of yours scares me a little: I believe that if you want to create a language able to do *everything* better than C++ you may end creating a language almost like C++. I was hoping for D to become less powerful (and quite less complex) than C++. Many things in D1 are designed to be less powerful than C++ ones. So now I'd like to know what Walter thinks about this subject (and other people), because there's a large difference in what I think D wants to be and what you say to me.

This also shows that general discussions are sometimes as important as discussing details :-)


>And what would you rather have in the standard library? And what advantages are you showing in exchange for the steep penalty in efficiency?<

You are right. Note that my libs aren't meant as replacement for the std lib.


>(I looked over your library a while ago and it seems to use delegates everywhere.)<

Yes, the situation is the same, I have just refined things, added more things, etc. (Two other people have told me that they don't like this.)


>Again you offer a false dichotomy. Do I want a beautiful wife or a smart one? D code can enjoy the properties you mention without needing to pay an arm and a leg for them.<

From the little I have seen your women aren't much nice looking ;-)


>In fact I'm thinking that map should be lazy by default.<

I have both map() and xmap() in my libs (and map2, unfortunately), in my lib map() == array(xmap()).
Python 2.5 has map() built in and xmap (named imap) in a std lib, and Python 3.0 has just a xmap() as built-in (named map).


>If there are no licensing issues (which Walter is weary of) I'd be grateful to benefit of your code or designs. Do you have a link handy?<

The code is Python License, I'll probably change it to the license used by Phobos:
http://www.fantascienza.net/leonardo/so/libs_d.zip
Most of the functional stuff is in 'func.d', while lot of templates are in 'templates.d' :-)
I can't see how that code of mine can be adapted to yours, because they are based on quite different principles.

Bye,
bearophile

bearophile wrote:
> That idea of yours scares me a little: I believe that if you want to
> create a language able to do *everything* better than C++ you may end
> creating a language almost like C++.

Not at all. C++ has much gratuitous complexity and just elementary language design mistakes.

Andrei

bearophile wrote:
> That idea of yours scares me a little: I believe that if you want to
> create a language able to do *everything* better than C++ you may end
> creating a language almost like C++. I was hoping for D to become
> less powerful (and quite less complex) than C++. Many things in D1
> are designed to be less powerful than C++ ones. So now I'd like to
> know what Walter thinks about this subject (and other people),
> because there's a large difference in what I think D wants to be and
> what you say to me.

Back when I worked for Boeing, I had a discussion with some of the cockpit engineers about the jet engine controls (which were not made by Boeing, but by the engine company). Managing the fuel flow in a jet engine is a pretty complex business. Early engines relied on the pilots to tweak parameters, and if they got it wrong the engine would flame out probably at the worst possible moment.

Every effort was poured into automating it. Over time, they came up with a marvelous, and very complex, mechanical computer that bolted on the side of the engine, all of which was commanded by a single lever in the cockpit that the pilot pushed forward and he got more power.

The pilot (our "programmer") had all this *power* at his command at the simple, and intuitive, push of a lever. The pilot wasn't giving up a thing for this elegance.

I believe that at least half of the complexity of C++ is unrelated to its power (it's more related to the language's history). I see no inherent reason why a powerful language must be complicated.

Sure, there's complexity in D, too, but I regard those aspects as a failure in the design department.

Look at it like vinyl vs CD. There are people who insist that vinyl does better sonic reproduction. If you look at how the sound is reproduced, that just doesn't make any sense. What is really happening is they *like* the peculiar imperfections of vinyl; they like the hiss, rumble, pops and clicks. I know people who like the wacky imperfections in C++. They revel in mastering the arcana. But I don't see the point in that. I  see beauty in elegance, which is not the same thing as simplicity achieved by stripping out the power.

Walter Bright wrote:
> bearophile wrote:
>> That idea of yours scares me a little: I believe that if you want to
>> create a language able to do *everything* better than C++ you may end
>> creating a language almost like C++. I was hoping for D to become
>> less powerful (and quite less complex) than C++. Many things in D1
>> are designed to be less powerful than C++ ones. So now I'd like to
>> know what Walter thinks about this subject (and other people),
>> because there's a large difference in what I think D wants to be and
>> what you say to me.
> 

IMHO

I think complexity is relative to the problem being tackled.  At the point at which something gets complex it probably requires its own abstraction.

Case in point, ranges.  We could create and manage ranges ourselves using standard C style forloops however to get it up to the level ranges provide we would have to add a load of asserts to validate that its correct.  Ranges abstract so that we don't have to think about it all the time.  Yes ranges are a more complex beast but only the internals, not the externs when your using them in a foreach.  So to begin with we are writing more code but its abstracting away details that you don't want to think about on a day-to-day bases, not to mention reuse.

Maybe D will endup with many more complex features then C++ however if they are used by library writers (in particular the standards) to make libraries easier to use then I'd say its a win.  If a feature enables us to optimize code just by using a few different terms then its a win.  If a feature reduces the complexity (size) of our own code then its a win.  If it reduced time spent in the debugger then its a huge win.

Looking at something like a car, these things are more complex then ever however its there complexity that makes them simple to use.  Personally when I'm coding I like to only pull as few strings as possible to get a job done.  It takes some time to get code in a state where that is possible however thats marginal compared to the time saved.

-Joel