The D programming language... is it worth taking my time off my current projects to learn?
I've actually found one independenet game programmer who uses D -- source code included with this halfpipe shooter called Torus Trooper is written entirely in D.
But will this language ever really take off enough to warrant learning it? There aren't even any books on it, and that may be a bit of a handicap in really getting mentally "into" it.
Name:
Anonymous2006-10-14 22:11
So you're stupid, you don't know anything at all about scientific programming you don't know how to read a graph or understand benchmarks? You assume shorter is always better (a stupid assumption). You make stupid arguments that 2 tools come up with similar solutions therefore one has to be poorly optimized?
You ignore the fact that D can not match C at all. You rely on a relatively shitty benchmark to argue any of this. You ignore the tool adoption points yet have the gall to ask stupid questions?
You have failed.
Name:
Anonymous2006-10-14 22:25
You ignore the fact that D can not match C at all.
I thought this was D versus C++, but okay, let's talk C. How can D not match C at all?
You rely on a relatively shitty benchmark to argue any of this.
Okay, so tell me upon what basis you claim D's implementations are poor performers then?
You ignore the tool adoption points yet have the gall to ask stupid questions?
Ah...! This is a valid point, my dear troll, but you raised the issue of speed (see >>30). And of course, any library with C headers can be used by D, and any debugger that or tool that can interface with GCC and its metadata can also do the same with D, so... what?
Name:
Anonymous2006-10-15 1:33
both of you are idiots, language doesn't matter, it takes about half an hour to learn a new language if you have any kind of skill. one may be superior, but who cares
Name:
Anonymous2006-10-15 2:08
Half an hour? You must be a very fast reader. Most specs take longer than that to read (unless it's Scheme or Forth).
I have personal benchmarks on real life problems I had.
Considering what your apparent ignorance of the language, I have my doubts. But okay, if you say so.
Just because you suck doesn't mean everyone eles does.
Or maybe I'm realist, not a teenage braggart.
Later.
Name:
Anonymous2006-10-15 9:41
| Considering what your apparent ignorance of the language
How can you judge someone's ability in writing in D or C++ without having seen some of his code? moron.
Name:
Anonymous2006-10-15 9:44
>>48
Engineers have NDA you know? Of course not, you're flipping burgers instead. Keep up the good work though.
So D does have significant performance issues? That's one of the reasons I'm also wary of C#. C# does have nice features, but is not practical for anything other than prototyping or small/medium-small applications (nor was it intended to compete with the performance of C/C++).
How exactly does D have problems with recursion? I'm not exactly an expert on writing compilers but I'm pretty sure recursion has been one of the more trivial and easy things for language designers within these last 3 decades...
Name:
Anonymous2006-10-15 16:32
OP you truly are an idiot. "Not practical for prototyping". Oh come off of it. Practicality for large systems is based on the programmers hardly the language and tools they use. Your knowledge of enterprise computing is obviously really limited if you think CPU bound processes are the big issue.
Name:
Anonymous2006-10-15 18:47
>>54
Last I checked, C# is similar to Java in that the programmer can't decide when memory is freed with explicit new/delete statements, instead relying on an automatic garbage collector to decide the right time -- and often it may be wrong and doing allocs/deallocs at the most time-critical moments. That shit can get very clunky against your will in certain situations no matter how efficient your algorithms are.
I admit I know less about C# than C/C++/Java and even Common LISP. If there's a way to put a tighter leash on the garbage collector to behave as I want it to, I'm all ears.
Name:
Anonymous2006-10-16 0:12
You're talking about enterprise computing and are whining about GC being slow? Have you ever heard of programmers? They are people who work on code. It turns out the most complexity involved in coding the higher chance there is for bugs.
Why are you talking about ENTERPRISE COMPUTING and CPU BOUND PERFORMANCE...
What is with /prog/ you have no fucking clue about context or even real world systems.
I imagine if you want to program the software for the Starship Enterprise it's going to have to be fast enough to make split-second decision calculations for certain situations, but that's just me.
Ever heard of reference counting? I'm sure you have since you claim to know C++ ... modern garbage collection system don't "stop the world" to do garbage collection, they can run in parallel with the rest of program and do generational collection, this is no slower than doing reference counting in a C++ program.
Name:
Anonymous2006-10-16 5:10
>>58
Signed. Signed. Signed. Signed. Signed. Signed. This man knows what he's talking about.
Besides, even if you're stuck with the most primitive type of stop-the-world conservative GC, it's still possible to get controllable performance. How? Simple: only run the GC collection if you: a) allocate to the heap, and b) you're running low on memory, and c) you haven't disabled the GC. Incidentally, D does it like this, which is why it can still perform so well despite a conservative GC.
If you have any experience at all at writing performance code, you are not going to be allocating memory in a performance-critical section. Everyone and their dog knows just how bloody slow malloc is, and so the same rule applies to GC.
Of course, if one wants to rice up an application (and I hope there's a good reason for it other than WOW CFLAGS FAST OMG OPTIMIZED), it's better to have a big buffer pool and take memory from it.
Name:
Anonymous2006-10-16 8:47
>>53
Okay, two things:
a) The one problem the implementations of D definitely do not have is performance.
b) Focusing on performance is going to get you in trouble.
Honestly, if performance is your main concern, and you're coming from a Common Lisp background, you might be better off learning Ocaml. Good performance, more support than D, and more powerful than C++.
That's not to denigate D. I think it's a very promising system language, but it's only for hobbyists at the moment.
Name:
Anonymous2006-10-16 13:29
>>61
Honestly, if he's coming from a Common Lisp background and is concerned with performance, he should learn about (declare (optimize (speed 5) (safety 1))) and explicit fixnum etc. type decls. Though buggered if I can remember the correct syntax.
Name:
Anonymous2006-10-16 19:18
>>57's comment deserved to be appreciated. "Enterprise computing" brilliant. 5 stars.
Name:
Anonymous2006-10-19 14:20
D < Java < C# < C++
Name:
Anonymous2006-10-19 14:29
You guys have to learn that d and c suck and P is teh best
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
P IS THE BESTZORZ
D will never be popular because who the fuck wants a language that is almost as ugly and bloated as c++ and has broken OO (no uniform access principle. c++ at least adheres to it by convention), no community, no documentation etc.
It's like c++ without the reasons to use it despite how bad it is.
D is not a good language that is undeservedly unpopular like lisp, smalltalk, scala, eiffel, haskell etc.
D is a horrible kludge of a language like c++ and java that just happens to (fortunately) also not be used by anyone.
>>23
D does support lamdas. Very soon I believe there will be a new syntax allowed that allows them to be even more concise, something like "a -> a + 2".
Bringing /prog/ back to its people
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy