This is part of a occasionally updated series on various programming languages. It should not be interpreted as a benchmark, but rather as a casual look at various programming languages and how they might be used by somebody for a practical purpose.
Currently, there are Articles written regarding Python,C#, Java and VB6 (merged for some reason),Scala,F# & Ruby,Perl, Delphi, PHP,C++,Haskell,D, VB.NET, QuickBASIC, and Rust
The D Programming language is designed as a extension of C and C++ into the domain of a higher-level programming language. It is not 100% Source compatible with C++ or C, in fact it’s very much not source compatible, but it provides the same system-level constructs and tinkering to the programmer while also, and in general, defaulting to- safety. Whereas Java takes the approach of, “If it’s not safe, it’s not worth it” and C# takes the approach of “Well, if you really are willing to jump through these hoops, it must be worth it” D takes the approach of, “You can do it, I just hope you know what you’re doing because there ain’t any training wheels”.
Working with D is actually quite easy, once you get the hang of it’s basic design strategy. Arguably, this is true of pretty much any Programming Language. The D Implementation of the anagrams program is one of the shortest thus far:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
import std.stdio, std.string,std.algorithm,std.stream,std.datetime; char[] sortstr(char[] src) { return src.dup.sort; } void main() { //declare the associative array... string[][string] anagrams; //Associative array of string arrays indexed by a string. std.stream.File f = new std.stream.File(); //Open the dictionary word file. f.open("D:\\dict.txt"); int wordcount=0; StopWatch sw; sw.start(); while(!f.eof()) { char[] gotline = f.readLine(); immutable(char)[] sorted = cast(string)sortstr(gotline); anagrams[sorted]~=cast(string)gotline; wordcount++; } f.close(); sw.stop(); writeln("wordcount:", wordcount); writeln("executiontime:",cast(Duration)(sw.peek())); } |
Well, it’s not as short as F#… and certainly not shorter than Ruby, but a lot of the conciseness we see here is thanks to conceptual shortcuts facilitated by the language design. Note the declaration of the anagrams associative array. in C#, we used this:
|
1 |
Dictionary<String, List<String>> anagrams = new Dictionary<string, List<string>>(); |
In D, we use this:
|
1 |
string[][string] anagrams; |
So the question is- what does this mean? well, D Associative arrays work rather simply:
|
1 |
Typename[keytype] |
Therefore in the above instance, we have the Type name of each value as string[], and the key type is itself another string. The result is that we have string array’s that are indexed by another string, which is the favoured approach I’ve been using for each anagrams implementation. Another shortcut we are able to take:
|
1 |
anagrams[sorted]~=cast(string)gotline; |
This is thanks to another interesting design standpoint of D, which adds a lot of first-class support for lists and enumerations. This includes operators, such as the tilde (~), which have the affect of concatenating items to the end of an array. In this case, we cast gotline to a string, and concatenate it to the anagrams array, storing the result in the same location. I’m not 100% on the performance implications of this usage, or how it could be done faster; but this was a trade-off IMO that favours readability. I could, arguably, find some faster way to do it, but this is one of the highlights of programming- you need to know when your software is fast enough. It makes sense to spend a few extra minutes making a program faster if you plan to use that software frequently, but otherwise you might get a better benefit out of making it more readable, which in and of itself can help future maintenance. It all depends on if you can justify the extra man hours invested into something as saving more man-hours down the road.
The implementation shown above averages around 7 seconds of execution time to complete; this is when compiling with the -O flag, which optimizes the output. Given how much slower that is than some of the other implementations, I have to admit I am a bit disappointed. I Did a bit of research and found that there is an Appender type in D’s std.algorithm library that I might be able to use to eke out a bit of speed; but the default array allocation is rather efficient as well, from what I’ve read; in this case however the problem is that the program is creating a lot of small arrays and only appending to them a few times, so the reallocation strategy doesn’t work as well.
Have something to say about this post? Comment!