LinuxQuestions.org - D- ? Is D Programming Language Just Too Much?

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - D- ? Is D Programming Language Just Too Much? (https://www.linuxquestions.org/questions/programming-9/d-is-d-programming-language-just-too-much-898862/)

D- ? Is D Programming Language Just Too Much?

First of all for those of you who have not heard about it, D Programming Language http://d-programming-language.org/ .

The first time I looked at the language garbage collection scared me away. I don't really like having my program stop randomly to collect garbage. The second time the write up on garbage collection put me on the fence. After taking a good look I notices that the language had some fantastic features. Many of them being related to re-doing (removing) the pre-processor and make it more like regular code. I also loved delegates something that was a pain in the @$$ to do in C++.

But, after looking through the language I found that a lot of things were really quite unnecessary. Guido van Rossum (creator of python) popped into my head thinking that there should be one clear way to do things. For example, closures. Fantastic for scripting languages because they are quick and easy. For the same reason that the are awesome for replacing macros. But, as soon as you return them from a function I think you want a class. Writing code like this is about writing something that can be evolved. A function that returns a function is just a class constructor with one method. Now try to add a second one. Oops.

Also, I find that too much is implemented in the language instead of libraries. This is one of the things that made C so powerful. You started with noting but if you wanted you have access to a wonderful standard library. In D string is a built-in and all of the functions that work with is are just sitting around in the global namespace. They did the same things with arrays. The say that an array carries around no bounds information. This is true and a great reason to wrap it in a class that implements an array interface. Then you can extend it at will and all of the functions you need are right there in that namespace. I don't think that C++ needed to have new features. The syntax and symantics just needed to be cleaned up and re-worked.

I'm not saying that D sucks. In fact I love it. The language took a bold step forward with the beloved C/C++ style and did a lot of cleaning up. The only problem is I think it went a little overboard.

The things that I like most about D is that it has build in standardized support for unit testing and documentation. Making it easy to ensure you codes works and a small update doesn't break anything, and makes it easy for other people to know what your code does (or you a year from now).

I have one more nit that I am going to pick before I shut up. I think using the old build system was a bit of a mistake. The reason why I started looking for a new programming language after loving C/C++ for a good number of years is that the #include's suck. They really do. You have to keep the header file and the source file and compile them correctly. If you write a library you need to ensure that people using it link their program with the proper libraries and la-deda-deda. I was looking something like an import style inclusion where everything is included once and the imported namespace is controlled. Unfortunately D doesn't do this how I would like. D sticks to old tools for compiling and linking. This means that imports aren't automatically compiled and linked as necessary. I would love to go compile app.d and have the whole application build and linked for me. In the new days of programming languages is think it would be good to have the build info built right into the file.

So I was wondering what you guys thought about D and evolutions of C.

Another last thing. In the title I made a D- joke, I wasn't really intending to make a new language. I don't know squat about compiler writing or the like. But if someone/somepeople (preferably more that one person) share some views I would be prepared to put some time into helping this project happen. Just an offer :P

Quote:

I'm not saying that D sucks

Good :)

Can I say that C++ sucks?

C rules.

So does Ada :)

But I'm guessing that D is more or less irrelevant now that we have F#.

D should not be seen as a successor of C or C++, that is nonsense.
it is a nice "new" (not rely) programming language with tons of cool features

unfortunately it is out since years now but it is still not part of distributions, with the 1.x series there was the tango/phobos quirks and some other stuff, but with 2 things become somehow better and I still have the hope that someday it will be more in use.

since some years, don' know exactly how many but enough, it is meanwhile somehow a tradition for me to go once or twice a year to d programming language, play around with it and think ok, lets wait an other year...

Quote:

Originally Posted by youarefunny (Post 4450715)

The first time I looked at the language garbage collection scared me away. I don't really like having my program stop randomly to collect garbage. The second time the write up on garbage collection put me on the fence. After taking a good look I notices that the language had some fantastic features. Many of them being related to re-doing (removing) the pre-processor and make it more like regular code. I also loved delegates something that was a pain in the @$$ to do in C++.

One thing I like about garbage collection in D, is that you have a lot of control over it. You can disable the GC and you can manually invoke it. (Which means it actually won't stop your program randomly if you don't want it to). Also, you have full access to the C standard library and you can use manual memory management. (which is not supported that well by the standard library yet, but I think it will eventually)

Quote:

