“D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. D is statically typed, and compiles direct to native code. It’s multiparadigm: supporting imperative, object oriented, and template metaprogramming styles. It’s a member of the C syntax family, and its look and feel is very close to C++’s. See this comparison of D with C, C++, C#, and Java.”
If you click the garbage collection link you’ll see that the author believes garbage collection belongs in the kernel. I’ve heard this quite a few times, can’t say that I agree with it, but I’d be interested to hear if anyone knows of a paper that shows significant benefits from putting GC in the kernel (instead of running under the user-process).
Is there significant extra work needed to do garbage collection in user-space?
You probably don’t want to put garbage collection in the kernel, because it’s a big piece of complex code that really doesn’t need to be in there. However, what you do want is to give the garbage collector a bit more control than it has now. The win that is most often mentioned is in the GC’s interactions with the VM — you could maintain some summary structures regarding objects referenced from swapped-out pages, so you wouldn’t have to read back those pages in order to do a garbage collection. Also, you might be able to play some tricks to avoid kicking out too many TLB entries during tracing. Lastly, some garbage collectors use the VM to implement write barriers, so fast access to the MMU and fast handling of page faults could improve the performance of these collectors.
On the other hand, these improvements probably wouldn’t help a huge amount. Modern systems shouldn’t be swapping that much anyway. On architectures without tagged TLBs (like x86) TLB flushes from context switches happens several orders of magnitude more frequently than TLB trashing from a major collection cycle. And given how expensive it is to muck with the MMU these days, you shouldn’t be using them to implement barriers anyway.
As rayiner said, GC doesn’t belong in the kernel, but the kernel VM manager should definitely cooperate better with the GCs as how much memory should be allocated before doing a garbage collection depends on the memory pressure:
– allocate too little memory and the GC will waste CPU time doing garbage collection while there is still a lot of “free” memory available.
– allocate too much memory and some pages could be paged out before the GC reclaim memory which is dumb as the GC will have to swap-in again the page to do its collection pass to release memory, a kind of trashing which could have been avoided in some case.
Currently system administrator have to hand-tune the memory used by the GC to make the system works better which is quite suboptimal..
The only paper I know (there are probably more papers, but it’s the only one I know) about this research topic is here:
http://www.cs.umass.edu/~emery/pubs/04-16.pdf
They patched a Linux kernel and got interesting numbers.
Note that in GCs for ‘client type applications’ you may still want to limit the size of the memory used by the GC even though there is still free memory so that each GC-pass do not take too much time, avoiding a freeze for the user.
I am a fan boy of D.
Check out WxD, a cross platform gui for it.
If you try WinForms, they are slow for big projects. Your options are delphi … but I found D better.
Apple OSX page has a D mention even.
.V
That is probably another D, from sun.
Something to do with dtrace.
This isn’t news, hell this isn’t even an article… just a link to the website providing D, which hasn’t changed in ages..
To make matters worse, the comparison between programming languages are packed with incorrections and pure lies (“C doesn’t have resizeable arrays” or “built-in strings” or “complex/imaginary number support”, “garbage collection”, etc etc etc… All lies which are refuted time and again but they still keep on ticking).
I don’t see how anyone can adopt a language that, when compared to other languages like C++, doesn’t bring anything new to the table except a few useless semantic touch-ups and whole technical steps backwards, like the brain fart which is having strings being a part of the core language. If that wasn’t enough, the agressive astroturfing campaign that is being run by the D proponents, which includes spamming multiple online forums like newsgroups and blogs (this is a good example) clearly sends the message that the language isn’t able to stand on it’s own two feet without a string marketing campaign.
it seems to me that the only one here running an aggressive campaign it’s you. your anger and frustration sliping and sliding between your teeth is being seen from miles away… i wonder why
C doesn’t have built-in strings and resizeable arrays. It has pointers, and builds hard-to-use, error-prone, leak-prone, and security-holeprone facsimiles of strings and arrays on top of them, but facsimiles are not the real thing.
My bad. Unfortunately I wrote C instead of C++.
To make matters worse, the comparison between programming languages are packed with incorrections and pure lies (“C doesn’t have resizeable arrays” or “built-in strings” or “complex/imaginary number support”, “garbage collection”, etc etc etc… All lies which are refuted time and again but they still keep on ticking).
How about instead of the rant, you _actually_ refute these claims. Because as far as I know they are ALL true. How you can refute them I have no idea, but go ahead and take a shot at it…
I don’t see how anyone can adopt a language that, when compared to other languages like C++, doesn’t bring anything new to the table except a few useless semantic touch-ups and whole technical steps backwards, like the brain fart which is having strings being a part of the core language.
If you think that having strings be a 1st class data type is a “brain fart”, that explains your previous comments. Please give 1 actually reason why it shouldn’t be a core data type, and I mean ANY reason. Just one. I certainly can’t think of any.
If that wasn’t enough, the agressive astroturfing campaign that is being run by the D proponents, which includes spamming multiple online forums like newsgroups and blogs (this is a good example) clearly sends the message that the language isn’t able to stand on it’s own two feet without a string marketing campaign.
OMG, please stop!!! There are like maybe a couple thousand people… LITERALLY – who give a flying f*ck about D and would even notice an article about it. You act like its some massive coordinated effort to undermine the programming industry or something… 10 or 20 guys trying to spread the word is NOT an “aggresive astroturfing campaign”. Get a grip already.
C++ has function delegates for an instance. Not in the standard library, but C++ does support delegates. It also has garbage collector (many in fact, if you want to use them).
The information are incorrect, unless you only compare standard libraries which is a pretty moot comparison.
C doesn’t have resizeable arrays” or “built-in strings” or “complex/imaginary number support”, “garbage collection”, etc etc etc… All lies which are refuted time and again but they still keep on ticking
Huh? Did you read the chart? It says that C does not have garbage collection, built in strings, or complex numbers.
However…
char ** array = malloc(sizeof(char));
array = (char**)remalloc(sizeof(char));
is a resizable array, the contents are preserved.
char * s = “this is a built in string”;
is a built in string (what else would it be? It even says so.)
void * my_malloc(size_t size);
void my_free(void *);
is all you need to define to handle garbage collection in your private modules.
Nothing can beat C for pure expressive power, but it is time consuming even with XP methods, so something like D probably will be the next C++.
(Man I hope so, I need to work to eat and I don’t really like all the trained monkey stuff I need to do just to live with C++’s restrictiveness. And what idiot thought up ‘virtual’ as optional in an oop language? I blame the French, you know. It must have been them. I mean, who else, really? Come on.)
I love how you attempt to refute the claim about C using invalid C code.
1) If you resize your arrays in the way you propose, you will run into the following problems:
a) Your program will be extremely slow if you need to extend an array successively.
b) It is extremely bug prone, as you illustrated perfectly — You cast a char* to a char**, but only allocated 1 char (1 byte). Although it may compile, attempting to access the array is very likely to crash your program since you may end up accessing memory that doesn’t belong to your program (since sizeof(char) == 1 and sizeof(char*) == 4 on 32-bit architectures).
2) That is not a built-in string. It is a pointer to an array of chars, the syntax for obtaining which happens to be built-in. Try manipulating, even measuring, the string without library functions. I think you will find yourself rewriting string.h.
3) So basically C has garbage collection because you can override malloc, and write your own? COME ON, DUDE!
Oh, and yeah, C is NOT (NOT!!!!!) an expressive language! It is the most low-level language there is, and as such is very closely resembles assembler code.
Having things like the above built into the language (and really, they are just built into the mandatory standard library Phobos) makes programs less bug-prone, likely to perform better, and quicker to develop.
(C++ has an optional ‘virtual’ keyword for the same reason that members are private by default… Sometimes classes need to be able to depend on the side-effects of a method to avoid memory leaks and such, and so some methods may not be overridden.)
– Simon
“3) So basically C has garbage collection because you can override malloc, and write your own? COME ON, DUDE!”
C has a wonderful O(1) garbage collection! Observe:
int sum(int a, int b) {
int answer = a + b;
return answer;
}
After calling sum, the variable answer is automatically garbage collected.
(No, I’m not being totally serious)
How about instead of the rant, you _actually_ refute these claims. Because as far as I know they are ALL true. How you can refute them I have no idea, but go ahead and take a shot at it…
Those claims have been publicly refuted over and over again. The C++ case is particularly laughable due to the fact that the digitalmars people know for a fact that their D comparison to C++ has serious flaws and outright lies. Yet, they still refuse to correct them. It has been pointed out to them time and again and they still want to pretend that those lies are even remotely true, probably to influence some unknowing newbie to swallow the hook. Don’t believe me? Go take a look at C and C++ usenet newsgroups, where the digital mars people and even Greg Comeau himself frequently takes part in this astroturfing campaign.
But about the comparison flaws, C++ does have resizeable arrays. C++ does have built-in strings. C++ does have complex/imaginary number support. C++ does have garbage collection. And on and on and on… Yet, in the D comparison it is claimed that it does not. To make matters worse, some of those claims are ignored with the justification that they are not part of the standard library (as if every software component outside of the standard library didn’t exist) and others , which are in fact part of the standard library, are ignored because although they are a part of the standards they aren’t part of the core language. How can anyone take such a biased, flawed comparison seriously?
What does Greg C have to do with it? DM is Walter Bright, who wrote the Zortech C++ compiler which became Symantec C++. Who else do you mean by ‘the digital mars people’?
C++ does have garbage collection????
I’d be a bit careful about ‘C++ has strings’ too. std::string doesn’t have special support in the compiler and is Just Another Class (well, ok, a typedef) and the literal “hello world” is NOT a string in that sense.
If you think that having strings be a 1st class data type is a “brain fart”, that explains your previous comments. Please give 1 actually reason why it shouldn’t be a core data type, and I mean ANY reason. Just one. I certainly can’t think of any.
Trying to incorporate non-primitive types like strings into the core language of a programming language which aims to be modular is a braindead decision. Do you want a couple of reasons? Well, unnecessary core language bloat and all those unnecessary modularity restrictions for starts. And knowing the disadvantages of the core language approach, what are their advantages? None. So where in fact is that a good decision?
OMG, please stop!!! There are like maybe a couple thousand people… LITERALLY – who give a flying f*ck about D and would even notice an article about it. You act like its some massive coordinated effort to undermine the programming industry or something… 10 or 20 guys trying to spread the word is NOT an “aggresive astroturfing campaign”. Get a grip already.
The problem is that everytime a D article arises, the digitalmars people are behind it. Even in the newsgroups discussions, where Greg Comeau himself actively participates in spam campaigns on the virtues of D Vs whatever language the newsgroup is about. Don’t believe me? Check out google news and do a small search on that. There are a ton of spam discussions bordering trolling on language-specific newsgroups like comp.lang.c++.moderated, comp.lang.c++, comp.lang.ruby, comp.lang.tcl, etc… and even non–language specific newsgroups like comp.programming and comp.lang.misc which are started and fueled by digitalmars people dedicated to market the D programming language.
Trying to incorporate non-primitive types like strings into the core language of a programming language which aims to be modular is a braindead decision. Do you want a couple of reasons? Well, unnecessary core language bloat and all those unnecessary modularity restrictions for starts. And knowing the disadvantages of the core language approach, what are their advantages?
Could be speed. D strings, maps and arrays are faster than those provided by all C++ standard library implementations.
OTOH, IMHO, it says more about C++ standard library and its implementations than about D.
(OK, a bit of biased guerrilla marketing:
http://www.ultimatepp.org/www$uppweb2$vsstd$en-us.html
)
The problem is that everytime a D article arises, the digitalmars people are behind it. Even in the newsgroups discussions, where Greg Comeau himself actively participates in spam campaigns on the
Are you sure you got the name right? Greg Comeau is of Comeau C++ glory, which is highly regarded 100% standard compliant C++ -> C compiler. AFAIK he has nothing to do with D (unless he got completely crazy very recently:) and I have never seen him posting about D in C/C++ newsgroups.
The man behind D is Walter Bright, author of Zortech C++, AFAIK second C++ compiler on the market (~1988).
Currently he provides Digital Mars C++, direct descendant of Zortech C++ and D language & compiler.
Could be speed. D strings, maps and arrays are faster than those provided by all C++ standard library implementations.
OTOH, IMHO, it says more about C++ standard library and its implementations than about D.
(OK, a bit of biased guerrilla marketing:
http://www.ultimatepp.org/www$uppweb2$vsstd$en-us.html
)
That benchmark has been discussed in one of the many “D is better than jesus” newsgroup discussions and it has been pointed out that, as you stated, it is an implementation issue and not a result of “buil-in-ness”. If you are interested in that issue please read the discussion titled “How does D compare to C++?” on comp.lang.c++.moderated. In there once again the digital mars people claim (based on dishonest and incorrect comparissons) that D is some sort of second coming of jesus, claims which are promply corrected.
has been pointed out that, as you stated, it is an implementation issue
Well, yes and no. While better design and implementation of C++ string/map library can match and most likely outperform D solution, it is nevertheless true that compiler can do much better about types it has full control about.
It is always a trade-off between flexibility and performance.
(Now all that said, personally I think C++ way is better…)
What is this “jesus” of which you speak?
If that wasn’t enough, the agressive astroturfing campaign that is being run by the D proponents, which includes spamming multiple online forums like newsgroups and blogs (this is a good example)
Do they have any other choice? The project is not backed by big money to buy ads in New York Times.
Personally, I do not like D too much (mostly because I think C++ does not need fixing
, but I am far from angry about its guerrilla marketing…
I understand their need to sell the D idea. Nonetheless that doesn’t make astroturfing acceptable, specially if it is based on lies and dishonesty. If the D programming language is any good and has technical merit then it will fly on it’s own. If it is not (or to put it in other words, it doesn’t bring any relevant improvement over existing languages and is nothing more than another language with some small syntax changes and a couple of silly options just for the sake of being different) then obviously a lot of guerilla marketing, including astroturfing, is needed. Yet, marketing doesn’t bring any technical merits to any project.
Umm.. C DOESNT have built in strings, resizable arrays, garbage collection, etc.
Technicly it has resizable arrays from a memory standpoint (you can resize a previously allocated block of memory via realloc), however from a purely syntactic standpoint there are not resizable arrays. Ive used D, and its actually just a matter of setting a new size variable. myArray.size = 10; (the actual attribute name might not be correct, but its the same idea) This is all it takes to resize an array in D. Try that in C
Post the results here.
There is certainly no garbage collection (in any way shape or form), I dont know how you can say this is a lie. This is always listed as one of the drawbacks of C. Note that addons do not count as they are talking about the base C language. Not the C language with joe schmoes addon for garbage collection.
There are no built in strings either. Note the suddle difference between character arrays that can be manipulated via pre made functions in the standard C libraries, and having the language native support all of the various functions of strings via operators.
I think their point is that those things aren’t supported in the core language, but rather in the standard library. Therefore, it is possible (however unlikely) that an implementation could be released without those features and still be considered standards compliant.
> I think their point is that those things aren’t
> supported in the core language, but rather in the
> standard library. Therefore, it is possible (however
> unlikely) that an implementation could be released
> without those features and still be considered
> standards compliant.
How could an implementation that does not include the _standard_ library be called _standard_ compliant? I mean, what’s the point of a standard then?
The version 1.0 is about to be released. It was planed for Jan 1, 2007
http://www.digitalmars.com/d/future.html
however Walter Bright, its creator, posted yesterday that it’ll be delayed
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.c…
looks like D has a lot of functions, personally i think that this is a bad thing for a programming language.
The simpler the language and the fewer things it has makes a programming language better, since it is easier to read and maintain.
Of course this is probably a subjective thing and I’m sure there are probably people who prefer to have every function under the sun instead.
Edited 2007-01-02 23:13
The simpler the language and the fewer things it has makes a programming language better, since it is easier to read and maintain.
Are you refering to mantaining the language compiler and VM or programs written in the language?
I would think that it would be more difficult to read codes that didn’t use a lot of standard functions. Any D programmer would know the inbuilt functions and would find it much easier to read than trying to decipher how each other programmer decided to implement them.
– Jessta
“since it is easier to read and maintain.”
Good god… thats just what every maintnance programmer wants, every hack fresh from college righting their own round* functions. Then they get to spend their first month at each job figuring out if its Math.Round(), Math.round(), MyMath.Round(), or Math.rnd().
*Just an easy example, but this would also most likely include networking, string manipulation, random numbers, encryption, etc.
In other words standard libraries, with lots of functions covering basic tasks, makes maintnance easier!
Maybe this was supposed to be news because:
“The release of D version 1.0 is scheduled for Jan 1, 2007.” (Taken from http://www.digitalmars.com/d/future.html)
However, I can’t see any official post on their website about it.
http://www.digitalmars.com/d/changelog.html#new1_00
There are your changes…
I like the design philosophy of D, especially the module concept. Unlike many other modern langauges, it is statically typed and compiled, which means a lot of errors can be caught before running the program. In contrast to JavaScript, where a simple typo makes a difficult to track situation. I very much support the idea of a cleaned up and refined C++.
However, I really feel that such features as unit testing should be left to the library vendors and IDE makers. D’s feature matrix is dishonest when it claims that C++ has no strings, scope guard, array classes, and a lot of other things. They’re available as library features — standard, or very widely accepted libraries. The C#’s string is just an alias for System.String, which is a system library class as well, so I don’t understand the reason why C# string is considered built-in, while C++ string is not. C doesn’t have a string; C++ does.
Besides, the support for D is almost non-existent, except for a few open projects. If I have a C# question and post it on a MS newgroup, I get answer in minutes. D’s popularity is nowhere near close yet. Can I do web services in D as easily as with Visual Studio? Can I develop GUI as easily as with WinForms? If so, can I find so many 3rd party visual controls for it as for .NET or Delphi? Can I do COM programming with D?
Finally, I must be able to carry my existing source code, and link existing 3rd party engines to my project. I can very easily use C++ code from C# with the help of C++/CLI, which is a seamless link between the two worlds. I see major problems with D from this respect — nobody is going to rewrite millions of lines of legacy code, just because C++ is considered an old design where you can abuse the language and shoot yourself in the foot.
That being said, I still like the idea behind D, and would try it if they provided a way to directly reuse existing C++ code, like C++/CLI does it with .NET.
Not sure if this is still the case, but the D compiler isn’t even backwards compatible with itself, as in: if I write code for one version of the D compiler, chances of it successfully compiling on a later(or earlier) version are slim.
Not sure if this is still the case, but the D compiler isn’t even backwards compatible with itself, as in:
At this point I would forgive the backwards compatibility since it would have be a pre-1.0 release. But moving forward that is more important.
For a pre-1.0 release, I wouldn’t expect backwards compatiblilty. So I can forgive the D guys for this.
Why do you think you can’t reuse C++ directly from D?
I mean, the author of D also has a C++ compiler, and a lot of the technology is common (at least for his Win32 compiler). How do you think the existing D interfaces to C++ libraries like WxWidgets?
I personaly wouldn’t have said that C++/CLI provides for direct reuse of any C++ code I have that I might want to access: granted P/Invoke is dead handy though. But that’s not the point.
Yes, use D and your bleeding edge minority.
And I don’t understand why he bothered either. But that’s Walter’s business. What’s wrong with Eiffel anyway?
Why do you think you can’t reuse C++ directly from D?
Because the FAQ clearly states it:
“Why doesn’t D have an interface to C++ as well as C? Attempting to have D interface with C++ is nearly as complicated as writing a C++ compiler, which would destroy the goal of having D be a reasonably easy language to implement. For people with an existing C++ code base that they must work with, they are stuck with C++ (they can’t move it to any other language, either).”
What you can do to reuse an existing code base is to flatten it to a C API. D is fully compatible with pure C-style interfaces. Too bad it doesn’t support COFF object files, but it works with C-style DLLs.
Also, since D seems to support COM, it means a D vtable must be 100% compatible with a C++ vtable. So you can reuse Delphi and C++ classes residing in a DLL by inheritance. Your C++ code can export an interface with virtual methods only, and D can inherit from it. This is another way of interfacing, which works under the Win32 platform as long as the exported function signatures don’t use C++ types (especially not std::string or std::vector).
Either way, interfacing with existing code doesn’t come free. It’s quite a lot of work. In my previous post I mentioned C++/CLI, because it allows the seamless mixture of ISO C++ and .NET calls in the same unit. You can call an STL function from a managed method, for example. This way I can mix a C# call with a C++ call within the same function, without any worries. To make legacy C++ code available to C#, I still have to write a small wrapper class. Only that wrapper is much easier to write than a flat C-style API, which would require double wrapping (C++ classes wrapped into C wrapped into D classes).
You mentioned WxD. That’s a wrapper around wxWidgets. wxWidgets is already wrapped into a C-style API. That makes it available for virtually any language in the world, including Python. Normally it’s a very painful way of interfacing, and as I said, it requires double wrapping, with C as an intermediate layer. Go to http://wxd.sourceforge.net/ and see how an intermediate wxc library was created for this purpose. So it’s NOT a direct reuse of C++ classes, it ivolves major work, and can introduce major bugs. You have to pass strings as char*, vectors as T*, and so on, in that intermediate layer.
Nevertheless, I’m honestly wishing good luck to D. I like the language, and the author is an exceptionally talented person. He built airplanes in his garage, created a major C++ compiler from scratch (many don’t realize what an extraordinary accomplishment it is), and a language that’s better than C++ in almost every way. It’s only a decade too late for me.
Edited 2007-01-03 19:02
no amd64 linux port for gdc. no d for me.
yeah, thats a big downer..
i found D some time ago, and was intriqued, but the thing that keeps me away is the support, i cant rely on this as im not garantueed to be able to compile and run it. im gonna need upstream gcc support before i can use it.
no amd64 linux port for gdc. no d for me.
Well, one of things to know about D is that it is quite x86-32/x87 oriented. E.g. its famous 80-bit fp numbers are not available in SSE2 and therefore do not work in amd64 mode (that is why support was dropped from major C/C++ compilers).
Does anyone know of a language that allows you to extend the syntax as a core feature?
That would f.ex. let the programmer to define
arg1[arg2] = arg3
as
arg1.put(arg2,arg3)
or define
arg1++
as
arg1 = arg1 + 1
and that kind of syntactic sugar.
Lisp
How do you define a postfix operator in lisp?
Edited 2007-01-03 07:25
If you really want you could use reader macros in Common Lisp to define something like that.
That syntax can be defined in C++ with operator overloading. It isn’t very complicated.
As I understand, you can also do this in D (even simpler), except for the “++” syntax which is semi-deprecated and not supported for complex types.
Also, Ruby supports extending existing classes, and operator overloading.
– Simon
I know about operator overloading (which is similar in Ruby I think). But I believe operator overloading may be a bit to inflexible for what I’ve had in mind.
With operator overloading you can just “override” operators already supported (i.e the syntax is already there). I was hoping for something that allows new kinds of syntax to be invented.
Implementing that is impossible in a compiled language, and I believe in any language that is parsed using current-day language parsers.
Since what you have in mind (as I understand it) involves modifying the syntax of the language in new ways, you would need a whole meta-language for modifying the base language, which involves another parser. Generally, I cannot see how this is worth the trouble. Not only will the parser be immensely complex (and thus bug-prone), it will also produce confusing and unreadable source-code (since every programmer can basically make up his own language conventions).
What defines a language is not the things you express with it, but the things you don’t express with it.
– Simon
Why impossible? But OK, it doesn’t have to be infinitely flexible.
For example, in SML you can define any function that takes two arguments as infix and what precedence level it should have. It doesn’t seem to support postfix though.
Is this possible in C++/Ruby or can you only redefine a given set of infix operators?
There should be a continuum from fixed syntax – overridable syntax – modifiable sytnax – extendable syntax – redefinable syntax – flexible syntax. So how for out on the right can you go? How much has been done already?
Postfix and infix should be trivial. Trinary a bit harder, but not that much. Syntax that wraps a block ([]”” and such) even harder.
C has macros to achieve a little syntax extension, but they are quite limited. But a preprocessor may be one way. Compiler plug-ins could be another way. In any case you shouldn’t have to write a whole compiler just to get one language feature.
take a look at nemerle and their metaprograming.
http://nemerle.org/Syntax_extensions
Thanks, looks interesting.
Edit:
Some googling gave me this very useful discussion
http://lambda-the-ultimate.org/node/1718
(In case anyone else is interested)
Edited 2007-01-03 09:08
Besides Lisp, there’s a guy somewhere working on some language named Seed7. It supports user-defined statements and operators and in the examples section there is a couple of examples demonstrating how to define it’s own for statement and some operators.
There are a number of languages that allow you to redefine parts of the syntax using macros. Lisp is the classical example, but Scheme and Dylan fit the bill too.
In Dylan, you can define macros that take one of three forms:
define ?something
?stuff
end;
?something
?stuff
end;
?something ( ?args ) ;
Macros map code from code written using these shapes to other code that implements the desired semantics.
Between these constructs, much of the higher-level elements of the Dylan language are actually implemented as macros (either in the core library or in the compiler). Macros are also used to implement features not available in the core language. For example, with-lock and with-open-file are macros that implement RAII, without requiring destructors built into the language.
Edited 2007-01-03 19:10
I actually find the use of C derivative syntax to be a disadvantage when learning a new language. It’s not as if D is backward compatible as is the case for C++.
Java and C# have already added to the confusion; in both of these, the semantics are significantly different from C or C++, and really the only similarity with C is syntactical.
D seems to diverge even further from the semantical C view, but tries to steal the advantage, relying on familiarity with C in the industry by re-using some of the syntax:
Variable definitions are different (eg.byte vs char)
Interface specifications are different
Open arrays
Strings
Nested functions
Garbage collection
“Mixins”
The list goes on and on
I have found languages such as Modula/Oberon a whole lot easier to learn (without having to unlearn another language) as it’s syntax and style are completely different from other languages. This allows efficient partitioning in my mind [boxing] between the languages, and allows one to become proficient in a variety of languages. The similarity only leads to confusion and syntactical or even worse, semantic coding errors.
Literally, trying to learn C, C++, Java, C# and now D all at the same time leads to being a “Jack of all trades, but master of none”.
I really really like some of the new ideas in D, and even some of the old ideas being re-introduced. But why, oh why try to make it look like C?
Edited 2007-01-03 08:38
I really really like some of the new ideas in D, and even some of the old ideas being re-introduced. But why, oh why try to make it look like C?
I believe that it’s because:
1) D is targeted at the same problems as C/C++.
2) D is meant to be an evolution descendant of C++ (not a revolutionary descendant) so it is intended to look similar
3) Everyone who uses C/C++ and to some degree Java will ‘feel’ familiar with D’s syntax. (i.e. shallow learning curve)
//void * my_malloc(size_t size);
//void my_free(void *);
//is all you need to define to handle garbage
//collection in your private modules.
Is this what you think garbage collection is? I hope not, but if it is, I would recommend that you go back to school.
I like quotation from famous people, it always add credibility to a project.
“To D, or not to D. — Willeam NerdSpeare”
Well who is this guy ?
I wonder what are the domains that D is trying to cover.
‘System’ language can not mean a language to write a kernel in, because D has quite a lot of high level concepts built in which are not always suitable for kernel development.
The above comment is also valid for drivers.
‘System’ certainly can not mean business applications, because those are covered well by C#, Java, Visual Basic, even Cobol.
‘System’ might mean scientific or military hard/soft real-time or communication applications, but I do not see how companies can replace ADA or C++ for that matter. These systems do not make use of garbage collection, as they usually run in embedded platforms.
‘System’ can not mean PC games, because PC games have either really low level code which D does not make a difference for (shader code for example) or very high level code (the Unreal Engine, for example) which is already written in C++.
‘System’ can not mean console games, because D is not available for the major consoles which all have their own proprietary C-based development systems.
For all these reasons, I do not think D will be successful. It’s not really low level, not really high level, not really functional, it contains every feature under the sun (it has over 90 keywords!), and the other languages already have billions of lines of code written for them.
Personally I would consider switching to another C++-like language if it significantly lowered the development cost. D does lower the development cost, but not significantly. It is essentially C++ with a fixed collector and a few other goodies.
>’System’ can not mean PC games
Take a look at ABA games ( http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html ). Not all, but a handful of them are indeed written in D and have turned out quite nice and playable. (Sure, they’re no Unreal Engine, and yes, they make use of SDL and/or OpenGL for low level stuff, but the games themselves are written in D)
so finally it’s out
http://www.digitalmars.com/d/changelog.html
http://ftp.digitalmars.com/dmd.1.00.zip
I was wondering why the site was slow as hell, I understand now.
Thanks for the information.
Can we drop the word “astroturf”?
Thank you.
GreatBunzinni: There’s a huge difference between having something part of a language and part of a standard library.
And strings is NOT part of the C/C++ languages. It is only implicitly part of the D language, as a consequence of D’s advanced support for arrays (a string in D is defined as an array of char: char[]).
However, if you cannot see the benefit of having strings built-in in the language, I have serious doubts as to your experience in real-world situations.
A huge majority of security issues stem from buffer-overflow problems and bounds checking. This is the reason programming in C is strongly discouraged for applications where security is a higher priority than speed. But having strings built into the language prevents all that. It is simply impossible to cause carnage, since everything is already under control.
Also — please refrain from posting 5 successive posts.
– Simon
You claimed “there’s a huge difference between having something part of the (core) language and part of a standard library” and yet you failed to point out the benefits. So please point out what are the benefits of pushing a non-primitive data type into the core language instead of supporting it as a derived data type, specially in programming languages which are created with modularity and the ability to create data types in mind.
Then you boldly claim that C++’s strings aren’t a part of the language. That is so blatantly false that it isn’t even funny. The std::string is defined in the C++ standards, as all it’s standard library. It may not be hard-pressed into the core language, which frankly would be unnecessary bloat, but that doesn’t make it less of a language part than it is. It’s a part of the language and it is as modular as it gets, which is what makes a language great, specially if it aims to be modular.
You really don’t understand, do you?
As I pointed out earlier, there is a HUGE difference between having something part of a language and part of it’s standard library!
For instance, malloc/realloc are NOT part of the C language. They are, however, part of the C Standard Library. They’re even defined in stdlib.h, look at ‘man malloc’ for yourself.
std::string IS in the C++ STL, which most consider the C++ standard library, however you can easily avoid the string type: simply don’t #include <string>. Yes, that means it is NOT part of the language, as opposed to all the simple types, such as int, double, char, char*, void*, etc.
luzr: Yes, C++’s string is overrun-safe. And yes, D’s string implementation DOES bounds-checking. The performance hit is very very much worth it when considering the security benefits. Besides, in C you need to do it anyway unless you want blatantly insecure code.
(I just checked — An ArrayBoundsError exception is thrown in D if you try to write beyond the boundaries of an array.)
It’s amazing how great a length people are willing to go to defend a cause they are obviously not involved in.
– Simon
For instance, malloc/realloc are NOT part of the C language. They are, however, part of the C Standard Library. They’re even defined in stdlib.h, look at ‘man malloc’ for yourself.
std::string IS in the C++ STL, which most consider the C++ standard library, however you can easily avoid the string type: simply don’t #include <string>.
Well, that is just a matter of definition. C++ standard clearly defines “C++ core language” and “C++ library”. C++ library is part of C++ Language standard, means std::string is part of C++ language (which BTW is a pity, because std::string is a piece of crap).
Yes, C++’s string is overrun-safe. And yes, D’s string implementation DOES bounds-checking. The performance hit is very very much worth it when considering the security benefits.
From D website
Array Bounds Checking
In C++, string array bounds checking for [] is not done. In D, array bounds checking is on by default and it can be turned off with a compiler switch after the program is debugged.
So it is not consistently checked all the time. Equals to my C++ ASSERTs…
A huge majority of security issues stem from buffer-overflow problems and bounds checking. This is the reason programming in C is strongly discouraged for applications where security is a higher priority than speed. But having strings built into the language prevents all that. It is simply impossible to cause carnage, since everything is already under control.
The C++ programming language didn’t made strings a part of the core language and nonetheless where are the buffer-overflow problems associated with them? They are nowhere to be seen. Just because C uses arrays as strings and, when not used properly, they can generate security problems it doesn’t make the concept of not having strings included in the core language insecure.
Moreover, pushing non-primitive data types into the core language ends up being nothing more than syntactic sugar covering up a component which could very much be modular, as in C++’s case. So where are the security benefits of adding syntactic sugar to a module? There are none.
Also — please refrain from posting 5 successive posts.
If you don’t like to read the discussions in flat mode than you are free to use any of the threaded modes that are available. And by the way, please refrain from telling anyone how and/or when to write their posts. If you believe that is acceptable then I could also tell you to reply directly to the posts instead of posting to the discussion root, as you just did.
A huge majority of security issues stem from buffer-overflow problems and bounds checking.
Come on, any decent C++ string class avoids them too. You do not have to have strings in core language to avoid buffer-overflow.
And, BTW, unless D makes runtime bounds checks, which I quite sure it does not for performance reasons, you can still have buffer-overflows in D (just use wrong index).
If the following items were working and implemented in D, I’d then maybe try it out:
OOP:
Multiple Inheritance No
Dynamic class loading No
Compatibility:
Macro text preprocessor No
Seems that Obj-C is overlooked. Obj-C has many additional features to original C, and Obj-C 2.0 that will come with Leopard, will have garbage collector and support 64 bit.
Oh yeah, by the way…
Technically, strings are not part of the core language in D. However, arrays are. And D supports some very advanced arrays compared to C/C++. For instance, they are resizable. No, reallocating memory is not the same as resizing! C++’s std::vector does resizing, it is not built into the language.
Having something used so extremely often built into the language is good for the following reasons:
1) You avoid common traps, such as buffer overruns, and resizing too often.
2) It can dramatically improve performance, since the compiler knows exactly what you mean, and can optimize accordingly. You don’t need to bother with the details.
This is hardly bloat.
If you think you know better, you are entirely free to implement your own String-class (it has been done, FYI — see dstring). It is, however, an extremely bad idea.
– Simon
If you don’t wish to try D then don’t. No one is twisting your arm, but don’t fool yourself into believing they are equivalent.
C++ has some features D doesn’t(multiple inheritance,return references) and D has many features C++ doesn’t (lazy expressions, delegates, inner functions, scope expressions, static if, mixins).
With lazy expressions you can make control structures in D. Here is a homebrewed version of while:
void While( lazy bool condition, lazy void expression )
{
for( ; cond(); ) expression();
}
Inline delegates allow List comprehensions in D:
http://www.digitalmars.com/d/archives/digitalmars/D/39313.html
Scope guard statements make sure cleanup without multiple try/catch statements:
http://www.digitalmars.com/d/statement.html#ScopeGuardStatement
Just the fact it uses references instead of pointers makes my programs less painful.
Those of you who have never used it should really quit trashing it just because it isn’t C++.
-David
At first I was a huge fan of ‘D’. The concept.
I started to play more with other newer language concepts, ruby, and then Io.
One thing about ‘D’ that I find worrisome was that C++ has ~70 or so keywords. With D that’s now in the 90’s. I wonder if they carried over too much un needed crap into ‘D’. (In contrast, ‘Io’ has no keywords)
…but D is not going to be the cause of it.
x86 specific is the biggest problem with it and I am not going to drop PPC support just to jump on some bandwagon.