Linked by Thom Holwerda on Tue 2nd Jan 2007 21:39 UTC
General Development "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."
Order by: Score:
Garbage Collection in the kernel
by ma_d on Tue 2nd Jan 2007 22:47 UTC
ma_d
Member since:
2005-06-29

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?

Reply Score: 4

rayiner Member since:
2005-07-06

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.

Reply Score: 5

renox Member since:
2005-07-06

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.

Reply Score: 2

love D!
by netsql on Tue 2nd Jan 2007 22:50 UTC
netsql
Member since:
2005-09-09

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

Reply Score: 2

RE: love D!
by thrashdront on Wed 3rd Jan 2007 10:52 UTC in reply to "love D!"
thrashdront Member since:
2006-11-07

That is probably another D, from sun.
Something to do with dtrace.

Reply Score: 2

What the ....
by tux68 on Tue 2nd Jan 2007 22:54 UTC
tux68
Member since:
2006-10-24

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..

Reply Score: 5

RE: What the ....
by GreatBunzinni on Wed 3rd Jan 2007 00:22 UTC in reply to "What the ...."
GreatBunzinni Member since:
2005-10-31

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.

Reply Score: 2

RE[2]: What the ....
by difool on Wed 3rd Jan 2007 00:46 UTC in reply to "RE: What the ...."
difool Member since:
2006-09-05

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

Reply Score: 5

RE[2]: What the ....
by rayiner on Wed 3rd Jan 2007 00:55 UTC in reply to "RE: What the ...."
rayiner Member since:
2005-07-06

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.

Reply Score: 5

RE[3]: What the ....
by GreatBunzinni on Wed 3rd Jan 2007 12:16 UTC in reply to "RE[2]: What the ...."
GreatBunzinni Member since:
2005-10-31

My bad. Unfortunately I wrote C instead of C++.

Reply Score: 2

RE[2]: What the ....
by galvanash on Wed 3rd Jan 2007 01:32 UTC in reply to "RE: What the ...."
galvanash Member since:
2006-01-25

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.

Reply Score: 5

RE[3]: What the ....
by dylansmrjones on Wed 3rd Jan 2007 05:30 UTC in reply to "RE[2]: What the ...."
dylansmrjones Member since:
2005-10-02

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.

Reply Score: 4

RE[4]: What the ....
by Magma on Wed 3rd Jan 2007 06:19 UTC in reply to "RE[3]: What the ...."
Magma Member since:
2006-03-07

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.)

Reply Score: 3

RE[5]: What the ....
by vinterbleg on Wed 3rd Jan 2007 06:51 UTC in reply to "RE[4]: What the ...."
vinterbleg Member since:
2005-07-11

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

Reply Score: 5

RE[6]: What the ....
by vegai on Wed 3rd Jan 2007 07:10 UTC in reply to "RE[5]: What the ...."
vegai Member since:
2005-12-25

"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)

Reply Score: 1

RE[3]: What the ....
by GreatBunzinni on Wed 3rd Jan 2007 12:32 UTC in reply to "RE[2]: What the ...."
GreatBunzinni Member since:
2005-10-31

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?

Reply Score: 2

RE[4]: What the ....
by jmansion on Wed 3rd Jan 2007 15:56 UTC in reply to "RE[3]: What the ...."
jmansion Member since:
2006-02-20

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.

Reply Score: 2

RE[3]: What the ....
by GreatBunzinni on Wed 3rd Jan 2007 13:05 UTC in reply to "RE[2]: What the ...."
GreatBunzinni Member since:
2005-10-31

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.

Reply Score: 2

RE[4]: What the ....
by luzr on Wed 3rd Jan 2007 18:39 UTC in reply to "RE[3]: What the ...."
luzr Member since:
2005-11-20


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.

Reply Score: 1

RE[5]: What the ....
by GreatBunzinni on Wed 3rd Jan 2007 19:20 UTC in reply to "RE[4]: What the ...."
GreatBunzinni Member since:
2005-10-31

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.

Reply Score: 0

RE[6]: What the ....
by luzr on Wed 3rd Jan 2007 19:31 UTC in reply to "RE[5]: What the ...."
luzr Member since:
2005-11-20


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...)

Reply Score: 1

v RE[6]: What the ....
by MrGAM on Thu 4th Jan 2007 02:56 UTC in reply to "RE[5]: What the ...."
RE[2]: What the ....
by luzr on Wed 3rd Jan 2007 10:16 UTC in reply to "RE: What the ...."
luzr Member since:
2005-11-20

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...

Reply Score: 2

RE[3]: What the ....
by GreatBunzinni on Wed 3rd Jan 2007 13:13 UTC in reply to "RE[2]: What the ...."
GreatBunzinni Member since:
2005-10-31

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.

Reply Score: 3

RE[2]: What the ....
by computrius on Wed 3rd Jan 2007 16:41 UTC in reply to "RE: What the ...."
computrius Member since:
2006-03-26

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.

