The Case for D • Hacker News Board

Re: The Case for D

#21

Post by sketerpot » Fri, Oct 30, 2009, 6:26 PM UTC

martincmartin wrote: post #7

stevejohnson wrote: post #2

D is well-designed and has many wonderful features, but its documentation is so bad as to make it unusable for serious work. This article is the best reference work on D2 that I have yet seen, which should not be the case. Also, this guy has been working on the book for over two years now. Even when it's done, it's going to be just like Grails is now: you can read the online docs, but you don't really get it until yo…

> you can read the online docs, but you don't really get it until you read a certain book. Isn't that expected and normal for anything that involves thinking about things a different way? D has language features that most programmers aren't familiar with, so to use the effectively involves a shift of thinking. Same with Grails.

I learned Python by reading the official tutorial and hacking away until it made sense. I did the same for O'Caml, and later for Haskell (although that one took longer). Isn't that normal?

Re: The Case for D

#22

Post by stevejohnson » Fri, Oct 30, 2009, 6:42 PM UTC

martincmartin wrote: post #7

stevejohnson wrote: post #2

D is well-designed and has many wonderful features, but its documentation is so bad as to make it unusable for serious work. This article is the best reference work on D2 that I have yet seen, which should not be the case. Also, this guy has been working on the book for over two years now. Even when it's done, it's going to be just like Grails is now: you can read the online docs, but you don't really get it until yo…

> you can read the online docs, but you don't really get it until you read a certain book. Isn't that expected and normal for anything that involves thinking about things a different way? D has language features that most programmers aren't familiar with, so to use the effectively involves a shift of thinking. Same with Grails.

It's not that books are bad, it's that there is only one book. If it's not in The Book, you essentially can't find it anywhere, unless your mailing list spelunking skills are particularly good.

Re: The Case for D

#23

Post by eldar » Sat, Oct 31, 2009, 8:29 AM UTC

Keyframe wrote: post #20

shin_lao wrote: post #17

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…

I wouldn't be that confident. D1 is a dead-end. If you ask a C++ user, he wouldn't drop C++ and a damn lots of libraries, IDE's, debuggers and industry support for it. I recently talked to my C++ friend writing scientific multithreaded stuff, and he was only convinced by D2.

Templates are the killer feature of D. There is nothing wrong in the emphasis on them.

Yes I agree that there are problems in D2. But there are much more problems in D1.

If I were you, I wouldn't do such an anti-advertisement campaign here. Instead you could have pointed at what you think are the problems with D2. That would be more constructive.

Re: The Case for D

#24

Post by eldar » Sat, Oct 31, 2009, 8:41 AM UTC

Keyframe wrote: post #20

shin_lao wrote: post #17

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…

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

Re: The Case for D

#25

Post by WalterBright » Sat, Oct 31, 2009, 9:14 AM UTC

steveklabnik wrote: post #16

Nelson69 wrote: post #14

Earlier quoted context omitted.

A top quality, supported, opensource compiler would help. The LLVM front-end looks promising but I half expect it to be abandoned. It's kind of odd, it definitely seems like there is a desire for a compiled machine code producing language to compete with C and C++. I kind of remember this argument with Ada over the years, particularly when the GNAT front-end to GCC was mainlined. Having tools available is a big notic…

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.

Re: The Case for D

#26

Post by WalterBright » Sat, Oct 31, 2009, 9:15 AM UTC

sketerpot wrote: post #21

martincmartin wrote: post #7

Earlier quoted context omitted.

> you can read the online docs, but you don't really get it until you read a certain book. Isn't that expected and normal for anything that involves thinking about things a different way? D has language features that most programmers aren't familiar with, so to use the effectively involves a shift of thinking. Same with Grails.

I learned Python by reading the official tutorial and hacking away until it made sense. I did the same for O'Caml, and later for Haskell (although that one took longer). Isn't that normal?

I tend to learn languages by writing compilers for them. I'm sure that isn't normal .

Re: The Case for D

#27

Post by WalterBright » Sat, Oct 31, 2009, 9:16 AM UTC

shin_lao wrote: post #13

Keyframe wrote: 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…

D started 10 years ago. It's not a flash in the pan.

Re: The Case for D

#28

Post by pornel » Sat, Oct 31, 2009, 10:14 AM UTC

I've tried several times to write a project in it, and every time I found some horrible bug, something missing, broken (OSX support is poor) or libraries turned out to be useless/outdated (dsource is a graveyard), or that I've chosen the wrong set (D1 vs D2, Phobos vs Tango).

I'd really like to use D, it's the non-sucky C++ I've been waiting for, but it's just far from being usable and reliable yet.

Re: The Case for D

#29

Post by baxissimo » Sat, Oct 31, 2009, 10:22 AM UTC

eldar wrote: post #24

Keyframe wrote: post #20

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.

I also don't think it's true. In addition to writing code for the std.* Phobos library, I think Andrei has been using D for data processing stuff related to his recently finished dissertation. He would make comments from time to time about this or that not performing well enough in std.*, and then go fix it.

Re: The Case for D

#30

Post by aerique » Sat, Oct 31, 2009, 10:35 AM UTC

Keyframe wrote: post #15

shin_lao wrote: post #13

Earlier quoted context omitted.

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…

"I like the range approach for the standard library" This is D2 - I don't use D2 and wouldn't use it. I was talking about D1/Tango combination. I don't think I'll make a switch to D2. "Is the output binary as good as a C++ one? That would be my first purely technical concern." That depends on the compiler/linker, of course. In short - dmd good enough, ldc great (llvm as the backend after all). "Other concerns would b…

Same applies for other emerging or obscure technologies as well (I'm looking at you Lisp).

This is so generic a remark as to be worthless. You do know Lisp signifies a family of languages, right? Of which most or neither emerging nor obscure.