Slashdot Mirror

← Back to Stories (view on slashdot.org)

The D Programming Language

Posted by michael on from the whiter-whites-and-brighter-colors dept.

dereferenced writes: "Walter Bright, author of the original Zortech C++ Compiler and the free (as in beer) Digital Mars C/C++ Compiler, has posted a draft specification for a new programming language that he describes as "a successor to C and C++". It seems to me that most of the "new" programming languages fall into one of two categories: Those from academia with radical new paradigms and those from large corporations with a focus on RAD and the web. Maybe its time for a new language born out of practical experience implementing compilers."

2 of 530 comments (clear)

  1. Re:Convince me by Karmageddon · · Score: 0, Redundant
    compare the speed of a VM executed program to a native compiled one

    i don't think it's a quibble or pedantic to point out that the x86 architecture itself is nothing but a VM. The reason you can run "native" code on all the different chips available is because the myriad all implement the same virtual machine. Everyone agrees that code for that virtual machine is executed "quickly".

    If there is something about Java that means it conflicts with this (or some other important) VM, that would be interesting to hear. But it can't be said that VMs are "slow" in general.

  2. Here's what D can't do... by d3l3t3_m3 · · Score: 1, Redundant
    from the original text

    There is no:
    • C source code compatibility. Extensions to C that maintain source compatiblity have already been done (C++ and ObjectiveC). Further work in this area is hampered by so much legacy code it is unlikely that significant improvements can be made.
    • Link compatibility with C++. The C++ object model is just too complicated - properly supporting it would essentially imply making D a full C++ compiler too.
    • Multiple inheritance. It's a complex feature of dubious value. It's very difficult to implement in an efficient manner, and compilers are prone to many bugs in implementing it.
    • Templates. Templates are a way to implement generic programming. Other ways are using macros, or having a variant data type. Using macros is out. Variants are straightforward, but the loss of type checking is a problem. The difficulties with C++ templates are their complexity, they don't fit well into the syntax of the language, all the various rules for conversions and overloading fitted on top of it, etc. What's needed is a smoother way to integrate them into the language, so they have a much more natural and obvious feel to them. I am searching for this solution.
    • Namespaces. An attempt to deal with the problems resulting from linking together independently developed pieces of code that have conflicting names. The idea of modules is simpler and works much better.
    • Include files. A major cause of slow compiles as each compilation unit must reparse enormous quantities of header files. Include files should be done as importing a symbol table. Creating object instances on the stack. In D, all objects are by reference. This eliminates the need for copy constructors, assignment operators, complex destructor semantics, and interactions with exception handling stack unwinding. Trigraphs and digraphs. Unicode is the modern solution to international character sets. Preprocessor. Modern languages should not be text processing, they should be symbolic processing.
    • Operator overloading. The main applications for operator overloading seem to be implementing a complex floating point type, a string class, and smart pointers. D provides the first two natively, smart pointers are irrelevant in a garbage collected language. When using operator overloading for non-trivial purposes with multiple non-trivial classes, the interaction complexity of the overloading coupled with user-defined conversions, overloading in general, leads the person maintaining the code wondering whether it was all worth it.
    • Object oriented gradualism. Class instances in D are object oriented, the other data types are not.
    • Bit fields of arbitrary size. Bit fields are a complex, inefficient feature rarely used. Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures.
    After using C++ how can someone want to use this???