The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Any D users here?

I started messing with D sometime back after some people here were talking about it.

I think I've basically learned it and have even written some production modules using it.

But, at this point, I'm going to leave it alone. I wanted D to be the obvious improvements to C. But it's not. I don't like the string implementation at all, it's pretty much incomplete and the design is just wrong in some places. Walter Bright wants the string to just be a array of characters so badly and that constraint has made the implementation poor, plus I'll say that even the array implementation is incomplete. It seems its an experimental language that is not finished yet.

Also, there is no multiple inheritance, but there is also no messaging. I got to have one or the other if I'm going to switch.

Yes, there are many small things that are an improvement like foreach obviously, but none of it is anything I don't already have in C++.

What I am wondering is if you think that D is going to eventually be completed, or if the current version is pretty much the way it's going to be.
Scott
Thursday, February 15, 2007
 
 
> I think I've basically learned it and have even
> written some production modules using it.

So you probably no the language better than I ;)

> What I am wondering is if you think that D is
> going to eventually be completed

Just recently the official version 1.0 was released so it has hit some level of completeness.

> or if the current version is pretty much
> the way it's going to be.

Based on the discussions that sometimes rage on the D forum it seems like the the language is anything but static:

http://www.digitalmars.com/webnews/newsgroups.php?search_txt=&group=digitalmars.D

To me it looks like a nice alternative to C++ but I personally don't like garbage collections languages.

I have never had a problem understanding pointers so issues like leaks, overwrites and ownership have never been a problem for me.

I much prefer to manage pointers and memory usage using a good design, rather than leaving the task to a "one size fits all" garbage collector.
Jussi Jumppanen
Thursday, February 15, 2007
 
 
You know, I agree with you somewhat on the garbage collection. It's not always the best solution.

You can supposedly turn it off, though I haven't tried that yet. You can still use malloc and free for objects. It seems that setting a garbage collected pointer to NULL is the same as telling the collector it's ok to free it.

I have also noted as you have that it is in a state of flux despite it's 1.0 status.
Scott
Thursday, February 15, 2007
 
 
I've been following the D developer newsgroup for the last three years, and post my opinions to the NG every so often.

I've written a bit of code in D (although it's been a while), and there are a lot of things I like:

* No header files. It's the 21st century, so it's about time that a C-like natively-compiled language implements a 2-pass compiler. Thank god.

* No preprocessor.

* Reference semantics are the default for objects. with value semantics for primitives and structs. Pointer semantics are available, though not usually necessary.

* Centralized memory management. The GC owns all memory, so you never have to make boneheaded decisions about which  object owns which little chunk of memory. The heap owns all memory, and it cleans up after itself. It's very very nice. (Though the D GC is only a conservative collector, and it doesn't do any copying, so it still has a long way to go.)

A few of my complaints:

* The string implementation sucks. Rather than developing a single string class, you still have to deal with char[] and wchar[]. A huge disappointment.

* The standard library is all over the place. Love it or hate it, in Java and C#, the standard library is full of classes. In the D standard library, some of the functionality is provided by classes. Some of it comes from functions in modules. Add to this inconsistency the many different naming conventions (CamelCase, lowerCamelCase, underscored_names, etc) and the standard library is pretty painful to work with.

* The language itself includes support for resizable arrays and hashtables. That can be handy, but it prevents any new collection class library from presenting a really well-designed set of classes that play nicely together.

* The foreach() and foreach_reverse() implementations are weird. Rather than using iterators (and generators, through coroutines), the D implementation uses delegates. In my opinion, it overly conflates the collection contents with the collection iterator, and it implies that each collection only has two sensible iteration strategies (forward and reverse).

* Dynamically linking is still difficult. I would have preferred it if the D compiler produced object files in its own binary format, loading and linking them at runtime through a dynamic classloader. Because of difficulties linking, most D programs are statically linked.

I may think of other things later, but that's all for now...
BenjiSmith Send private email
Thursday, February 15, 2007
 
 
"To me it looks like a nice alternative to C++ but I personally don't like garbage collections languages.

I have never had a problem understanding pointers so issues like leaks, overwrites and ownership have never been a problem for me.

I much prefer to manage pointers and memory usage using a good design, rather than leaving the task to a "one size fits all" garbage collector. "

I use only C for automatic memory management with C++ Automatic virtual destructors, so there is never any memory leak in my programs.

If anyone is interested and is not sure how to implement automatic memory management in C I will let you know.
Donald Duck
Sunday, February 18, 2007
 
 
> I use only C for automatic memory management
> with C++ Automatic virtual destructors, so
> there is never any memory leak in my programs.

Exactly. Managing memory is not rocket science and with a bit of planning and design it is in fact dead simple ;)

I would much prefer to track down an erroneous new/delete than some obscure memory allocation error deep inside the garbage collector.
Jussi Jumppanen
Sunday, February 25, 2007
 
 
"If anyone is interested and is not sure how to implement automatic memory management in C I will let you know."

I'm just learning C, so I'll bite.  Could you expand on this a bit?
Kevin Send private email
Sunday, February 25, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz