D already has a history with heroes and great projects... Unfortunately, lots of dead great projects. IMHO, a monument to them should be set up.

Reasons:

1. If a project failed because of some design issues (e.g. Descent) new developers should be informed about a danger of this approach and ways to fix it (links to discussions of making a library from a compiler).

2. If a project failed because of past compiler bugs, lack of developers (DDL?) or other solved/solvable things, new developers should be able to easily find and start reanimation of this project.

Any thoughts?

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Thursday, 19 April 2012 at 10:00:29 UTC, Denis Shelomovskij wrote:
> D already has a history with heroes and great projects... Unfortunately, lots of dead great projects. IMHO, a monument to them should be set up.
>
> Reasons:
>
> 1. If a project failed because of some design issues (e.g. Descent) new developers should be informed about a danger of this approach and ways to fix it (links to discussions of making a library from a compiler).
>
> 2. If a project failed because of past compiler bugs, lack of developers (DDL?) or other solved/solvable things, new developers should be able to easily find and start reanimation of this project.
>
> Any thoughts?

Great idea. In particular, I would be interested to have more information about Descent :)

On 4/19/12 6:08 PM, Roman D. Boiko wrote:
> On Thursday, 19 April 2012 at 10:00:29 UTC, Denis Shelomovskij wrote:
>> D already has a history with heroes and great projects...
>> Unfortunately, lots of dead great projects. IMHO, a monument to them
>> should be set up.
>>
>> Reasons:
>>
>> 1. If a project failed because of some design issues (e.g. Descent)
>> new developers should be informed about a danger of this approach and
>> ways to fix it (links to discussions of making a library from a
>> compiler).
>>
>> 2. If a project failed because of past compiler bugs, lack of
>> developers (DDL?) or other solved/solvable things, new developers
>> should be able to easily find and start reanimation of this project.
>>
>> Any thoughts?
>
> Great idea. In particular, I would be interested to have more
> information about Descent :)

Things to learn about Descent:

 * It's impossible for one/two men to continually port a project from one language to another (C++ to Java in this case)
 * 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.
 * 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.
 * 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.
 * Maybe the project didn't recieve a lot of help because it was written in Java... don't know.

On 20/04/12 04:51, Ary Manzana wrote:
> * 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.

