The D Language Progresses 526
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."
Language overloading... (Score:3, Interesting)
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).
A Religion (Score:5, Interesting)
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).
Thou shalt use objective-C (Score:4, Interesting)
D Language from early 80's (Score:5, Interesting)
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.
Re:What is D? (Score:2, Interesting)
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.
The evolution of languages (Score:5, Interesting)
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. :)
Re:no value classes == no go (Score:4, Interesting)
`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++.
Re:What is D? (Score:2, Interesting)
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)
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.
I would like to have something else.. (Score:2, Interesting)
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.
Re:The evolution of languages (Score:5, Interesting)
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.
D == Java? (Score:5, Interesting)
Also, it's a bit funny that the preprocessor is mentioned twice under "Features to Drop." This guy must really hate the preprocessor. :)
Re:Thou shalt use objective-C (Score:2, Interesting)
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.
Re:Looks like they fixed all the problems except.. (Score:2, Interesting)
The garbage collector itself obviously couldn't be done in D, so it's out for that task, but once that's done, I fail to see any reason why D couldn't be used at the kernel level.
As for random pauses and the like, D has some functions for controlling the garbage collector. In particular, you can suspend the collection process (though objects are still tracked) during some speed-critical process, then re-enable it. Additionally, if I read the spec right, D's garbage collector runs incrementally and it runs in its own thread.
D also has structs and auto classes, which can both exist on the stack. From what I've done with D, they fulfill the need for value types pretty nicely. (it'd be nice if structs could have constructors though)
By the by, I did some quicky (read: wildly inaccurate and completely useless) benchmarks with DMD. As it is, it finished the Sieve of Erathostenes a bit quicker than the C# version. Not a bad for an alpha.
Re:Contracts (Score:3, Interesting)
Re:slick C++ with Ada-like techniques? (Score:2, Interesting)
Here's the state on the GCC backend. That project is run by Jan Knepper, who at this time and for the forseeable future has no time to spare for it. GCC is the most amazingly opaque piece of software internally, which makes this a pretty serious project needing someone who can make a pretty serious commitment. Once that time comes, I figure it will be three months after that point for the GCC port to be well-functional.
It is probable that there soon will be a better solution for Linux than my crap-generating port, which is also missing more recent D features. Let's just say that in my opinion it will meet the needs of every Linux i386 user, and being far faster than GCC while producing high-quality code will be a good advantage in that market.
Why not use an existing modern, well-designed one? (Score:2, Interesting)
Where is Algol68? (Score:4, Interesting)
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 :-)
Re:Where is Algol68? (Score:2, Interesting)
Algol68-to-C by Sian Leitch
(Source appears to be somewhat Debian-centric. I haven't managed to compile it on NetBSD yet.)
[xs4all.nl]
Algol-68G
(Works fine with NetBSD-i386, I suppose it would on sparc too.)
-Lasse
hacker's language (Score:2, Interesting)
D - Not for beginners! (Score:3, Interesting)
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
I've Known Walter a Very Long Time (Some History) (Score:5, Interesting)
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.