But, after looking through the language I found that a lot of things were really quite unnecessary. Guido van Rossum (creator of python) popped into my head thinking that there should be one clear way to do things.

Python has both classes and closures. Sure, they somewhat conflate the two, but that is only practical if you have no static typing.

Quote:

For example, closures. Fantastic for scripting languages because they are quick and easy. For the same reason that the are awesome for replacing macros. But, as soon as you return them from a function I think you want a class. Writing code like this is about writing something that can be evolved. A function that returns a function is just a class constructor with one method. Now try to add a second one. Oops.

The power of delegates/closures is that they are not an object with a single method. They are a function, that is represented as pointer to code and pointer to context. Nobody cares what the context actually is. It could be an object reference of one class, it could be an object reference of another class (this you get in python through dynamic typing), or something entirely different, for example, it could be a function pointer itself, so that you can pass a function pointer as a delegate.
Btw, C++11 will have closures. I think it would be silly to have delegate literals/lambda functions but not closures.

Quote:

Also, I find that too much is implemented in the language instead of libraries. This is one of the things that made C so powerful. You started with noting but if you wanted you have access to a wonderful standard library. In D string is a built-in and all of the functions that work with is are just sitting around in the global namespace. They did the same things with arrays.

Strings are just arrays of characters, comparable to like in C, strings are just pointers to null-terminated character arrays.

Code:

alias immutable(char)[] string; // somewhere in object.d which is implicitly imported to every D module

It is safe to say that strings are no more built in than in C. They just feel built-in because built-in arrays with length are a more useful concept than built-in pointers to first element. (which you could do in D too) What is built-in is Unicode support, so you get char, wchar and dchar, for utf-8, utf-16 and utf-32 codepoints respectively.

Quote:

The say that an array carries around no bounds information. This is true and a great reason to wrap it in a class that implements an array interface.

This is just wasting the array declaration syntax and imposing unnecessary inefficiency on the user.

Quote:

Then you can extend it at will and all of the functions you need are right there in that namespace.

Actually you cannot, because at some point people will start to agree on a standard way to do things, your string class will find its way into the standard library, compilers will start to treat it specially, which in fact will turn it into a built-in facility. In the end, what you get are built-in strings with non-optimal syntax because the language was not designed for them. Also, your built-in string literals will probably be of a different type than the standard string class everyone should actually be using. I cannot see how this would be better than the lightweight D solution.

To the namespace thing: There is no global namespace in D, only module namespace, and most operations on a strings are actually implemented in the library. The design for uniform function call syntax (you can use method call syntax for non-member functions on arrays) should probably be generalized to be less ad-hoc and to work with other data types as well. But so far it has worked quite well.

Btw, no standard library implements all useful string facilities. In D you can just extend them with custom functions and use the array.function syntax with them as well.

Quote:

I don't think that C++ needed to have new features. The syntax and symantics just needed to be cleaned up and re-worked.

And yet, the new C++11 standard adds quite a lot of useful features that already are in D to C++. D just implements most of them somewhat less kludgy, because it does not have to be backwards-compatible with all the C++ code out there.
And even with C++11, C++, language-wise, does still not hold a candle to D.

Quote:

I'm not saying that D sucks. In fact I love it. The language took a bold step forward with the beloved C/C++ style and did a lot of cleaning up. The only problem is I think it went a little overboard.

That is probably exactly the point, the problem is that you think it went a little overboard. ;)
In fact that is a common reaction from programmers coming from a C++ background. In C++ the argument "if it can be done in the library in some half-assed way, it does not have to be a language feature" has real value, because changing the C++ language is a pita, as it has so much legacy and a no-breaking-change policy. If you design everything from scratch in the way 'it should actually have been done', you have much more freedom to make things that should be language features, well, language features.

Quote:

The things that I like most about D is that it has build in standardized support for unit testing and documentation. Making it easy to ensure you codes works and a small update doesn't break anything, and makes it easy for other people to know what your code does (or you a year from now).

I have one more nit that I am going to pick before I shut up. I think using the old build system was a bit of a mistake. The reason why I started looking for a new programming language after loving C/C++ for a good number of years is that the #include's suck. They really do. You have to keep the header file and the source file and compile them correctly. If you write a library you need to ensure that people using it link their program with the proper libraries and la-deda-deda. I was looking something like an import style inclusion where everything is included once and the imported namespace is controlled. Unfortunately D doesn't do this how I would like. D sticks to old tools for compiling and linking. This means that imports aren't automatically compiled and linked as necessary. I would love to go compile app.d and have the whole application build and linked for me. In the new days of programming languages is think it would be good to have the build info built right into the file.

