golgeliyele Wrote: > It is a mistake to consider the language without the tooling that goes along > with it. I think there is still time to recover from > this error. Large projects are often build as a series of libraries. When the > shared library problem is to be attacked, I think > the tooling needs to be part of that design. Solving the tooling problem will > raise D to one level up and I hope the > community will step up to the challenge.
So far D 1.0 development has forced me to study the compiler and library internals much more than I could ever imagine. Had 10 years of Pascal, Delphi, and Java programming under my belt, but never really knew what's the difference between a compiler frontend and compiler. I knew the linker though, but couldn't imagine there could be so many incompatibilities. For example the Delphi community has a large set of commonly used libraries for the casual user. I also ended up learning a great deal of regexps because my editor didn't support D and don't feel awkward reading dmd internals such as cod2.c or mtype.c now. This was all necessary to use D in a simple GUI project and to sidestep common bugs. I really like D. The elegance of the language can be blamed for the most part. In retrospect, I ended up running into more bugs than ever before and spent more time than with any other SDK. However it was so fun that it really wasn't a problem. Basically if you're using D at work, I recommend studying the libraries and finding workaround for bugs at home. This way you won't be spending too much time fighting the tool chain in professional context and get extra points from the voluntarily open source hobby. It also helps our community. This newsgroup's a valuable source of information. Read about tuning of JVM, race cars, rocket science, CRT monitors, and DVCS here. We don't always have to discuss grave business matters.
