Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

The D Programming Language, Version 1.0 570

Posted by kdawson from the coming-of-age dept.
penguinblotter writes in a journal article: "Soon, Walter Bright is scheduled to release version 1.0 of the D Programming Language. D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. D has appeared on Slashdot a few times before, and Walter has continued to add more and more features. Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives. It has been here over the past seven years where extremely gifted and experienced programmers hashed out discussions and arrived at excellent implementations of all the ideas discussed." Read on for the rest of penguinblotter's writeup.

For those with a C/C++ background, D offers:
  • native code speed
  • extremely fast compilation times
  • garbage collection (although you can manage your own memory if you want)
  • OOP - by reference only, easy initialization, always virtual
  • cleaner template metaprogramming syntax, more powerful templates, as well
  • built-in dynamic and associative arrays, array slicing
  • versioning (no preprocessor madness)
  • link-compatibility with C
  • nested functions
  • class delegates / function pointers
  • module system
For those with a C#/Java background (a shorter list, but one with big wins):
  • similar syntax
  • No virtual machine or interpreter
  • built-in unit testing and design-by-contract
These two comparison sheets can go into more depth on how D stacks up against other languages.

From D's creator:
For me, it's hard to pinpoint any particular feature or two. It's the combination of features that makes the cake, not the sugar, flour or baking powder. So,
  1. My programs come together faster and have fewer bugs.
  2. Once written, the programs are easier to modify.
  3. I can do (1) and (2) without giving up performance.
Get your compilers and start hacking D!
  • DMD (Digital Mars reference compiler, Windows & Linux, x86)
  • GDC (GCC front-end)
This discussion has been archived. No new comments can be posted.

The D Programming Language, Version 1.0 More

The D Programming Language, Version 1.0