In my opinion, you are absolutely right. There is already some effort going in that direction, I think eventually compile app.d will just work. (edit: rdmd can already do it quite well.)

Quote:

So I was wondering what you guys thought about D and evolutions of C.

One of the design goals of D I do not fully agree with is that every piece of C code should either be valid D code with the same semantics or not compile.

Quote:

Another last thing. In the title I made a D- joke, I wasn't really intending to make a new language. I don't know squat about compiler writing or the like. But if someone/somepeople (preferably more that one person) share some views I would be prepared to put some time into helping this project happen. Just an offer :P

Well, if you'd end up writing that compiler in D, I'd be puzzled if you wouldn't find use for all D language features, as D's primary designer Walter Bright is a quite well-known compiler builder. ;)

My sense concerning language projects like "D" is that the driving opinion is that "C++ is too much (for me and my project). My engineering needs would be served by a simpler language that provided, e.g. automatic garbage-collection, without throwing in a lot of other stuff that I don't need or want."

If your software engineering needs are consistent with that, then "D" might be the cat's meow for you. If they're not, it's not a condemnation of the language itself.

Thanks for all of the insights. A lot of you mentioned the "built-in" string class. What I mean is best showed with a code example.

Code:

string str0 = "Hello World!";

char[] str1 = "This is a character array.";



str0.dup;    str1.dup;      // Some basic methods

str0.sort;    str1.sort;    // are built into the

str0.reverse; str1.reverse;  // base "string" class



import std.string;



rightJustify(str0, 10);      // Ones in the standard

insert(str0, 3, str1);      // library are global

format("%s %d", str0, 4);    // functions.

I am going to take a look at F# which rings a bell but I can't remember looking at it before.

Quote:

Originally Posted by youarefunny (Post 4451117)

Thanks for all of the insights. A lot of you mentioned the "built-in" string class. What I mean is best showed with a code example.

Code:

string str0 = "Hello World!";

char[] str1 = "This is a character array.";



str0.dup;    str1.dup;      // Some basic methods

str0.sort;    str1.sort;    // are built into the

str0.reverse; str1.reverse;  // base "string" class

There is no string 'class'. Strings are arrays of characters.
I think sort and reverse should not be built-in, but it does not normally hurt at all. (edit: apparently they will even eventually get deprecated)

Quote:

Code:

import std.string;



rightJustify(str0, 10);      // Ones in the standard

insert(str0, 3, str1);      // library are global

format("%s %d", str0, 4);    // functions.

That is not global. It is module scope.

edit: I did not look close enough into your code. It could be written as:

Code:

import std.string;



str0.rightJustify(10); 

str0.insert(3, str1);

"%s %d".format(str0, 4);

And that is basically when all arguments for a string class vanish. (I already wrote that in my first post. ;))

Quote:

I am going to take a look at F# which rings a bell but I can't remember looking at it before.

F# and D are unrelated, nobody who knows D would say that it is irrelevant because there is F#.

Quote:

Originally Posted by youarefunny (Post 4450715)

I know this is highly debatable subject but personally, I find Python Zen to be overly puritanical. I prefer the toolbox approach. Give me everything I may find useful and I'll decide what's appropriate for the given job. The "there can be only one [way]" approach, IMO, tends to lead to "If all you have is a hammer, everything looks like a nail".

Quote:

Originally Posted by youarefunny (Post 4450715)

But, as soon as you return [closures] from a function I think you want a class. Writing code like this is about writing something that can be evolved. A function that returns a function is just a class constructor with one method. Now try to add a second one. Oops.

I find this to fall into the "If all you have is a hammer..." category. Functors are PITA kludge. Why should I have to deal with the boilerplate of an entire class if all I want is to just return one simple function? That's my thinking on it anyway.

Quote:

Originally Posted by youarefunny (Post 4450715)

In D string is a built-in

No it isn't. 'string' is defined in the library (Inside the implicitly-included object.di) as:

alias immutable(char)[] string;

A D string is literally just an array of immutable characters. (Well, actually, a D 'char' is a UTF-8 code-unit, but the point is, a D string is literally just an array.)

Quote:

