View mode: basic / threaded / horizontal-split · Log in · Help
April 19, 2012
Let's give a honor to dead giants!
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
April 19, 2012
Re: Let's give a honor to dead giants!
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 :)
April 20, 2012
Re: Let's give a honor to dead giants!
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.
April 20, 2012
Re: Let's give a honor to dead giants!
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".
April 20, 2012
Re: Let's give a honor to dead giants!
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.
April 20, 2012
Re: Let's give a honor to dead giants!
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?
April 20, 2012
Re: Let's give a honor to dead giants!
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
April 20, 2012
Re: Let's give a honor to dead giants!
"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
April 20, 2012
Re: Let's give a honor to dead giants!
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. :)
April 20, 2012
Re: Let's give a honor to dead giants!
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.
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home