Reply Score: 1

RE[2]: What the ....
by Clinton on Wed 3rd Jan 2007 17:35 UTC in reply to "RE: What the ...."
Clinton Member since:
2005-07-05

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.

Reply Score: 1

RE[3]: What the ....
by Morin on Thu 4th Jan 2007 14:27 UTC in reply to "RE[2]: What the ...."
Morin Member since:
2005-12-31

> 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?

Reply Score: 2

RE: What the ....
by difool on Wed 3rd Jan 2007 00:30 UTC in reply to "What the ...."
difool Member since:
2006-09-05

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...

Reply Score: 4

D
by kap1 on Tue 2nd Jan 2007 23:11 UTC
kap1
Member since:
2006-05-12

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

Reply Score: 2

RE: D
by jessta on Wed 3rd Jan 2007 01:46 UTC in reply to "D"
jessta Member since:
2005-08-17

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

Reply Score: 2

RE: D
by eggs on Wed 3rd Jan 2007 17:15 UTC in reply to "D"
eggs Member since:
2006-01-23

"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!

Reply Score: 2

Version 1?
by Nycran on Wed 3rd Jan 2007 00:01 UTC
Nycran
Member since:
2006-02-06

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.

Reply Score: 4

RE: Version 1?
by elzurawka on Thu 4th Jan 2007 15:49 UTC in reply to "Version 1?"
elzurawka Member since:
2005-07-08
Lack of legacy code support
by tdemj on Wed 3rd Jan 2007 00:10 UTC
tdemj
Member since:
2006-01-03

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.

Reply Score: 5

RE: Lack of legacy code support
by milkycow on Wed 3rd Jan 2007 02:47 UTC in reply to "Lack of legacy code support"
milkycow Member since:
2006-04-04

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.

Reply Score: 4

RE[2]: Lack of legacy code support
by Aaron1 on Wed 3rd Jan 2007 02:57 UTC in reply to "RE: Lack of legacy code support"
Aaron1 Member since:
2006-01-19

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.

Reply Score: 3

hohonuuli Member since:
2005-11-23

For a pre-1.0 release, I wouldn't expect backwards compatiblilty. So I can forgive the D guys for this.

Reply Score: 1

RE: Lack of legacy code support
by jmansion on Wed 3rd Jan 2007 09:21 UTC in reply to "Lack of legacy code support"
jmansion Member since:
2006-02-20

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? ;-)

Reply Score: 2

RE[2]: Lack of legacy code support
by tdemj on Wed 3rd Jan 2007 18:56 UTC in reply to "RE: Lack of legacy code support"
tdemj Member since:
2006-01-03

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

Reply Score: 3

no 64bit support
by _df_ on Wed 3rd Jan 2007 01:59 UTC
_df_
Member since:
2005-07-06

no amd64 linux port for gdc. no d for me.

Reply Score: 3

RE: no 64bit support
by Redeeman on Wed 3rd Jan 2007 02:34 UTC in reply to "no 64bit support"
Redeeman Member since:
2006-03-23

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.

Reply Score: 1

RE: no 64bit support
by luzr on Wed 3rd Jan 2007 10:20 UTC in reply to "no 64bit support"
luzr Member since:
2005-11-20

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).

Reply Score: 1

Extendable syntax
by John Nilsson on Wed 3rd Jan 2007 05:54 UTC
John Nilsson
Member since:
2005-07-06

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.

Reply Score: 2

RE: Extendable syntax
by prince_seth on Wed 3rd Jan 2007 06:21 UTC in reply to "Extendable syntax"
prince_seth Member since:
2006-11-22

Lisp

Reply Score: 4

RE[2]: Extendable syntax
by John Nilsson on Wed 3rd Jan 2007 07:20 UTC in reply to "RE: Extendable syntax"
John Nilsson Member since:
2005-07-06

How do you define a postfix operator in lisp?

Edited 2007-01-03 07:25

Reply Score: 2

RE[3]: Extendable syntax
by ramunas on Wed 3rd Jan 2007 10:23 UTC in reply to "RE[2]: Extendable syntax"
ramunas Member since:
2005-07-06

If you really want you could use reader macros in Common Lisp to define something like that.

Reply Score: 3

RE: Extendable syntax
by vinterbleg on Wed 3rd Jan 2007 06:40 UTC in reply to "Extendable syntax"
vinterbleg Member since:
2005-07-11

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

Reply Score: 1

RE[2]: Extendable syntax
by John Nilsson on Wed 3rd Jan 2007 07:22 UTC in reply to "RE: Extendable syntax"
John Nilsson Member since:
2005-07-06

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.

Reply Score: 2

RE[3]: Extendable syntax
by vinterbleg on Wed 3rd Jan 2007 07:34 UTC in reply to "RE[2]: Extendable syntax"
vinterbleg Member since:
2005-07-11

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

Reply Score: 1

