The D Programming Language
in [C++]
|
From: Walter Bright on 24 Nov 2006 17:25 (Dear Mr. Moderator: this post makes my other reply to David redundant, might as well delete that.) David Abrahams wrote: > Walter Bright <walter(a)digitalmars-nospamm.com> writes: > >> David Abrahams wrote: >>> Walter Bright <walter(a)digitalmars-nospamm.com> writes: >>>> Ok, show me a language that is so user extensible so that, say, I can >>>> construct a library so powerful that it can exactly emulate other >>>> computer languages. In other words, where is language X that can accept >>>> C++, Pascal, C#, Lisp, etc., source code just be adding on a powerful >>>> library? >>> FORTH >> Has anyone proven this by writing a FORTH library that can accept C++ >> source code? Pascal code? C# code? Lisp code? > > Of course not. So FORTH isn't worthy. Has anyone advanced a serious proposal for user definable tokens and user definable syntax for C++? >> As I suggested to Bo Persson, such a "mother of all languages" may not >> be that usable. > > Scala looks pretty interesting. Did you have a look at it? If it's possible to know even less about a language, I know less about Scala than FORTH. Maybe tomorrow I'll look it over. >> After all, why aren't you using FORTH? > > 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? > And RPN eventually makes my head hurt :) RPN might make your head hurt, but some C++ TMP code gives me an aneuryism <g>. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 24 Nov 2006 17:26 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. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 24 Nov 2006 21:07 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. > Are you telling me you can't find a way to > generalize the literal syntax a bit so we could have the same kinds of > benefit for UDTs? There have been some proposals, but they all suffered from one grevious fault or another. >> The only thing I can think of to add is that Python may need to put >> such basic things it its core language for performance reasons. > Sure, sure, but the fact that Python is interpreted is really > unimportant to this discussion. I haven't looked closely at Python implementations, but my extensive experience with javascript is it being interpreted is not what makes it slow. It's the dynamic typing. I hear a lot about the static vs dynamic typing, and which is better, but I've seen few mentions of the fact that dynamic typing runs slowly, and I could find no way to fix it. I've had the sneaky suspicion for some time that type inference will produce many of the benefits of dynamic typing, but with the performance of static typing. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bob Bell on 25 Nov 2006 01:17 Walter Bright wrote: > And why do users often write their apps in Python, and use C++ just for > the bottlenecks? Because they don't know what they're doing? ;-) Seriously, don't assume that this works just because developers feel good when they do it. I know of a major project at my previous company that was written that way, and it turned out to be a disaster. The developers loved working on it, though -- the fact that they could make a small correction and see it running in seconds gave them a great feeling of power and control. They all felt extremely productive, that Python made the project go very smoothly. The failed to notice several factors: 1) their gains in productivity were offset by additional problems that would not be present in a one-language-only project (e.g., language boundary issues) 2) It turns out that Python has large-scale development issues that aren't apparent when knocking out a simple script (e.g., they had numerous, repeated problems making sure that the versions of all their modules were in sync) 3) Python's "rapid development" (i.e., the absence of a compiler) optimizes the wrong bottleneck; waiting for the compiler is not what makes a complex program take a long time to write The issues were not related to competence; the engineers on the project were all extremely competent. But the end result is that it took over two years to get the program done -- about what it would have taken to get it done with C++ alone. > 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. What makes Python feel so productive? No compile-link phase and the availability of a wide variety of libraries. Bob -- [ 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:14
James Kanze wrote: > Andrei Alexandrescu (See Website For Email) wrote: >> James Kanze wrote: >>> AJ wrote: >>>> 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. > >>> No language manages to completely do away with undefined >>> behavior. Although C++ could surely do better in this regard; >>> there's a lot of unnecessary undefined behavior. > >> (Late in the thread, but this cannot be let slip away.) Whatever >> happened to all languages that do manage to completely do away with >> undefined behavior? > > Name one. I'm unaware of any. Java, Lisp, Scheme, ML, Haskell, Ocaml. >> I'm asking this again: it would be best if we all refrained from "I'll >> qualify it on-demand" statements. > > Well, I suppose that if you exclude support for threading, it > might be possible. Java has threads and no undefined behavior. I don't know Ocaml but I recall there is a parallel version of it, which probably also doesn't have undefined behavior. > But as far as I know, no language even comes > close. If nothing else, most older languages don't define the > case of insufficient ressources---some dialects of Lisp, for > example, say that in case of overflow in integral arithmetic, > they switch to an extended format, but they don't say what > happens when the extended format gets too big to fit in memory. > And most modern languages support threads, and I'm fairly > convinced that it is currently impossible to support threads > without undefined behavior---it would mean being able to > statically diagnose thread-safety. That's simply wrong. Java does not check thread safety statically, yet is able to define behavior of even incorrect multithreaded code. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |