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.
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.
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.