The D Programming Language
in [C++]
|
From: Walter Bright on 25 Nov 2006 17:18 Andrei Alexandrescu (See Website For Email) wrote: > Walter Bright wrote: >> It's the same with computer languages. Some succeed, a lot fail. They >> fail for all sorts of reasons, certainly not always technical. If I can >> learn why they fail, perhaps I can avoid their mistake. If I can learn >> why some succeed, I hope I can learn from that, too. > 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. > 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. > 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. >> 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++. > 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. >> For another imponderable, why do reusable Java libraries sprout >> everywhere you look, but reusable C++ libraries seem to follow a more >> tortured path? Is there something about C++ that makes it difficult to >> write libraries? > We discussed this and came to the conclusion that garbage collection is > the first thing. I know, I just was reluctant to turn this into yet another debate about garbage collection <g>. >> And why do users often write their apps in Python, and use C++ just for >> the bottlenecks? Is there a way I can combine the productivity of Python >> and Ruby with the performance of C++ with Java's ease of library >> creation? I like to think there is, and I want to find that sweet spot. > Then add sparse matrix infix operations to the core. It's what I care > most about :o). I used to do numerical analysis programs for Boeing, so I have a soft spot for the topic. C++ (and to a lesser extent C) has historically not paid much attention to the needs of serious numerical analysts. Improvements have come, but at a glacial pace, and it seems to meet with stubborn resistance or just apathy. It even goes in reverse now and then (such as the dropping of 80 bit support). So the analysts keep on using FORTRAN, and the FORTRAN compiler people know who pays their bills. 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. 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>. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 25 Nov 2006 17:15 Walter Bright <walter(a)digitalmars-nospamm.com> writes: >> Because it's not a "mother of all languages." You might consider it >> an evolutionary great-great-great-....-great grandmother of the mother >> of all languages, if such a thing even exists. It may be >> theoretically possible to do, but FORTH wasn't really designed to be >> good at allowing people to do that sort of embedded language >> construction with sufficient flexibility. Also, one thing you need in >> order to write good languages is a reasonably expressive language to >> do it in. FORTH ain't, in my opinion, very expressive in and of >> itself. > > So can we agree that the expressiveness and ease of use of the core > language matters a lot - maybe even more than the ability to redefine > syntax and tokens? Absolutely. 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 25 Nov 2006 17:13 Walter Bright wrote: > If a language is a failure, before adopting its features, I would need > some convincing that those features are not the reason it failed. If a > language is a big success, odds are pretty good that the technical > decisions behind it are sound, too. I think you're being overly optimistic. After all, the most successful language of all time is Cobol. And more recently, you can't argue with the success of Perl. As far as I can see, there are no sound technical decisions in either. When it comes down to it, if you go back 15 or 20 years, Modula-3 was certainly superior to C++. We're only just discussing introducing some of its features into the next version of C++ (and some others, like exceptions, have been introduced long ago). It certainly can't be counted as a big success, however. As it happens, C++ does have a number of good features. But my impression is that it is a success despite them, and not because of them. -- James Kanze (Gabi Software) email: james.kanze(a)gmail.com Conseils en informatique orient�e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nemanja Trifunovic on 25 Nov 2006 17:14 Walter Bright wrote: > Nemanja Trifunovic wrote: > > Walter Bright wrote: > >> 1) Extend std::string to support UTF-8. > > > > Ehm: http://utfcpp.sourceforge.net/ > > The class supports UTF-8, but not by extending std::string. It uses > std::vector, for example. > The set of template functions (not a class) is meant to be used with sequences of bytes, including char[], std::string or vector<char>. The point of my post is that a utf-8 encoded string may be stored into a std::string object just fine, and then some of the common string operations would require a little help from a library like the above mentioned one. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 25 Nov 2006 17:19
Andrei Alexandrescu (See Website For Email) wrote: > Modula-3 didn't make it in the mainstream either :o). It's quite amazing > how this language died. In 1995 it was all the rage. Five years later it > practically was non-existent. I knew some Modula 2 compiler engineers. It was C++ that killed it. Modula 2's window of opportunity had closed by 1991, the rest was inevitable. Some special extensions were put in to my C++ compiler at the time at the request of some major Modula 2 app developers in order to help them get their code converted to C++. They knew Modula 2 was dead and they didn't want to be caught by the decomposition. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |