• bearophile <bearophileHUGS lycos.com> Sep 09 2008
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Sep 09 2008
• Walter Bright <newshound1 digitalmars.com> Sep 10 2008
• JAnderson <ask me.com> Sep 11 2008

bearophile <bearophileHUGS lycos.com> writes:

Andrei Alexandrescu:

you seem to expose a false dichotomy: "simple" versus "allows power"/"allows
STL".



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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

Walter Bright <newshound1 digitalmars.com> writes:

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.

JAnderson <ask me.com> writes:

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