Slashdot Mirror
The D Language Progresses
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."
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.
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.
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++.
Washington, DC: It's like Hollywood for ugly people.
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.
A deep unwavering belief is a sure sign you're missing something...
In an industry where the technology doubles every 18 months, for a language to last 30 years is an accomplishment.
If longevity of a language means much, then both Cobol and BASIC (Darmouth '66) must be even more fantastic.
Seriously, C is a powerful language, but I think its longevity relates more to the difficulty in porting legacy code than as a triumph in itself
Michael
There is no cryptographic solution to the problem where the intended receiver and the attacker are the same entity.
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.
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.
- 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.
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
- I don't need to go outside, my CRT tan'll do me just fine.
"you are not able to tell whether the form "if" is implemented as part of the "language" (whatever that means) or as a procedure in the same way any user could write it."
IIRC, "if" in Scheme cannot be implemented as a procedure because all the arguments to a function/procedure are evaluated before calling the function/procedure so that both the "then" part and the "else" part would be evaluated each time which would be bad if they cause any side effects.
However, Lisp and Scheme have very powerful Macro systems (Scheme's standard macro system trades some flexibility and power for security and ease of use) that allow one to rewrite much of the language using it.
I think that in most Schemes implementations "if" and many other control structures are not primitives but macros, but then, you cannot really tell the difference between a primitive syntactic form and a macro in Scheme/Lisp or, seen from the other side, you can extend Schem/Lisp with new syntax very easily and with nobody knowing that it isn't part of the base interpreter/compiler.
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
That's a logical fallacy. Just because C++ is commonly used successfully doesn't mean a certain part of C++ is commonly used successfully. Nor does it tell whether the success is due to the language's design or to the ingenuity of the programmers using the language. It's a very common thing for the cout identifier to be the only part of the standard library used by a C++ programmer. Other libraries provide similar functionality. So you can't assume that STL, for instance, is in use in each and every C++ product out there.
really need to invent a different language.
The D site provides a very good justification of the language's invention.
Washington, DC: It's like Hollywood for ugly people.
Actually that code is a work of art as far as I'm concerned.
Obviously, it wasn't originally written in the form that it shows up on that web page. In fact, the author wrote it in a much cleaner way and then used well known techniques for shrinking code size in C (with the help of a second author) to make a point.
The main point was: This is not a tough probably to solve, in fact 434 bytes is enough! ("lines" has always been a poor measure of complexity, so he chose bytes...)
A secondary point may have been: If Perl is supposed to be a compact and general language, C seems to beat the pants off of it in this problem space.
If you actually want to read the code and understand what it does, I'd suggest running it through a beatifier and then possibly changing variable names as you feel is appropriate. Or you could email the author and ask him for the original version...