The D Programming Language
in [C++]
|
From: Walter Bright on 26 Nov 2006 08:56 David Abrahams wrote: > But then, I've never insisted on the ability to redefine > syntax and tokens, and I don't even believe it's necessary in order to > achieve the kind of flexibility and power I'm describing. How would you do it, then? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 26 Nov 2006 08:51 David Abrahams wrote: > Scala looks pretty interesting. Did you have a look at it? I had a brief look at it, thanks for the pointer. Scala has two things of interest for this discussion: 1) functions with two arguments can be used as infix operators, so I can declare: int foo(int a, int b); and use it like: x = a foo b; I'm afraid the lack of syntactical redundancy if there were any syntax errors would make for incomprehensible error messages. An old proposal for D suggested doing things like: x = a :foo: b; to remove the ambiguity. That technically works, but it's just a bit jarring to the eye. @foo or #foo or $foo are similarly just too ugly for words. I thought of the old FORTRAN syntax: x = a .foo. b; but unfortunately that is even worse, ambiguity-wise. 2) Lazy function argument evaluation. D already has this: http://www.digitalmars.com/d/lazy-evaluation.html It's an idea I adapted from Lisp <g>. It's pretty cool. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 26 Nov 2006 08:51 Andrei Alexandrescu (See Website For Email) wrote: > If a new language is to > become successful, it better comes up not with what's good in other > languages, but with some good of its own. Otherwise it will always be > one step behind. Consider the following: Language A has features X,Y. Language B has features S,T. X sucks, Y is cool. S sucks, T is cool. So why is a language C that implements Y,T behind? The combination of Y and T may actually make C a far more powerful language than A or B, even though it didn't actually do anything innovative. Even so, D has already implemented C++ features that exist only as proposals, such as contract programming, type inference, unicode support, modules, etc. It has moved ahead of C++ with things like tuples, scope guard, function literals, lazy arguments, inline assembler, etc. All these things make it easier to develop library code. I don't see how D is a step behind. I don't understand how strings and arrays as core types sabotages library development. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 26 Nov 2006 09:35 Walter Bright wrote: > Andrei Alexandrescu (See Website For Email) wrote: >> Walter Bright wrote: >> I think that's wise, but also it puts the language designer in a >> follower position, not a leader one. It's like in business - the big >> money is for those who take a risk. The FedEx idea was the laughing >> stock in business school. Yet its creator went ahead and implemented it. >> Now anybody could try starting somebody like FedEx "because it was >> successful", but probably they're gonna fail. > > Most successful businesses succeed not because they have an innovative > business plan, but just do the boring basics better than anyone else. > Walmart comes to mind. Starbucks is another. I think there is huge > opportunity in the programming language area for a language as > performance oriented as C++ but with the productivity capabilities of > Python/Ruby. Wrong. Both Walmart and Starbucks started with a new business idea. See "22 immutable laws of branding" by Laura Ries and Al Ries, which happens to mention _both_ and describes their ideas. McDonalds, too :o). I, too, think there is an opportunity for a new language combining RAD with efficiency, but I doubt that the _approach_ to that language is that of window shopping goodies from the two categories of languages. I'm not trying to imply D does just and only that, but it looks like it is certainly driven by that philosophy. >> In C++, programming with templates can be considered the focal point of >> interest. > > I agree, but there's the danger that focus has taken away attention that > should be paid to other basic programming issues. Those other issues may > be boring, but they're the bread and butter of a successful language. A beautiful house would be spoiled by some cheap doorknobs. But doorknobs are just a little part and deserve only this much attention. >> People use it to implement in user space features that are >> akin to language features. That's not different, is the exact opposite >> of making complex a primitive type or adding infix matrix operations to >> the core. What the heck will I do with that? I use sparse matrices. D's >> infix operators will be useless to me. Would you please add infix >> operators for sparse matrices too? > > D doesn't have core matrix features. The whole thing was put off to be > reevaluated later. Then don't forget sparse matrices :o|. And triangular matrices :o|. And band matrices :o|. And... >>> I am certainly not always right about the utility of various features, >>> but if you examine D carefully, it is comprised of features that there >>> is good reason to believe were drivers of success in other languages. >>> Certainly, the bulk of C++ is in D, and that's sincere flattery. D has >>> adopted C++'s powerful methods of creating libraries. But D isn't just a >>> copy of other languages - you've contributed a number of innovative >>> ideas to it, too, such as scope guard. >> If you include everything good in C++ but then you take a 180 degrees >> turn away from its philosophy... that doesn't bode well. (I'm >> exaggerating here to emphasize my point.) > > Having a philosophy is a good thing, unless one becomes a slave to the > philosophy rather than the users <g>. One thing I'd like to emphasize is > D does not take away C++'s UDT capabilities. If anything, it's easier to > create a UDT in D than in C++. Becoming the slave of your users entails losing sleep over having too much power compared to them. >> The discussion on complex and the built-in matrix operators just >> bristles my hair. It's just so wrong doing it, doubly wrong to claim >> it's a good thing to do it, and triply wrong claiming there's no other >> good way. Everybody would be happier with the admittance: "I didn't know >> how to do it well, but there is evidence it's useful, so I added it to >> the language. Sorry." > > I'll admit exactly that. It's true that I know of no way to get the > basics of strings, arrays, and complex where they need to be and still > be library features. Many proposals for C++0x have cool features, but > none of them get us there either. That might be largely because they have the burden of integrating with the legacy languages. You may want to look at'em while being relieved of that burden. > I'd like to get D to the point where analysts can say: "finally, I can > ditch the old FORTRAN war horse and move on to a modern language that > actually caters to my needs." For that to happen, complex and vector > math support has to be top drawer. What's wrong with C++ complex support > has already been discussed, it isn't all currently fixable using UDT > techniques. Here's exactly where the mistake begins. It isn't all currently fixable using ___C++'s___ UDT techniques. It would be great if you developed better UDT techniques. Then instead of saying "look, I can put a complex in two registers!" you can say "look, I can put any two-floats structure in two registers!" etc. > If proper vector/matrix math can be done using UDT's, then > it'll go that way in D. If it cannot be, then D is faced with having > inferior support for it, or do it in the core. I can't tell at this > point what will happen there. > > You are right in one sense - there's a limit to what can be put in the > core, and that limit isn't very high. UDT's have to pick up the slack. > But as I said before, strings and arrays are ubiquitous types. Everybody > uses them, almost as much as they use int's. Therefore, I feel that the > extra goodies one gets by making them core types is justifiable. > > With complex/vector/matrix operations, I admit that the audience is far > smaller. It's just that I do have an interest in numerical work, and the > people doing it have suffered long enough with FORTRAN and the apathy of > other languages <g>. And this pretty much summarizes my point: instead of a language bearing whatever preferences its creator has, it would be better to have a language streamlined through the innovative permanent participation of a community. Just like a human language, now that you mentioned it :o). Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 26 Nov 2006 09:36
Peter Dimov wrote: > Andrei Alexandrescu (See Website For Email) wrote: > >> That's simply wrong. Java does not check thread safety statically, yet >> is able to define behavior of even incorrect multithreaded code. > > It does on a physical level (long and double aside), but not on a > logical level. An object invariant can easily be broken by a data race. > The behavior from this point onwards is defined but makes no sense. > This decision is correct for safety reasons, but doesn't offer many > other benefits. And that contradicts my statement how? Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |