tooling quality and some random rant

[Paulo Pinto]

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" <charl7n at yahoo.com> wrote in message 
news:ij95ge$119o$1 at digitalmars.com...
> 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.