D Programming Language.

[Kornman00]

I feel like I may be talking to an empty town hall here but has anyone here ever played with the D language? I was checking out Digital Mars' website, seeing what set it apart from other languages and it looks kind of neat. Some of the properties and constructs of the language I frown upon but overall, it looks like a decent (heh) language. So: thoughts, comments?

[TheGhost]

What's the point I just write machine code in binary.

Srsly tho never really heard about it until just now. Looked at the Wikipedia page but that doesn't help much. What is it good for?

[Cojafoji]

What is it good for?
Absolutely nothing!

[Kornman00]

This is what I was using when I was checking out the ups and downs of D: http://www.digitalmars.com/d/2.0/comparison.html

Compile-time constructs

One of the things that really caught my eye were the compile-time constructs. I'm really big on code/data processing. Having compile-time constructs, to me at least, is the compiler's version of the shift-reduce pass which is done by some forms of parsers. The more rich and deterministic information I can feed the underlying compiler, the more it should be able to optimize the code/data in the resulting machine code. I'm really anal about how the compiler treats my fucking code sometimes (and even other's compiled code whom I may be...studying). There are things which are way obvious as to being determined at compile time.
Take for example a class's virtual table. If there is a static-allocation (meaning c_bigfoot_data data; instead of c_bigfoot_data* data) of a object, I've seen optimized MSVC++ compiler output not only initialize that virtual table reference in the static object definition but ALSO create a at-startup initializer procedure which again sets that virtual table reference in that explicit static object definition. It's doing twice the work and generating more executed code!
Even data which is explicitly marked constant and which is statically initialized in the code, is constructed with a initializer proc in C++ where as in C it would have just been compiled straight into the resulting object definition with no initializer proc (though C has decades more of compiler development under it's belt, not too mention simpler in terms of lexing).


Preprocessor

One thing which just made me frown was the lack of any support for doing textual inclusion of source. D is just like that of java or C# where it's all symbolic and you just declare import or using statements at the top of your source code. In C of course you use #include preprocessor statements. Well, D went the route of replacing the preprocessor pass with compiler based constructs. So no more C macros.

Some of you more stubborn users may so 'oh cool, no more macros'. Well, sometimes macros can help with compile-time data construction. IE a pre-compile task could resolve data in a database and output a macro'd include file (ie .h, or .inl for me) using definitions from said database.
Various code points code then do a #include on that file with different definitions of that macro so different objects and code can be automatically generated. It relieves a step from the programmer so they don't have to write tools which output language specific code which now also has to know about the code's implementation, where as the macros would have taken care of that hurdle.

Lets take for example the Campaign component in Open Sauce:


// from Game/Campaign.inl
DEFINE_CAMPAIGN_LEVEL(a10, "levels\\a10\\a10")
DEFINE_CAMPAIGN_LEVEL(a30, "levels\\a30\\a30")
DEFINE_CAMPAIGN_LEVEL(a50, "levels\\a50\\a50")
DEFINE_CAMPAIGN_LEVEL(b30, "levels\\b30\\b30")
DEFINE_CAMPAIGN_LEVEL(b40, "levels\\b40\\b40")
DEFINE_CAMPAIGN_LEVEL(c10, "levels\\c10\\c10")
DEFINE_CAMPAIGN_LEVEL(c20, "levels\\c20\\c20")
DEFINE_CAMPAIGN_LEVEL(c40, "levels\\c40\\c40")
DEFINE_CAMPAIGN_LEVEL(d20, "levels\\d20\\d20")
DEFINE_CAMPAIGN_LEVEL(d40, "levels\\d40\\d40")
I'm able to define data from a single reference point at compile-time. Any change I ever have to do is done here. There are 3 code points which redefine DEFINE_CAMPAIGN_LEVEL to produce different data (enumeration members, scenario paths and scenario help text paths). With this I don't have to worry about initializing 3 different objects (actually, the enumeration member HAS to be compile-time in order to work) with data which can be inferred.

Macros are hacks, yes. But they're hacks on top of would-be nastier hacks. They can sweep code details under the imaginary source carpet which really doesn't matter to an end-user. Even still, as long as you have documentation any half way decent programmer should be able to tell what the fuck a macro is doing and work with it if they have to.


Their contract programming (http://www.digitalmars.com/ctg/contract.html) setup is a good idea. Microsoft has a research project in development right now which brings such things into the C# world but...it's beta.

The "static if" is something else I really like. All too often do I find myself wanting or needing something to perform it's functionality. Luckily there is the boost C++ library.

Supports inline assembly too.

List goes on, check out the link from the beginning of this rant post.

Overall, it provides some pretty cool new (to the underlying language, not in terms of researched) concepts and constructs into a C++ derived language which you can of course also find some in C#. Just with this you drop some of the .NET hassle and gain some of C++'s power. But like any language it has it's downfalls. And like any language, you use the one which can best do your solution forging for the problem you're trying to hammer.


If I had more time I would have included more code examples in my sub-rants to better illustrate what I was getting at so please excuse some of the more bare-bone explanations :(

[Rob Oplawar]

Yet another object-oriented programming language. I'm currently in the "if you've seen one you've seen them all" phase of programmer lifecycle, but I'm sure I'll grow out of it sooner or later.
Some of those concepts seem cool, others just go way over my head.

[Kalub]

Wut...

[Dwood]

Nah, I'm waiting for the E language.

[flibitijibibo]

E? Forget that, I'm waiting for Ab.

[Random]

Nah, I'm waiting for the E language.

Nah man they already have J

[dark navi]

I only code in C♭.

[Phopojijo]

Pffft... D is just ++C.

[legionaire45]

lolwat

My school is making me use Python for the first two courses and then we'll get to use Java. After that, I'm not sure what they'll make us do.

I understand that C# is like C++ but with even more focus on object oriented programming and some .net crap...is D similar in that it's C++ with more of a focus on object oriented stuff? Or am I completely wrong?

[Kornman00]

Well, that isn't explicitly what C# is about nor D. OOP isn't the only concept being developed into languages (I would call C++'s OO integration very immature as they're not pure. Even Java suffers from that fact). D is just another evolutionary (not: not calling D evolutionary) step in the way we use a language for computable expressions.

Take C++ for example, it didn't have exposable contract programming. With D, you can explicitly annotate in your code the pre and post conditions. Using a smart parser/compiler, automatic documentation could be generated from that information. I could have sworn there was a saying "code as documentation" but no quick google results return anything. Basically having the documentation be the code so you're only maintaining a single point in your code instead of both the code and the associated comment blocks.
Even better, you could implement a pass in the compiler that actually performs these pre/post condition checks at compile time, performing some rich code verification. One .NET tech in development is bringing these kinds of solutions to light which I'm really excited about: http://research.microsoft.com/en-us/projects/contracts/

There are more concepts (ie, concurrent programming) which aren't native to many languages in modern day but are in both previous and new emerging languages. Languages will continue to evolve in this manner. However, I don't think we'll ever really discover the perfect language to drive machines. I think the future of exposed* software/hardware engineering doesn't even rest in written language like today's code but in other expressions. Maybe one day we'll even be able to translate our thoughts into mechanized interpretations. In order to get there though we'll have to continue to use and develop today's existing forms of code language as we've always done.

* When I say exposed, I mean the interface in how engineers create new solutions. When it all started out, we used punch cards. Then we had machine code (binary/hexadecimal). Then assembly (textual form of machine code). Then we have things like C and Lisp (evolutions in textual interfaces to machine code). I could go on but I think you get the picture.

[Phopojijo]

I, likewise, don't think we'll find the "perfect language" to drive machines...

There are many different types of machines with different amounts of instructions -- zero, one (which is Turing-complete by the way), limited highly-optimized, many-instruction... also non-generalized hardware too.

There are also many different applications... system on a chip for cellphones... supercomputers... desktop PCs...

But most importantly -- it also depends on what you're doing.

The more control you want, the more you'll need to control... you can't have your language make everything autopilot for you and yet still control the nitty gritties.

I mean you can make it as easily as possible... like the visual editor for MASM assembly... but you all know what I mean.