On Friday, 20 April 2012 at 02:50:39 UTC, Ary Manzana wrote:
* D needs to be implemented as a library. This means no global
variables and means to make it easy to build tools on top of
it. I know of about two alternative new implementation of D
(SDC and DCT) but for now they are making the same mistake as
DMD: they use global variables. Also, the developers of those
projects don't seem to have experience in writing compilers so
the code is not very nice (though I saw a visitor in DCT).
People suggest me to send pull requests or open issues to SDC,
but if the main design has a big flaw it's better to start from
scratch than to change the whole code.
As for DCT, I am going to write a little more about its
development soon. But my strong belief is that its impossible to
build a good design before you know *deeply* the domain (from
practice, not just theory). The highest priority is to make
things work at least for a minimal subset of language before
introducing flexibility.
I do not commit to finish the project as a production ready D
compiler with 100% specification conformance. The reason is that
I have too little resources available to make that happen. But I
*can* guarantee that DCT is going have good design AND will be
reused (and thus reusable) in at least several projects.
I resisted introducing visitor as long as I could (although I
knew that I will have to do that some time). One reason is that
there are many ways to implement a visitor, and once you choose
one, it is quite difficult to switch. The other reason is that I
wanted to find what I need most from it. I mean, one to three
most important usage scenarios which would be awkward to
implement the other way.
Global variables will stay there for some time, unless somebody
would prioritise eliminating them as important enough to
implement it themselves (and not add some more *working* code).
The reason is simple: it is far easier to cut a project into
cohesive units this way.
Design should be done, well, thoughtfully. Cutting a big piece of
code into smaller units should be done in a such way that there
will be at least:
* few module dependencies (low coupling)
* emphasis on domain concepts (aka ubiquitous language, but I'm
not going to build a DDD system here ;)
* probably most importantly, SOLID public interface modules with
high afferent coupling (but better SOLID implementation)
* no high-level dependency cycles
Writing a compiler is not going to be fun. There will be a lot of
fun, but it is possible that 80% of time will be spent on routine
things which, apparently, don't need a fancy design.
It is difficult to get right before you actually know what are
the problematic aspects and actual *usage* scenarios. I could
optimize a lot from the beginning, but made my best to avoid
doing it. KISS.
* Eclispe is great for writing IDEs but after programming in
Ruby for some years now and exclusively using vim I can't go
back to using a slow IDE so I don't think I'll ever write
anything else for Eclipse.
One of my goals is to extend VIM and Sublime Text to be better
suited as D IDEs.
* Maybe it's better to implement things from scratch instead
of starting with a project like JDT and modifying its source
code to be usable as a D IDE. Though in the beginning you go
faster later it slows you down more and more.
Yes, I thought a lot before starting the project from scratch
myself. This seems to be a better option, at least for me. :)
