The One With D

C-Style Declarations in D

There’s a thread in the digitalmars.d.D NG right now regarding support for c-style declarations in D. A small number of people are asking for it to be deprecated. Walter’s take is that it adds very little overhead to the parser, makes porting C apps easier for some people, so if you don’t like it don’t use it. In this argument, I’m on Walter’s side.

The arguments for removing it have been pretty weak - basically that it’s ugly and it complicates the language syntax. Walter already shot down the second argument (very little parser overhead). And really, who cares if it’s ugly? Is one of D’s design goals to be the most syntactically beautiful languages out there (whatever that means)?

If I were to make an argument against it I would point out one of the major complaints people have with C++ - it supports too many paradigms. While some people find this a strength, others find it a flaw. By supporting multiple paradigms you make code maintenance and readability complicated, and the language becomes more difficult to master. D already supports multiple paradigms (procedural programming, object oriented programming, generics/meta programming). While support for c-style declarations doesn’t really constitute a paradigm, supporting them serves to potentially make reading and maintaining D code a bit more complex just because it makes more than one way to make the same declaraion. This is particularly problematic for people who don’t have a C background. But considering how often we have to work with legacy C code in D anyway, I don’t see that it’s a major issue.

I generally don’t chime in on threads like that one, but if you feel strongly about the issue one way or the other, you might want to speak up in the thread (titled C-Style declarations, are they here to stay?!! Walter?).

Posted in Discussion | 2 Comments »

Phobos Answers

Yesterday, I talked about how some in the D community think Phobos is lacking in one way or another. Rather than waiting and hoping, some enterprising individuals created new projects to address some of the perceived deficiencies. If Phobos is missing some functionality you need, or if you think some of the existing functionality does not meet your needs, perhaps one of the projects below can help you out.

One of the most ambitious projects at DSource is Ares. This library was created by Sean Kelly as a full replacement for Phobos. To use it, you must replace the stock DMD phobos library with the one built when you compile Ares. From the Ares forums:

The Ares project aims to produce a fully functional standard library for D. This library is being designed from the ground up with robustness, consistency, and usability in mind, and as such, it does not aim to be a interface-compatible with Phobos. To allow cross-compilation however, Ares will include a Phobos compatibility package for programmers who want to use both.

Sean accepts submissions from the community. If you like the project and want to speed it along, help the guy out!

Deimos is a project that started out as a place to incubate extensions to Phobos. Unfortunately, the project maintainer has not been seen in any D related forum in quite some time. Although the project is currently dead, there is still some useful code in the repository. Some of it may need to be modified to make it work with current DMD/GDC versions.

Another ambitious project (and one I am extremely interested in) is DDL (D Dynamic Libraries). Java programmers coming to miss often miss Java’s reflection and dynamic class loading. D’s reflection system is weak compared to Java or C#. And being statically compiled it has no mechanism for dynamically loading classes. DDL aims to improve upon the situation by allowing dynamic loading of compiled object files. Project founder Eric Anderton (better known in D circles as pragma) has put some comprehensive documentation online. Here’s a blurb from the About page:

DDL is a multi-faceted technology. It can be used as a plugin architecture, a replacment for DLL files or as a means for working with intermediate files. It is presently in Beta, with a release scheduled for mid 2006 as an SDK and Utilities bundle (both suitable for end developers).

DDL Features

• Loading intermediate (binary) files in OMF, ELF and COFF formats
• Runtime linking of binary files, under Windows and Unix environments
• A common wrapper format (.ddl) that will accelerate runtime linking and binary file management
• Command-line utilities for examining and manipulating binary files
• Interface for examining binary file contents at runtime
• Completely D-coded library, suitable for use under Windows or Unix

How’s that for neat? DDL could ultimately allow D programmers to implement some of the tricks Java programmers are used to. Put this one in your Bookmarks folder.

I would be remiss if I did not mention Mango in this post. Mango is one of the oldest (if not the oldest) projects on DSource. Originally billed as a servlet engine, the library has evolved since its inception to include a number of packages which provide features that are either are not available in Phobos or serve as replacements for some Phobos modules. IO, logging, internationalization, low-level system utilities… it’s full of good stuff. As a bonus, Mango’s source is the cleanest and most nicely formatted D code I have ever seen. I should also mention that Mango can be compiled to use Ares rather than Phobos with a version switch.

Posted in Discussion | No Comments »

How Would You Like Your Phobos?

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 »

Debuggers, GUIs and IDEs

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 »

Derek Parnell’s Build Utility

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 »