tooling quality and some random rant

[golgeliyele]

I wonder if we can get something positive out of this discussion. I would like to enumerate a few possibilities for the several
things we discussed:

1. Difficult to understand linker errors due to missing main():
  Fixing this would be useful for newbies. If there is not already a defect on this, I suggest we file a defect and it gets fixed
sometime. I am assuming that this can be caught before going to the linker. Does dmd support creating an executable
whose main() comes from a library? If not, the compiler would know if there is a main() or not before doing the linking. I
can see how this is a problem with incremental builds though. However, with the compilation model that is being advocated
by the documentation (i.e, feed dmd all the .d files at once), the compiler should know if main() is there or not. Yet another
reason to clarify the compilation model, IMO.

2. dmd compiler's command line options:
  This is mostly an esthetic issue. However, it is like the entrance to your house. People who are not sure about entering in
care about what it looks like from the outside. If Walter is willing, I can work on a command line options interface proposal
that would keep backwards compatibility with the existing options. This would enable a staged transition. Would there be
an interest in this?

3. Incremental compilation (or lack of it)
  First of all there is a documentation problem here. There needs to be clarity about whether incremental compilation is
possible or not. I won't count approaches that work partially as anything more than a stopgap solution. IMO, it is acceptable
if we can state that dmd compilations are blazingly fast, and as a result, there is no reason to do incremental compilation.
The problem is that I get mixed signals on this point:
  - If this claim is true, then I think it should be asserted strongly and should be backed up by numbers (100K library
compilation takes X seconds, etc.)
  - If this claim is false, then we should look at enhancing the tooling with things like xfBuild. Perhaps that kind of
functionality can be built into the compiler itself. Whatever is needed, the following needs to be clearly documented: What is
the best way to organize the build of large projects?

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.

One last thing: Personally, I don't like this business with .di files. They are optional, but then they are needed for certain use
cases. I believe the information that is contained in .di files should be packed alongside the shared library and I should be
able to build/link against a single library package. I haven't used Java for a long time, but I recall you get a .jar file and
javadoc documentation when you are handed a library. I like that.

p.s.: Does anyone know what the best way to use this newsgroup is? Is there a better web interface? If not, is there a free
newsgroup (on a Mac) reader that is easy to use?