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#.
I guess the users of languages don't like readable, simple, or maintainable code.
Confirmation!
Your ad here. Ask me how!
And that's just on a personal level.
On a business level you've got to offset the risk associated with using a less known language with probably a much smaller toolstack around it, a smaller pool of available developers, and a less certain future. There has to be a very compelling reason for a business to not just go with c++ or java or .NET.
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?
Should be, but it isn't.
Here are couple of reasons why (IMHO):
1. The main compiler is not free-software (as in freedom).
The compiler package (called 'dmd' [http://dlang.org/download.html]) has a non-free license,
and regardless of any wishi-washi explanations about front-end/back-end freedom, the fact is - it is not free, and will never be included in any distribution's main repository.
2. The free-software compilers (GDC, based on GCC and LDC, based on LLVM) are always lagging behind in features and compatiblity.
Walter Bright and Andrei Alexandrescu (the two lead developers) focus mainly on DMD, and so the free-software version will never catchup.
3. Building the compiler and the 'standard library' (which was itself a moving target up until recently) is done with really broken 'makefile' system, which requires one to put things in specific directories. Not fun for package maintainers, or for people wanting to build the lastest versions. Time to move to CMake (or autotools).
4. poor eco-system and package-manager. There is 'dub' (http://code.dlang.org/) but it is barely useable in the real-world. For example, the slightest error in the 'package.json' file of a package, and not only nothing works, but also the error messages are next to useless.
5. Less-than-great platform support. Despite claims to supporting Windows,Linux and FreeBSD - it seems some compilation/linking things are not functional on Linux (haven't tested FreeBSD). There's seem to be a big focus on Windows, and little motivation from the top-brass to give a 'push' to make it work perfectly on Linux.
6. A pet-peeve: The 'string' type is very annoying. Regardless of how marvelously it is engineered to fit perfectly within the D-language paradigm, using it is a pain, especially when needing to pass it around or modifying it.
An example is http://stackoverflow.com/questions/20747893/convert-auto-string-to-char-in-d
That being said,
The compiler 'dmd' is blazingly fast,
and once everything is setup correctly (and if one ignores the non-free issue), then programming in D is so much fun! It really feels like this: http://xkcd.com/353/
I never understood what D offered that wasn't offered elsewhere.
Mainly, it's a systems programming language, meaning that it gives the programmer fine-grained control over memory and operations so that you can write operating systems, drivers, and high-performance applications. This is relevant because, aside from the two biggies (C and C++), there aren't a lot of other languages in this space. I mean, there's Objective-C (which sort of half-asses it), and recently Go and Rust arrived on the scene. All the other popular languages are pretty much for scripting (Python, JavaScript, PHP, etc.), or running atop a managed virtual machine (Java and C#).
As for what it offers... it's basically a re-invention of C++. No, no... it's deeper than that. It's the idea of C++ re-invented in such a way that you get most all the power and low-level control of C++ without so many of the dangers and difficulties.
Unfortunately, D has struggled to gain wider acceptance. It fractured it's community when D version 2 broke backwards compatibility with D version 1, and the forums (which run on a dedicated Usenet server, FFS) are filled with endless commentary about what does and doesn't work in the latest point release of the DMD compiler. Bright and Alexandrescu have certainly designed a compelling language, but they seem (from my distant vantage point) to be mired in implementation details... yeah there's a standard library and everything, but the surrounding ecosystem (standards, tutorials, tools, IDE's, API's, packaging, etc.) hasn't made the leap to that sort of functional minimum you see with (for instance) node.js or Haskell's "batteries included" experience.
TL;DR - D's a super awesome low-level language, but it's not yet a platform.
-1, Too Many Layers Of Abstraction
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
When Chuck Norris throws an exception, it is always fatal.
If that isn't a hit to performance, nothing is.
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.