File size

File size

File size

File size

File size

834.6 MB

The D Programming Language combines modeling power, modern convenience, and native efficiency into one powerful language. D embodies many new ideas in programming languages along with traditional proven techniques.

@Walter: You said that D is not going to succeed ;). While I am not using D, I already read Andrejs book about it and found it fascinating. So here are my reasons why I am not using D and maybe you can concentrate the community to fix it:

1) Good Visual Studio support. The VisualD plugin is not really what I mean, it is better than nothing but ^^... What one needs is basic IntelliSense, that is real and good code completion (I mean Clang has such stuff in the compiler) and basic refactoring (renaming is of utmost importance, I could live without the rest for a while). Well language should feel like other Visual Studio citizens.

2) Debugging. I know I can set some breakpoints and inspect variables but it all feels weird. I can't specifically say why. Just compare it with the way you debug C# or C++ apps in Visual Studio and you will know.

3) And probably the biggest issue. No C++ support. You said one would need a C++ compiler in D compiler. That is true, but you also said that this alone would require 10 men years of work and this is false. Just use ClangLib! For D to live on, it must support existing C++ codebases and this would also really set it ahead of anything there is. You could limit some advanced C++ features like some template vodoo to be used in D. So you could restrict the interface to something that is D compatible and maybe extend D at some corner cases where necessary.

No really, C++ backward compatibility would make D rather to an evolution of C++ and this is more or less what it is. D is how C++ should have been. But as we already discovered, if C++ would have been C backward compatible, the it would not have succeeded. And the same will happen to D. Butcher he langauge a bit and make it at least "almost" backwardcompatible to C++ APIs, not C++, only the APIs...

I would love to program with D, but for now it is just not possible, at least not in a commercial productive way.

PS: A little addition that just pops into my mind. I am not aware of the connection to Digital Mars, but one thing that might bother some developers is the closed back-end. Why not put the entire compiler under a free license, preferably the same a Clang and LLVM?! I mean what good is a proprietary license for when the language does not succeed...

@Luna: There are three implementations if D compiler. Two of them are pretty stable. One is the GDC project which adds D support to the GCC, second is the LDC project, which builds a D compiler on top of LLVM. There are few others, most notably the SDC project, which is a D compiler based on LLVM written in D itself.

About your previous post related to "requirements for success"... 1) Support for VisualStudio is obviously important to you, but to other people who write server-software that is most likely going to work on Linux (there is no need to debate that anymore - Linux is de-facto the winner here), we actually need a good toolchain for Linux and BSD. Sure for Windows developers VisualStudio support is important, others could care less (including myself).2) I agree that better debugging is important. GDB support is pretty fine.3) D should not offer 100% C++ support. I think that with coming support for C++ namespaces D is pretty fine. If developer needs more - write a wrapper. On top of all said, all C++ library authors typically provide C interface along their libraries (if they want them to be used by wider community).

What stops me from D is three stuff:1. Good IDE. Faster than writing on C# in VS I never ever written! Good intellisense and debugging is a must have.2. Lack of DBMS support. It must be fully functional, actively developed library with at least MS SQL, Oracle and MySQL support. Of course in most achievable generic way.3. Same for GUI. I'm tired of ugly boxes names "Super controls for D", it's a cr@p. Neither DFL, nor DWT, GTkD and other wrappers can be used as a rich interface. Library must be flexible in terms of constructing new controls, flexible in using different data sources, easy to use and capable to change layout in runtime. Now D has nothing even close to it. And of course lib must be written in D, using all his power.

Anyway, I study D and will do as much as possible to push D in public.

@Vincent: Did you try Mono-D ? I switched from Code::Blocks to Mono-D recently.2) There are wrappers for almost every modern RDBMS drivers. However I agree that a higher level API similar to, say, JDBC would be great.3) I agree with the last statement here - a proper GUI toolkit for D must be done in D, using it's excellent support for concurrency, take advantage of TLS, D's delegates, use std.json and store layout and widget info in JSON format, the same way Clutter project does...

@Dejan: >There are three implementations if D compiler. Two of them are pretty stable.

Ok I didn't look at all the others. But the front-end of the official compiler also contains some high priority bugs, showstoppers, like the inability of handling "ref" arguments to lambdas. Changes are not propagated, which renders the whole idea of lambdas pretty much useless for anything but pure functional ones... I just mean we shouldn't start to spawn a whole pile of compilers all having bugs and lacking feature in different areas (which is a common pattern in the OpenSource world) but instead one really good compiler should be written (like Clang). And I blame the original compiler, because it was not entirely OpenSource. Otherwise there would not have been the need of reinventing the wheel...

> About your previous post related to "requirements for success"... > 1) Support for VisualStudio is obviously important to you, but to

Well, I think you are missing the point. When looking at recent charts of OS distribution, Linux is not even a rounding error anymore, at least on Desktops. How it looks on servers is a different matter but then I highly doubt that any sane person would dare to use D in (productive) server segment, as long as it is not proven to work correctly in the Desktop segment (and it has still a lot of bugs!). Anyway, the priority should not be to support a small fraction of developers first. Reaching the masses is much more effective and you do that by supporting Visual Studio... And a Visual Studio plugin for 2010 and above is not that hard to write if the compiler supports code-completion and reflection already.

> 2) I agree that better debugging is important. GDB support is pretty fine.

Well for some people it might be. The state-of-the art is way beyond GDB and when you chose a new language you don't want to take a step backwards.

> 3) D should not offer 100% C++ support.

Well I said not 100%. But pretty much anything that is vital for most APIs to work...

> If developer needs more - write a wrapper.

This attitude won't work out. And in general reality works quite differently. D wants to get into a segment between C++ and say C#. This is a tough competition! There is simply no room for such a "do it yourself" attitude. D MUST reuse what we already have to even stand a slightest chance of becoming mainstream. I would recommend to support a major part of the C++ APIs, which should be possible, and maybe even some automatic wrapper generation to interact with existing .NET code. Thanks to D's garbage collector this might work out quite well...

@Luna, none of your priorities are mine. They seem to be only Windows development related. Personnally, I don't care about windows development, I care about server side development. My own priorities are closer to what Vincent wrote in points 2 and 3. Of course, having a good IDE would be nice, but I can do without. What's important to me is not so much writing code quickly than writing code that's not full of bugs. Now, writing a GUI would be pretty nice, D has everything needed for that, and rather than trying to follow native intefaces, I'd suggest starting from scratch and doing something slick with OpenGL. D has everything to do that, it only demands work.

Folks, I know Lekic from long time ago - one of those "Linux is the only way, Windows and M$ suck". Everything he says, take with a grain (or, a mountain) of salt. Surprised to see him here in first place, given his attitude toward anything from MS throught last decade.

@Whoever: "none of your priorities are mine. They seem to be only Windows development related. Personnally, I don't care about windows development, I care about server side development."

This is one very reason why Linux will never enter the consumer market. This attitude is typical to almost any Linux guy I know. They just don't get it why Windows is useable and used by normal people and thus they will have no chance at all to create a Linux that is consumer friendly, actually there is nothing close but Mac OS, which is too locked-in in my opinion, meaning it feels like a fridge.

So back to topic, if you want a mainstream language, you need excellent mainstream tools for mainstream operating systems. There are two kinds of guys seriously developing productive software in editors:

1) Ingenious people (like Andrei for one) with a great memory, those are quite countable on our little earth ball2) The cool collage guy who thinks he looks smart by not using IDE but actually has no idea what he is doing at all.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.