The D Programming Language
in [C++]
|
From: Andrei Alexandrescu (See Website For Email) on 25 Nov 2006 01:16 Walter Bright wrote: > Andrei Alexandrescu (See Website For Email) wrote: >> Arguing that these languages weren't as successful >> as more rigid languages is not very convincing because languages of all >> ilk succeed or fail for a variety of imponderable reasons. > > One of my hobbies is history. I'm not interested in dates or events in > particular, I'm interested in why things have turned out the way they > did. Why are some generals, for example, more successful than others? Is > it luck? Is it because they're smarter? Only genial generals make decisions that make sense to the person on the street. :o) > 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. > It may be imponderable, but I'm not ready to throw in the towel on it. > 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. In C++, programming with templates can be considered the focal point of interest. 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? > 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.) 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." > 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. > 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). 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 25 Nov 2006 01:13 Jeffrey Yasskin wrote: > On Nov 23, 5:03 pm, "Andrei Alexandrescu (See Website For Email)" > <SeeWebsiteForEm...(a)erdani.org> wrote: >>> Of course, it is possible to define a language without UB and give it a >>> library that is "reach enough", but such languages are not what we would >>> call "system-programming languages" (try to find one). >> I think Modula-3 was system-level PL and also safe. > > http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-52.pdf section 7 > describes several features that can cause "unchecked runtime errors", > which look a lot like undefined behavior to me. These features are > segregated into "unsafe" modules, so one could see Modula-3 as two > languages: one system-level and unsafe, and one not system-level and > safe. Yah, also see http://www.cs.washington.edu/research/projects/spin/www/papers/WCS/m3os.ps which describes how type safety in Modula-3 helps systems level programming. 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. Andrei -- [ 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 06:22 You make a lot of good points. I want to reply to a couple of them. Francis Glassborow wrote: > What makes a language popular and widely used? Well why is English the > commonest second language in the World. It is a terrible language full > of special cases. English is a terrible language from an academic point of view. It is, however, a wonderful language from a practical point of view. English has, for example, over a million words, far more than any other language. That makes it the most expressive language. English has no problem with freely incorporating words from other languages, apparently to the distress of others <g>. It seems that anything that is easy to use for humans involves special cases. The easier to use it is, the more special cases. That's why nobody has come close to figuring out how to build a gui based on simple, orthogonal rules. Computer languages are the same way. The ones that are based on simple, orthogonal rules (Lisp - everything is a list, Smalltalk - everything is an object) get mowed down by languages that special case things like integers, much to the baffled frustration of their enthusiasts. Don't get me wrong. I'm not saying just load up a language with special cases and it'll be better. It has to be the *right* special cases, very carefully designed. If it's done right, ironically the user won't notice the special cases at all and it'll feel perfectly natural to him. It's possible that C++ may fall into a similar trap that Lisp and Smalltalk fell into, by adopting a principle that features should be pushed into libraries even if that is to the detriment of usability. C++ is willing to accept usability compromises for strings, arrays, complex numbers, and associative arrays in order to be able to implement them as libraries. But then C++ watches in frustration as users migrate to other languages that don't make those compromises. Maybe that isn't the whole reason they migrate, but I'm pretty sure it's part of it. D isn't willing to cede usability on basic features like strings, arrays, etc. And like English, D is very willing to adopt and adapt features from other languages that have proven to add a lot of value to those languages. > D may well be a much better multi-paradigm language but currently it IS > a niche language (though that might change). It has a small user base relative to C++, but it is not a niche language in the sense that it is targetted at a niche. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jeffrey Yasskin on 25 Nov 2006 06:24 On Nov 21, 2:16 pm, Walter Bright <wal...(a)digitalmars-nospamm.com> wrote: > 1) Extend std::string to support UTF-8. This would be as misguided as extending Java strings to support Unicode. ;) What do you propose std::string::length() would return, the number of bytes or the number of characters? But both this and your argument about complex vs imaginary numbers support putting as much as possible into the library instead of the language. If std::string were baked into the language, we would have a very hard time replacing it with a utf-8 string class. Since it's part of the library, all you have to do is write functions using a different class. Similarly, if std::complex were part of the language, as _Complex is part of C, we'd be trapped with the language designers' mistakes. As it is, you're free to write an "imaginary" class that works correctly. The language even allows you to make it interoperate with the "flawed" implementation of std::complex and the math libraries. The point of moving things from the language to the library is that language designers aren't all-knowing gods. They make mistakes, but putting those mistakes in the library instead of the compiler allows us, the language's users, to fix them. Jeffrey -- [ 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 06:25
Walter Bright wrote: > David Abrahams wrote: >> Walter Bright <walter(a)digitalmars-nospamm.com> writes: >> So your only reason for having these things in the D core language is >> the literal syntax? > > No. I've given a list before. Here it is again: > > 1) literals > 2) comprehensible error messages > 3) faster compilation > 4) custom syntax for it (not just literals) > 5) better code generation (like for complex, we can (and do) return them > in the FPU registers rather than like a struct) > 6) better constant folding (Don Clugston and Eric Anderton have done > some really amazing things with strings and templates in D - there's > just no way to do it in C++) > 7) no embarrassing incompatibilities between core features and library > replacements (like cannot mix C style arrays and std::vector) > 8) no gaps like ("string1" + "string2") > 9) less intimidating for people who are just not comfortable using > templates > 10) can customize function overloading and type deduction rules specific > to the type > 11) the very inflexibility of core features can be an advantage - when > someone is reading another's code, and they see a core string, they know > what it is and how it works. If everything is customizable, there are no > guideposts, no north star, no breadcrumbs. If you see ("abc"+"def"), you > know it is not the command to launch nuclear missiles. I forgot to add: 12) Interoperability. Remember bad old days in C++ where everyone invented their own string class? The end result was libraries that were all incompatible with each other. C++98 fixed that, but at the price of making std::string *fixed* and *inflexible* by definition. You're not standard conforming if you make any attempt to change std::string in the slightest. I've never heard of anyone extending or customizing std::string's behavior. Saying standard library implementations of basic types offers user flexibility and extensibility is not correct either in theory or practice. Might as well implement it in the core. (Note that I'm not talking about internal changes to std::string to, for instance, improve performance or fix bugs. I'm talking about extending or modifying its externally visible behavior.) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |