Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

The D Programming Language 530

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

The D Programming Language More

The D Programming Language

Comments Filter:

  • A critique (and take a look at Ocaml) (Score:3, Interesting)

    by Chuck Messenger ( 320443 ) on Thursday August 16, 2001 @08:54AM (#2110708)
    Briefly examining the specs for D, here are some thoughts which occur to me, based on my experiences with C++, Java, and a few other languages:

    o Multiple inheritance is absolutely necessary. The main way it is useful is for Java-style interfaces.

    o Getting rid of macros (preprocessor) is a very bad idea. What is needed is even more powerful macros (see Lisp).

    o Generic programming with templates is the greatest thing about C++ -- the one feature that puts C++ above other programming languages. I'd rate generic programming capability as being a "must" of any modern programming language.

    o Operator overloading is a Good Thing, in that it helps you set up a well-designed library as a "mini-language". Good programming practice involves reducing the number of keystrokes required to achieve a given result (ultimately). Generic programming, macros, and operator overloading all go in this direction. Eliminating them is a step backward.

    o You say "smart pointers are irrelevant in a garbage collected language". Not true. There are many types of resources which a destructor might free besides memory. One weakness of Java vs C++ is that it is hard to control Java's "destructors".

    The "best" programming language (for general-purpose "big" programming projects) I've encountered may be Ocaml. It can compile into native code as efficient as C++'s. It can also be interpreted. It is stronly typed. It supports a powerful "functional" programming idiom. It looks pretty good to me, although I haven't used it for anything "real" yet. But if you're looking for the "be-all, end-all" modern programming langauge, I think Ocaml's worth taking a look at.

    • Good programming practice involves reducing the number of keystrokes required to achieve a given result (ultimately).

      Not really. What you really want is to increase productivity. This might mean "reducing keystrokes", but more importantly, you want to maximize maintainability. This is why operator overloading is often a great evil -- you are hiding information that is not readily apparent. What does "+" mean in context X? It can be extremely difficult to know, particularly when bringing on a new programmer to work on old code.

      You're argument will probably be something like, "well, yeah, but everything can be abused" but that's not the point. The point is how easily overloading can be abused, how little it actually adds to the language, and how complex it makes things.

      • Yes -- overloading can be abused. It's the same reasoning people use against macros -- that they can be even _more_ abused. It takes an experienced hand to use them effectively.

        Still, overloading, and macros, add a great deal to the language, increasing the possibilities for creating powerful libraries, with simple, intuitive interfaces. If you want a language which protects you from yourself, use Java. But don't expect to be as productive! (he says as he ducks for cover...)

        As an example (of overloading), consider the C++ streams library. Imagine having to do:

        put(put(put(put(cout, "Value "), valName), " = "), val);
        It's horrible! Instead, we can write:
        cout << "Value " << valName << " = " << val;
        Nice! It's much faster to type, and much more clear (hence more maintainable and less prone to bugs).

        In my experience, in general, reducing the number of keystrokes (increasing the conciseness of code) leads, simultaneously, to faster-written, less-buggy, and more-maintainable code.

        In general.

      • Good programming practice involves reducing the number of keystrokes required to achieve a given result (ultimately).
        Not really. What you really want is to increase productivity.

        Sure, and such surveys as have been done have repeatedly shown that your typical programmer will average roughly the same number of lines of code in a given period of time (about 20 per day, usually). Thus, the more power there is in each of those lines, the better.

        This is why operator overloading is often a great evil -- you are hiding information that is not readily apparent.

        It should be. If it's not pretty much immediately obvious what a + operator means in a given context, then it's clearly a bad use of operator overloading. (Granted, it does get widely abused. So does inheritance. That's not to say these things can't be very useful when used properly.)

        What many people ignore is that operator overloading, like the option to use value or reference semantics, is important to allowing user-defined types to function just like built-in ones. C++ is one of the few languages that (almost) achieves this. As a result, you can do things like writing nice generic algorithms using templates, which is still a much under-rated but incredibly powerful feature.

        For example, in C++, I can write a "sum" algorithm that iterates over an array of values, and +s them all. On ints, you get the sum of the values. On complex numbers, with a suitably overloaded operator+, you also get the sum of the values. On strings, if I've defined + to mean "concatenate" (which even those langauges claiming operator overloading is bad actually do) then I get the concatenation of several strings. All of this makes sense and is nicely consistent. It's just that in C++, it's fully controllable, whereas in Java, you're stuck with + meaning concatenate with a String, whether you like it or not.

    • While I generally agree that you need macros in some form, I'll observe that once you have macros with the same expressive power that lisp macros have, you don't need templates anymore. On the other hand, it may be that LISP style macros would prevent the compiler from handling the sort of type matching that C++ templates have (which both lend power, and make them the very devil to implement correctly).

      LISP style symbolic manipulation of code permits the construction of special purpose syntax that is closer to the problem at hand, making the code easier to write and understand, provided that the macros are written to make things more clear rather than less. It is certainly true that you can take things too far with LISP-style macro expansion, but you can also go much much farther than you can with any text-preprocessor scheme.
  • It is not very nice thing to say, but the guy stuck
    in the time few years ago:

    1. Java is already invented.
    2. Nobody cares about 16 bit code anymore.

    If you like Java, use it. If you dislike java,
    stick to good old C++. No need to invent a new language.
    • No need to invent a new language.

      This sort of staement really amazes me. Are you so righteous that you think Java and C++ are the answer to all programming problems? Get real. They both have their place, and there's nothing to say that D might not have its place too.

      This guy's trying something new. If you see a particular problem with his approach, by all means let him know. We all value constructive criticism and suggestions. But don't just say it's no good before its even been given a chance. I for one think he has some good ideas in there, and I look forward to being able to try it out some time.
      • > This sort of staement really amazes me. Are you so
        > righteous that you think Java and C++ are the answer
        > to all programming problems? Get real. They both
        > have their place, and there's nothing to say
        > that D might not have its place too.

        If he would invent something really new I would not argue. What he offers is another facelift to C++ which was extention of C. He offers it in a way very similar to Java.

        For fresh approach to OO languages take a look at
        OZ [mozart-oz.org]. I wish I had more time to play with it. Looks quite interesting.

        I really get disappointed when people invent pet language for their project when there are thousands of other lanugages which you could use. For my projects I am using
        GUILE [gnu.org].

  • It would be really nice to have an open alternative to Java that is also compiled. Glancing through the spec there is lots to like there. For instance the idea of building unit tests into the language spec seems like a pretty good one to me and would help popularise unit testing among developers. Native support for unicode is nothing new but it's nice that unlike Java he still retians the ascii type for those who don't need i18n. I hope the guy pulls it off. I'd like to play with a new C++ like language. If he only reconsidered his views on templates though...
  • Looks like he took C++, removed all the nastiness, and added all the niceness of Java in. The syntax, and spec is surprisingly Java-like. Sounds like a wonderful language...I was waiting for somebody to makea native Java-like language.
  • I mean, it's taken me since yesterday morning to skim less than half of the on-line documentation for D, but there were hundreds of posts within the first hour!

    Overall, it looks like a pretty good job, if what you wanted is a language for large projects on modern desktop & server computers. It doesn't entirely take away C's capability of letting you screw up enormously, but it does make screwups a little less likely. For instance, C and C++ programmers tend to manipulate strings with pointers; this results in very efficient code, but combined with sloppy programming (always by management decree, I'm sure) it also results in hundreds of security exploits involving buffer overruns. D gives you dynamic arrays, which handle strings the way they ought to be handled, and I think makes a program that allows buffer overruns harder to write than one that doesn't.

    On the other hand, I do some embedded programing with 8-bit CPU's. I rather suspect that over half the people who frequently code on-the-job are doing the same, although most of them are not "programmers" but rather are EE's, design engineers programming their own designs. Certainly you'll find a few dozen of those 8-bitters in the average american home, even though they own nothing they recognize as a computer.

    D doesn't even define how to compile to a CPU with less than 32 address bits. That doesn't mean it's a bad language -- in fact, it make's it a better language for the 386 and up -- but it does mean that it's widening the gap between embedded programmers and the rest.

    Likewise garbage collection is acceptable in an embedded system of any size only if you can control when it happens, and there is no mechanism in place for this. (The docs do mention that interrupt-handlers probably can't be written in D because of the garbage collection.

    But for desktop and server applications, I like 99% of what I've seen and have just one complaint: operator overloading is _important_, it lets you write extensions to the language.

  • Reading the document, I felt that old shuddering horror I felt when I learned Modula-2. M-2 looks great on paper until you try to build a major project with it.

    It sounds like he took Java's design aims and added Nicholas Wirth's bugbears (being an academic) and tried to marry them, but the problem I have is: what's the compelling reason to use this over Java? I didn't see anything in there that gives it a clear advantage over Java, and he doesn't give an alternative to templates. Templates, especially as implemented by C++ and Ada, can create type safe structures that a pure OO design can't (A Stack of Objects cannot distinguish what's being pushed onto it at compile time).

    Sounds like he's enjoying the ego trip of making his own language. Personally, I'd rather wait and see what Stroustroup's C++ Redux effort generates.

  • There has already been a "D" language. It was written and used in an early phase of the Xanadu project, when C was still young. It compiled into C (essentially a preprocessor) to give it a number of features that were missing at the time. (One that sticks in my mind is long names, though there were several others of significance.)

    (It led to an interesting confrontation at one point. Roger Gregory was accosted by a member of one of a cult, who gave him a flower and started on the cult's conversion spiel. When the cultist got to the first question (your occupation) he said "I'm a 'D' programmer.". Of course the cultist heard it as "deprogrammer" and ran.)

    I hear that the language "BCPL" was part of the inspiration first for a language called "B" and then for "C". By that precedent the first non-superset successor to "C" should be "P".

  • This language looks to be the same as everyone else's attempt to make a modern C-like language (ie, Java, C#). What is the point?

    For a fast (as fast as C, maybe faster), safe language with some really neat (and probably unfamilar) features, try O'Caml. This will cure your doldroms, and you may never want to go back...

    http://caml.inria.fr/

  • Here's my 2 cents: D Sounds ok. I DO like the idea that a typedef actually creates a new type. But as a C++ programmer of 9+ years who is not "terrified" of managing his own memory, and who thinks that operator overloading and templates are cool, I have some issues with the draft standard as it stands:

    1) Templates: I hope that Mr. Bright does find an answer. I agree that C++ template syntax is tough, but the power of generic programming is far too great a feature to drop for large applications!

    2) Operator overloading: I like it, many people don't. Used properly you can make some very cool looking type safe code. I don't think a very powerful feature should be dropped from a language just because some people are idiots. C++ is not a toy; and neither should it's successor be.

    3) Interfaces: Hello out there? The world has gone distributed. How about direct language support for CORBA interfaces? Now THAT would be a slick feature to add to an extended C++ language!

    4) Standardize the name mangling! Name mangling issues are what make different C++ compilers incompatible; let's fix this oversight...

    5) Garbage Collection: I'm ok with garbage collection but DO give me a way to override the collector! There will always be situations where I know I can get rid of something but the garbage collector wouldn't see it that way. DO give me a way to manually kick off a garbage collection cycle and DO give me a way to manually delete things.

    6) I'm working on a million line+ surface ship combat system right now. One thing that the old Ada programmers keep screaming about is the inability to get very fine grained control over numbers; and for this application I can see why they are complaining. What's needed is a way to enforce the domain of a numeric type, ala low bound high bound with an exception thrown for invalid values. Very fine grained control over coordinate and range values is key to a large class of military applications.

    I've been pondering my own new language too. Maybe I should go for it. My language would look alot like C++/D - with the items listed above - plus some other ideas that I've been pondering...

    --Richard

  • I read the specs. 20 years ago it would have been impressive, but now...

    Lets summarize:
    - no generics, yet (he was 'thinking' about it)
    - I haven't spotted an interface construct like in Java, very useful and no performance penalty -> include it!!
    - no dynamic classloading, another useful Java feature
    - no reflective features, another useful Java feature.
    - no new features worth mentioning

    I would propose this language were called Java--. It removes features the author of the spec deems irrelevant and doesn't add any new ones. Java has its flaws but these flaws are tolerated because it also adds useful features.

    Incidently, the VM approach has been adopted by MS now in .Net for a very good reason: it adds a great deal of flexibility. Java has already shown that VMs can efficiently execute numerical code. HP has shown that interpreting bytecode can actually be faster than compiling it. There is no sound reason to dismiss the concept of a VM anymore. Java vms are even available on embedded machines now so size is not an issue either.

    If the author of the spec still wants to go ahead with implementing D (aka Java--), I'd strongly suggest to make it compile to .Net, the JVM or some other vm (unix currently lacks one) so that you can at least take advantage of the features and libraries offered by such environments.

    And finally, there is no market for this language. C/C++ programmers are generally so much in love with the language that they are virtually blind for its disadvantages and ignore/dismiss competing languages (of which there are many). Based on this it is safe to assume that most of them will also dismiss D, no matter how good it is. And since I already argued that the language really doesn't add anything new, programmers of other languages will also not be inclined to swap language.

    It is funny that all attempts to make a new language that looks like C++ but doesn't have its advantages end up looking like Java. Maybe the Sun guys got it right after all. It certainly is a nice language to program in.
  • of my project! However there are some differences.... I do plan to allow templates and operator overloads, however currently these two feature a vapor, since they are not yet supported

    I called it Dtone, since I thought calling it just D would be arrogant, claming a single letter name. However it seems others didn't disturb that :o)

    Well it's not nice to link to ones own page, and advertise on /. but:
    http://w ww.dtone.org

  • D versus C# (Score:3, Informative)

    by Zeinfeld ( 263942 ) on Thursday August 16, 2001 @12:47PM (#2133190) Homepage
    It would be interesting to know if the guy has contacted Microsoft. Many of the features of D are in C# and vice versa. It would be a good thing if the future of programming languages was not considered the domain of Microsoft alone (bad) or Suns lawyers alone (worse).

    Many of the features look pretty sensisble. There is now pretty unanimous support for dropping Multiple inheritance. The problem with multiple inheritance being that it leads to programs only the original authors understand.

    It is disapointing that the syntax was not changed more radically. I for one am pretty bored with typing semicolons at the end of lines. Using braces for block structure is equally tedious.

    The garbage collector is of the 'stop everything and collect' type, this is not a good scheme as anyone who has seen a PET running Microsoft Basic GC will agree. The incremental GC in .NET is a better scheme, even if it is slower overall. But that is an implementation detail.

    It would be good if people would start to look at adding support for parallel program execution. The threads programming model is very clunky and hard to use, in part because there is no means for the program to perform checks on access conflicts.

    Also a persistence model should be part of any new language. The current division between programming language and database is a lot of wasted overhead.

  • Can you imagine the flop they would make marketting 'Visual D' - VB and VC worked ok

  • Garbage Collection vs. Virtual Memory (Score:3, Interesting)

    by Bryan Ischo ( 893 ) on Thursday August 16, 2001 @10:40AM (#2135571) Homepage
    Something I've always wondered about Garbage Collection is, doesn't it basically add alot of VM paging overhead to a process?

    Meaning that, since the garbage collector has to periodically walk all of the heap of a process, it would seem to me that it would thus periodically force any pages that are paged to disk to be brought back in by the VM even if they didn't need to be otherwise.

    I used to do alot of Java programming, and I got the uncanny feeling that every time my program grew very large (which was very often - Java programs use *soooo* much memory, don't know if it's just a general tendency of GC or if it's Java's implementation) the system would thrash quite a bit more than if I wasn't running any Java programs ... and I came to believe that it might have something to do with the garbage collector forcing the OS to load every page of the process into memory as the GC swept through, so everything that modern OS's do in terms of trying to streamline VM kind of gets thrown out the window when garbage collectors are forcing every page of their process to be loaded in periodically.

    Just wondering why no one has ever made the point (to my knowledge, anyway) that garbage collectors may be very bad for virtual memory performance. It seems quite likely to me, anyway.

    Otherwise, I like just about every idea in the D language, especially his Name Space notion - although I didn't read too much detail of his spec, at least he's thinking about it. I hate the fact that modern languages are based on string identifiers during linking; there's no formal mechanism whatsoever of avoiding clashes in the namespace (Java's class package name idea is a small step in the right direction), and it really seems stupid to me that shared libraries should be carrying around all this string baggage, and doing all these string compares during linking ...

    Anyway, that's how I see it.

    • Nope. Modern garbage collectors certainly don't walk around memory collecting things (and neither do modern heap allocators). All the tabular stuff that indexes memory and structures is usually contained in a small set of pages. Those refer to blocks elsewhere. No page swapping is required.

      Java's class packaging is considerably more than a small step in the right direction. It supports a universal naming convention, based on the internet's naming systems, that can underlie local and remote code. D's modules are a primitive mechanism at best, similar to Delphi's. They're OK for a single organization, but problematic for integrating code on a wider basis.

      • Hm ... I'll have to read up on modern GCs ...

        And the reason that I think that Java's mechanism is only a small step in the right direction is that it's simple a convention. There's very little behind it. I don't have to name my classes with a package, nor to I have to pick a package name that is reasonable. Package names actually take up a considerable amount of space in a Java file - I wrote a commercial obfuscator package and it turned out that something like 5 - 10% of a Java class file's size is just package names embedded in every reference to other classes - and it seems silly to drag all of these strings around when a more concise, robust system could be used instead ...

      • Nope. Modern garbage collectors certainly don't walk around memory collecting things (and neither do modern heap allocators). All the tabular stuff that indexes memory and structures is usually contained in a small set of pages. Those refer to blocks elsewhere. No page swapping is required.

        Actually, that's not quite true. But generational collectors are set-up so you don't have to run through entire sections of memory except in rare circumstances. And you can use virtual memory hardware to alert the collector when an old generation is being written to (so you don't have to look yourself).

  • D's floating-point model is dangerous (Score:4, Informative)

    by fullcity ( 108058 ) on Thursday August 16, 2001 @12:21PM (#2135793) Homepage
    D's philosophy about floating-point arithmetic is dangerous:
    On many computers, greater precision operations do not take any longer than lesser precision operations, so it makes numerical sense to use the greatest precision available for internal temporaries. The philosophy is not to dumb down the language to the lowest common hardware denominator, but to enable the exploitation of the best capabilities of target hardware.

    For floating point operations and expression intermediate values, a greater precision can be used than the type of the expression. Only the minimum precision is set by the types of the operands, not the maximum.

    This reflects a terrible misunderstanding of floating-point arithmetic. Decades ago, scientific programmers realized that getting a computer to "just give me the best FP answer you can come up with, I'm sure it's good enough" caused headaches. That's why we have IEEE FP standards that define EXACTLY what the results should be, to the bit.

    If you get different answers on different computers due to different roundoff errors, your software becomes unreliable. It's true!

    People get confused by Intel's 80-bit FP arithmetic. Yes, the FPU expends some effort in rounding the 80-bit result back to 64 bits, but the result is not more accurate than a 64-bit FPU. In fact the answers will be exactly the same--this is mandated by the standard.

    Anyone using floating-point arithmetic for anything serious needs to know exactly what the arithmetic model is. If Walter pursues this philosophy with his new language, he will make it unusable for numerical applications.

    Walter needs to read:

    David Goldberg, "What Every Computer Scientist Needs To Know About Floating Point Arithmetic," ACM Computing Surveys, vol. 23, pp. 5-48, 1991.

    I could not find a copy online, but here is an interview with William Kahan [berkeley.edu], the Turing award winner who co-developed the IEEE 754 floating-point standard. Language designers should notice that Kahan implicates of Java and Fortran at the end of the article.

    • I agree that Goldberg's "What Every Computer Scientist Needs to Know about Floating Point Arithmetic" is a good and important read. Google found it several places, including at citeseer [nec.com]

      But you know, just yesterday I re-read 80% of Kahan's site, and he does in fact recommend that non-expert numerical analysists (i.e. just about everyone) should use the maximum precision possible, as a sort of band-aid. Not that a guru like him thinks it's a cure-all, just that it'll help people a bit.

      So Walter isn't that far wrong there, after all.

  • Seems like every language is an excercise in How Things Should Be Done.

    As a programmer that's worked with about 15 languages over 18 years what I really want is a language that:

    1> Is as quick to program in as php/perl/python.
    2> Is still managable for large projects.
    3> Is as fast as C/C++.
    4> Is easy to port across platforms(porting Quake V from Linux to Windows should just be a recompile).
    5> Performs in a predictable manner(no wierd behavior out of the basic operations every language has in common).
    6> Memory management should be handled automatically.
    7> Integrates seemlessly over networks.

    Is this too much to ask for?

  • After C comes P! (Score:4, Informative)

    by vu13 ( 462742 ) on Thursday August 16, 2001 @08:43AM (#2138425)
    First their was BCPL, then B, then C. Logically the next language in this family would be P.
    • Whoa! Somebody who remembers BCPL!

      I guess few remember the great debates (in good humor) about whether the successor to C would be called D or P. Bjarne Stroustrup managed to appease (and probably get a good chuckle out of) both sides by calling his newly developed language C++... An obvious software engineering in-joke.

  • can you say "Java?" (Score:5, Insightful)

    by dobratzp ( 155212 ) <dobratzp@ele.uri.edu> on Thursday August 16, 2001 @08:46AM (#2138570) Homepage

    from the overview page [digitalmars.com]...

    features to keep:
    • compile/link/debug development model
    • Exception handling
    • Runtime Type Identification
    • link compatibility with the C calling conventions

    All except the last is contained in Java.

    features to drop:
    • C source code compatibility
    • Link compatibility with C++
    • Multiple inheritance
    • Templates
    • Namespaces
    • Include files
    • Creating object instances on the stack. In D, all objects are by reference.
    • Trigraphs and digraphs
    • Preprocessor
    • Operator overloading
    • Object oriented gradualism
    • Bit fields of arbitrary size
    • Support for 16 bit computers

    This seems to be precisely the parts of C++ that Java also does away with. Furthermore, the C preprocessor is not strictly part of the C language and in fact many other programming projects use cpp for simple cut and paste includes of their favorite language. When I first read about trigraphs, I couldn't wait to try them out to make some extra obfuscated [ioccc.org] code, but alas the C compiler I was using didn't support them. In fact the lack of standards compliance is one of the main drawbacks to programming in C++ and C. If my Java code compiles on sun's compiler, then I can be assured that it will also compile on any other compiler claiming to compile Java code.

    The author also mentions that D will not have any bytecodes. From a strict perspective, the Java programming language and the Java VM are two different standards and just because you typically compile Java code into (confusingly named) Java byte codes, doesn't mean you can't use one without the other. For example, anyone (who is insane) can pick up a copy of the Java Virtual Machine Specification [sun.com] and a hex editor and make some syntactiacally correct class files. More realistically though, java bytecodes are often targets for compiler construction classes. Also, if you use the GNU Java Compiler [gnu.org] you can compile programs written in the Java programming language directly into machine code.

    While 90% of the description of this language screams Java, there seem to be some of the more useful features of C++ thrown in (typedefs, scope operator, etc.). The only way for this to be successful, is to finish standardizing the language as soon as possible and get a reference compiler for it so it leaves the realm of theoretical vaporware. Perhaps Java might have looked more like this if the language design was revisited. However, Java has lots compilers [geocities.com] which are much much more likely to conform to the standard [sun.com] than the C++ equivalents [cplusplus.com].

  • After a quick read of the specs:
    • Make the compiler generate an human-readable (ASCII and properly indented) version of the symbol table of a module/class, so that programmers don't have to dig in a thousand lines of code only to discover the interface of a public method;
    • BTW, I hope there is some provision for public/private methods/attributes (did not find it, but did not read the whole specs); large projects cannot rely only on programmers 'sense of responsibility';
    • Borrow ruby's accessors, but with a less mangled syntax: something like 'readwrite int foo' that generates automatic 'int getFoo()' and 'void setFoo(int)' methods, while a 'readonly int foo' generates only 'int getFoo()', meaning that the attribute is only changed inside the class.
    • A doc tool a la javadoc, which helps generating consistent documentation from code (main goal: the developer should not be forced to repeat in the documentations things which are already stated in the code). Maybe an optional 'description { text }' clause after the definition of main items.
  • Good lord, folks, it's 2001 so why are we still putting semicolons at the end of every line?? Parsers have come a long way in thirty years. It turns out that terminating a line with anything more than a carriage return is completely unnecessary [python.org].

    Burris

  • Sorry, but as a long-time C++ programmer, I find this only a marginal improvement in the language. Granted, it is an improvement, but how many people are going to rewrite legacy code for a marginal improvement?

    Personally, I think we need a radically different way of programming. I don't know what it is, but we need it. We're really in the bronze-age of programming. We've got a long way to go. Right now, writing software is more art than engineering. The few groups that do it like engineering pay a heavy premium to do it (i.e. the Shuttle Software group)

    There was a guy a while back that wrote a program that emulated a bunch of CPUs. He then wrote a language for those CPUs and had a "goal" for the program. He then introduced the idea of mutations and spawning child programs. He would start off writing a program to acheive the goal, and then feed it into the "CPUs". After several generations and mutations, and a "natural selection" type process, the computer ended up generating better code than he originally did.

    I've had it in the back of my mind that that's what we really need to do in software. Come up with a way for computers to put our software through some sort of "mutation" and "natural selection" process and in the end we get better code. Obviously in the real world, this is a much more complex problem than the simulation this guy wrote. Wish I could remember where it was and what the link was. Very cool stuff.

  • SECURITY BY DEFAULT (Score:2, Insightful)

    by zenray ( 9262 )
    One thing in this new programming language that needs to be designed in from the ground floor is SECURITY BY DEFAULT. Make buffer overruns impossiable for starters. I'm very weak as a C programmer and just a student of computer security but it woluld go a long way to solve most of the security problems in appliacations if the programming language enforced proper security codeing practices. Maybe everything would be as secure as OpenBSD. Theo should help design D language to be SECURE BY DEFAULT rather than doing a security review after the software is written. Just my opion, I might be wrong.
    • It's called "Visual Basic" (seriously, no joke here).

      Builtin security = slower runtime. If you know how to program then you don't write code with buffer overruns. If you don't, then you can use a bounds-checking coddle langauge like VB.

  • Maybe? (Score:3, Interesting)

    by scott1853 ( 194884 ) on Thursday August 16, 2001 @08:54AM (#2154059)
    "Maybe its time for a new language born out of practical experience implementing compilers."

    Maybe it's time for a new language to be born out of practical experience writing software.

    I don't know how it is in Linux, but I really hate having to write several hundred lines of code for a single window w/controls in Window API calls. Personally, I'd like to see MS get rid of those API calls (and don't replace it with ActiveX until ActiveX works). Between the ones that don't work as documented and the rest of them being overly cumbersome, it's just a hassle. Especially when you have to create your own encapsulation objects for those things. I like Delphi because of its encapsulation of the visual components, but their base library sucks in itself in that it doesn't expose all the functionality. And since they saw that it was so important to declare everything as PRIVATE methods, you can't get descendent object to do everything you want either because you don't have access to all the base functionality.

    Simplicity shouldn't be taken to the extreme either, and gear a new language towards the non-programmer crowd like MS tries to do.

    Of course MS is just making things worse right now by implementing these new Luna APIs for XP. I'm sorry, but I don't know of anybody thats been really dying for the ability to use API calls to put a gradient on a button. In my opinion, this is just MS's attempt at trying to get developers to waste time, so they don't work that hard on developing new products that may compete with MS.

    • Re:Maybe? (Score:4, Insightful)

      by rabtech ( 223758 ) on Thursday August 16, 2001 @10:48AM (#2119589) Homepage
      Have you ever tried Visual Basic? I know it gets a bad rap sometimes, because it is VERY forgiving. It is extremely easy to write very crappy code that still works.

      However, for those who bother to do the job right, VB can be a very powerful tool, used to create shipping application. (As I personally have done.)

      With VB, you don't care about all the "stuff" underneath (which can be a problem when you try to do something that isn't built-in, but there are creative solutions). You just drag controls onto your window, and write the code behind them. Very easy.

      VisualStudio.NET is bringing this in two different directions: First, VB gets full access to everything, and is no longer the "bastard" child of the VS family. Secondly, the other VisualStudio languages get a new Forms system similar to VB's -- just drag controls onto the Window, set properties, then write the code to handle the events. Easy and clean.

      That's really what the entire .NET runtime is about: moving away from Win32. What is easier for using sockets to listed on Port 80? Fooling with the separate WinSock2 API, or doing "Dim mySocket as New System.Sockets.TcpListener(80)" ?
      This message sometimes gets lost because .NET is a very large umbrella. But what it is bringing to the programming side of things is very impressive indeed. An entirely new programming paradigm where everything you ever wanted to do is neatly arranged within the various Class libraries. I know that in and of itself isn't new, but having that kind of support on the OS level IS new.

      Microsoft has already stated that when the Win9x code line is pretty much dead, and everyone is writing to the CLR instead of Win32, they are going to make a move to port the CLR to the WinNT Executive (that is NT's native kernel API). Win32 will finally be relegated to "legacy" tech just like DOS interrupts and Win16.

      • Re:Maybe? (Score:3, Informative)

        by MagikSlinger ( 259969 )

        While I think you have some valid points, you are far too eager to suckle at Microsoft's teat and call the watered down skim soya milk it gives 10% m.f. homogenized.

        I too like VB (quit staring at me like that!), and I agree with you that poor programmers give VB a bad man, but I big to differ on the idea that VB somehow protected you from Microsoft's shifting API's. You've read the reviews for VB.Net? Everyone VB programmer out there is screaming blue murder because the object model in VB has so radically changed that it requires re-learning VB. Yes, I said re-learning VB. MFC has changed their official "ways to do things" with each major release that it's necessary to re-learn MFC every major release. Sure, MS can provide some insulation from their API's, but even their insulation can't protect you from the pointy spikes that poke through everytime MS changes its architecture.

        One other thing:

        An entirely new programming paradigm where everything you ever wanted to do is neatly arranged within the various Class libraries. I know that in and of itself isn't new, but having that kind of support on the OS level IS new.

        As an embittered and disgruntled fan of NextStep, I vehemently disagree with your opinion. :-) You want a seriously kick-ass distributed networking object-based API? Try NextStep's Distributed Objects. Can you say, "Sweeeeeeet!"

        Other than that, I think you made some good points for people to think about.

        • I like VB.NET.

          Given that I converted several hundred program from VB to VB.NET, I can speak on how different the two are.

          Essentially, if you "just got by" with VB6 because of how simple a world view it could present, you may be in for a small learning curve with VB.NET

          Now the good part:
          If you can program in any C-family language, perl, or anything moderately more complex than VB, you're going to love VB.NET because you get to keep the simplicy of VB 95% of the time, but you get 99% of the power of C whenever you want it. These percentages are of course made up, but for those of you that are following C# and like it - VB.NET is almost the same language, what-you-can-do-wise :) They both compile to CLR, and VB and C# can use eachothers classes interchangably. Each has its own specific quirks and strengths, but in general, if you can do it with C#, you can do it with VB.NET, and if you cant, then just do that part in C# (or Managed C++) and then consume it from VB.NET.

          You'll be happy to know that there is no longer a VB runtime - now theres a .NET runtime, and vb simply compiles to it. You'll also be happy to know that theres now a standalone commandline vb compiler. Best of all, theres a standard VB project type called "Console Application". No silly forms ever get involved - at all.

          On the other end of the spectrum, theres a VB project template for creating Windows NT services. This was not even necessarily possible with VB6 - and to do many interesting things in VB6 you needed to import Win32 functions.

          So in general, i think people that are programmers will love VB.NET - it gives all the long-time vb haters and complainers many things they've been asking for - and then some.

          On the other hand, people that can barely grasp VB6 may be in trouble - the new power and flexibility of VB.NET does come at a price in terms of complexity of auto-generated code. If you're already in trouble when you accidentally go into the code window instead of the design window, expect problems with VB.NET.

  • Improving languages? More power to the people doing it. C++ is daunting as hell even to experienced programmers coming from other languages, and has some pretty odd legacies.

    However, to play Devil's Advocate, why base a language on anything pre-existing? Is anyone creating languages completely (or mostly) from scratch?

    Admittedly a from-scratch language would be up against a higher learning curve, but I wonder if the benefits would outweigh this.

    Just a thought from a person who's had to learn a lot of languages.

  • Useful? Not Really. (Score:3, Interesting)

    by Unknown Lamer ( 78415 ) <clinton@nOSPAm.unknownlamer.org> on Thursday August 16, 2001 @11:47AM (#2154169) Homepage Journal
    From what the draft specs says, D doesn't look like a very good language. It ditches (arguably) useful features like multiple inheritance, templates, and operator overloading; and then it adds features like resizable, bounds checked arrays...in the language. In C++, there is a very nice resizable (optionally bounds checked using vector::at()) that is implemented in the Standard Library.

    What D will implement in the core language is really meant for the standard library. Not everyone needs resizable and bounds checked arrays (the bounds checking is the one with the real overhead). If you are coding a kernel or something low level, the overhead isn't neccesary. If I don't need to resize my arrays, I just don't #include <vector>. Simple as that.

    Also, there are no prototypes. Now, tell me, how does one get the source for a 3rd party proprietary library and read the source for the documentation? Often times, I document my code by putting a 3 or 4 line description of what the class [member|function|data type] does below its declaration in the header. If I forget what a function does, I just open the header in another frame in emacs and read its description (which has such useful information as what it uses its arguments for, what exceptions it may throw, what it returns, and whether or not it will modify an argument). It is also much easier to see what members are in a class when you can look at a simple declaration with the outline of class, instead of having to wade through 50 line members to see the next member. That just makes the class look messy, unless each function was only 1 line long.

    The lack of operator overloading also makes it harder to implement something like, say, a complex number in a library. With C++, you have the standard complex type in the standard library. If there was no operator overloading, using complex would be more difficult (which is easier: complex foo, bar; foo.i = 1; bar.r = 2; foo.add(bar); OR complex foo, bar; foo.i = 1; bar.r = 2; foo += bar;).

    I do see some good qualities. One is the ability to call a constuctor from a constructor. This results in less duplicated code, and makes it easier to keep two constructors of a class synced. Say you had a class with two constuctors: one that takes no arguments (default) and one that takes an int argument. The int argument one can't call the default constructor (this creates a temporary, contructs it, and then deletes the temporary). D allows you to do that. Maybe the next C++ specification will fix that.

    D does seem to have a lot of flaws. It doesn't seem very useful. Maybe some people will find it useful. But it seems to me to be yet another language written for someone's personal usage. It makes sense to that person, but not to anyone else. C is a good language because its creators made it useful for other people as well as themselves, same for C++, lisp, Objective-C, and countless other languages.

  • templates and operator overloading are good things (Score:5, Interesting)

    by sanermind ( 512885 ) on Thursday August 16, 2001 @08:40AM (#2157829)
    It seems this guy really dosen't like c++. Now, being that he is a compiler implementor, I can certainly understand that! *grin*

    Templates and stack instantiation of of objects with semantics [i.e. constructors/destructors] is a royal pain in the a** for compiler writers. In fact, only somewhat more recently is g++ even able to handle templates in a decent way; it took a long time to get it right. C++ was a very ambitious language, hard as hell to implement, but that's what makes it so usefull. Give up templates and multiple inheirantance? He suggests this is a good thing?! D is clearly not a language innovation, he should have called it C--.

    Besides, you don't actually have to use such features extensively [or at all, really] in a C++ program. You could always avoid iostream and just #include old stdio.h, for example, only choosing to use classes with constructors for some usefull/neccessariy/labor-saving part of the code, while all the rest of it is essentially no different then C [aside from stricter compile-time type checking, which ANSI C has been moving towards anyway, lately]

    This is no innovation.

    A few other random points:
    Ohh! Garbage collection, you can link to a garbage collecting malloc in a C++ program anyway. [If you really care to look into it, C++ allows a whole range of complex underlying storage classes for custom memory management of different parts of a project.]

    Arrays are not first class objects?!
    Well, this is true, sort of. But you can choose to use vectors, [or other more efficient representations [such as maps, etc] depending on your data type, and with inlining, they will be as efficient as if they were 'native language syntax' features. You don't even have to use the STL, you can write a custom implementation of dynamicly resizable vectors of your own [with automatic bounds checking and resizing, for example] quite trivially. I did it once, and it took, what, 2 pages of source. That's the power of C++, it's so expressive for implementing custom manipulations of low level data, packaged nicely into classes.
    No on stack variables? All data as dynamic references?
    Yech. Generally too inefficient. I still suspect that he just dosen't want to tackle the hairness of writing such a complex compiler. Remember, you can use only dynamic memory in C++ easily enough, with garbage collection too.

    Overall, I think D is too lenient. I give him an F.

    Still, I strongly respect the desire to attempt to implement a novel language. Not that there aren't hundreds out there, but it's a noble effort. Still, publishing without even demo code? Yeesh.

    • I agree. I've been programming for real :) for about a year now. I'm starting to get really annoyed with java about the lack of operator overloading and genericity.

      I find it humorous, because two of the 'advantages' of java were simplicity through lack of support of templates and operator overloading.

      But, now that the language is mature, and the people using it want a more mature language, they are probably going to add genericity back in :).

      Which kind of leads me to the thought that, in general, the whole idea of 'leaving features out because they aren't used' is flawed. Leaving features out for other reasons is good. But perceptions of lack of use are not.

  • Sounds like... (Score:5, Interesting)

    by dmorin ( 25609 ) <dmorin@@@gmail...com> on Thursday August 16, 2001 @08:27AM (#2158083) Homepage Journal
    ...just a case of a guy who knows what he doesn't like about C/C++, and has the capability to do something about it, doing it. More power to him. Hey, if it generates traditional binary executable code so the end result is independent of the D language, and it really does have the advantages he says, then what does he have to prove to anybody? Create his own little company doing D development, crank out better product faster than anybody else, and take over the world. It could happen. If he's managed to create the language that he would prefer to work in, go for it. His only problem would be getting programmers. But it's not like D would be the first proprietary language out there.

    If, on the other hand, all he wants to do is sell compilers, and therefore he needs to convince the rest of the world of the language's benefit, then fooey.

    And for the record, damn, I feel old -- I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989 or so(?) and having problems. I think at one point or another I might have actually gotten email from Walter. Wow, names from the past. In a conference call yesterday I needed to come up with a secure hashing algorithm and I said "ROT13. If we need extra security we can do it twice." and absolutely no one got it.

    Anyway, back on topic: No templates? Oooooo, I have a C++ friend who is gonna be pissed....

    duane

    "In C++, you can look at your friend's privates."

    • I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989.

      Didn't Borland end up buying the Zortech compiler and turning it into Turbo C? There were a lot of C compilers back then.
      Which reminds me, back in 1987 I was working with the Computer Innovations CI86 compiler. The documentation was a few hundred pages of photocopies in a 3-ring binder, no tools, just the debugger and linker, but it came with the source. Find a commericial compiler these days that includes the source.

      • Didn't Borland end up buying the Zortech compiler and turning it into Turbo C? There were a lot of C compilers back then.

        No -- Symantec bought Zortech, turned it into Symantec C++, back when Symantec was into development tools; it had the coolest Windows IDE at the time, but like many other Symantec products throughout the years it died a silent death.

        Walter Bright probably did a deal with Symantec to acquire the rights to the compiler and development tools; essentially this the free C++ compiler available on the Digital Mars [digitalmars.com] site.

        Zortech may have been the first native C++ compiler, but TopSpeed had the better one, known as the fastest compiler around. TopSpeed had a common IDE/back end for C/C++, Pascal and probably some other languages. TopSpeed merged with Clarion and Clarion/TopSpeed was acquired by SoftVelocity [softvelocity.com]. Clarion isn't C++, but its compiler is probably still based on TopSpeed technology.

        • Thanks, I knew Zortech, Wizard, and Lattice were bought, but I got the buyers muddled.

          I think Walter Bright should be encouraged to keep doing what he is doing. Your comments about TopSpeed (I remember that one, too) are an illustration of how the software industry is going today; a small number of big companies buying a large number of small companies, with deminishing choices for the consumer. Let's encourage all the innovtion we can, even if we dont' think the idea is particularly sound.

    • I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989 or so(?) and having problems. I think at one point or another I might have actually gotten email from Walter

      Ah...the good ole days. I think in around 1991 I was dealing with a Watcom? C compiler under VM/CMS and was having trouble with something. I posted to a BITNET mailing list - nothing too major, and someone from Watcom actually called me like 10 minutes later after reading the post.

      Back when customer service was good!
    • Doesn't seem to me that D doesn't anything which can't be done perfectly well in C++ or Java, both of which are massively supported by contemporary technology. Inventing a language like this is fun and is a useful mental exercise, but is about on the same level of utility as trying to learn Klingon.

  • Nothing special... (Score:3, Informative)

    by frleong ( 241095 ) on Thursday August 16, 2001 @08:25AM (#2158095)
    • Dynamic arrays - Some juicy stuff that frees the programmer from using malloc, realloc. Copied from Java or Ada or _________________ ( fill in the blank, strip out unused characters)
    • Fixing some inconsistency issues of C's syntax - some purification to make it prettier - like switch/case accepting strings, using something.size, instead of sizeof(). Nothing by itself is absolutely necessary. Syntactic sugar.
    • Unicode character support - Interesting, but usually people just got used not to embed Unicode strings in the source code. Besides, they simply renamed wchar_t to unicode just to make sure that D supports Unicode.
    • No kididing. Anything you can do with switch statement you can do with if...elses. Even better, if...elses have way more flexibility (you can do strings, floats, objects, not just int/char). So that feature is not so important.

      Also, I like sizeof() since it's a feature of the language, not a class's function, so it shouldn't pretend to be a member function.

  • The only thing new is the name (Score:4, Insightful)

    by seldolivaw ( 179178 ) <me@seldo.DALIcom minus painter> on Thursday August 16, 2001 @08:16AM (#2158236) Homepage
    It's a nice name. I like "D" as a name better than C#. But that's all. From the description of the language, it's just Java without bytecodes -- but with "the option" of bytecodes. The major things it does is throw away legacy C compatibility -- making for faster compilers that are easier to write, but not a whole lot of gain for the programmer. However, maybe it would be good to have C++ updated and throw away unnecessary features, and more structured ways of defining things (like the try-catch-finally structure instead of try-catch, which I like the idea of).
    • Anyone who really knows the origins of the language "C" knows that its successor should be called "P" and not "D".

  • D already exists.. (Score:4, Informative)

    by gatkinso ( 15975 ) on Thursday August 16, 2001 @08:13AM (#2158250)
    It is a scripting language for a X Window based RAD tool called Telesys(? - maybe that was the name of the company that made the software).

  • weirdness (Score:3, Interesting)

    by seizer ( 16950 ) on Thursday August 16, 2001 @08:07AM (#2158370) Homepage
    I love the way there's a reserved word "imaginary" heh...

    He doesn't have any post-code gen optimization? I know you can perform elementary optimization onthe intermediate rep, (such as folding, etc), but he'll really need another phase if he wants to optimize for pipelines, which will vary from architecture to architecture? Tut tut. Maybe it's just an omission on his part.

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close