Slashdot Mirror
Is D an Underrated Programming Language?
Nerval's Lobster writes: While some programming languages achieved early success only to fall by the wayside (e.g., Delphi), one language that has quietly gained popularity is D, which now ranks 35 in the most recent Tiobe Index. Inspired by C++, D is a general-purpose systems and applications language that's similar to C and C++ in its syntax; it supports procedural, object-oriented, metaprogramming, concurrent and functional programming. D's syntax is simpler and more readable than C++, mainly because D creator Walter Bright developed several C and C++ compilers and is familiar with the subtleties of both languages. D's advocates argue that the language is well thought-out, avoiding many of the complexities encountered with modern C++ programming. So shouldn't it be more popular?
The languages with the biggest gains this time around include JavaScript, PL/SQL, Perl, VB, and COBOL. (Yes, COBOL.) The biggest drops belonged to the six most popular languages: Objective-C, C, Java, C++, PHP, and C#.
So shouldn't it be more popular?
FTA:
"D offers compilers for all three platforms (Windows, Mac and Linux) as well as FreeBSD."
"There's a D package registry that currently lists over 400 third-party packages."
That pretty much sums it up.
/ All three platforms!
Jeezus fuck. Its bad enough that we get Dicevertisments, but Diceverticements with Campaign ID's on them?
Anyway this is the direct link to the D Language
I am Slashdot. Are you Slashdot as well?
C++ is essentially a mixture of languages at this point, with several ways to do many things. You can still write very C-like code using C data types, with the pitfalls of C (memory leaks, buffer overflows, etc). You can write more modern-style C++ programs using the container classes, iterators, and RAII techniques to avoid C's pitfalls. You can also end up with a program that's an ugly mash of C and C++.
C++ templates, which enable generic programming, are complicated enough to be their own sub-language, and errors that are output by the compiler about any of the templated container classes can be nigh-incomprehensible on their own, and take up a few dozen lines to describe an error like "You need a random-access iterator here, not just a forward iterator".
There are other examples, but essays can be (and have been) written about unnecessary complexity in C++.
It is pitch black. You are likely to be eaten by a grue.
It's actually in process of feature freeze for 1.0 release right now and it's usable enough for Mozilla to be developing their new layout engine in it, but do tell us more about all you've ascertained by looking at their website's front page.
Dude, don't use square brackets with STL arrays and vectors, just to make your code more readable. The [] operator skips bounds checking, which is the main reason for using these classes in the first place. At() is the proper methodology to use in pretty much every case, unless you are so confident in your bounds that its worth the trivial speed increase in access time.
This is usually just plain wrong. I have extremely seldom ever seen "at" used in production code. Why? Because it's usually duplicating a bounds check you've already done. If you're going to naively randomly access a location into a vector without checking if it's within bounds, sure, but that's kind of a nasty smell (also, are you handling the exception that may/will occur?). Most vector accesses occur something like looping from 0 until (but not including size), or using begin/end (either the free functions or the members). At best, the optimizer might be able to deduce you're never modifying the size of the vector during a loop and elide the repeated bounds check. At worst, you're evaluating "if ((_M_end - _M_start) <= i) throw std::out_of_range();" on every iteration.
Regarding point #4, forward declarations aren't to save compilation time or declare linkage. Yes, they can be used to do both, but the prime function is to, well, declare a name and just enough information to be somewhat useful before it is used (i.e. reduce very simple otherwise circular-references). I can forward-declare 'struct A', but I cannot instantiate/allocate it until it is defined (need to know the size, layout, etc.). You can declare a pointer to 'struct A', because well, you know the size of the pointer. Same reason you can't define "struct A { struct A a; };", but you can define "struct A {struct A* p_a; };".
Regarding "#ifdefs", yeah, there shouldn't really be a need for them in this day and age, but they won't go away due to legacy code. If you removed them, you'd break every single codebase in the world. Not going to happen. Additionally, due to the historical lack of variadic macros, there are numerous libraries that rely upon multiple inclusion of the same header to fake variadic macros. If you assumed a "#pragma once", you'd break various Boost libraries as well as even some STL implementations. Headers guarded with ifdef's can only safely be precompiled and reused if any and all preprocessor defines referenced are identical across all usages and inclusion order of every & all predecessor headers is exactly the same for all usages, otherwise you very well may violate the one-definition-rule.
I'm an undergrad Computer Science student, and last year I used D for my Compiler Design course in which I wrote just over 18000 lines of D code (including tests and documentation). My experience with the D programming language has meant that I'll probably never use it again for any serious work. The truth is D has some very deep-seated problems within the language, standard libraries, and even the community, which (IMHO) will prevent it from seeing widespread use before a version 3 sees the light of day. To elaborate a tad:
1. Walter and Andrei refuse to make any breaking changes, despite major players in the D ecosystem begging them too.
The language and libraries are riddled with inconsistencies, 'gotcha's', and general ugliness that require breaking changes to fix, and proposals or pull-requests relating to such things are almost categorically rejected on the basis of "lol breaking change". In one case, a well-known community contributor wrote an entire breaking patch to remove virtual dispatch by default (for performance reasons), posted it, got approval from the community, and finally got approval from Walter who merged it (despite it being a breaking change), only to have it all reversed the next day when Andrei found out about it because he "would never have agreed to it". Several medium to large companies that have actually adopted D have literally begged Walter and Andrei to break code and fix the language issues now before it's too late, to no avail. Some examples of such language issues include:
- A horrible mix of keywords and annotation syntax for function/method attributes ('const', 'pure', and 'nothrow' are all keywords, but '@property', and '@nogc' are annotations)
- Huge portions of the standard library are missing attributes like 'pure' and 'nothrow', which directly impacts user code that attempts to include them
- Simply too many attributes, with no attribute inference (template functions/methods infer attributes, but these cannot be virtual and so cannot be overridden in sub-classes)
- Many others - see this example: https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d
Some of these may seem nitpicky, but they give the language the overall feel of one that is incomplete, hacky, and inappropriate for industry use.
2. Can you turn the garbage collector off? Sure! But don't try and use the standard library if you do!
Most of the standard library is written assuming the garbage collector will clean up after it. Turning it off and using the library therefor means memory leaks ahoy, and leaving it on makes real-time solutions difficult due to the 'stop-the-world' nature of D's GC. There is an effort underway to remove this dependence on the GC, and a short term solution was implemented with the @nogc attribute. That is, yet another attribute, and yet another breaking change that will be rejected when the proposal pops up in a few years to remove the then unused attribute.
3. The documentation poor.
In many cases, the documentation is either out of date, or extremely lacking. At last check, there were still pages referencing deprecated features, or features that have yet to be properly implemented. In the cases that the documentation is correct, it usually lacks basic things such as usage examples and proper explanations of function overloads (and their parameters). To top it all off, the actual presentation of the documentation is incredibly poor when compared with something like Scaladoc.
4. Instead of fixing things, the developers keep tacking on new features, and patches don't get reviewed.
Walter and Andrei are focused on new features, and seem to leave much of the bug-fixing to the community. That's great, until the community proposes a breaking change and instantly gets shot down. On top of that, there are god-knows how many patches and pull-requests that have been awaiting review for *years* without having even been looked at. Such things result in low contributor moral, and have resulted in several community mem
You'll find that this can happen in the South. Where, wear, were, whir, will, and well can all have the same vowel sound, known as the Redneck Schwa.
This is not to be confused with the Redneck Dipthong, where single syllable words are stretched into two syllables by extending a single vowel into two unique sounds, such that where and wear become WAY-ur, or will and well become WEE-ul and WAY-ul, respectively.
When doing low level system programming, there aren't that many viable choices out there. C, C++, possibly ObjectiveC (not familiar enough with it to tell for sure). That's about it. Of those, ObjectiveC is, pretty much, a one platform language. C++ is used quite extensively, but it is way too complex, resulting in most C++ programmers not knowing what the 1@#$@!# they are doing. Also, some C++ features are not suitable for some low level scenarios. For example, you probably wouldn't want your kernel code to throw exceptions, or do iostream formatting, in kernel code.
C, on the other hand, is a very simple language. It has no expensive features (though, to be honest, that mostly means that if you need something expensive, you'll need to do it yourself). As such, it is without competition for what it offers. The most it loses in market/mind share is through scenarios that used to require low level system programming but no longer do.
As for D....
D advertises itself as supporting this mode. My employer chose to develop a low-level high performance low latency system in D. I've been programming it for the past half year. I'm not overjoyed. I don't hate D, but my personal opinion is that we'de have been better off going with C++ (though, to be honest, I love C++ like few of my peers do).
I have two main gripes with it on that front. D has a horrid GC (though no GC provides the latency requirements we need), and though it claims you can do without it, you really can't. At least, not without giving up on much of the language features and almost all of the standard library. When comparing to C++'s ability to use custom allocators with the standard library, D's phobos seems deathly pale.
D also claims to support RAII semantics. I happilly went about implementing a reference counting pointer, only to find out that there are cases where you cannot use a struct with a destructor, and there are cases where you theoreticaly can use one, but in practice find that the compiler will not call your destructor. All in all, RAII is an untested unutilized option in D.
Shachar
Here's a paradigm for you: "frog in a well". The frog looks up all its life and thinks that the entire world outside the well looks just like that patch of sky it sees. C programmers often view objects this way. (I am a C programmer, but I do not view objects that way.)
On a more concrete note, you better review your "all exceptions implementations cause a performance hit" claim. Modern exception handers are not the same as your grandaddy's exception handler. Apparently unlike you, I have verified that there is no discernable performance hit for exceptions with the compiler I use.
When all you have is a hammer, every problem starts to look like a thumb.
Templates and template metaprogramming do not cause performance degradation, but generally produce faster code. Namespaces are useful, particularly with libraries, and give the option of using the shorter name where it's local and the longer name where it's not as heavily used. Object-oriented programming is very useful sometimes, doesn't slow things down particularly with a good implementation, and doing it in C is awkward. The fact that you can write C to do anything doesn't mean you should write C to do everything, and you seem to be taking the attitude that things you can do awkwardly in C needn't have facilities in other languages to do better.
Exceptions do cause performance degradation, but modern C++ implementations have very little in a try block. Exceptions are, well, exceptional, and mean something's gone wrong, so it's reasonable to accept some degradation during exception handling. Returning an error value doesn't work as well. First, some functions don't have a possible return value that's invalid, so the programmer has to pass a variable for the desired value by pointer or reference. Second, returning an error value doesn't work well if you want to call a function in an expression (except in floating-point, where NaNs propagate). Third, having to check and return an error value every single time is tedious and easy to forget once, and once is all it takes for a serious bug.
I'm not advocating exceptions or reflection in systems programming, which (in my opinion) should not rely on much external infrastructure to run. Reflection has its own problems, in that it makes it difficult to reason about what the program does, and that makes some compiler optimizations impossible.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes