The D Programming Language
in [C++]
|
From: Walter Bright on 18 Nov 2006 22:31 Bo Persson wrote: > We have tried that before, but as the designer of the D language believes > that we should compare core language only, and that features already > implemented in the C++ library doesn't count, this avenue hasn't been very > fruitful. I don't believe there's much point to discuss library features in language X vs language Y because any library can be implemented in any language. Heck, I once posted that a garbage collector could not be implemented in Java, and someone replied that it was possible and someone had done exactly that. I've even heard of a FORTRAN compiler written in TECO! Isn't it a lot more interesting to discuss core language features that make it easier/harder to write certain types of code (and thereby libraries)? Given all the core changes proposed for C++, certainly a lot of people feel the core language support is inadequate. But what I think is fruitful to discuss or not only pertains to what I decide to post - I don't control these discussions. I'm not a moderator here. > Some of us, who are not compiler writers, actually see a great advantage in > being able to add library features. I don't know of any computer language that prevents one from writing libraries for it, even TECO (gads, I'm old). But certainly, it's the core features of a language that have a powerful influence on the style and ease of building libraries for it. Building template libraries for C++ is a major source of activity and interest, so it's fun to compare it with D programming language templates: http://www.digitalmars.com/d/templates-revisited.html -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Seungbeom Kim on 19 Nov 2006 03:47 Walter Bright wrote: > I don't believe there's much point to discuss library features in > language X vs language Y because any library can be implemented in any > language. > > [...] > > I don't know of any computer language that prevents one from writing > libraries for it, even TECO (gads, I'm old). But certainly, it's the > core features of a language that have a powerful influence on the style > and ease of building libraries for it. Yes, you said it; but isn't it contradictory to what you said above? For example, in Pascal you cannot write a single library procedure that sorts both array [1..10] of integer and array [1..20] of integer. Thus it is important for the core language to have enough flexibility and power to accommodate good library designs. But considering only the core language features would be a serious mistake; it would be an unfair disadvantage to a language which has preferred library solutions to core language solutions. For example, under that criterion, you would say "C99 can handle variable-length arrays but C++ can't; C99 can handle complex numbers but C++ can't." However, what is important is whether a programmer can do his/her task efficiently with the language and the associated tools, not whether it is done by the core language or by the standard library or by a third-party library. Whether a language facilitates good libraries or it hinders good development tools, much of the credit/blame is to the language. -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 19 Nov 2006 16:31 Seungbeom Kim wrote: > But considering only the core language features would be a serious > mistake; it would be an unfair disadvantage to a language which has > preferred library solutions to core language solutions. For example, > under that criterion, you would say "C99 can handle variable-length > arrays but C++ can't; C99 can handle complex numbers but C++ can't." And that Fortran can handle IO, but C++ (and Java!) can't. There is no cut and dried answer. At some early point, the developers of C decided, for example, that IO would be relegated to the library. And then designed the language in such a way that this would be possible (e.g. in C, varargs, conversions between pointers and pointer arithmetic, etc.). Similarly, C++ has generally made the choice to enrich the language in such a way as to permit a library solution, rather than solve the problem directly. There are, of course, limits to what one can do in this direction, and at least some of the proposals for the next version of the standard---things like threading, garbage collection or concepts---require or benefit from some help from the compiler. In general, as a user, what interests me is how efficiently the language supports my application. Whether that support comes in the form of language features, standard library, or even, at least to some degree, third party libraries, is really irrelevant. (Considering support from third party libraries is somewhat arguable; the fact that Java has Swing, where as C++ depends on third party libraries for GUI support, is a definite disadvantage for C++ if your application needs GUI support.) -- 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: Bo Persson on 19 Nov 2006 23:18 Walter Bright wrote: > Bo Persson wrote: >> We have tried that before, but as the designer of the D language >> believes that we should compare core language only, and that >> features already implemented in the C++ library doesn't count, >> this avenue hasn't been very fruitful. > > I don't believe there's much point to discuss library features in > language X vs language Y because any library can be implemented in > any language. The C++ language defines features that can optionally be implemented as a library, or built into the compiler. The standard allows, but does not require, specific compiler support for these features. In my opinion, they are still part of the language. The D language requires compiler support for strings, the C++ language allows it. That doesn't mean that there are no strings in C++. > > Isn't it a lot more interesting to discuss core language features > that make it easier/harder to write certain types of code (and > thereby libraries)? Given all the core changes proposed for C++, > certainly a lot of people feel the core language support is > inadequate. Some people feel the need for more features. I am not sure that they are all widely missed by others. Variadic template arguments are not high on my wish list, for example. > > But what I think is fruitful to discuss or not only pertains to > what I decide to post - I don't control these discussions. I'm not > a moderator here. It was I who didn't find it fruitful to compare the languages, when you concentrate on a core only comparison. Without the string, vector, and complex classes, C++ admittedly is just half a language. I respect your opinion, but just don't find it interesting to discuss languages from that point of view. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: AJ on 19 Nov 2006 23:14
Hi there, Seungbeom Kim wrote: <snip> > But considering only the core language features would be a serious > mistake; it would be an unfair disadvantage to a language which has > preferred library solutions to core language solutions. For example, > under that criterion, you would say "C99 can handle variable-length > arrays but C++ can't; C99 can handle complex numbers but C++ can't." It would also be unfair to consider library support as good as core language support for (at least) two reasons: 1) Syntax. 2) Convenience. Here's one example: Multi-threading and thread safety. For 1: In D, this is achieved in a super-clean and succinct manner: Adding a synchronized keyword. In C++, one must add error-prone boilerplate for critical sections (or mutexes, or locks) and in general the syntax is verbose and a hassle. For 2: In D, synchronized is built-in. No need to download or install anything else. No need to check additional documentation on library usage. In C++, one must install and add a dependency to boost (non-trivial) or pthreads (still non-trivial), or sacrifice platform-independence and go Win32. On the other hand, D isn't available by default almost anywhere, whereas C++ is, so that's one disadvantage. However, wasn't this the case with C++ vs. C too, at some point? One other serious legacy flaw in D (inherited from C/C++) is that it doesn't do away with undefined behavior. It's close, I think, but it's unfortunate that the holes aren't closed entirely. > However, what is important is whether a programmer can do his/her task > efficiently with the language and the associated tools, not whether it > is done by the core language or by the standard library or by a > third-party library. Whether a language facilitates good libraries or it > hinders good development tools, much of the credit/blame is to the language. 'Efficiently' is the key. Adding certain things to the core language can improve efficiency by an order of magnitude. "Can be done at all" isn't the same as "can be done simply and easily." :) Cheers, -Al. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |