Forgot your password?
typodupeerror
Programming IT Technology

The D Language Progresses 526

Posted by michael
from the lots-of-letters-left dept.
xsniper writes "D made its debut here on Slashdot in August 2001. Since then, many new features have been implemented, to include: operator overloading and slew of additional functionalities. It was featured as a cover story for the February 2002 issue of Dr. Dobb's Journal, and has been ported to the UNIX environment. I encourage programmers to revisit the specs to see how Walter Bright has addressed their concerns. A copy of the compiler is also available for testing. I'm sure some would be surprised by the achievements made thus far."
This discussion has been archived. No new comments can be posted.

The D Language Progresses

Comments Filter:
  • What is D? (Score:5, Informative)

    by Anonymous Coward on Sunday January 12, 2003 @01:12AM (#5065294)
    What is D?
    D is a general purpose systems and applications programming language. It is a higher level language than C++, but retains the ability to write high performance code and interface directly with the operating system API's and with hardware. D is well suited to writing medium to large scale million line programs with teams of developers. D is easy to learn, provides many capabilities to aid the programmer, and is well suited to aggressive compiler optimization technology.
    D is not a scripting language, nor an interpreted language. It doesn't come with a VM, a religion, or an overriding philosophy. It's a practical language for practical programmers who need to get the job done quickly, reliably, and leave behind maintainable, easy to understand code.

    D is the culmination of decades of experience implementing compilers for many diverse languages, and attempting to construct large projects using those languages. D draws inspiration from those other languages (most especially C++) and tempers it with experience and real world practicality.

    Why D?
    Why, indeed. Who needs another programming language?
    The software industry has come a long way since the C language was invented. Many new concepts were added to the language with C++, but backwards compatibility with C was maintained, including compatibility with nearly all the weaknesses of the original design. There have been many attempts to fix those weaknesses, but the compatibility issue frustrates it. Meanwhile, both C and C++ undergo a constant accretion of new features. These new features must be carefully fitted into the existing structure without requiring rewriting old code. The end result is very complicated - the C standard is nearly 500 pages, and the C++ standard is about 750 pages! The reality of the C++ compiler business is that few compilers effectively implement the entire standard.

    C++ programmers tend to program in particular islands of the language, i.e. getting very proficient using certain features while avoiding other feature sets. While the code is portable from compiler to compiler, it can be hard to port it from programmer to programmer. A great strength of C++ is that it can support many radically different styles of programming - but in long term use, the overlapping and contradictory styles are a hindrance.

    It's frustrating that such a powerful language does not do basic things like resizing arrays and concatenating strings. Yes, C++ does provide the meta programming ability to implement resizable arrays and strings like the vector type in the STL. Such fundamental features, however, ought to be part of the language. Can the power and capability of C++ be extracted, redesigned, and recast into a language that is simple, orthogonal, and practical? Can it all be put into a package that is easy for compiler writers to correctly implement, and which enables compilers to efficiently generate aggressively optimized code?

    Modern compiler technology has progressed to the point where language features for the purpose of compensating for primitive compiler technology can be omitted. (An example of this would be the 'register' keyword in C, a more subtle example is the macro preprocessor in C.) We can rely on modern compiler optimization technology to not need language features necessary to get acceptable code quality out of primitive compilers.

    D aims to reduce software development costs by at least 10% by adding in proven productivity enhancing features and by adjusting language features so that common, time-consuming bugs are eliminated from the start.

    • Re:What is D? (Score:5, Insightful)

      by -strix- (154910) on Sunday January 12, 2003 @01:21AM (#5065335)
      I understand the goal of D, but personally I like the idea in C and C++ where the base laguage is simple (especially C) and all the complicated stuff is in libraries. It makes it easy to get started with the language and learn the more powerful stuff as its needed. It seems to be the goal of D to toss a bunch of stuff in the language itself and let the programmer sort it out. I could imagine it being a real pain for a new programmer to learn a language like that.
      • Re:What is D? (Score:2, Interesting)

        by russellh (547685)
        I understand the goal of D, but personally I like the idea in C and C++ where the base laguage is simple (especially C) and all the complicated stuff is in libraries. It makes it easy to get started with the language and learn the more powerful stuff as its needed. It seems to be the goal of D to toss a bunch of stuff in the language itself and let the programmer sort it out. I could imagine it being a real pain for a new programmer to learn a language like that.

        A language feature is an assumption about the problem domain. Perl for instance has great regex capabilities built right in; C++ doesn't. Doing text manipulation in C++ is harder and although one can get libraries to do everything, it is not native to C++ and therefore requires significantly more code.

        A key C++ assumption is that one may wish to do OO programming. This is much easier in C++ than in C, if only from a syntax standpoint; pointers to functions in various structures are painful and illogical in C, whereas in C++ there is essentially no need for them given the classes, inheritance, polymorphism built into C++. This is not library functionality. So if you want to do OO programming, you start with C++ and not C. If you want, say, auto memory management (but no VM), maybe you go download a C++ garbage collector, or maybe you consider D.

      • Re:What is D? (Score:3, Interesting)

        by aminorex (141494)
        When the functionalities in question are basic
        functions of any utile development environment,
        I have to disagree. Java is enormously simplified
        by integrating thread handling and synchronization
        into the language itself. Would you rather
        write regex code in Perl or in C? Associative
        arrays, likewise. I think the choices made were
        good ones, in this regard.
      • Re:What is D? (Score:5, Insightful)

        by SecretAsianMan (45389) on Sunday January 12, 2003 @02:24AM (#5065535) Homepage
        I like the idea in C and C++ where the base laguage is simple (especially C)

        While I won't dare disagree with you on C, C++ is not simple! Perhaps you should read a little more about it to understand. Things I personally object to in C++ are:

        • The multiple casting notations: ( type ), foo _case< type >
        • Excessively arcane template system
        • Every design-of-syntax error listed in the D site's overview
        • Retarded naming scheme, small size, and wierd design of standard library. The damn thing's almost useless.
        So basically, C++ is anything but simple. It's a big, bloated monster and is loaded with nasty cruft.

        One final bitch: I want the person pulled into the street and shot who was responsible for the font used in the Stroustrup C++ book's code examples. Who the hell writes code in an italic, proportional, serif font?! The only thing more painful than programming in C++ is reading about programming in C++.

        • Re:What is D? (Score:4, Insightful)

          by be-fan (61476) on Sunday January 12, 2003 @02:35AM (#5065562)
          Retarded naming scheme, small size, and wierd design of standard library. The damn thing's almost useless.
          >>>>>>>>
          I love the C++ STL naming scheme. Nice and concise, but still clear and memorable. Java and many other languages suffer far too much from name bloat. And the C++ STL is probably one of the last things a C++ programmer really understands, and it can be years before people truely appreciate the power of the STL.
      • by the_Speed_Bump (540796) on Sunday January 12, 2003 @04:18AM (#5065801) Homepage
        It seems to be the goal of D to toss a bunch of stuff in the language itself and let the programmer sort it out. I could imagine it being a real pain for a new programmer to learn a language like that.

        Sounds an awful lot like C++ to me. C++ is a mish-mash of C, and everything that entails, object oriented programming constructs, and a standard library that is often quite functional in nature. The syntax is convoluted (due in no small part to templates) and the compilers are convoluted beyond human reason.

        Don't get me wrong, I love C++'s sheer semantic flexibility, but if you've ever done anything in C#, Java, or Python, it becomes clear just how long it takes to get stuff done in C++. (and it becomes apparent how annoying the Java OOP obsession can be ;)
      • by fygment (444210)
        "I could imagine it being a real pain for a new programmer to learn a language like that."

        D isn't for beginners. It's for intermediate to advanced programmers of medium to large programs. Read about it here:

        http://www.digitalmars.com/d/overview.html
    • by macrom (537566) <macrom75@hotmail.com> on Sunday January 12, 2003 @02:16AM (#5065510) Homepage
      D aims to reduce software development costs by at least 10% by adding in proven productivity enhancing features and by adjusting language features so that common, time-consuming bugs are eliminated from the start.

      You know, the above little blurb had me going until this statement. For Chrissake, why don't you just prefix it with "The following marketing fluff statement was divined specifically so non-technical, pointy-haired managers could force yet another programming language on already overworked developers." I would have expected more from computer scientists than this. How is the world can you design a programming language, assume that it will automatically meet my needs, then assume that it will reduce my costs for development, which are completely unknown to you? I'm afraid in this case, ASSUME makes an ASS out of U and not me.

      I mean, you'll never hear (nor have you heard in the past) Bjarne claiming that C++ will solve your development ills. Hell, I don't even think Microsoft has claimed that C# will reduce your costs by a specific amount.

      Wait...what did you say? The D programming language will get me laid? Not laid off? Where's that compiler again...?
      • Re:What is D? (Score:3, Insightful)

        by HiThere (15173)
        The blurb does sound strange, but read the specs and see if you don't think it a reasonable guess. If you don't, then this isn't the langugage you want, obviously.

        Personally, I think it may be conservative. My only qualm is with linking to other languages like Java, Python, and Ruby. Everything seems to depend on C routines to manage the interlanguage calling.
    • A D text referencing C++ states: It's frustrating that such a powerful language [C++] does not do basic things like resizing arrays and concatenating strings[snip], however, ought to be part of the language.

      The C/C++ languages are written by programmers for programmers. They are base-level for a reason and successful at what they are meant for. I haven't read all the info about D, but I'm going to go out on a limb and assume that D is probably written in C/C++ or at least partially. So that would be one good reason not to discredit C/C++ in favor of D.

    • well, the d is tenacious of course, the ragekage show!

    • Where is Algol68? (Score:4, Interesting)

      by Anne Thwacks (531696) on Sunday January 12, 2003 @08:22AM (#5066188)
      Algol68 is what we want/need.

      Algol68 does all the things claimed for D, and more (Including support for threads). Designed and tested 30 years ago, it only died because it was not invented by IBM, who, at that time, were the power that M$ is today. And the books about it were printed in decent fonts :->

      Come on all ye compiler-writers, and give us an Algol68 compiler (preferably will support for NetBSD on Sparc :-)

  • by aerojad (594561) on Sunday January 12, 2003 @01:15AM (#5065305) Homepage Journal
    Before C came B, before B came A, and after C came C++, ++ meaning +1, or in other words, D. So if the next language is D does C++ become C 1/2? or C.5? ...someone had to sacrifice the karma to say it
    • by autopr0n (534291) on Sunday January 12, 2003 @01:17AM (#5065318) Homepage Journal
      The next language should be named C+=2!
      • Nooooooo!

        Until the language becomes more popular and depending on the stability, etc.. it should be C/=0 !!

        But then again, it could have been called E, but that letter on it's own might have evoked images of a certain little pill... remember Intel upheld it's PC (political correctness, not personal computer) brigade when they decided to "re-number" the 666Mhz P3 chip as being 667Mhz (AFAIK) so you can never tell with companies these days.

        Oh well, at least *nix creators had a sense of humour when creating commands so that you could "finger user" ;-)

    • Thought there already was an E, for the amiga. A scripting language or something?

      Off-topic: C.5 sounds cool. When I design a C knockoff language with ill-considered features, I think I will call it this, with your permission. There aren't nearly enough C-based programming languages that use C in the name, if you ask me. C/C++/ObjC/C# and the best of all, C.5!
    • silly geek, it depends what C was initialized to

    • Actually, the Camel book says that it all started with BCPL.

      The next language was simply B, and after that, C. No-one knows whether the idea was that C came after B in the alphabet or that it came after B in "BCPL", but C++ dodged the issue with a neat play on the auto-increment operator.

      Perl takes up the last two letters and settles the issue. There should be no-more BCPL derivatives! :)

    • by tfinniga (555989) on Sunday January 12, 2003 @02:00AM (#5065457)
      Actually, C++ is being post-incremented, so this iteration C++ is the same as c, but next time around it'll be great!
    • Uh... NO! (Score:2, Redundant)

      by kzinti (9651)
      C++, ++ meaning +1, or in other words, D

      Since when does the ++ operator increment the variable name and not its value? Duh?

      --Jim
    • IIRC, there already is (well, was) a C-variant called "E". It had most of the features of C++, with one change: persistent variables. I can't recall the specific method for declaring the variables to be persistent, or the mechanisms for storing the data.

      Anyway, this was about 10 years ago, and my memory isn't what it used to be.
  • by ObviousGuy (578567) <ObviousGuy@hotmail.com> on Sunday January 12, 2003 @01:18AM (#5065320) Homepage Journal
    The D language is a language looking for a niche. It needs a pretty hefty runtime to support all the features that it exposes. It duplicates so many features of C++ that it's indistinguishable at first glance. And it is far from complete.

    They could have saved themselves the trouble and waited for Microsoft to implement C# (which is lightyears ahead of D as far as implementation goes).
    • While the implementation of C# is ahead, its
      design is considerably behind the curve in terms
      of simplicity. The elegance of D lies in the
      ease of acquiring the necessary skills for
      doing serious development. C# is so intimately
      intertwined with the .NET framework, complicated
      by its runtime and complilation model, that
      it takes one heck of a lot more work to get to
      the point where you can do serious development.

      Of course, once you've done that work, you can
      leverage a lot of implemented runtime -- but you
      can do that with D as well, to the degree that
      the D implementation is mature.
      • The elegance of D lies in the ease of acquiring the necessary skills for doing serious development.

        Yeah...substitute 'Java' for 'D.'

        Seriously though...the author states in the documentation:

        D is not a scripting language, nor an interpreted language. It doesn't come with a VM, a religion, or an overriding philosophy. It's a practical language for practical programmers who need to get the job done quickly, reliably, and leave behind maintainable, easy to understand code.

        however:

        The general look of D is like C and C++. This makes it easier to learn and port code to D.

        but then:

        Realistically, nobody is going to convert million line C or C++ programs into D, and since D does not compile unmodified C/C++ source code, D is not for legacy apps. (However, D supports legacy C API's very well.)

        So what is it for then? Why do we need it? Of course, not to disparage creating a new language for kicks, but in the interest of actually trying to convince people to use it in the real world...why?

  • What is D? (Score:2, Insightful)

    by Jason1729 (561790)
    From the article, it sounds like it's C++ with the spec tightened up. If that's true, isn't this just another C++ compiler and not a new language?

    Even the sample program looks like it will run in and C++ compiler, so where is D different?

    Jason
    ProfQuotes [profquotes.com]
    • Re:What is D? (Score:2, Interesting)

      by pstemari (579210)
      Plenty of differences, bringing across a number of restrictions from Java: No MI, No auto (i.e. stack-based) objects, etc.

      Of course, eliminating auto objects means that the metaphor of resource allocation is initialization carries the same fatal flaw as Java--resources will not be released until the GC runs, and the GC doesn't know about anything like file handle limits, critical hardware resources, database transactions, and the like.

  • by Quaoar (614366) on Sunday January 12, 2003 @01:19AM (#5065322)
    Now I can just tell my mom that my grade in computer programming is actually just the name of the course...she'll never suspect!
  • by sunwukong (412560) on Sunday January 12, 2003 @01:19AM (#5065326)
    Me: Boss, I think building our app with the D language will put us a step ahead of our competitors!

    Boss: "D?" What happened to C? Or that other one, C++, that you're always harping about?

    Me: Well, D is a further refinement of C++, and ...

    Boss: Weren't you just telling me that "J" language was supposed to be the next big thing? Isn't J further along than D?

    Me: Yes and no ...

    Boss: And if only want to make small changes, is a "+" higher than a "#"?

    [suddenly, a shot rang out]
  • by long_john_stewart_mi (549153) on Sunday January 12, 2003 @01:20AM (#5065332)
    "The D Language: It's C! With Implants!"
  • by Anonymous Coward
    If not, it's obsolete already.
  • by gothamNY (473289) on Sunday January 12, 2003 @01:22AM (#5065338)
    As soon as they get to F, which I am intimately familiar with, I might pick it up..
  • Contracts (Score:4, Informative)

    by The Bungi (221687) <thebungi@gmail.com> on Sunday January 12, 2003 @01:25AM (#5065347) Homepage
    Nice to see contracts [digitalmars.com] were added to D. They are one of the cooler things in Eiffel. And I'd wish they would have added them to C#.

    And of course, generics [digitalmars.com].

    Now all it needs is some community support and ECMA goodness. I think it has a good chance of being widely used.

    • Re:Contracts (Score:3, Interesting)

      by __past__ (542467)
      Contracts in D seem to suffer from the problem that the language doesn't have a way to enforce that pre- and postconditions are side-effect free. Given that the conditions won't be executed in "production" code, this may introduce ugly heisenbugs itself, when the correctness depends on some (accidental) changes made in the conditions - bugs that are not reproducible in debug mode.
  • Golly (Score:2, Insightful)

    by xagon7 (530399)
    Aside from the garbage collector and foreward declarations..

    1. interfaces instead of multiple inheritance

    2. Cross platform (somewhat at the moment)

    3. compiled and the ability to go down to assembly

    4. use of try..finally and try..except exception handling. ...damn ...smells like Object Pascal (Delphi) to me..except with "{" instead of "begin"
  • A Religion (Score:5, Interesting)

    by bahwi (43111) <incoming.josephguhlin@com> on Sunday January 12, 2003 @01:27AM (#5065353) Homepage
    "It doesn't come with a VM, a religion, or an overriding philosophy."

    Not a religion? Neither was C. Neither was Java. Neither was C++. Neither was vi. Neither was Emacs. I think we all know where this is going and that that statement should be considered pure FUD. And a new language covered in FUD is not a good thing, even if it look like a good thing(tm).
    • And a new language covered in FUD is not a good thing

      My memory fails me at the moment... I can't recall a language that doesn't have an associated Jihad, Syntax Crusaders, Grammar Flame Corps and a comp.lang.?.advocacy or similar Usenet newsgroup.

      I think what he means is that he's not trying to fight anyone, he's not hyping it and he's not interested in any of those things.

      But as with most languages, eventually it will gain a following and corresponding showdowns at the Usenet Corral. I think there's a Murphy Axiom that covers this.

    • I know your point is that none of these were intended to be a religion, just ended up that way. I think Emacs might not quite fit that. Stallman wrote Emacs as the essential first tool in the quest to make the HURD a full OS that could compete and eventually replace UNIX. Granted, a lot of the religion that grew up with EMACS was more functionality and scriptability (and the accompanying bloat) vs. vi, but there was a religion nonetheless.
  • now where are the library functions?

    One of the changes since the last time we heard about D is the addition of floats and doubles (32 bit and 64 bit floating-point types, respectively) in addition to the "extended" type (as much precision as available). This is absolutely a Good Thing -- extra precision can be just as bad as insufficient precision, and adding these types allows people to ensure that they're using the right precision.

    It would have been really nice to see the same thing for the math library functions; as it is, the only sin function is an extended -> extended function. IEEE doesn't require determinism on transcendental functions the way it does for arithmetic functions (which, I'm guessing, is why it isn't provided here), but there are times when it would be quite helpful.

    Remember, there are times when getting the right wrong answer is more important than getting the right answer.
      • One of the changes since the last time we heard about D is the addition of floats and doubles (32 bit and 64 bit floating-point types, respectively) in addition to the "extended" type (as much precision as available). This is absolutely a Good Thing -- extra precision can be just as bad as insufficient precision, and adding these types allows people to ensure that they're using the right precision.
      This is very x86-centric. Most RISC CPUs don't have an extended precision, and some super computers have multiple extended precision modes. x86s are rather unique in their support of exactly one extended precision mode. Oh yeah, and older ARM and x86 processors don't even have FP built-in. So much for "portable".

      • It would have been really nice to see the same thing for the math library functions; as it is, the only sin function is an extended -> extended function. IEEE doesn't require determinism on transcendental functions the way it does for arithmetic functions (which, I'm guessing, is why it isn't provided here), but there are times when it would be quite helpful.
      The reason the IEEE 754 standard does not specify exactness for transcendentals is because there are no provably known finite algorithms for computing them. It is even very difficult to state the bound for how many steps are required for any non-trivial finite set of inputs without computing them all.

      The IEEE 754 standard makes the choices which delivers as much as is possible within reasonable practical limits. When the Java committee foolishly tried to establish their own FP standard ... well, you can read about it here [syr.edu] -- once explained, the Java committee backed down and adopted IEEE 754.

      I believe the D guy has probably taken this lesson to heart but probably overstepped by considering the x86 model as the most legitimate model.
  • by g4dget (579145) on Sunday January 12, 2003 @01:32AM (#5065373)
    Creating object instances on the stack. In D, all class objects are by reference. This eliminates the need for copy constructors, assignment operators, complex destructor semantics, and interactions with exception handling stack unwinding. Memory resources get freed by the garbage collector, other resources are freed by try-finally blocks.

    The reason why C++ is so popular nowadays for numerical, engineering, graphics, and scientific applications is that it supports value classes: classes allocated on the stack, passed around by copying, and represented without any additional overhead. They are used for things like points, points with small coordinate ranges, vectors, 3D rotation matrixes, rectangles, and lots of other types. I don't believe any systems or applications language for which efficiency is a consideration can do without them.

    Why the creators of D think that providing value classes is a problem, I don't understand. Sure, C++ fell all over itself with initializers, but lots of other languages have managed just fine. Pascal has value classes, and so does C#. JavaGrande recognized the lack of value classes as one of the biggest deficiencies in the Java language.

    And it's not something a compiler can just optimize automatically, no matter how good it is: the use of value classes has user visible effects on interfaces and data structures.

    • I don't know much about D, but if it supports structs, isn't that essentially the same thing as a value class (save the instance methods and such)?

      I personally prefer passing pointers instead of having to remember if the object is being copied behind the scenes or is the original object because I used an ampersand (pass by reference). If I wanted to make a copy, I'd call the "copy" instance method and poof, one has a copy. If I'm worried about my objects being changed, then just make the object immutable.

      But that's just me,
      F-bacher
    • by macshit (157376) <miles@g[ ]org ['nu.' in gap]> on Sunday January 12, 2003 @02:13AM (#5065502) Homepage
      Why the creators of D think that providing value classes is a problem, I don't understand.

      `Value classes' as you term them, amazingly complicate the language; they're one of the reasons that C++ is such a ball of hair.

      If you've got GC, then a reference-only design is a lot simpler. Whether this results in a lot of inefficiency is something of a controversial (in general; I guess that in fields such as embedded/real-time systems systems, perhaps less so).

      However it's clear that many people think that `value classes' are `needed for efficiency,' so arguably they were necessary simply to convince a skeptical and conservative (in the real sense, not the political sense!) audience to switch to C++.
    • Why the creators of D think that providing value classes is a problem, I don't understand.

      Providing what you're calling "value classes" isn't a problem. Nor is providing polymorphic behaviour with virtual functions. However, combining the two is a problem, and probably a top-5 cause of bugs in C++ programs.

      As an aside, the term "value class" is slightly misleading, IMHO. I suspect what you mean is a class that can be stored in-place and accessed without indirection via a pointer, which isn't necessarily the same: you could implement value semantics quite sensibly for a class that is really always accessed via a (hidden) pointer. It would look the same in code, but the implementation would have the same increased flexibility and performance penalty assoicated with pointers to base classes and the like in today's C++.

      Why they couldn't make structs a simple value type that didn't allow virtual methods, and classes a full-blown object type that always looked up a v-table before calling (even if it appeared to have identical value/reference semantics to a struct otherwise) I'll never know. That way, you could have most common uses available trivially, but guarantee safety without nasty things like slicing going on.

      (Yes, yes, some classes have some virtual and some non-virtual methods, and you call the non-virtual ones a lot, so you'd take a performance hit making all of them virtual. However, falling back on the old-but-still-true cliche, this is almost always indicative of a misjudged design, IME. If you took away the ability to do it -- in exchange for removing some of the more horrible behaviour you can inadvertently get in C++ -- then people would simply design around it, with no great loss of expressive power than I can see.)

      And he's wrong about removing the need for copy c-tors and assignment operators, of course (as he is about several other things he wants to change, such as the need to differentiate between . and ->, which breaks down in data structures that use more than one level of indirection). Fundamentally, you can copy a reference/pointer/other indirection to an object, or you can duplicate its value (whatever that means in context). If you choose to make the = operator of your language do the reference one, you just wind up needing a clone() method of some sort for the other case. It might have a different name, but it's still there.

  • by jpt.d (444929) <abfall@NOSPam.rogers.com> on Sunday January 12, 2003 @01:47AM (#5065422)
    Maybe off topic, but 'yet another language'? Where c++ may do too much: Templates Operator Overloading Go back to a simpler time... then giveth objective C! It has the 'named' parameters (in its own way), arbitrary message handling (methods to everybody else), hell even a traceback! Not even java has operator overloading, there maybe a reason.... (reduce ambiguity?) We need simpler languages, not progressively 'general purpose' languages... a 'CISC' language vs. 'RISC' lange... Objective C is just that... simple.
    • D has usable associative arrays and regex built in.
      D is capable of running fast. D doesn't weld
      two alien syntagma into one rough beast.
    • Hallelujah! Hallelujah! Praise the Obj-C!
    • by Anonymous Coward
      I realize that you Mac zealots were just recently introduced to Objective-C and all, but it's really not that impressive. If you really want linguistic simplicity why don't you just use Smalltalk? Why all of those senseless complexities of C? Why not all of the reflective and introspective power of Smalltalk with the simplicity of garbage collection, transparent persistency, and perhaps one of the easiest languages ever created?
      If you're going to go for the slow-ass dispatch of Objective-C methods, you might as well just leverage decades of optimizing VM work and get blocks and all of the other powerful concepts ignored by Objective-C.
  • by MichaelCrawford (610140) on Sunday January 12, 2003 @02:01AM (#5065463) Homepage Journal
    A friend of mine at CalTech named Mike Roberts created a language called D when he was in high school, because his parents wouldn't shell out for a BASIC compiler for his DOS PC. We were both in the high school class of '82 so this would have been around '81 or so.

    Unfortunately, his original D compiler was written in BASIC, which he ran interpreted, so compilation was slow. In order to speed up the interpreter, he used the sort of "source code compression" that is illustrated at Chuck's Power Koding [wpi.edu] - removing any unnecessary spaces, using long source lines and having as few actual lines as possible.

    (This kind of ancient interpreter didn't use byte codes - if you looped ten times, you'd parse the loop's source code ten times!)

    We suggested that he rewrite his D compiler in D so he could get it to compile faster. He decided to do that, and worked really hard at it but got it working after some time.

    As a complication he improved the language, but it meant that his old compiler wouldn't compile the newer kind of D code. I think what he did was make two revisions of the D-written compiler, one written in the old syntax that would understand the new, but could be compiled by the BASIC version and then an update that was written in the new D that could compile itself.

    It was a sort of mix of Pascal but with lots of convenient stuff like BASIC string handling mixed in. I don't think the language would have made any computer scientists happy - D was designed to suit Mike's personal style.

    He used it at first to write an Adventure-style game (a text adventure) that he and another friend designed.

    Later he wrote a text-adventure compiler, where he could write a specification file for a text adventure, process it, and an executable file for a text adventure would be generated.

    He didn't have to get a real summer job because he was selling these generated games to game software publishers!

    Mike was an amazing programmer. He taught me a lot of what I knew about C and x86 assembly early on.

    This was all on 640 kb 8088 DOS PC's that were outfitted with whizzy 10 MB hard drives. The students in the computational physics lab were expected to use the hard drives only during class, and to store their personal files on floppy when we weren't actively working at the PC's.

    So his D language compiler would fit on a floppy. The old 5 1/4" inch kind, that really flopped. I think they stored 360kb.

    I wonder whether we would all be better off if programmers designed their own personal languages just to suit their own personal styles. Yes, there would be portability problems but wouldn't we be more productive?

    I got my own chance to hack a whacky compiler. This was a team effort though and I was just a contributor. Star Sapphire Common Lisp [webweasel.com] manages to run a complete common lisp environment with MicroEmacs on a 640kb DOS 8088 PC.

    The way it does that is by swapping to an 8 MB backing store file. But the 8088 doesn't have an MMU, you say? That's right - we operated the virtual memory manually, by writing C code that would explicitly get or put each lisp cons from or into the VM system with a function call.

    It made it ... interesting ... to operate on complicated data structures. I designed the implementation of the lisp scoping rules, among other things.

    Oh yeah, and I was the source code control system and project manager. We didn't have a network - networks were way too expensive in 1986. What I did was wait until late when all the other programmers went home, copy the changes off all their machines onto floppy, integrate them on one machine and then copy the new release onto everyone's PC.

    Kids these days. Don't know when ya got it good.

    • (Goingware? Hey, I remember you from BeOS days.) I'm guessing this is the Mike Roberts of TADS? I bought that program when it was shareware--and never really got around to finishing the text adventure I wanted to write with it, although that wasn't the language's fault. It was really well-designed.
      • Yeah, that's me from the BeOS days.

        I haven't booted BeOS in a while but I'm about to, to hopefully help roll out a new release of ZooLib [sourceforge.net] soon.

        I would also like to add support for BeOS PowerPC to ZooLib, but probably won't for this release. It doesn't work with my PowerLogix CPU upgrade, but you can still get Newer Technology CPUs that are supposed to work.

        I'm still using the 8500 I used to port Spellswell to the BeOS. I'm typing into it right now in fact. But mostly these days I run Debian on it. I managed to install OS X on it, but it doesn't work too well. For OS X I have an iBook.

        I don't recall what Mike's text adventure compiler was called, but what you describe sounds like it.

        I have lost touch with Mike over the years.

  • by SAN1701 (537455) on Sunday January 12, 2003 @02:04AM (#5065474)
    As I recall...

    Dilbert: No! C is not the grade of the project. It's the programming language I'll use on it.

    PHB: (After a few seconds) OK. But why don't you program at least with B?
  • by DarthWiggle (537589) <[sckiwi] [at] [gmail.com]> on Sunday January 12, 2003 @02:05AM (#5065476) Journal
    You know, I've spent a lot of time thinking about the proliferation of languages. We have Assembly. We have C. We have C++. We have Java. We have Cold Fusion, PHP, and ASP.NET. We even have iHTML or whatever that bastard offspring of HTML was called.

    What's the purpose of creating entirely new languages? Is a new language even entirely new, or is it an evolution of older languages incorporating new concepts and methodologies? Or is the creation of a new language just a way of leaving a mark? Or, even worse, is it a manifestation of that damnable desire to start from scratch every time? (I'm afflicted by it... most coders I know are afflicted by it...)

    Here's what I'd like to know, in my limited knowledge of languages: What languages out there are truly modular? Are there any languages that encompass basic logic principles and which are then able to be augmented by blackboxed modules? So, if you had a language that needed string concatenation, you could whip up a string concatenation module that would then become part of the language.

    Now, I'm walking a semantic line here, because you can presumably do all that by writing header files, includes, classes, etc. that contain new logic within the structure of the language. But what I mean is a language that by its nature is abstracted and modular, even to the point where the syntax of, say, control structures could be modified in a module?

    And, if the answer to my question is "Well, hell, you can do that in C!" then why do we need to bother writing a new language? Is it just to keep things fresh and interesting?

    It just seems that with all the many languages I've learned and used, there's very little that I can think of that one language can do that another language can't. Where doing something in one language is harder than in another because the structure of the language makes it awkward, maybe that points to a language that needs to be made obsolete.

    I guess the root question I'm asking is: Are there any truly novel languages out there, or are they all just variations on a common theme, with shared shortcomings and much duplication of effort?

    Be gentle. :)

    • by aminorex (141494) on Sunday January 12, 2003 @02:36AM (#5065566) Homepage Journal
      There are three fundamentally good reasons to design
      a new programming language:

      (1) A new model of computation or machine. Lisp,
      Prolog, Algol, Forth, SNOBOL, ML, BLISS-32,
      APL, SETL, Parallation Lisp, Smalltalk, Self
      are examples.

      (2) A new kind of progamming methodology or
      application domain. Bourne/Korn shell, Perl,
      C++, Eiffel, Sather, Logo, PHP are examples.

      (3) Incremental improvement derived from
      practical experience. Java, C#, Kylix/Delphi,
      Visual Basic, Haskell, D are examples.

      Each of these can make serious contributions to
      the state of the art. The innovations of the
      first type are more fundamental, more profound,
      but also more academic in nature, and take some
      time to provide practical improvements in the
      art of practice. Those of the second and third
      kind can provide more immediate and accessible
      improvements in reliability, productivity, and
      feasibility of practical development.

      Yes, there is a tendency to create vanity
      languages. If D ever was that, it has progressed
      far beyond, if a half-hour's reading has not
      deceived me regarding it's design. Whether it's
      implementation has or will ever have progressed
      to the point where it can fulfill its potential
      as an innovation of the third kind... I just don't
      know.

    • by coreyb (125522) <coreyb.j2t@cjb@net> on Sunday January 12, 2003 @04:17AM (#5065794)
      Well, once you have a language that is Turing-complete, it can do anything that any other Turing-complete language can do. Basic theorem of computer science (in the sense as a field of mathematics). And there aren't any languages (that I know of anyway) that are more than that, so yes, all languages are variations on a common theme in that anything you can do in one, you can do in another. It comes down to the question of which one is better for the task at hand.
    • by nels_tomlinson (106413) on Sunday January 12, 2003 @01:42PM (#5067199) Homepage
      Here's what I'd like to know, in my limited knowledge of languages: What languages out there are truly modular? Are there any languages that encompass basic logic principles and which are then able to be augmented by blackboxed modules? So, if you had a language that needed string concatenation, you could whip up a string concatenation module that would then become part of the language.

      Lisp.

      Now, I'm walking a semantic line here, because you can presumably do all that by writing header files, includes, classes, etc. that contain new logic within the structure of the language. But what I mean is a language that by its nature is abstracted and modular, even to the point where the syntax of, say, control structures could be modified in a module?

      Lisp.

      I guess the root question I'm asking is: Are there any truly novel languages out there,

      Lisp.

      or are they all just variations on a common theme, with shared shortcomings and much duplication of effort?

      Everything else.

  • Sounds great... but are there actually any real project written in D ? I don't see any links anywhere to substantial projects written in this language. If it debuted a year ago, you would think there are at least a few projects...
  • And that would be a compiled language with Ruby-style syntax and programming model.

    Implementing things in Ruby is really fast, and what makes it fast are the objects and blocks. I really don't understand why so few new languages have efficient block-handling (to allow nice and easy-to-write visitor partterns and things like that).

    I wrote a small application server few my website (with it's own HTTP implementation and all) initially in about 10 hours while just learning Ruby. The downside is that Ruby is a bit slow.

    Well, fortunately this is free world, and I can still dream of doing a compiler for a Ruby-style language in the future.

    • It would be wonderful to have a Ruby compiler...
      But I'm not sure it's possible to compile a language as dynamic as Ruby where you can:
      - add methods to objects or classes at runtime
      - Do things like conditional inheritance or conditional mixins
      - mixin modules to objects or classes at runtime (extend)

      Ruby is extremely dynamic... I'm not sure how you compile something like that down to static object code...
  • by Animats (122034) on Sunday January 12, 2003 @02:51AM (#5065606) Homepage
    D is interesting, but it's conceptually close enough to Java that it's not likely to get much traction. Because it's garbage-collection based, you can't use D for low-level programming.

    C++ needs an overhaul; the cruft has gotten too thick. But, sadly, D isn't it.

    Walter Bright is a good compiler writer; he did the Zortech C++ compiler, years ago. So D is not a paper language.

    • Because it's garbage-collection based, you can't use D for low-level programming.

      Errr, sorry? Why not? I learned my trade on computers which ran LISP right down to the bare metal, with incremental GC. Dammit, the fist WIMP interfaces and the first Ethernet (among other things) were developed on those machines, and, lets face it, a Xerox 1186 in 1986 with 4Mb of core and 80Mb of disk ran complex WIMP programs better and faster than MS Windows does on 2GHz pentium boxes now.

      There's nothing wrong with writing low-level stuff in a GC language, although it may be necessary to mark bits of code with a pragma saying don't GC while you're doing this (which is, after all, much what an interrupt routine does on more conventional architectures).

  • D == Java? (Score:5, Interesting)

    by hebble (35128) on Sunday January 12, 2003 @03:00AM (#5065632)
    1. No multiple inheritance
    2. All objects accessed by reference on the heap
    3. Not source-compatible with C
    4. No namespaces
    5. All member functions are virtual (unless the compiler figures out they don't have to be)
    So basically, we'll still need C++ for a bunch of things. At least it's got templates, I guess.

    Also, it's a bit funny that the preprocessor is mentioned twice under "Features to Drop." This guy must really hate the preprocessor. :)

  • After C/C++ give me C# before D.
  • D# (Score:4, Funny)

    by CySurflex (564206) on Sunday January 12, 2003 @03:34AM (#5065717)
    Company Press Release

    REDMOND, WA 10:39PM PST - Microsoft Corp is pleased to announce our new state of the art language, D# . Additionaly, Microsoft is anouncing our own VM which will run regular D code plus our own set of WDE (Windows D Extensions) which will improve the usability of D and decrease development times. Microsoft corp would like to stress that there will be a D-VM for other platforms soon (within 20-30 years).

  • by JeanBaptiste (537955) on Sunday January 12, 2003 @03:44AM (#5065733)
    B is all you should need to write a good app. C++ with that newfangled OOP, but that was too hard so now they have this 'D'... whatever happened to pascal anyways?

    Why back in my day, I would write b++ code on my 25lb laptop while trudging through the snow on my way to the coal mine (uphill both ways). And I thought I had it easy! My dad used to 'program' with oscilloscopes and huge racks of patch cables (actually thats true) when punch cards came out he thought that was the best method that would be for a while... All you young curmudgeons with your D this and visual that and open source hullabaloo. Twenty three skidoo to all of you!
  • I haven't seen any development in a while, but Connective C++ is a rather interesting language, reminds be of VeriLog sorta, but compatible with C and C++ source (being a C++ extension)

    check it out [quintessent.com]
  • by Scotch Game (442068) on Sunday January 12, 2003 @04:02AM (#5065759)
    Eh. The way I see "D" is this:

    C++ was alone for the night when Eiffel stopped by, noticing C++ was by itself, "just for a few drinks". Well, things started to get out of hand and just then Java walks in. Tense moment. Awkward silence. But to C++'s relief, Java joins in.

    Well, as luck would have it, Java gets pregnant but the three of them have found they really enjoy each other's company, they balance each other out in certain areas, so they buck convention and all move in together and raise the kid under an "alternative" family, and hey, there's nothing wrong with that. They call their kid D, and while he's still young and has a lot to learn, he's got features, interfaces, delegates and assertions built in. He might just turn out all right after all.

    Watch for the movie, starring Richard Gere as C++ (he's older and has a rumored past, but he'll give the rest of the case a few pointers), Catherine Zeta Jones as Java, and Renee Zellweger as Eiffel (she's hot, but underappreciated). Lil' Bow Wow will guest star as D.
  • I don't see any features that would enable the use of functional programming techniques. I don't see any mention of function pointers or overloading (), so how does he expect to write, for example, a general sorting function? (i.e. Sort array a of strings case insensitively)
  • by Kupek (75469) on Sunday January 12, 2003 @04:18AM (#5065800)
    A lot of the comments in the Overview I find to be either unverifiable conjecture, or just plain silly. A sampling:
    • C++ programmers tend to program in particular islands of the language, i.e. getting very proficient using certain features while avoiding other feature sets.
    • A great strength of C++ is that it can support many radically different styles of programming - but in long term use, the overlapping and contradictory styles are a hindrance.
    • It doesn't come with a VM, a religion, or an overriding philosophy.
    • D aims to reduce software development costs by at least 10% by adding in proven productivity enhancing features and by adjusting language features so that common, time-consuming bugs are eliminated from the start.
    The first two I am not able to counter at all - I simply don't have the experience. I don't know if he does, either, so I don't buy it. The last... why 10%? Why not 11%, 15%, or 11.38%? It just seems silly.

    As for philosophy, every language has a philosophy. D adheres to the object oriented paradigm - that's a philosophy. Beyond that, it seems to me that it tries to attain simplicity in use while trying to force good programming standards. That's most definitely a philosopy.

    I've read a bit about the language itself, and I am interested in the unittest and contracts in particular. Those features would be great additions to any language, I think.

    But I don't see a need for the language itself. It seems like Walter Bright looked at the current OO languages and decided they weren't adequate for his needs. So he designed and implemented his own. This is commendable, but I don't see the result as being different enough from the other available OO languages to make any sort of switch or adoption advantageous.

    I think that languages get adopted widely when they offer something that other languages can't do, or do very poorly. Fortran allowed an abstraction higher than assembley. C++ allowed object oriented design using notation many people were familiar with and at high speeds. Perl allowed easy text manipulation. Java allowed platform independence (yeah, yeah, with the JVM, but that I think is what sold it). All of the feature additions and deletions are nice (well, not all of them, I like some of the things he decided against including), but I don't think they add up to something that people really need. And if you can't produce that, I don't think the language is going to catch on.
  • Oh great... (Score:5, Insightful)

    by ttfkam (37064) on Sunday January 12, 2003 @04:32AM (#5065822) Homepage Journal
    Yet another way to write and manipulate ints, floats, struct, and classes.

    Why don't people put as much effort into designing standardized interfaces for networking, threading, forking, database access, distributed logic, graphics, etc.

    He goes on and on about how we need unified syntaxes for unit testing, inline assembly, assertions, etc., but is curiously silent with regard to the above issues.

    What are the killer apps? Apache? OpenLDAP? OpenOffice? Mozilla? Konqueror? Photoshop? Gimp? Quake? Neverwinter Nights? Crystal Reports? Gaim?

    Now with that list in mind, how does D make anyone's life simpler? Need a TCP/IP socket? Sure! Just use the POSIX one...unless you're on Windows...or coding for BeOS... What about talking to a database? Well there's ODBC implementation #1, ODBC implementation #2, native database-specific API #1, etc. Well at least there's graphics right? OpenGL all the way...except when you need DirectX...or the framebuffer interface... And for GUI libraries, we have GTK+, Qt, FLTK, MFC, XUL, etc. Along those lines, do you use Gnome or KDE for your object model? Do I write to libxml or use some COM wrapper for MSXML3.DOMDocument?

    What good is uniformity in a complex type when anything I want to do with the language that implements it requires an unending list of non-D libraries that throw uniformity out of the window? Please explain to me how my life is enriched by this language? Please explain how solves more problems than it creates?

    Sure Java, Python, et al have their share of problems, but at least I can open a socket or a filehandle without doing market research on libraries first. At least code written in those languages is readable by someone who knows the language. Database calls look the same no matter your operating system. That's what I want. Not just some new and exciting method for representing imaginary numbers.

    And while we're talking about data types, he writes at length about how ints, longs, floats, etc. are all well-defined sizes unlike in C even though saying int16, int32, and int64 would be much easier to read and helpful. In addition, while the other types are well-defined and char is well-defined as a single 8-bit byte, wchar is sometimes 2 bytes, sometimes 4 bytes, and could be something else in the future depending on the wind. Ask the i18n coders about their experiences with wchar_t. Most end up using an avalanche of #ifdefs or just sidestep it altogether with their own array of bytes. Why? Because sometimes they're using UTF-16 and other times it is UCS4. You need to know how big the character type is! It's not something you leave up in the air! char16...char32... Are these too much to ask for?

    I hope to god that no one actually adopts D for real work in the near future. If they do, they will run into the limitations I mentioned above and figure out some hack to get it to work. Hack begets hack begets hack and you are left with another bloated language lacking uniformity that people will bitch about on tech discussion boards. And then some person will say, "Hey! I've got this new language that fixes all of those inconsistencies with D that we all hate."

    1. Wash
    2. Rinse
    3. Repeat
    • Re:Oh great... (Score:5, Insightful)

      by Tumbleweed (3706) on Sunday January 12, 2003 @05:31AM (#5065922)
      Okay, then, we should just never make any other computer languages until someone can come up with one that solves every one of those problems you listed.

      If someone finds that D solves problems they have, or if they just plain like the syntax better (and how can you NOT, compared to C and C++ (and Java)??), then there's nothing wrong with someone using D. Hell, I'd use D just for the string-handling alone (one reason why I think C is pretty ridiculous for a general purpose language).
  • by RockyJSquirel (412960) on Sunday January 12, 2003 @07:31AM (#5066116)
    I was looking at the list of features.

    While it looks fine, and useful, I can't help noticing that last time we heard about D it didn't have most of these features (templates, overloading etc.) and they were claiming that the lack of these features was it's strength.

    I called them ignorant swine for that at the time.

    The new D looks a lot like Modula 3, a great language aiming at the same sort of niche which disappeared without a trace.

    Rocky J. Squirrel
  • by ChaoticCoyote (195677) on Sunday January 12, 2003 @03:23PM (#5067737) Homepage

    ...and I have great respect for his work. Back in the early 90s, he had the first and best C++ native-code compiler, which he built on his solid Datalight C tools. Walter's compiler became Zoretch C++, which became Symantec C++, which became their Java compiler (after a fashion). I used Zortech C++ up until the time Symantec let it die on the vine. I even wrote the official numerical programming docs for Zortech and Symantec C++.

    I remember sitting around with Walter and his buddies, talking about how much trouble Walter had in implementing C++. This was before the ISO standard, and to some extent, before the ARM definition. Walter isn't a fool; he's one of the brightest programmers I've ever met. When C++ was first emerging, I talked with compiler developers from Watcom, Microsoft, and others; all found C++ to be more than a challenge. Stroustrup invented an incredible power tool that ANSI complicated through the committee process; I am impressed that anyone has come close to making this monster work.

    D is Walter's attempt to move beyond C++, based on his experiences in writing C, C++, and Java compilers. I'd say he has an excellent understanding of the issues involved.

    Do I use D? No. While a good effort, D simply doesn't address my programming needs. When I look at a "new" language, I consider O'Caml or Haskell or something that provides very different paradigms. I don't believe it is possible to define a single, all-purpose programming language that scales across the spectrum of applications. I haven't got anything against D, but it doesn't do anything for me that I can't get elsewhere.

    Whther or not I use D is irrelevent to its future. Walter Bright has created yet-another-C-derivative; it may succeed, or it may end up like the hundreds of "good ideas" that never caught on. But don't make the mistake of thinking Walter is foolish; he has a fine mind and has produced brilliant software before. He once started from obscurity to build the first useful XC++ compiler for MS-DOS and Windows; I will not be surprised at all if he proves his mettle again with D.

  • switch statements (Score:3, Insightful)

    by Eric Smith (4379) <eric&brouhaha,com> on Sunday January 12, 2003 @05:10PM (#5068333) Homepage Journal
    I looked over the FAQ, and am thoroughly unimpressed with some aspects, like the decision not to fix the behavior of the switch statement (i.e., falling into the next case if there's not a break).

    The stated argument is that it's desirable to make the language "look like" C. If you want a language that looks like C, use C. Personally, I want someting better. In fact, I think that making Java look like C was one of Java's biggest mistakes; it lulls the programmer into a false sense of familiarity when in fact Java's semantics are much different than C's.

    And if you just want to make sure that C programmers don't get burned by their old habits, there's a simple solution to that as well. Require that each case end with a "break" or "fallthrough" statement. That way there's no ambiguity if the user forgets the break, it will produce a compile error.

If I have seen farther than others, it is because I was standing on the shoulders of giants. -- Isaac Newton

Working...