Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming

Is D an Underrated Programming Language? 386

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#.
This discussion has been archived. No new comments can be posted.

Is D an Underrated Programming Language?

Comments Filter:
  • by Lab Rat Jason ( 2495638 ) on Tuesday January 20, 2015 @04:00PM (#48859781)

    ... is that they need to be better than old ones. Not just objectively better, but measurably better. And not just measurably better, but with enough margin as to offset the cost of learning a new language... I'm not going to ditch C++ just to learn D unless someone is paying me to. Show me the money!

    • by Anonymous Coward on Tuesday January 20, 2015 @04:04PM (#48859841)

      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.

    • And then there is a the question of portability. There is a C compiler for virtually anything powerful enough to support a compiler. C++ rules out some of the smaller microcontrollers but is available virtually everywhere else. Sure the code may need some work to remove platform specific assumptions, deal with missing library functionality on very small targets or deal with compiler bugs but that is still likely to be much easier than a complete rewrite.

      Any new language that is intended to be compiled to na

      • The new trend, as per the aforementioned rust, is to target LLVM.

        So there still may be places that the Gnu Compiler Collection can go that LLVM can't but port Clang and you get the rest for free.

    • I can do C, Java, Python, and .NET (C#) just fine. I can also muddle my way through C++ when I must. However, I'm nowhere near smart enough to do C++ well. I can't memorize the many edge and corner cases in the language definition itself, never mind the specific compiler implementations. I can't easily follow C++ code from people whose styles are significantly different than my own. There is a HUGE need for a systems programming language that is close to the metal, allows for higher-level abstractions
      • I'm nowhere near smart enough to do C++ well.

        This is a bit of an illusion. If it would benefit you to know C++ better, I'd encourage you to not give up easily.

        First, it's an illusion because when you read some template code by an expert like Andrei Alexandrescu, it's easy to imagine that this code flowed out for him as easily as writing Python is for you. But writing that kind of code is a slow thoughtful process even for experts, and even they get it wrong sometimes.

        Second, it's an illusion because you're comparing your limited experience with C++ p

  • by Actually, I do RTFA ( 1058596 ) on Tuesday January 20, 2015 @04:00PM (#48859783)

    D's syntax is simpler and more readable than C++,... so shouldn't it be more popular?

    I guess the users of languages don't like readable, simple, or maintainable code.

    The languages with the biggest gains this time around include JavaScript, PL/SQL, Perl, VB, and COBOL. (Yes, COBOL.)

    Confirmation!

    • I actually think that's why some languages (and projects) are more successful than others. The thing with beautiful languages and beautiful code is it puts people off wanting to tinker with it. People are more comfortable messing around with things that are a bit messy. And that's how they become popular. LISP is by far one of the most elegant languages, but that reputation means it makes people want to spend more time coming up with elegant code rather than useful features.

      A language like C++ has ugly s
  • by pla ( 258480 ) on Tuesday January 20, 2015 @04:03PM (#48859821) Journal
    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!
  • by OzPeter ( 195038 ) on Tuesday January 20, 2015 @04:05PM (#48859847)

    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 [dlang.org]

  • ... but I still think the rankings here are just about meaningless.

  • by Anonymous Coward on Tuesday January 20, 2015 @04:21PM (#48859989)

    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/

    • Failure by design?

      D is the Betamax of programming languages, well thought out, feature rich but flown into the ground.

    • The DMD compiler isn't free software because Walter Bright doesn't own all of the intellectual property rights. He has the right from other copyright holders to redistribute the code, but not the right to relicense it.
  • I tried it (Score:5, Interesting)

    by gabereiser ( 1662967 ) on Tuesday January 20, 2015 @04:26PM (#48860055)
    and I liked it, until I tried to deploy it. I think D could really use some more documentation on deploying applications written with it outside of the systems applications. I tried making a desktop application (opengl based) with it and found it extremely difficult to deploy to other machines let alone Mac OSX. But then again, it could have just been my naiveté.
  • The deletion ninjas on Wikipedia won't even let nim have it's own article. So D has a leg up on at least one "next-gen" language.

  • Perl went up in the ratings!
  • PL/I on TIOBE (Score:4, Interesting)

    by Rob Riggs ( 6418 ) on Tuesday January 20, 2015 @04:44PM (#48860227) Homepage Journal
    Who knew that PL/I [wikipedia.org] was still a thing? Hell, even IBM is releasing a compiler update [ibm.com] for this language. Somehow it is about as popular as D.
    • by msobkow ( 48369 )

      Man, that's a blast from the past. In my first year of university back in fall of '82, we used the PL/C subset of PL/1. Kind of a shitty language for introducing people to programming, but I'd been coding BASIC and assembler (Z-80) since I was 14, so it was mainly an issue of learning syntax for me.

      • by sconeu ( 64226 )

        Let me guess... WUSTL? I remember that we wrote PL/1 using the PL/C subset in '80 and '81. Go WUSTL Bears!!!

  • :D (Score:4, Funny)

    by wcrowe ( 94389 ) on Tuesday January 20, 2015 @05:02PM (#48860373)

    Perhaps they should call it :D. At least it would seem more friendly.

  • I'd publish a paper, "C syntax considered harmful" with roughly the same kind of rationale as the "Goto considered harmful" paper.

  • by dentin ( 2175 ) on Tuesday January 20, 2015 @05:24PM (#48860571) Homepage

    I've looked at D before. It looks promising, and I've considered using it. The reason I don't is a bad reason, but it's the most common bad reason: legacy code.

    I have two hundred and sixty four thousand lines of code in my personal project/library archive (my own code, not counting custom versions of external packages like openssl and portaudio), all in C/C++, all with a unified build system, that's been ported and debugged on serveral platforms. Every new project I start uses those core libraries and header files. When I think about switching to a new language, my biggest concerns are how new code will integrate with my existing, how the new language will make use of my existing libraries, and how to remain productive in a dual language environment. The long term gain might eventually make it worthwhile - but it might also just cost me time should the new language die out or not support a platform I need it to.

    I simply can't justify the gamble.

    • The reason I don't is a bad reason, but it's the most common bad reason: legacy code.

      Note that this is not the only reason you list, you also mentioned the doubt that the language will stick around. Which is another good reason.

  • c++11 does it in (Score:3, Interesting)

    by Anonymous Coward on Tuesday January 20, 2015 @06:04PM (#48860847)

    'D' was somewhat appealing until C++11 was released and support started. That removed any core feature advantages 'D' had.

    The whole mess of 'D' having automatic garbage collection as part of the language turned systems programmers who the language is supposed to target and also makes the language much more difficult to implement. Yes the compiler is easier to write but 'D' is much heavier than C++ feature wise erasing any advantage it may have had on the compiler side.

    So other than compilation speed what 'D' offers is marginally nicer than C++ but brings along with it a bunch of baggage, limited platform support and some very questionable engineering decisions.

    I personally would rather see C++ resyntaxed so that it's easier to compile. Unfortunately that would break source compatibility and have a bunch of other issues as well.

    • You can use D without automatic garbage collection, but most of the system libraries depend upon it. The two main language designers are working on an architectural change so you can use the system libraries with or without garbage collection as you choose.

      I still think legacy code and legacy expertise are the biggest obstacles, and they are formidable.
      • You can use D without automatic garbage collection, but most of the system libraries depend upon it. The two main language designers are working on an architectural change so you can use the system libraries with or without garbage collection as you choose.

        I really wanted to like D, but the dependence on the garbage collector is a deal-breaker. That's a pretty big oversight for a language trying to compete with C++. It makes me wonder how well they've thought out using different subsets of the language without paying for what you don't want, which is one of the reasons for using C++.

        Yes it would be nice to have a C++ with a cleaner syntax, but C++11 is already a huge improvement, and C++14 will be even better. If we can finally get concepts, it'll be amazi

  • The problem with D isn't the language, which is excellent. Unfortunately, superior languages loose out to inferior ones all the time. (Yes, I'm aware that superior and inferior are subjective terms.)

    Language quality is nice, but there are several factors that are more important when it comes to market success. These factors include: third party tools (compilers, debuggers, IDEs, profilers, etc.), third party libraries (both quantity and quality are important here), momentum (C++ and Java are pretty well

  • by Anonymous Coward on Tuesday January 20, 2015 @09:20PM (#48862215)

    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

  • I haven't heard of D (I'm not a programmer), but it would be great if the trademark/symbol was little blue flowers, for the love of PKD.

  • NO (Score:2, Interesting)

    by russotto ( 537200 )

    As long as it's a garbage collected language it goes in the heap with Java, C# and the rest of the garbage collected languages. If you want to compete with C and C++, you need real memory management.

A complex system that works is invariably found to have evolved from a simple system that works.

Working...