Monday, June 1, 2015

The D programming language, "dlang" - Part 1

I've started a new project recently, related to a product I want to develop. It's a software-only product, but it's electronics related. I thought it would be fun to chronicle the development and design progress.

I'm working on a tool that I don't think really exists yet, at least in the way I envision it. As usual, I'm going to be coy about specifics until I'm ready to announce it.

I've mentioned in the past that I'm a programming language geek. I still feel that C# is one of the overall best, most productive programming languages out there, and it continues to get better with each new edition of the language. Now that Microsoft has let Linux and OSX join the .Net family (even if they are still somewhat still the red headed step kids, which I feel will change in the not too distant future), I'm hopeful that developing desktop code on .Net will become a reality.

I have had it on my list forever to give the "D" programming language a go, and this project presented itself as a good opportunity to try it out. D is a non-main stream programing language that has been around since 2001. Despite it's fantastic design and feature set, it's adoption has been slow and steady.

To make a long story short, I had it as a goal to use D to develop my new software. I admit that a small part was driven by the desire for something new and shiney, but I have spent a decent amount of time researching that language. I think that D has some of the right set of features for large and medium sized application architectures. D has a bag of features at your disposal that very few languages have and have done right so that you can pragmatically "get stuff done".  Scala is another contender in this area, though in my experience Scala veers a little too much into academic theory and a little shy on the pragmatism end of things (for example loop flow control keywords were omitted because the language designers felt they encouraged imperative programming style.). At the same time, Scala, being a language that targets the Java virtual machine, is encumbered with some of that platform's limitations.

In the end, I decided to stick with C#, but not without a heavy heart and solemn face. I still have D in my heart, and will take another shot at it in the near future, it just wasn't the right fit in this case. The primary reasons for ultimately goign back to C# were the Framework support, especially GUI support.

Note that I'm be no means a D language expert. I've never authored any sizeable application in it. I'm still learning it. I'm bound to make a mistake or two here, please call me out if you spot something!

Comparison to C#

I have always found C# to be one of the most productive programming languages for getting things done. It is quite a well designed language. It has its warts and missing features as does every programming language, but it has enough of what matters to let the architect and API designer and application developer express their designs with few limitations. I'm a big a fan of statically typed languages for anything beyond simple scripting, it's why I'm so intrigued by Typescript and Dart for browser based applications. I plan for this series to be written to the existing seasoned C# developer, since that what I am, and give my overview of the D language

For the sake of brevity, I'll start off with the non exhaustive list of C# features that are missing from D (though some may appear in the future). So I'll get the "cons" out of the way first, then move on to all the ways that the D language is fantastic.


D is closer to C/C++ in that it compiles directly to machine code, and doesn't have it's execution "managed" like C# and Java. While almost every programming language has a "logical" virtual machine, even C makes certain guarantees about code behavior across platforms, it still compiles down to directly executable machine instructions. D works the same way, though its standard runtime is a little richer in services it provides than C++, it it nothing like the .Net CLR.


LINQ is one of my favorite features of the C# language. It just makes filtering, searching, transforming, ordering, grouping and projecting sets of data painless and concise. You can get almost LINQ with some third party libraries for D, but it's not quite what you can do in C#.


This is a big one. D has an RTTI system a bit more capable that C++, but nowhere near as sophisticated and featured as the full Type engine in .Net. There is some support for class and method information, but much of it is limited to comple time expressions. D has a user attribute capability, but without full reflection, it's usefulness is far below what you can do in C#.

Reflection in some cases is like a "safety valve" when you get boxed in by come API or third party code, you can always use reflection to "cheat" and access the internals of a framework. This is not typically something you target in your design, but it's a dirty hack you have to do from time to time, then you take a shower to wash off that dirty feeling.

In addition to the safety valve, reflection helps with introspection, extensibility and plug-in systems.

UI frameworks

I'm trying to focus on language features more than standard library comparisons, but this one is a big one for application development. An to some degree, the .Net UI frameworks have had a big influence on the language design. (see "partial classes")

In .Net you get Windows.Forms and WPF, two complete, mature and polished UI frameworks with a gazillion tools and UI editors to help you create simple or very complex UI's. The standard D library contains no support for UIs. There are numerous third part UI frameworks and I have evaluated or researched many of them. They all have numerous problems and are the reason I opted to stick with .Net for now. My goal was to have a cross platform U application, which eliminates 80% of D's UI frameworks. I spent a lot of time experimenting with well done gtkd library, the Gtk wrapper, but the problem is that under the hood, it's GTK, which is a very frustrating UI platform with work with. (woe be unto the fool who doesn't have the exact same version installed, breaking changes abound). Some of the other UI frameworks were either abandoned, or promising, but too new to place a lot of faith in.


This is a minor point since, events are really not much more that syntactic sugar for delegate (closure) registration aggregation. You could role your own without too much work in D, but having Events as first class language features would be nice.


D organizes code into Modules, which are just source code files. "Packages" are files grouped into directories. It is "sort of" like namespaces, but not quite. My best non-eloquent way of summarizing would be that they are somewhere between #includes and C# namespaces, though they differ greatly from both. 

Partial Classes.

This is another minor point. Partial classes and functions are great for interfacing auto-generated code with manually authored code. You don't need them so much in D, because you have mixin's which can achieve some of what partial classes do.

Expression trees and run-time code generation

I have on occasion had code that built logic based on data, and created a library dynamically, in memory, and executed that code. This is almost trivial in the .Net world.

This post has grown long, and so I think this is a great stopping point. In fact, I already have 90% of the next post authored, since I culled it from this one. Stay tuned for a discussion of D generic programming mechanics.


1 comment:

  1. This comment has been removed by a blog administrator.


I welcome you're thoughts. Keep it classy, think of the children.