Comments Filter:

  • This won't work... (Score:5, Funny)

    by PurifyYourMind ( 776223 ) on Monday January 01, 2007 @05:02PM (#17424762) Homepage
    ...it's just another version race. D may have won for now, but someone out there is already working on the E programming language. ;-)

    • Re:This won't work... (Score:4, Funny)

      by 0racle ( 667029 ) on Monday January 01, 2007 @05:09PM (#17424824)
      Now, after F do we get G or 10?

      • Re: (Score:2)

        by cmeans ( 81143 )
        The language naming started at A, not 0.

        • Re: (Score:2, Informative)

          by Zerathdune ( 912589 )
          actually, B was a modification of BCPL, not A (to my knowledge there was never a language called A.) BCPL was an enhancement of CPL.

      • Re:This won't work... (Score:5, Informative)

        by TERdON ( 862570 ) on Monday January 01, 2007 @06:46PM (#17425762) Homepage
        Now, after F do we get G or 10?


        Either it'll be called 10, or H. G, has already been taken, not only once [wikipedia.org], but twice [wikipedia.org].

        For your reference (kudos goes to Wikipedia [wikipedia.org]), the following single letter (sometimes including some additional nonalphabetic characters) have also been implemented:

        A+ [wikipedia.org] A++ [wikipedia.org] B [wikipedia.org] C [wikipedia.org] C-- [wikipedia.org] C++ [wikipedia.org] C# [wikipedia.org] D [wikipedia.org] E [wikipedia.org] F [wikipedia.org] F# [wikipedia.org] G (now known as Deesel) [wikipedia.org] G [wikipedia.org] J [wikipedia.org] J# [wikipedia.org] J++ [wikipedia.org] K [wikipedia.org] L [wikipedia.org] M4 [wikipedia.org] Q [wikipedia.org] R [wikipedia.org] S [wikipedia.org] S2 [wikipedia.org] T [wikipedia.org] X10 [wikipedia.org]

        So - that only leaves you the letters H, I, N, O, P (sic!), U, V, W, Y and Z if you don't want to have a name clash with another programming language. Technically, M and X are followed by numbers in the previous examples, so you could argue for them as well, and even A (as it has a plus behind the letter)

        I'm mostly surprised that noone has thought of a (P)rogramming language. :)

        • I'm mostly surprised that noone has thought of a (P)rogramming language. :)

          Sorry, someone's already been there and done that [wikipedia.org]. :-)

        • Re: (Score:2)

          by jd ( 1658 )
          w and Y are GUIs. Z is an ISO-ratified specification language - and a damn good one at that.

        • Re:This won't work... (Score:5, Funny)

          by sacrilicious ( 316896 ) <qbgfynfu.opt@recursor.net> on Monday January 01, 2007 @11:45PM (#17428500) Homepage
          So - that only leaves you the letters H, I, N, O, P (sic!), U, V, W, Y and Z

          I hope someone creates an "O" language. That way, interface bindings for it could be called "O-interfaces", or "O-faces" for short. So when you create a nifty library for the language, publishing it could be known as "showing the world your O-face".

        • Re: (Score:3, Informative)

          by Creepy ( 93888 )
          wow - you missed a couple of C dialects, most certainly because they extended the letter name with a word

          Objective-C [wikipedia.org] and the best programming language in existence, C-Intercal [wikipedia.org] (yeah, yeah - you whitespace [dur.ac.uk] lovers can bite me).

          I can't believe you don't know this - it's common knowledge that the letter 'P' was skipped because back in the early 80s Wordstar would use control-P to purge your document with no confirmation screen as opposed to Wordperfect's print, so there was an extreme hatred for the letter from
    • Someone Did that [wikipedia.org] years ago.
      Bu seriously: Why do we need yet another programming language?
      • Why do we need yet another programming language?
        Because C and C++ suck in many ways. The number of useful languages that can be compiled to native code is very small. I'm not sure about D, though. I'm looking through the tutorials, and it seems like strings are implemented as C-style character arrays. That seems incredibly stupid and Unicode-hostile.

        • Re:This won't work... D Strings (Score:3, Informative)

          by Anonymous Coward
          While D strings are mostly implemented as character arrays, it works quite differently than C. Here are some notable differences:

          - D arrays are bounds checked. No accidental buffer overflows here.
          - D arrays are dynamic, you can resize them and concatenate them together.
          - D strings are D arrays, so they get the above bonuses.
          - D has distinct 'char', 'byte', and 'ubyte' types. char[] != ubyte[]. When you use foreach to iterate over a char[]/string, it will expand each codepoint (or whatever they are calle

      • Re:This won't work... (Score:5, Insightful)

        by jlarocco ( 851450 ) on Monday January 01, 2007 @05:28PM (#17424994) Homepage
        Why do we need yet another programming language?

        Exactly. There's already Fortran and COBOL, everything else is superfluous.

        Seriously though, why don't we need another programming language? It's not like we only get a finite number of them. We're not going to run out of space or anything.

        If it doesn't interest you, don't use it.

      • Re: (Score:3, Insightful)

        by 0racle ( 667029 )
        Did you say the same thing when Python or Ruby were created? People do things in different ways, different languages end up with their strengths and weaknesses that way. So until there is a perfect language that is all things to everyone, yes there is always a need for another language.
    • Hold your horses, E [fov120.com] is already used in a quite good Amiga Language.

  • D is surprisingly good. (Score:3, Informative)

    by FishWithAHammer ( 957772 ) on Monday January 01, 2007 @05:06PM (#17424800)
    I'm looking at using it via GDC for my next project. For people who use C/C++ regularly, this is something you ought to look into.

    It's not a toy language. If you're a C++ programmer, you'll be almost immediately functional in the language. And you can call C and C++ libraries seamlessly. It's pretty sweet.

  • Weird writeup: (Score:4, Insightful)

    by Per Abrahamsen ( 1397 ) on Monday January 01, 2007 @05:24PM (#17424952) Homepage
    From the compared to C/C++ list:

            * native code speed

    As opposed to C/C++.

            * extremely fast compilation times

    Point granted (compared with most C++ compilers).

            * garbage collection (although you can manage your own memory if you want)

    Point granted, even though C and C++ arguably have optional garbage collection as well (if you link to the right library).

            * OOP - by reference only, easy initialization, always virtual

    Only value semantic? Meyer had to accept that value semantic was useful, and add it to Eiffel eventually, and C# added it over Java.

    And no way to specify that a function will always be the one specific. Good luck doing any kind of reasoning there.

    Bragging about missing features, that are essential to many tasks.

            * cleaner template metaprogramming syntax, more powerful templates, as well

    *More* powerful templates? The usual complaint is that C++ templates are too powerful (a Turing-equivalent compile time language).

            * built-in dynamic and associative arrays, array slicing

    Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.

            * versioning (no preprocessor madness)

    I'm guessing he meant variants here, the preprocessor is often used for variants, rarely for versioning.

            * link-compatibility with C

    Which C and C++ of course lacks?

            * nested functions

    Point.

            * class delegates / function pointers

    Obviously both C and C++ have function pointers.

            * module system

    More preprecessor replacement here.

    The C#/Java list:

            * similar syntax

    But totally different from C++?

            * No virtual machine or interpreter

    You can compile Java and C# to native code as well, so this is just another case of bragging about a missing feature.

            * built-in unit testing and design-by-contract

    I'm a C++ programmer, and this is by far the most interesting aspect of the D language (and of Eiffel before that). Don't know why it should be in the Java/C# list.

    • Re: (Score:3, Informative)

      by 91degrees ( 207121 )
      Couple of points:

      * native code speed

      I think this is a response to criticisms from C programmers about most modern languages, rather than a benefit over C.

      Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.

      Some of this is useful enough to be built in. stl and the like are pretty handy but sometimes it feels a bit of a kludge. Plus, built-in allows better optimistations for specific cases.

      Obviously both C and C++ have function pointe
    • > >* versioning (no preprocessor madness)
      >
      > I'm guessing he meant variants here, the preprocessor is often
      > used for variants, rarely for versioning.

      I does look like variants to me, but appears to be called versioning - check this:

      http://www.digitalmars.com/d/version.html [digitalmars.com]

    • The Win32 API makes heavy use of macros for versioning, so I do not believe you can classify it as "rare". Maybe it's rare on UNIX but that's a failing, not a strength.

    • Re: (Score:3, Interesting)

      by donglekey ( 124433 )
      This strikes me as the thoughts of someone who hasn't given D a good look. I have been using it recently and it is phenomenal. It is a breath of fresh air. It is not that it has many of these features over C/C++, it is that it cleans out the enormous amounts of headache inducing things about these languages while retaining what Java/C# lose. Native code speeds. No VM. Trivial Integration with C.

  • java native code compilation (Score:3, Informative)

    by Nutty_Irishman ( 729030 ) on Monday January 01, 2007 @05:24PM (#17424956)
    All other considerations aside, runtime speed really should be a justification as a bonus to Java. Java isn't that much slower if you actually take the time to compile it to native code first. Using something like a JIT compiler http://en.wikipedia.org/wiki/Just-in-time_compilat ion [wikipedia.org] can greatly increase the speed of your code and put it close in line with C++. I would certainly consider D if both 1 and 2 were better than Java.

    • Re:java native code compilation (Score:5, Informative)

      by Decaff ( 42676 ) on Monday January 01, 2007 @05:54PM (#17425230)
      Java isn't that much slower if you actually take the time to compile it to native code first. Using something like a JIT compiler http://en.wikipedia.org/wiki/Just-in-time_compilat [wikipedia.org] ion can greatly increase the speed of your code and put it close in line with C++.

      This is a bit of an old myth. Almost all Java is run as native code these days, even on VMs, and is mostly pretty close to C++ speed. Benchmarks that show Java as significantly slower than C++ usually result from not allowing the VM enough time to perform native code translation of time-critical code. Java has moved away from JIT compilation (as against the later optimisation of HotSpot) because it led to long start-up times - you had to wait for code to be compiled to native before it ran. Now Java usually starts up as interpreted, with the translation to native code happening later on, in the background.

      Where C, C++ and D win out over Java in terms of performance is when you need programs that have to start up fast, run fast, but only for short periods (a few seconds).
  • Cheers for D, and happy new year to Walter and all the rest! As much as the D community is often derided for their sometimes aggressive marketing, D is actually a programming language that can run with the best of them.
  • Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives

    You must be new here.

  • Currently learning D (Score:5, Informative)

    by kihjin ( 866070 ) on Monday January 01, 2007 @05:49PM (#17425188)
    Note: I've been programming in C/C++ for four years.

    I took it upon myself to learn D not more than a few weeks ago. A classmate introduced me to the language last spring.

    While I'm still learning D, it has some notable features:

    • auto keyword for inferred type declaration
    • lazy keyword for evaluation
    • delegates are like function pointers, but cooler. Literal statements can be passed as variables, and aren't evaluated until the delegate is called.
    • scope(exit|failure|success), specify a block of exit code
    • in/out/inout function keywords, offer readable code for determining what a parameter in a function is designed for.
    • get/set methods automatically become a property (accessed like a public variable)
    • foreach, foreach_reverse, container iteration
    • with statement, C++'s using on a object-level

    Of course one may argue that none of this is necessary and could be made independent of the language itself. My belief is that would increase the complexity of coding in D.

    If you're interested in D you should visit http://www.dsource.org/ [dsource.org]. There are some interesting projects such as Derelict [dsource.org] (collection of C game bindings) and Bud [dsource.org] (make and SCons replacement).

    • Intersting. How are public interfaces to private implementations declared, and how are mixins written?

      On dsource.org I can't find any examples of public headers into libraries.

  • It looks like a step down (Score:4, Funny)

    by Anonymous Coward on Monday January 01, 2007 @05:49PM (#17425196)
    After working so hard to get from C to C++, I don't see why I would settle for D. My next programming language is going to be B- or better.

    • Re: (Score:3, Funny)

      by 4D6963 ( 933028 )

      After working so hard to get from C to C++, I don't see why I would settle for D

      I'd gladly have my girlfriend to go from C to D, but I admit there's nothing I would love more than DD.

      Edit : yeah I know, quit telling me that I must be a liar, I don't have a girlfriend, WHO CARES?!?
      Edit #2 : What? You can't edit your comments on Slashdot? So how am I doing that, jerk?

  • Do we really need another D infomercial? (Score:4, Insightful)

    by Anonymous Brave Guy ( 457657 ) on Monday January 01, 2007 @05:57PM (#17425262)

    I'm sure D is a lovely language, but it just seems like another incremental change over C++, like Java and C# before it, and like both of those languages what it's lost and the opportunities it misses are as telling as the little tweaks it makes to improve things.

    No-one has yet been successful, IMHO, in developing a really good industrial programming language. Those that make it tend to be pragmatic, practical tools like C and Perl and FORTRAN and COBOL. To be sure, each of these has many widely-acknowledged weaknesses, but the overall balance between those weaknesses and what you could get done using the language was right.

    I can increasingly see why some well-known programming language designers shy away from feature comparison ticklists. I think it's because as soon as you go down this route, you bias the comparison so much that it's meaningless. For example, consider the first checklist [prowiki.org] cited in the Slashdot write-up. (I note in passing that this is a wiki, and may change before you read this.) Here are some of the "yes or no" (almost) categories:

    Templates or executable macros
    No difference in expressive power is acknowledged between LISP macros and C++ templates.
    Thread synchronization primitives
    With no reference to how expressive they are, and how powerful the idioms supported by them? This one is really telling, IMHO, because I don't believe the future lies in classical thread sync and locking primitives. The whole approach is just too prone to deadlocks and race conditions to withstand the heavily parallel future that multicore chips are starting to bring into the mainstream. When you have ideas like pure function programming languages, operating in a world without side-effects where explicit locking isn't necessary, or interesting ideas for inter-thread communication such as those in Erlang, another variation on built-in pthreads just isn't worth much.
    Enumeration
    So again, we acknowledge no difference between simple and low-level enumerations such as those in C, and concepts such as disjunctive types and pattern-matching that are very powerful, remarkably elegant, and mainstream in certain families of programming language. Again, this is just papering over a gap, where other languages operate on an entirely different level.
    Long double floating point (80bit)
    This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches.
    Lexical Closures
    Another telling omission: the power of all those neat functional programming features is dramatically reduced when you can't construct functions on-the-fly.

    On top of all of this, the feature lists invariably gloss over some less concrete things that are nevertheless very important to systems programming languages. How portable is D? How many production-quality implementations are available? Is the language standardised or under the control of a single, commercial body? How much backing is there behind the language in the commercial development space; do others write libraries specifically for this language, or is it reduced to using C-style interfaces at the lowest levels anyway, and what impact does this have on the usefulness of features like DBC, exceptions, and so on? Does the language have an active hobbyist/volunteer community supporting it?

    I could go on, but I don't want this post to disappear into the oblivion any more than it already will. Although I'm deliberately focussing on criticising in this post, as I often do with D, I keep an open mind and will happily engage in debate with others, or even be proved wrong by people who have found D to have compelling advantages. So go ahead, D advocates, start your counter-arguments here...

    • Re: (Score:3, Insightful)

      by stevenj ( 9583 )

      Long double floating point (80bit) — This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches.

      Um, considering that the vast majority of the world's floating-point hardware is x86 and supports extended precision, saying that it lacks "true support from almost every mains

      • Re: (Score:3, Interesting)

        by Anonymous Brave Guy ( 457657 )

        Um, considering that the vast majority of the world's floating-point hardware is x86 and supports extended precision, saying that it lacks "true support from almost every mainstream architecture" is comical.

        Not really. Take a look at the performance, addressing modes, and so on. The support for 80-bit on Intel boxes is not the same as the support for 64-bit, at least in practical terms.

        Also, while the vast majority of the world's FP hardware may indeed run on x86 (I don't know), I would suggest that a

  • Lazy Questions (Score:3, Informative)

    by Quantam ( 870027 ) on Monday January 01, 2007 @06:15PM (#17425468) Homepage
    Looking at the comparison lists, D looks pretty nice. It has a lot of features that I'd consider switching languages for (from C++), but any such language would have to have a few particular properties (due to the kinds of things I program):
    1. Must be able to disable garbage collection and manage allocation explicitly
    2. Must be able to allocate classes on the stack
    3. Must minimize use of exceptions in the standard library (in other words, exceptions must only be used for exceptional cases)

    Java fails all of them, if I recall correctly (I don't know that much about Java, actually). C# fails 2 and 3. It looks like you can disable garbage collection in D, but in the comparison list I didn't see mention of 2 or 3. Does anybody know, off the top of their head?

    • Re: (Score:2)

      by kihjin ( 866070 )
      These may satisfy your curiosity:
      1. You can disable GC entirely, on a per class or per instance basis.
      2. Yes, stack classes [digitalmars.com] are easy.
      3. I haven't used Phobos in great detail yet, but I haven't encountered anything like Java's exception library.

      Hope this helps,

      KG

    • 2. Must be able to allocate classes on the stack

      This is a really, really strange requirement. Why would you need to be able to do this in a language? In a high-level language, memory allocation is abstracted away from you so you don't need to worry about it. A decent JVM, for example, creates pools for frequently allocated and de-allocated objects so that they have a much lower cost than heap-allocation of C++ objects.

      Objective-C, for another example, follows the Smalltalk model of putting as little in the language and as much in the libraries as

    • Stack allocation (Score:3, Informative)

      by igomaniac ( 409731 )
      Deciding how to allocate an object you create would better be left to the compiler. It's not a hard analysis to do to make sure the reference to an object never escapes a particular (possibly recursive) function call, and in that case the object can be allocated on the stack. Leaving this decision to the compiler makes sure that if someone changes the code you're calling so it suddenly starts to keep references to the objects that you've allocated on the stack and are passing in, it won't break. In big C/C+
  • garbage collection ... No virtual machine

    How do they square that particular circle?

    native code speed

    Just In Time Compilation in C# or Java has "Native code speed", in fact it goes one better - since the compilation happens at a later time, more processor or other specific optimisations can be made. That's not the slow part. GC has a lot to do with the perceived slowness. Isn't it disingenuous to tout both "native code speed" and "garbage collection"?

    • Re:GC, No Vm or performance hit (Score:4, Informative)

      by Nasarius ( 593729 ) on Monday January 01, 2007 @06:26PM (#17425564)
      garbage collection ... No virtual machine How do they square that particular circle?
      It's really not that difficult. Hans Boehm wrote a garbage collector [hp.com] for C/C++ years ago, which happens to be the same one that the Digital Mars implementation of D uses.

      • Re: (Score:3, Interesting)

        by StrawberryFrog ( 67065 )
        If I read that FAQ right, it is possible that "integer or other random data be misinterpreted as a pointer by the collector" since given the nature of C - no VM, the difference between a pointer and an int is at best a gentleman's agreement - anything in memory *could* be a pointer. Well, I suppose it works if he says so. But it certainly isn't pretty.

    • Re:GC, No Vm or performance hit (Score:5, Informative)

      by Anonymous Brave Guy ( 457657 ) on Monday January 01, 2007 @06:30PM (#17425606)

      garbage collection ... No virtual machine ... How do they square that particular circle?

      The same way as countless other programming languages have in the past, I imagine. Why do you think garbage collection requires running your code under a VM?

      Just In Time Compilation in C# or Java has "Native code speed", in fact it goes one better - since the compilation happens at a later time, more processor or other specific optimisations can be made.

      Of course, you're overlooking all the overhead of monitoring the code long enough to determine which on-the-fly optimisations are worth performing, and of compiling the code itself, neither of which is trivial.

      GC has a lot to do with the perceived slowness.

      True, though of course it's not without overheads. Almost all of the Big Claims(TM) made by GC advocates in these discussions come with a catch: state-of-the-art GC method number 17 has a lower amortised cost of memory recovery than explicitly freeing it C-style!*

      * But only if your system contains 10x as much memory as the program will ever need anyway.

      This is traditionally followed by a wisecrack about how memory is cheap, followed by three enlightened posters pointing out the stupidity of that argument for multiple reasons. :-)

      Isn't it disingenuous to tout both "native code speed" and "garbage collection"?

      That depends a lot on context. If you really have a system where the overheads of GC are trivial but all the advantages are present, it seems a fair claim. It's just not likely to be universally true, and representing it as such would indeed be disingenuous.

      • The same way as countless other programming languages have in the past, I imagine. Why do you think garbage collection requires running your code under a VM?

        Because in a non-vm language like C with its use of pointers for everything, it is very hard if not impossible to tell if an object on the heap is in fact still in use and can not be automatically reclaimed. Sure you could have a Vm with pointers, but one of the main advantages of the Java or .net VM is that it can better track memory use.

      • Re: (Score:3, Funny)

        by discord5 ( 798235 )
        This is traditionally followed by a wisecrack about how memory is cheap, followed by three enlightened posters pointing out the stupidity of that argument for multiple reasons. :-)

        Let me help you with this :

        Ha! Memory is cheap!
        So was your mother last night.

        Dad?

        Meh, karma to burn...

    • Re: (Score:2, Informative)

      by scoonbutt ( 1022589 )
      Garbage collection has no requirement for using a virtual machine. They usually show up together, but there's no technical requirement.
  • I thought for sure that the D language was at least 25 years old and built way back when. Then about 2 years ago Solaris 10 came out with dtrace and all of the "scripts" have .d extensions. Yeah I know it is unix and the extensions are meaningless.

    Dtrace user guide [sun.com]

    But the disambiguation page [wikipedia.org] on wikipedia seems to bear out that calling a programming language D will only be interesting. Anyone know if it is trademarked yet?
  • ...is obviously the birthplace of D. Heavens, it's the union of C++ (already a nightmarishly huge language), C99, and C#, along with dozens of other features halfway borrowed from functional languages and other inspirations. More features must be better, never mind that the language becomes insanely complicated! (Next they'll be throwing in the Fortran 2000 standard.)

    My feeling is that languages shouldn't try to satisfy all possible needs. Rather, we should have small and clean languages, use the right tool for each job, and combine code libraries from different languages when needed. (I regularly use 3-6 languages in a single project and my life is much happier for it.)

    (Legacy support is critically important too, but it is vastly better to provide legacy support by providing ways to call older languages, especially the lingua franca of C, rather than demanding that the new language be a superset of the old. I still call numerical libraries written in pre-1970 Fortran, but that doesn't mean I have to write my code in a Fortran derivative.)

    • Amen. Here's a quote from the article:

      Special attention is given to the needs of quality assurance, documentation, management, portability and reliability.

      So where is the word simplicity in all of this? Anybody that has learned to use C++ really well has, to my mind, earned the equivalent of a Master's degree. This makes C++ a brilliant failure. So to learn D will we require the equivalent of a PhD?

      Good designers make things both simpler and more powerful. They improve the product as much through s

  • Python and D (Score:4, Interesting)

    by MightyMooquack ( 241719 ) <kirklin.mcdonald ... m ['gma' in gap]> on Monday January 01, 2007 @06:40PM (#17425706)

    One area I see D being useful in is integration with Python. Writing to the raw Python/C API is cumbersome. (Managing reference counts is tedious.) Boost.Python is difficult to build and slow to compile. I've written a library for D called Pyd [dsource.org], whose purpose is not entirely unlike Boost.Python's.

    Pyd is easy to use. It provides its own extension to Python's distutils. Usually, you just need to make sure the D compiler is on your PATH, write a setup.py file, and run python setup.py build.

    "Hello world" in Pyd looks something like this (and I apologize for the lack of indentation):

    import pyd.pyd;
    import std.stdio;

    void hello_func() {
    writefln("Hello, world!");
    }

    extern (C) void PydMain() {
    def!(hello_func);
    module_init();
    }
    • Good stuff. Alas, I see you inherit the necessity for FooWrap classes for polymorphism from Boost.Python. Is there any way of doing this automatically, or am I doomed to wrestling with SWIG?
  • ... actually going to use this? I think I'll wait for D++
  • I just can't see why I'd want to switch to a language that has no IDE support and is evolutionary to C# or C++. I hardly have to look at documentation for APIs anymore because I can just use Visual Studio's autocompletion to figure things out.

  • I skimmed it, and some of this stuff is a PiTA. For example, they make a lot of good points about the pre-processor, but I can't justify re-working all my code into D just from that alone. Some of this stuff is bells and whistles--e.g., the built in unit testing? You don't need a language construct for that. If your programmers are so lazy or stupid that they can't write unit tests in C or C++, having the language give them a little hand-holding, standard way of doing that is probably not going to help.

  • EVERY Language Sucks (Score:3, Funny)

    by JoeCommodore ( 567479 ) <larry@portcommodore.com> on Monday January 01, 2007 @08:02PM (#17426564) Homepage
    I mean, like, I try to write this program, and like, the language does ONLY what I tell it to, not what I really want. That really sucks.

    Can't someone write up some stuff that understands proper english? Geez.

    • Re: (Score:3, Funny)

      by istartedi ( 132515 )

      %ecc posting.english -o test
      warning 1: ``like" is superfluous teen speak, construct discarded.
      warning 1: ``and like" is superfluous teen speak, construct discarded.
      warning 3: ``english" assumed to be ``English".
      warning 3: ``Geez" undefined. Linking against null action function.
      % ./test
      The poster's meaning is that he tries to write a program.
      We have established that ``That" really sucks, and we are
      assuming that ``That" is the poster's act of writing a program.
      Can't someone write up some stuff that understan

  • object oriented (Score:3, Insightful)

    by elmartinos ( 228710 ) on Monday January 01, 2007 @08:21PM (#17426744) Homepage
    From TFA:
    // Object Oriented Programming
    CmdLin cl = new CmdLin(argc, argv);

    Why do they always insist on this bad syntax? Why can't they write
    CmdLin cl = CmdLin.new(argc, argv);
    This way you can think of CmdLin as an object, new is just a method that returns a new instance. Voila, one keyword removed, and much cleaner syntax. This would not even offend the Java people because they can have the same syntax with a static method.

  • Comparison to Objective-C? (Score:5, Interesting)

    by Jimithing DMB ( 29796 ) <dfe@tg[ ].org ['wbd' in gap]> on Monday January 01, 2007 @10:00PM (#17427738) Homepage

    I noticed that a comparison to Objective-C is quite conspicuously absent from the list of languages compared to D. Why is it missing? Granted D seems to be a much greater change to C than Objective-C is but I can't help but thinking that one of the main attractions to D seems to be its heap-based garbage-collected object system. You can already get the object runtime with Objective-C. If you use GNU you can even have Boehm GC (which is apparently the GC that D uses). If you use Apple you will have to wait for Leopard to get GC. Another new Objective-C feature is the ability to use full C++ objects as instance variables in your Objective-C classes and do the right thing with initializing (calling the default no-argument constructor upon alloc).

    On top of that, Objective-C actually includes tons of reflection information. Although Objective-C has protocols which are roughly equivalent to Java/C# interfaces they are almost completely unnecessary. In Objective-C one can query at runtime whether a method is implemented or not and if so call it. So whereas in Java you'd do this:

    if(anObject instanceof MyInterface) ((MyInterface)anObject)->doSomething();

    in Objective-C you can do this:

    if([anObject respondsToSelector:@selector(doSomething)]) [anObject doSomething];

    The difference being that in the Java case you have to declare MyInterface as containing the one doSomething() method and inform java that your object extends MyInterface whereas in Objective-C you merely need to provide a doSomething method on your object.

    Basically that means that in Objective-C every single method effectively becomes an interface. You would not believe how useful this is once you realize it. Note that at runtime there is ZERO difference. In both the Java and Objective-C cases the object is being checked to see if it implements something. Same with C++ if you use dynamic_cast<>()

    Granted every language has its niche and I'm sure D will find its. Objective-C's niche is definitely GUI programming. The ample reflection information allows for easy implementations of archiving (serialization) and most importantly key-value coding and the related action methods pattern. It's a pretty damn cool thing when your RAD tool simply outputs archived objects that refer to methods to be called upon certain actions simply by name.

  • Missing the point (Score:5, Insightful)

    by pammon ( 831694 ) on Monday January 01, 2007 @10:07PM (#17427782)
    The largest problem with C++ is its complexity, which causes the language to fragment into partially intersecting sublanguages representing each programmer's comfort zone. D does not address this problem; in fact, it makes it much worse. Example? C++ has seventy some keywords, but D has more than ninety. Another example? See if you can guess what this means in D:


    0XA1_2_C35_4_5_6_5P6_Li

    Give up? Why, it's an imaginary real. Yes, you read that right. Oh, and I specified it in hexadecimal, just to prove I can. And I threw in some underscores because you're allowed to do that too. Have you guessed what an imaginary real is yet? This is supposed to be the "simpler C/C++ replacement."

    A good language strives to find a few constructs that solve multiple problems. A bad language takes the kitchen sink approach. C and C++ are not good languages, but wide deployment and support make them useful anyways. D does not have that, but the designers do have the luxury of learning from the mistakes of the past. So what the hell is their excuse?

    • Re: (Score:3, Insightful)

      by donglekey ( 124433 )
      A good language strives to find a few constructs that solve multiple problems.

      D does this. You are looking past the dozens of examples where D has cleaned up problems that have been plaguing programmers for years to grasp at a chance to make a piece of code as messy as possible. Maybe you are comfortable working with C/C++ and don't want to deal with another language. I am not comfortable dealing with all the fucked up C and C++ out there. I have worked with D and it is exciting and refreshing. It is mu

  • OOP languages are slow (Score:3, Interesting)

    by bluefoxlucid ( 723572 ) on Monday January 01, 2007 @10:21PM (#17427910) Homepage Journal

    CPUs put a lot of stock in branch prediction; due to the nature of OOP languages like C++, Objective-C (I like this one), and D, this doesn't work. The way virtuals and class inheritence works, functions are necessarily dealt with as pointers; the function is pointed to by pointing to a master class object, basically. Here's a C reconstruction:

    struct myClass_members {
    struct myClass_members *(*alloc)(); // constructor
    void (*destroy)(struct myClass *); // destructor
    int (*my_member)(); // member function
    };

    struct myClass { // Data
    struct myClass_members *call; // Pointer to a list of members as above
    int my_value; // an integer value
    };

    What you do is initialize a constant myClass_members (called myClass_Object here) with a bunch of pointers to static functions in one source file; then call myClass_Object->alloc to create a new one (we'll call it my_inst). Then do my_inst->call->my_member() to call the member, and similarly my_inst->call->destroy(my_inst) to deallocate the class.

    Basically, OOP languages like C++ and Java use this methodology, but it's obscured through friendly syntax. What we can expose from the above is:

    1. When class members change, structs change. This causes binary incompatibility between different versions of libraries. The exception is Objective-C, which looks up members based on their name in a hash table generated at run-time
    2. The addresses of branches (specifically CALL to call a function) are indirect (yes, in Obj-C too); this means that you can replace the class with another class that has the same structure but different functions being pointed at. It also means that the CPU can't do branch prediction, which hurts pipelining and intelligent CPU caching, causing pretty big slow-downs.

    The whole "native execution speed" thing is bunk. Script languages are executed on a native bytecode interpreter, or JIT'd to native. The amount of work that goes into the execution is what you care about; as well as the utilization of the CPU's most powerful facilities. You can only justify OOP languages by saying that either A) the majority of the work doesn't involve making calls to other class members, and thus won't be hurt by this; or B) CPU speed doesn't matter. I hate argument (B); (A) I can accept, barely enough to tip my hat to you for having good software engineering sense.

  • GDC source is not 64-bit clean (Score:3, Informative)

    by The_Dougster ( 308194 ) on Tuesday January 02, 2007 @04:44AM (#17429854) Homepage

    I've been messing around for a couple hours now trying to compile gdc against gcc-4.0.3 in Gentoo amd64 and it's just not happening. I ran into an issue where it had a int and size_t mismatch, an undefined cpu symbols macro, and after hacking these the build died complaining it thought that I was cross-compiling gcc.

    I've given up for now. Maybe if D hits the 1.0 magic number somebody will fix it for 64-bit systems and add it to portage. Oh well, I would have liked to start playing with D but I guess I'll just have to wait.

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close