Archive for January, 2006
Friday, January 20th, 2006
Walter is a man with very tough skin. I would have flipped out a long time ago. One of the most difficult things for me in opening a project to the world is the stinging criticism that comes with it. I’m not talking about a commercial project released to the general populace. I expect some people to just not get it and blame it on me when they don’t (though I do try to minimize the odds of that as much as possible). But like I said in the last post, programmers are a picky lot. They are also highly critical and difficult to satisfy. When I was a medic in the Army, we had the saying, “Medics are the worst patients.”
One of the nitpicks D newcomers (and some oldtimers for that matter) have center on Phobos, the D standard library. I agree with the general newsgroup consensus that it isn’t complete and needs some work done on it before a 1.0 release goes out the door. Debating what’s right, what’s wrong, and what’s broken about Phobos is just opening a can of worms, so I won’t do that here. There are plenty of those on the newsgroup if you want to join in on one.
The D newsgroups are largely civil. Actually, it’s the most civil online discussion community I’ve had the pleasure of participating in to date (though I lurk for the most part). But there are a lot of highly opinionated members in the community. Just as everyone has their own reasons for being drawn to D, they have their own ideas on where the language should go. The standard library is a big part of that. I recall one discussion regarding std.loader (which was contributed by Matthew Wilson). Some people wanted a free function, C-style API. Others wanted an object-based API. The end result was a module that supports both.
That spirit of compromise doesn’t always work though. Complaints about one part or another of Phobos crop up with some regularity. Some people word their complaints strongly. Adjectives like ‘ridiculous’ and ’senseless’ are sometimes used to describe certain features. The reason is likely that the poster hit on some stumbling block in a current project and sent the post in a fit of frustration. I’ve done that in other places more than once.
My point is, getting Phobos ‘just right’ is an impossible task as there are such diverse views on what ‘just right’ is. Getting it ‘right enough’ is a good goal. The community definitely speaks up when they think it isn’t ‘right at all’, so I think we ultimately will see a Phobos that is ‘right enough’.
Anyone can submit a patch for Walter to include in Phobos. Several existing modules were contributions from community members. That’s one of the great benefits of using D right now is the ability to contribute. Don’t be shy in letting Walter know what you think is broken in the library and what you think should be fixed. More importantly, don’t be afraid to contribute additions and fixes. There’s no guarantee any contributions will make it in, but the possibility exists.
It’s not often we have the opportunity to help shape a programming language into the one we’ve been dreaming of. D is on the ground floor, so now is the time to hop on board. Help make the standard library the one you want to use. And if you get frustrated because there’s no sleep function in the thread class and post about how ridiculous that is on the newsgroup, don’t worry about Walter. His skin is made of granite.
Posted in Discussion | 2 Comments »
Wednesday, January 18th, 2006
Programmers are a picky lot. I often read comments from people who aren’t interested in trying D because of one ‘deal breaker’ or another. I would guess that the top 3 are: no debugger, no GUI library, and no IDE. I fail to see how any of these can be a deal breaker for trying a language. Sure, for production work with a large team it could get in the way. But I wouldn’t bank a project in that environment on a pre-release language anyway. Regardless, the ‘no debugger’ complaint is not entirely true. On Windows, there is some support for debugging D apps with the Visual Studio debugger and with Windbg. You miss the ability to view some D-specific features however. The Digital Mars development system CD ships with a version of Windbg that has better support for D. You can also use gdb on Linux.
On the GUI front, several community projects have sprung up over the last few years. Most of them stalled at one point or another. Currently, there are a handful of active projects. Two of note are wxD and DWT.
wxD is a set of bindings to the wxWidgets library. One interesting aspect of wxD is that D is not compatible with C++ at the binary level. You can link C libraries with a D app out of the box, but not C++ libraries. It takes a bit of effort to create D bindings for a C++ lib.
DWT is a port of (not a binding to) the Java library SWT from the Eclipse project. DWT was one of those GUI projects that stalled. Shawn Liu took it over last year and has made leaps and bounds with it since.
If you are looking to do development with D and need a GUI library, wxD and DWT are your best bets right now. DWT has the advantage of being pure D, meaning all allocations happen in the GC space. Depending on your project, this may be a big factor in deciding which to use.
As far as IDEs go, the pickings are slim. Like the GUI projects, several community projects have sprung up and either disappeared or just died. Aside from stand-alone IDEs, I have also seen plugins for Eclipse and Code::Blocks, and on the newsgroup recently someone announced one for Visual Studio 2005. I can’t really recommend any of these as I’ve never tried them, but one stand-alone IDE generating a lot of buzz lately is Poseidon. Developed by Shawn Liu using DWT, it serves as a testbed and demo of DWT’s progress. From what I gather, several newsgroup regulars have begun using it. Me, I’m still using Crimson Editor in conjunction with Build and the command line. Until D gets an IDE with all of the whiz bang features of Eclipse, I don’t really have any use for one.
Posted in Discussion, GUI, IDE | 4 Comments »
Tuesday, January 17th, 2006
Compiling and linking a D project is no different than compiling a C or C++ project. Fitting since the D front end relies on C back ends (DMC on Windows, GCC on Linux). Digital Mars provides a version of make with the DMC++ compiler tools, which is required when one installs the DMD compiler. For those (like me) who don’t have the patience to learn the innards of yet another version of make, Derek Parnell has come to the rescue with Build.
Build is a wonderful tool. Feed it one D source module and it will follow all imports and compile everything your project uses (much like javac does for Java). Build goes farther. One thing it does is define a special version. D does away with the C preprocessor and in its place allows for a ‘version’ statement. Anything wrapped in a version statement will not be compiled if the version is not active. Some built-in versions are: Windows, linux, BigEndian, LittleEndian, X86. There are compiler-specific versions, such as DigitalMars. You can define your own versions on the command line, or via assignments in the source file (version = someversion, which is only good at module scope in the module in which it appears). Build allows you to special case code when it is used. Wrap up your special Build-only code with a version(Build){ } block and you’re good to go. When compiling via another means, such as make or the command line, that block of code will be ignored (unless you explicitly define the ‘Build’ version yourself on the commandline). When using Build, that bit of code will be compiled in for you.
Build also does more parsing of your source modules than just looking for imports. One thing it looks for is a special pragma. D, like C and C++, allows for vendor-specific pragma statements. Compilers should ignore unrecognized pragmas. The Digital Mars implementation defines a ‘lib’ pragma which allows you to specifiy link libraries in source rather than on the command line (as with VC++ - this was one of the features requested by the D community that Walter added). Initially, the lib pragma was only implemented on Windows (DMD now handles it on Linux as well). Build searches for its own special pragma, called ‘link’, which serves the same purpose as the ‘lib’ pragma. There’s a difference between the two.With the link pragma, you don’t need to specify a file extension. As long as the library names are the same on both Windows and Linux, build will link them in with the one statement (so you don’t need to version them).
On Windows, Build will recognize if you have a WinMain or main function. If WinMain is present, it passes the appropriate arguments to DMD to compile a Windows GUI (no console) app. If both main and WinMain are missing, it will create a library for you instead. Additionally, any command line parameters accepted by either Build or DMD can be stored in a special Build Response File. I typically make two brfs for my D projects - projectName_debug.brf and projectName_release.brf. I create them both at the start of the project (usually by copying from another project and editing some paths) and never touch them again. Building projects then becomes a one-liner: “build @projectName_debug”.
The DMD compiler is blazingly fast. I doubt you’ve ever seen anything that compiles as quickly (though DMC comes close). One of the reasons for this is that D is designed to be easily parsed - compiler writers need help as much as the programmers who use their products. Build adds so little overhead that it is not even noticeable. I maintain a project at DSource.org called Derelict (a collection of bindings to C libraries that can be dynamically loaded, such as OpenGL and SDL). Initially, I relied on make files to build the Derelict libraries. Those days are gone, and now I use Build exclusively. I use it for all of my D projects as well. Build is also showing up in community-created IDEs.
Derek Parnell has created a real gem. The only downside to Build is that it currently doesn’t work with GDC (to my knowledge). If you are using DMD and not Build, then something is sorely amiss!
Posted in Discussion | No Comments »
Sunday, January 15th, 2006
If you’ve been around C++ for a while, you may remember the Zortech C++ compiler. The man behind the Zortech compiler was Walter Bright. Now, Walter runs a company called Digital Mars. He’s still in the business of C & C++ compilers, but he also has a new baby - D.
Rather than try to explain in my own words what D is, I’ll use Walter’s:
D is a general purpose systems and applications programming language. It is a higher level language than C++, but retains the ability to write high performance code and interface directly with the operating system API’s and with hardware. D is well suited to writing medium to large scale million line programs with teams of developers. D is easy to learn, provides many capabilities to aid the programmer, and is well suited to aggressive compiler optimization technology.
D is not a scripting language, nor an interpreted language. It doesn’t come with a VM, a religion, or an overriding philosophy. It’s a practical language for practical programmers who need to get the job done quickly, reliably, and leave behind maintainable, easy to understand code.
D is the culmination of decades of experience implementing compilers for many diverse languages, and attempting to construct large projects using those languages. D draws inspiration from those other languages (most especially C++) and tempers it with experience and real world practicality.
The above is taken from the overview page of the specification. If your interest is piqued, check out the entire overview for more information on why D was created and what problems it is meant to solve.
There are several projects under development with D. Many can be found at DSource.org, others are scattered around the web. In this blog I will try to colocate the latest D news along with my views and experiences with the language.
As of now, D is pre-1.0. Walter has been in bugfix mode for several months and there are still updates being made to the standard library. I encourage you to give it a spin and see what you think. Many of the regulars in the newsgroup come from C++ and/or Java backgrounds. They share the belief that D is the best of both worlds and then some. And the best part is, the community does have an impact on the direction of features for both the language and the compiler (though no new language features are being added for a 1.0 release unless they are huge, but 2.0 is wide open).
The reference implementation, DMD (Digital Mars D) is available on Windows and Linux. There is also an open source implementation being developed by David Friedman on top of the GCC toolset, GDC. It is available on Windows, Linux and Mac. If you are interested, follow the links from this site or visit the D newsgroups to learn more and see how you can contribute to the growing D community.
Posted in Discussion | 3 Comments »