Let's give a honor to dead giants!

[Roman D. Boiko]

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. :)