vim actually seems like a great development environment for D -- it was the first I could set up to really meet my preferences (I'm sure Emacs is also great, but I never got my head round it sufficiently).  The caveat being that my concept of IDE is "glorified text editor that has really nice handling of syntax highlighting and auto-indentation and in particular supports smart tab indentation with tabs for indent, spaces for alignment".

On Fri, Apr 20, 2012 at 05:15:36AM +0200, Joseph Rushton Wakeling wrote:
> On 20/04/12 04:51, Ary Manzana wrote:
> >* 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.
> 
> vim actually seems like a great development environment for D -- it was the first I could set up to really meet my preferences (I'm sure Emacs is also great, but I never got my head round it sufficiently). The caveat being that my concept of IDE is "glorified text editor that has really nice handling of syntax highlighting and auto-indentation and in particular supports smart tab indentation with tabs for indent, spaces for alignment".

I use vim, and would not touch an IDE with a 20-foot sterilized pole. Vim has decent auto-indentation, and quite configurable in what it does with tabs (expandtab, noexpandtab, tabstop, shiftwidth, etc.). I'm sure if somebody's willing to invest the time, you can do D autocompletion in vim too (but I've never felt the need for it).

One thing I miss, though, is ctags support for D. You don't know how powerful such a simple concept is; it lets you navigate 50,000-line source files without even batting an eyelid.  :-) (Just try that in an IDE, and you'll soon get an aneurism from trying to scroll with a 1-pixel high scrollbar...)

Vim/Emacs are the ultimate tools for programming IMAO. I mean, you can literally *implement* an IDE in Emacs if you're insane enough (heck, you can implement an entire OS in emacs if you lisp enough). Who needs klunky IDEs when *text editors* are that powerful?? ;-)


T

-- 
Creativity is not an excuse for sloppiness.

On 4/20/12 11:34 AM, H. S. Teoh wrote:
> On Fri, Apr 20, 2012 at 05:15:36AM +0200, Joseph Rushton Wakeling wrote:
>> On 20/04/12 04:51, Ary Manzana wrote:
>>> * 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.
>>
>> vim actually seems like a great development environment for D -- it
>> was the first I could set up to really meet my preferences (I'm sure
>> Emacs is also great, but I never got my head round it sufficiently).
>> The caveat being that my concept of IDE is "glorified text editor that
>> has really nice handling of syntax highlighting and auto-indentation
>> and in particular supports smart tab indentation with tabs for indent,
>> spaces for alignment".
>
> I use vim, and would not touch an IDE with a 20-foot sterilized pole.
> Vim has decent auto-indentation, and quite configurable in what it does
> with tabs (expandtab, noexpandtab, tabstop, shiftwidth, etc.). I'm sure
> if somebody's willing to invest the time, you can do D autocompletion in
> vim too (but I've never felt the need for it).

I use autocompletion in vim with a plugin that just offers every possible text found in all buffers. This has worked great for me in Ruby because every name is so intuitive and similar names (count, length, size) are provided as aliases so you almost never make a mistake when writing code (at least when writing the correct names, of course bugs lurk now and then.)

> One thing I miss, though, is ctags support for D. You don't know how
> powerful such a simple concept is; it lets you navigate 50,000-line
> source files without even batting an eyelid.  :-) (Just try that in an
> IDE, and you'll soon get an aneurism from trying to scroll with a
> 1-pixel high scrollbar...)

How do you implement ctags for a language? I know there is one for Ruby. What's the difficulty of making one for D?

On Fri, Apr 20, 2012 at 12:55:56PM +0800, Ary Manzana wrote:
> On 4/20/12 11:34 AM, H. S. Teoh wrote:
[...]
> >One thing I miss, though, is ctags support for D. You don't know how powerful such a simple concept is; it lets you navigate 50,000-line source files without even batting an eyelid.  :-) (Just try that in an IDE, and you'll soon get an aneurism from trying to scroll with a 1-pixel high scrollbar...)
> 
> How do you implement ctags for a language? I know there is one for Ruby. What's the difficulty of making one for D?

I've no idea, to be honest. Never done it before. I just use it for C/C++ code at work, and it works wonders. Makes code *soooo* much easier to find, esp. in a very large project with many developers. (Finding code without tags in large projects is just so painful and slow that nobody should have to suffer it.)


T

-- 
Why have vacation when you can work?? -- EC

"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jmqq77$1158$1@digitalmars.com...
>
> How do you implement ctags for a language? I know there is one for Ruby. What's the difficulty of making one for D?

I think someone already did that awhile back...

[digging...]

http://www.digitalmars.com/d/archives/digitalmars/D/announce/d2tags_-_converts_DMD2_s_JSON_output_to_Exuberant_Ctags_format_18248.html

https://github.com/Dubhead/d2tags

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

On Friday, 20 April 2012 at 02:50:39 UTC, Ary Manzana wrote:
> 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).

I don't have any prior experience with compilers. I doubt that there are many people who do *and* are willing to spend their time writing another (one more) D compiler. Resources on compiler design are widely available and it is actually more difficult to decide what *not* to do that to find [controversial] information how to do something "right". Actually implementing a compiler is more difficult than learning how to do it.

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

It's up to you to start from scratch or join some team :) I would not recommend spending time on it at all, unless you are really interested. I don't even know whether my own decision to do start from scratch was reasonable: there are too few differences between purpose of SDC and DCT (except that SDC is far more advanced currently). Possibly some time I will find it easier to reuse a lot of SDC code than to write my own. When I found SDC, I already knew what I want to do and how will I do it. I was amazed to see that some other people already made the same choices as I did in so many aspects.

Although I currently believe that starting from scratch was better for me, by doing this I have literally thrown away a lot of effort that other people already spent to make their compilers actually work. (Bug-fix them, design, fine-tune, etc.)

If you would like to get more results *in total* over the period of time you are going to spend on this, it is likely that you will get accomplished it better if you join the SDC team or use SDC as basis. Simply because you will not spend another two years making mistakes (arguably, some of those will be different from SDC or DCT or DMD or whatever other compiler's problems).

Please don't take my claims as if I thought I know your situation or have enough experience to give advice. This message is merely a sequence of random thoughts on the subject which are applicable to myself and even for myself I didn't decide to follow them.