Hi, this is what I miss in D and Go.
Most developers that only used C and C++ aren't aware how easy it is to compile applications in more modern languages. It is funny that both D and Go advertise their compilation speed, when I was used to fast compilation since the MS-DOS days with Turbo Pascal. JVM and .Net based languages have editors that do compile on save. Most game studios that have changed from C++ to C# and Java as main development language always cite the productivity gain in the compile-test-debug cycle. I was a bit disappointed to find out that both Go and D still propose a compiler/linker model. -- Paulo "charlie" <[email protected]> wrote in message news:[email protected]... > 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.
