Live data from Hacker News

The Case for D

ddj.com

31–40 of 48 posts

Re: The Case for D

#31

Earlier quoted context omitted.

Having read that blog post, I can completely and emphatically rule out using D at all for anything, unless and until I hear it's no longer a pitiable train-wreck (and I won't hold my breath).

Honestly, 99% of this doesn't matter if you're not concerned about the politics of the development of the language itself. If you code with D1, and pick a library... none of this matters. Your comment is akin to "After seeing the debacle with the C++0x committee, I will rule out C++ for anything until I hear it's no longer a train-wreck." Which might be legit. Just saying.

It's not akin to C++/C++0x at all. C++03 is standardized and the current mainstream compilers do a good job of implementing that standard; the tools are rock-solid. C++0x is coming along nicely, with support from the big industry players. Concepts were dropped, but the rest of the features are still a massive improvement over C++03 and I can't wait to use them.

On the other hand, reading that blog post about D has confirmed my worst suspicions about the instability of the language and the immaturity of the tool set.

Re: The Case for D

#32
post #31

Earlier quoted context omitted.

Honestly, 99% of this doesn't matter if you're not concerned about the politics of the development of the language itself. If you code with D1, and pick a library... none of this matters. Your comment is akin to "After seeing the debacle with the C++0x committee, I will rule out C++ for anything until I hear it's no longer a train-wreck." Which might be legit. Just saying.

It's not akin to C++/C++0x at all. C++03 is standardized and the current mainstream compilers do a good job of implementing that standard; the tools are rock-solid. C++0x is coming along nicely, with support from the big industry players. Concepts were dropped, but the rest of the features are still a massive improvement over C++03 and I can't wait to use them. On the other hand, reading that blog post about D has co…

There is an awful lot of problems with C++ though.

- The tool are certaintly not rock solid. Parsing requires arbitrary look-ahead and semantic pass, order of headers inclusion matters, #if and dirty tricks are everywhere

- compilation is slow

- non standard extensions makes painful portable C++ across compilers and platform, because you need them and they can have incompatible syntax

- C++ const is useless when it comes to optimization or concurrency.

- any real world project involving C++ is going to be challenging if you're not working with top C++ library implementers or emasculating rules (like "no exceptions" or "nothing goes in the constructor" at Google)

Anyway, even if C++1x was already here and completely supported (which C++03 is not), D would still have an edge.

Despite its current problems D greatly enhance productivity over C++. Refactoring is _way_ faster when you have import and no headers to maintain. Properties enhance expressivity a lot. You have access to the machine, value semantics, and reference returns, so there is nothing conceptually wrong with it.

Also, in D there is much less skill diffference between library writers and typical programmers as compared to C++.

Finally if you really want C++1x features, I sincerely advises to try D because there is a lot of overlapping.

Re: The Case for D

#33
post #4

The question is, is D better enough than C++ to make us switch? When taking over you must not just be better, you must be a hell better to justify the cost of the switch.

I find it a lot better.

Re: The Case for D

#34

Earlier quoted context omitted.

I'm curious, why don't you want to do the switch to D2? Is it because it's not mature enough?

First of all, D2 is not mature at all. It's like asking "Is C++0x mature enough?" Secondly, lots of people won't ever switch to D2, even when it's done, because they feel that it adds a lot of feature bloat for very little gain.

I don't think many-cores compatibility is a little gain.

Re: The Case for D

#35
post #9

Earlier quoted context omitted.

D might not be better from the glance over it, but it's little things in it that REALLY add up. I strongly recommend anyone who ever wrote C++ code to give it a go for at least a couple of months and see for themselves. That is the best way to measure - I can only give you my sincere recommendation to try it out.

It looks great, I agree. I like the range approach for the standard library. I also like the end of the include nightmare. Is the output binary as good as a C++ one? That would be my first purely technical concern. Other concerns would be related to the building tool chain and the quality of IDEs. But the real concern is business oriented. For pet projects I'd be inclined to give a green light. It's always nice to pl…

Unsupported is a bit strong.