RE[4]: Extendable syntax
by John Nilsson on Wed 3rd Jan 2007 07:59 UTC in reply to "RE[3]: Extendable syntax"
John Nilsson Member since:
2005-07-06

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.

Reply Score: 2

RE: Extendable syntax
by noraguta on Wed 3rd Jan 2007 08:18 UTC in reply to "Extendable syntax"
noraguta Member since:
2007-01-03

take a look at nemerle and their metaprograming.
http://nemerle.org/Syntax_extensions

Reply Score: 3

RE[2]: Extendable syntax
by John Nilsson on Wed 3rd Jan 2007 08:55 UTC in reply to "RE: Extendable syntax"
John Nilsson Member since:
2005-07-06

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

Reply Score: 2

RE: Extendable syntax
by GreatBunzinni on Wed 3rd Jan 2007 13:20 UTC in reply to "Extendable syntax"
GreatBunzinni Member since:
2005-10-31

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.

Reply Score: 2

RE: Extendable syntax
by rayiner on Wed 3rd Jan 2007 19:04 UTC in reply to "Extendable syntax"
rayiner Member since:
2005-07-06

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

Reply Score: 2

Oh No! Not another C Syntax
by Lousewort on Wed 3rd Jan 2007 08:36 UTC
Lousewort
Member since:
2006-09-12

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

Reply Score: 5

RE: Oh No! Not another C Syntax
by hohonuuli on Tue 9th Jan 2007 16:47 UTC in reply to "Oh No! Not another C Syntax"
hohonuuli Member since:
2005-11-23

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)

Reply Score: 1

Back to school for you I'm afraid
by snowflake on Wed 3rd Jan 2007 08:47 UTC
snowflake
Member since:
2005-07-20

//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.

Reply Score: 4

Quotation
by Duffman on Wed 3rd Jan 2007 09:34 UTC
Duffman
Member since:
2005-11-23

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 ?

Reply Score: 1

What does 'system' means in D's case?
by axilmar on Wed 3rd Jan 2007 12:00 UTC
axilmar
Member since:
2006-03-20

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.

Reply Score: 4

Just a small note...
by gonzalo on Wed 3rd Jan 2007 15:00 UTC in reply to "What does 'system' means in D's case?"
gonzalo Member since:
2005-07-06

>'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)

Reply Score: 1

DMD 1.00 - here it is!
by difool on Wed 3rd Jan 2007 12:44 UTC
difool
Member since:
2006-09-05
RE: DMD 1.00 - here it is!
by renox on Wed 3rd Jan 2007 16:31 UTC in reply to "DMD 1.00 - here it is!"
renox Member since:
2005-07-06

I was wondering why the site was slow as hell, I understand now.
Thanks for the information.

Reply Score: 1

Please...
by vinterbleg on Wed 3rd Jan 2007 14:31 UTC
vinterbleg
Member since:
2005-07-11

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

Reply Score: 4

RE: Please...
by GreatBunzinni on Wed 3rd Jan 2007 17:32 UTC in reply to "Please..."
GreatBunzinni Member since:
2005-10-31

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.

Reply Score: 1

RE[2]: Please...
by vinterbleg on Thu 4th Jan 2007 06:23 UTC in reply to "RE: Please..."
vinterbleg Member since:
2005-07-11

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

Reply Score: 1

RE[3]: Please...
by luzr on Thu 4th Jan 2007 14:34 UTC in reply to "RE[2]: Please..."
luzr Member since:
2005-11-20

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...

Reply Score: 1

RE: Please...
by GreatBunzinni on Wed 3rd Jan 2007 17:38 UTC in reply to "Please..."
GreatBunzinni Member since:
2005-10-31

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.

Reply Score: 1

RE: Please...
by GreatBunzinni on Wed 3rd Jan 2007 17:41 UTC in reply to "Please..."
GreatBunzinni Member since:
2005-10-31


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.

Reply Score: 0

RE: Please...
by luzr on Wed 3rd Jan 2007 18:43 UTC in reply to "Please..."
luzr Member since:
2005-11-20

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).

Reply Score: 1

If He/She Got The Following Working....
by mlauzon on Wed 3rd Jan 2007 20:12 UTC
mlauzon
Member since:
2005-07-25

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

Reply Score: 1

Obj-C
by Babi Asu on Wed 3rd Jan 2007 23:37 UTC
Babi Asu
Member since:
2006-02-11

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.

Reply Score: 1

Strings in the core language
by vinterbleg on Thu 4th Jan 2007 06:31 UTC
vinterbleg
Member since:
2005-07-11

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

Reply Score: 1

C++ zealots
by DavidM on Fri 5th Jan 2007 01:59 UTC
DavidM
Member since:
2006-06-29

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

Reply Score: 2

Interesting
by bnolsen on Fri 5th Jan 2007 05:19 UTC
bnolsen
Member since:
2006-01-06

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)

Reply Score: 1

SamuraiCrow
Member since:
2005-11-19

...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.

Reply Score: 1