Originally Posted by youarefunny (Post 4450715)

all of the functions that work with [strings] are just sitting around in the global namespace.

No they're not. D doesn't have a global namespace. In D, *everything* is inside a named module, and the modules *are* namespaces. Look through D's module documentation. You'll see that all the problems with free-floating functions are avoided by the module system.

Quote:

Originally Posted by youarefunny (Post 4450715)

The say that an array carries around no bounds information.

This is COMPLETELY false. D arrays ALWAYS carry bounds information. D's array are essentially implemented like this (but the language provides some sugar and a few other extras):

Code:

struct Array(T)

{

    T* ptr;

    size_t length; // Number of T's (not bytes)

}

In fact, you can directly access both of those 'ptr' and 'length' members.

Quote:

Originally Posted by youarefunny (Post 4450715)

Then you can extend it at will and all of the functions you need are right there in that namespace.

Arrays are already extendable:

Code:

void foo(T)(T[] a, string blah)

{ ... }



void bar()

{

    int[] arr;

    arr.foo("hello");

}

Unfortunately, this only works for arrays at the moment. But the plan is to extend it to all types.

Quote:

Originally Posted by youarefunny (Post 4450715)

This means that imports aren't automatically compiled and linked as necessary. I would love to go compile app.d and have the whole application build and linked for me.

Once again, that's not true:

Code:

> rdmd --build-only -ofapp app.d

And if you really *need* it to just be one param for some reason, that's trivial enough:

Code:

@echo off

rdmd --build-only "-of%1" "%1.d"

Linux is obviously similar. And supporting additional params isn't hard either. But point is, yea, that already works.

Quote:

Originally Posted by youarefunny (Post 4451117)

Thanks for all of the insights. A lot of you mentioned the "built-in" string class. What I mean is best showed with a code example.

Code:

string str0 = "Hello World!";

char[] str1 = "This is a character array.";



str0.dup;    str1.dup;      // Some basic methods

str0.sort;    str1.sort;    // are built into the

str0.reverse; str1.reverse;  // base "string" class



import std.string;



rightJustify(str0, 10);      // Ones in the standard

insert(str0, 3, str1);      // library are global

format("%s %d", str0, 4);    // functions.

I am going to take a look at F# which rings a bell but I can't remember looking at it before.

You can do this, due to the "universal member call syntax" feature:

Code:

str0.rightJustify(10);

str0.insert(3, str1);

"%s %d".format(str0, 4);

I think that it's also worth noting that, now that CPUs and so-forth are just so dammed fast, nowadays ..., computer programming languages can often easily afford to be "sloppy." Or to put it another way, "sloppy," interpreted tools can be used.

Having said that, let me very quickly concede the fact that languages such as "C" or "D" are the ones that are used to build these other tools. Hence, they do retain and always will retain their vital place. However, having said that, the sheer firepower that can be made available at moderate cost ("throw silicon at it ...") makes those "sloppy" higher-level tools become very attractive indeed in situations where lower-level tools once would have been the most logical choice. Ruby, Perl, PHP, Python, even dot-NET, all exploit the fact that CPU-power is today not nearly so much "a resource that must be conserved like water in the desert." Given that "80% of the time is spent in 20% of the code," that "80% of the time" can be spent in highly-optimized, yet "wasteful," interpreter core-code.