"For pet projects I'd be inclined to give a green light. It's always nice to play with new technologies as it opens your mind and give you new ideas."

I had no success in learning another languages now that I know D... be cautious :p

"For full fledged commercial products you expect to live several years, that's going to be a solid red light. I wouldn't take the risk of using an unsupported language."

I would have said that a year ago, but it becomes less true over time.

You are likely to encounter less bugs in D1 than one year ago. DMD is released frequently, usually fixing a lots of bugs you didn't even worried about.

All problems other than compiler bugs aren't really blocking. There is also bugs in C++ compilers.

Re: The Case for D

#36

Earlier quoted context omitted.

I'm curious, why don't you want to do the switch to D2? Is it because it's not mature enough?

There are several reasons. I'll try to list them, but it might not be complete: - D2 looks and feels foreign to me as a somewhat D1 experienced user - Templates maelstrom and strong emphasis on them - D1 grew organically, D2 looks like an academic exercise where stuff is put in just for the sake of it by the people that don't write programs in D at all (Andrei) - D2 book and Andrei are a filibuster for D2 - Walter Br…

Maybe you could have a read at Modern C++ Design by Andrei. A mind expanding book with incredible insight in meta-programming.

All this "template maelstrom" makes sense and is unavoidable to have powerful and expressive statically-typed languages.

Re: The Case for D

#37
post #24

Earlier quoted context omitted.

There are several reasons. I'll try to list them, but it might not be complete: - D2 looks and feels foreign to me as a somewhat D1 experienced user - Templates maelstrom and strong emphasis on them - D1 grew organically, D2 looks like an academic exercise where stuff is put in just for the sake of it by the people that don't write programs in D at all (Andrei) - D2 book and Andrei are a filibuster for D2 - Walter Br…

>> ...the people that don't write programs in D at all (Andrei) >> Walter Bright listens to Andrei (ok, a smart guy) but he doesn't write D programs You stated twice that he doesn't write D programs. Well since you are mentioning Tango, it's unfair because he writes code for a _standard_library_. And he is writing a good code.

Walter rewrited his game Empire in D.

Re: The Case for D

#38
Okay, I'm totally going to bite on the "find something you don't like in 30 seconds" and it's the hello world example.

void main() { writeln("about to do something important"); doSomethingImportant(); }

is this really not going to run doSomethingImportant() if the writeln fails? I find that to be a poor default for a systems language.

This may just be a personal preference, but I strongly want a systems language to do one of 2 things:

1) Require me to explicitly state when I care about an operation failing 2) At compile time ensure that my code explicitly states when it's not going to handle an exception. (Java with this, like so many things, gets it 90% right and then falls on its face)

Silently passing exceptions out to the system is a bad default for something that is supposed to be able to be used to build the system!

Note that this preference does not apply for a large swath of applications programming. For a webapp, it may be reasonable to log any uncaught error conditions to a log file, since we can just signal the client to try again.

Re: The Case for D

#39
post #34

Earlier quoted context omitted.

First of all, D2 is not mature at all. It's like asking "Is C++0x mature enough?" Secondly, lots of people won't ever switch to D2, even when it's done, because they feel that it adds a lot of feature bloat for very little gain.

I don't think many-cores compatibility is a little gain.

That's a compiler issue, not a language issue.

Re: The Case for D

#40

Earlier quoted context omitted.

Yes. This is actually is one of the main points of contention... that the dmd frontend is 'source available.' The community is doing some things to address this, but that's all I'll say. LDC is a really great project. It's not being abandoned anytime soon, trust me. Those guys are working hard, and they answer bug reports really, really fast. Though I'm admittedly slightly biased, since they use my kernel as a test c…

The dmd front end is GPL'd.

Thanks for the correction, Walter. As Wikipedia says:

The Digital Mars D compiler is the official D compiler by Walter Bright. The compiler front-end is licensed under both the Artistic License and the GNU GPL; the source code for the front-end is distributed along with the compiler binaries. The compiler back-end source code is available but not under an open source license.

Post reply on HN