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.
Aside from the garbage collector and foreward declarations..
...damn ...smells like Object Pascal (Delphi) to me..except with "{" instead of "begin"
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.
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.
A runtime is a binary library that exports certain functions. The Win32 and glibc runtimes are a couple that Slashbots are probably somewhat familiar with. They have specialized routines that facilitate some kind action that the language itself does not directly support.
A VM is a completely different beast. It is a complete runtime environment for your program. Whereas a program that uses a runtime is typically compiled into machine code, a program that uses a VM is typically compiled at runtime from source (Perl) or parsed into memory from bytecode (Java).
It has become fashionable to call runtimes "VMs", especially in the Unix world where multiple APIs are supported on the same kernel, but it is a misnomer. (You'd expect the pedantry that is so prominent in the Unix culture to correct this, but I digress.)
I have been pwned because my
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.
I'm not sure if I should feel comfortable with the idea of code "called before main" combined with OOP.
What stops someone from writing a malicious routine called before main is run, and slipping it into a tainted version of a popular (how do you say library in OOPese?) A truly paranoid programme could run MD5SUMs on each library it requested functions from and say "okay, this is the libc.so.6 that came with Slackware 8.1, so it's good"... but it couldn't do that until it got to main, and the damage was done.
I can also see a problem with race conditions. Library A sets things up how it needs them before execution, and so does Library B. Is the order in which the pre-main code is run standardised? Even if it is, it seems to open the door for a lot of confusion, especially if you add a library in and suddenly things break because of non-immediately-obvious changes to the pre-main sequence.
OTOH, I appreciate that you aren't forced to do OO. I'll believe OO is a panacea when it buries me knee-deep in gold sovereigns, and smites my enemies with heavy objects. I don't think those functions are in the Java spec yet.
It's just like a fascist dictatorship, without the punctual rail service!
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)
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.
And right now, any new binaries which I need to write, I do them in Ada95. If D is somehow better than Ada then I will start using it when possible. Obviously if you are doing something which relies on c++ libs then just stick with that, but if you have the luxury of a new project, then hey what the heck use the new D compiler. Why not, anyways.
Clickety Click
There are some basic system facilities that have to be secure. This includes SSH for example.
Because of pointers and lack of bounds-checking, C++ is not it. Java doesn't interface with low-level system facilities very well. If this newfangled D language does all that, this may be the security Holy Grail.
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?
Most Lisp variants will fit that description (this includes Scheme btw). Legend has it that the creator first wrote a lisp parser in lisp (and it was pretty short), then it was first implemented when someone else converted that to machine code.
It's fairly common practice in lisp to have a program write subroutines on the fly because the code is made of lists, which is the basic data type.
Any function you add will look exactly like builtin ones from the outside, they're all called the same way (even math operators, like +). Macros for lisp are written in lisp. You can define a function then, in the same file, use that function *during compilation* with identical syntax to runtime code. Thus you can extend lisp with lisp.
You always can use C, or Objective-C if you want to program object-oriented.
You can use C++ if you think, programming C would be to easy. And you can use Java if you think, C would be too fast. :)
If you want to write a really big and complex application, you better add support for a scripting language (as Guile, Ruby, Perl or Lua).
And finally if you don't like that C doesn't has GC, just use some GC-lib.
- C source code compatibility - Yes. Wow, gosh.
- Link compatibility with C++ - No, can be linked to C++ Builder modules
- The C preprocessor - Yes
- Multiple inheritance (ie Full not Java-style) - Yes
- Namespaces (use modules instead) - Yup
- Tag name space - Yup
- Forward declarations (compiler searches whole module for name definition) - Nope
- Include files - Mostly 'Yes' but a little bit 'No'. Delphi does allow includes, but it doesn't
use them in the C/C++ sense; it imports binary symbol tables like D. Score
1/2.
- Creating object instances on the stack as opposed to the heap - Yes, dropped when Turbo Pascal
became Delphi
- Trigraphs and digraphs - Yes
- Preprocessor - Yes
- Non-virtual member functions - No, but the Delphi syntax copes better than C++ with the cited
problem (no error messages when you fail to supply a virtual base class)
by using an extra keyword - override - to signal programmer intent. Score 1/2.
- Bit fields of arbitrary size - Yes
- Support for 16 bit computers - I suppose 'No' since Delphi 1 was 16-bit.
- Mutual dependence of compiler passes - I think 'Yes', but I am out of my depth
- Compiler complexity - Probably Yes - deduced from Object Pascal's fast compilation. Besides everything
is less complex than C++.
- Distinction between . and
->. Yes - uses only '.' operator.
So 13/17. Better offers?"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...