The "C" language is primitive. (By design, I might add ... and it's also a middle-aged fortysomething ... which a-HEM! is not 'old' :tisk: at all!!) Therefore, there are always opportunities to improve upon it, and to that end, an incremental improvement strategy (such as the one "D" takes) is quite valuable. As others have said, well-seasoned designers who have produced excellent results in the past are working on it, and with good reason.

Quote:

Originally Posted by sundialsvcs (Post 4451085)

Actually, most opinions on the Internet are that D has more stuff than C++! It has better templates, still has classes, functions, scope guards, pointers, the list goes on. D takes away two major things - the "mutable" keyword and multiple inheritance, but then adds other stuff to still get the job done while enabling new things.

Quote:

I think that it's also worth noting that, now that CPUs and so-forth are just so dammed fast, nowadays ..., computer programming languages can often easily afford to be "sloppy." Or to put it another way, "sloppy," interpreted tools can be used.

The beauty of D is it gives you the best of both worlds. I find writing even dynamic web code in D to be both faster and easier than with Ruby, Perl, PHP, and Python. And the resulting code runs much faster too!

Quote:

Originally Posted by destructionator (Post 4451332)

More stuff, yes, but it should be pointed out that the "stuff" is much less convoluted in D than C++. So really it's "more" and "simpler" at the same time. Sounds contradictory, but it's not so unreasonable considering what a contrived mess C++ is. (At least IMO, speaking as a C++ refugee that's been granted asylum by D.)

Quote:

Originally Posted by tigehr (Post 4451052)

Btw, C++11 will have closures. I think it would be silly to have delegate literals/lambda functions but not closures.

Are you talking about C++0x, which was approved this year? Just last week I remember thinking, "you know, C++ would be a lot more useful with closures!" This is because I have a C++ data-encapsulation template library that would actually be appealing if it used closures. I don't think I'll hold my breath for a C++ compiler that supports closures, though; I'd rather learn a new language. In my opinion, having a standard that one must pay for causes C++ a lot of problems because C++ is available to everyone, yet its requirements are only available to those who are willing to pay. I'm not saying you have to be a software engineer to write quality C++, but I'd say the majority of C++ programmers don't know the difference between "standard" and "implementation" (an opinion partly derived from threads on this board and my own growth as a C++ programmer).

I looked over the conceptual background of D on its homepage and the creators acknowledge all of my main complaints about C and C++. They seem to have taken these issues into account with the design, rather than justifying their design after the fact. Whether or not their solutions are agreeable is another question; I have no experience with D. They do treat the developer like an actual adult with experience and the ability to make his/her own judgments, though.

One critical feature I noticed about D is the C ABI compatibility. That certainly beats inventing an IPC protocol or writing language bindings to access existing libraries (e.g. POSIX functions). One of the main problems I have with Java is it was designed to be too universal, without any concept of interacting with non-Java programs or libraries.

I don't think having a large number of features and/or functionality is inherently negative. There are certainly a lot of ways to make additional features a negative thing:

Cluttering or ambiguating syntax.
Forcing the developer to use a "feature" to perform a task they want to do some other way.
Bloating or slowing applications.
Requiring an unreasonably-large RTL or VM for even simple programs.
Performing tasks that the designers or creators aren't unambiguously experts in (i.e. if in general there are a lot of people that could do it better on their own, it shouldn't be a "feature").
Adding "neat" things or showy features.

I have yet to take a look at D in depth, but I doubt I'll find any of the above based on my research so far. What I've read so far doesn't strike me as marketing, propaganda, or frivolity.

Quote:

Originally Posted by youarefunny (Post 4450715)

I have one more nit that I am going to pick before I shut up. I think using the old build system was a bit of a mistake. The reason why I started looking for a new programming language after loving C/C++ for a good number of years is that the #include's suck. They really do. You have to keep the header file and the source file and compile them correctly. If you write a library you need to ensure that people using it link their program with the proper libraries and la-deda-deda. I was looking something like an import style inclusion where everything is included once and the imported namespace is controlled. Unfortunately D doesn't do this how I would like. D sticks to old tools for compiling and linking. This means that imports aren't automatically compiled and linked as necessary. I would love to go compile app.d and have the whole application build and linked for me. In the new days of programming languages is think it would be good to have the build info built right into the file.

I think it would be difficult to retain C ABI compatibility without using a build system similar to that used for C. For one, linking shouldn't be completely transparent if you expect to utilize C libraries, or if you expect to write a shared library in D (not sure if this is possible and/or simple).

Thanks for bringing this up! I looked into D several years ago, probably because of a thread on this board, and I didn't really care for it at the time. It looks like it's come a long way, though, and I'm not nearly as "loyal" to C++ as I was back then (I've probably become proficient in 3 new languages since then).
Kevin Barry

Quote:

Originally Posted by paulsm4 (Post 4450745)

But I'm guessing that D is more or less irrelevant now that we have F#.

Just out of curiosity, what's the connection you see between D and F#? F# is primarily functional and it's also an MS product.
Kevin Barry

Quote:

Originally Posted by Abscissa256 (Post 4451280)

Once again, that's not true:

Code:

> rdmd --build-only -ofapp app.d

And if you really *need* it to just be one param for some reason, that's trivial enough:

Code:

@echo off

rdmd --build-only "-of%1" "%1.d"

Linux is obviously similar. And supporting additional params isn't hard either. But point is, yea, that already works.

This doesn't work for me. I get linking issues.