Descent has a problem: it supports D1 very well (kinda) but good D2 support is still far away.  The latest dmd versions I ported it to are 1.045 and 2.030. Porting from 1.045 to 1.050 should be fast (not many front-end changes). Porting from 2.030 to 2.035 is heavy because a lot of changes were introduced.

In both cases porting is a slow (and boring) task: checking the diffs between each file, finding the matching function if it already exists or creating it, copying the code, translating it to Java, then translating some bits of code to Descent (it's a bit more than just copy, past, change size_t to int, remove stars). Doing it alone is really, really slow and boring, but I have no problem doing it from time to time, like maybe 10, 15 minutes each day.

Another problem with porting, specially to D2, is that when I'll finish porting to 2.035 there will probably be a 2.037. Maybe some changes that were applied in 2.035 were roll backed or changed a little, so perhaps I should wait for D2 to become frozen and then port. Either way, I'm afraid that when I'll finally have good D2 support there will be a D3 in the way. When I stabilize Descent more or less (write a lot of tests, improve memory and performance, etc.) maybe the situation that exists now will repeat itself: D2 will be more or less stable but some people will be focused on D3 because it's the new thing, Descent won't support D3 because it's a moving target and because it's not backward compatible with D2, so I'll start porting to D3 but D4 will appear, etc.

And I think this situation doesn't only affect Descent but many libraries and tool suffer from this constant upgrades in D. I think this situation sucks. :-P

Finally, D's userbase is not huge so I really can't tell if Descent is useful enough (and there are the people that prefer to code without an IDE, or with a lighter one).

So... what should I do?

For now I decided to wait, and even maybe abandon the whole idea of keeping Descent up-to-date until D becomes more successful (more probability of people helping me).

Ary Borenszweig wrote:
> Descent has a problem: it supports D1 very well (kinda)

Definitely wait for D2 spec to finalize before incorporating it.

Question: how much of DMDfe do you have in descent? As in how much
effort do you spend keeping each of lexer, parser, and semantic up to date?

Ellery Newcomer wrote:
> Ary Borenszweig wrote:
>> Descent has a problem: it supports D1 very well (kinda) 
> 
> Definitely wait for D2 spec to finalize before incorporating it.
> 
> Question: how much of DMDfe do you have in descent? As in how much
> effort do you spend keeping each of lexer, parser, and semantic up to date?

It's not hard, it's just tedious and long. But I don't think it can be automated. :(

But it's the one tasks that is most needed, because with those things not up to date users can't fully take advantage of it.

Hello Ary,

> So... what should I do?
> 
> For now I decided to wait, and even maybe abandon the whole idea of
> keeping Descent up-to-date until D becomes more successful (more
> probability of people helping me).

Pleas do keep working on it. The only reason I don't use it more is because 1) it doesn't like ultra heavy meta-programming and 2) it doesn't support having stuff scattered across several computers and OSes like I have. One of these days I'll fix the second issue.

Ary Borenszweig wrote:
> Ellery Newcomer wrote:
>> Ary Borenszweig wrote:
>>> Descent has a problem: it supports D1 very well (kinda)
>>
>> Definitely wait for D2 spec to finalize before incorporating it.
>>
>> Question: how much of DMDfe do you have in descent? As in how much effort do you spend keeping each of lexer, parser, and semantic up to date?
> 
> It's not hard, it's just tedious and long. But I don't think it can be automated. :(
> 
> But it's the one tasks that is most needed, because with those things not up to date users can't fully take advantage of it.

let effort = tediousness and longness

what is the ratio of effort spent keeping lexer vs parser vs semantic up to date?

I'm exploring whether it would make more sense to use a parser grammar (e.g. ANTLR) or to keep the lexer and parser that you already have. If you're spending a lot of time with the lexer and parser, then it might. (see, I'm using descent as a case study :)

So far my philosophy has been use the parser grammar because it's easier to maintain, less prone to bugs, and, at least for D1, the only changes across DMD releases in the parser are bug fixes, most to all of which don't exist in the generated grammar. Of course, the flip side is error reporting sucks, performance sucks (seriously, it takes the thing 10 freaking seconds to parse Tango!), and you still have to do something about semantic.

Ellery Newcomer wrote:
> Ary Borenszweig wrote:
>> Ellery Newcomer wrote:
>>> Ary Borenszweig wrote:
>>>> Descent has a problem: it supports D1 very well (kinda) 
>>> Definitely wait for D2 spec to finalize before incorporating it.
>>>
>>> Question: how much of DMDfe do you have in descent? As in how much
>>> effort do you spend keeping each of lexer, parser, and semantic up to
>>> date?
>> It's not hard, it's just tedious and long. But I don't think it can be
>> automated. :(
>>
>> But it's the one tasks that is most needed, because with those things
>> not up to date users can't fully take advantage of it.
> 
> let effort = tediousness and longness
> 
> what is the ratio of effort spent keeping lexer vs parser vs semantic up
> to date?

semantic >>>>>>>>>>>>>>>> parser = lexer

Ary Borenszweig дµ½:

> Descent has a problem: it supports D1 very well (kinda) but good D2 support is still far away.  The latest dmd versions I ported it to are 1.045 and 2.030. Porting from 1.045 to 1.050 should be fast (not many front-end changes). Porting from 2.030 to 2.035 is heavy because a lot of changes were introduced.
> 
> In both cases porting is a slow (and boring) task: checking the diffs between each file, finding the matching function if it already exists or creating it, copying the code, translating it to Java, then translating some bits of code to Descent (it's a bit more than just copy, past, change size_t to int, remove stars). Doing it alone is really, really slow and boring, but I have no problem doing it from time to time, like maybe 10, 15 minutes each day.
> 
> Another problem with porting, specially to D2, is that when I'll finish porting to 2.035 there will probably be a 2.037. Maybe some changes that were applied in 2.035 were roll backed or changed a little, so perhaps I should wait for D2 to become frozen and then port. Either way, I'm afraid that when I'll finally have good D2 support there will be a D3 in the way. When I stabilize Descent more or less (write a lot of tests, improve memory and performance, etc.) maybe the situation that exists now will repeat itself: D2 will be more or less stable but some people will be focused on D3 because it's the new thing, Descent won't support D3 because it's a moving target and because it's not backward compatible with D2, so I'll start porting to D3 but D4 will appear, etc.
> 
> And I think this situation doesn't only affect Descent but many libraries and tool suffer from this constant upgrades in D. I think this situation sucks. :-P
> 
> Finally, D's userbase is not huge so I really can't tell if Descent is useful enough (and there are the people that prefer to code without an IDE, or with a lighter one).
> 
> So... what should I do?
> 
> For now I decided to wait, and even maybe abandon the whole idea of keeping Descent up-to-date until D becomes more successful (more probability of people helping me).


 should not use java to write descent, but should be written about him by the direct use of d , it's would be more easily.
java is too slow.

Thank you for your jobs !

dolive

Hello dolive,

> should not use java to write descent, but should be written about him
> by the direct use of d , it's would be more easily.

All/most of eclipse is in Java so decent more or less needs to be in Java. The next choice would be the C++ that DMD is already in.

> java is too slow.

Lots of people will debate you on that.

Ary Borenszweig Wrote:

> Descent has a problem: it supports D1 very well (kinda) but good D2 support is still far away.  The latest dmd versions I ported it to are 1.045 and 2.030. Porting from 1.045 to 1.050 should be fast (not many front-end changes). Porting from 2.030 to 2.035 is heavy because a lot of changes were introduced.
> 
> In both cases porting is a slow (and boring) task: checking the diffs between each file, finding the matching function if it already exists or creating it, copying the code, translating it to Java, then translating some bits of code to Descent (it's a bit more than just copy, past, change size_t to int, remove stars). Doing it alone is really, really slow and boring, but I have no problem doing it from time to time, like maybe 10, 15 minutes each day.
> 
> Another problem with porting, specially to D2, is that when I'll finish porting to 2.035 there will probably be a 2.037. Maybe some changes that were applied in 2.035 were roll backed or changed a little, so perhaps I should wait for D2 to become frozen and then port. Either way, I'm afraid that when I'll finally have good D2 support there will be a D3 in the way. When I stabilize Descent more or less (write a lot of tests, improve memory and performance, etc.) maybe the situation that exists now will repeat itself: D2 will be more or less stable but some people will be focused on D3 because it's the new thing, Descent won't support D3 because it's a moving target and because it's not backward compatible with D2, so I'll start porting to D3 but D4 will appear, etc.
> 
> And I think this situation doesn't only affect Descent but many libraries and tool suffer from this constant upgrades in D. I think this situation sucks. :-P
> 
> Finally, D's userbase is not huge so I really can't tell if Descent is useful enough (and there are the people that prefer to code without an IDE, or with a lighter one).
> 
> So... what should I do?
> 
> For now I decided to wait, and even maybe abandon the whole idea of keeping Descent up-to-date until D becomes more successful (more probability of people helping me).

Ary,

You have done a great job with Descent to date.  Thank you; I've been using
it every day since I started with D about 5 weeks ago.  Part of my
reason for using it happens to be that I'm regularly looking at past
Java projects and trying to get a handle on recoding some of these
in D so having both D and Java editors at hand (via Eclipse) is convenient
for me at the moment.

To be honest though I feel Eclipse is becoming less appealing year after year .. seeming as though it's now past its prime.  To be honest, Eclipse is just not a snappy, responsive code editor anymore (if it ever was).

There comes a time, like now since you are asking, when it becomes a
good idea to stand back, have a look around, have a rethink
(where you want to go / what you want to get out of developing Descent)
and then regroup accordingly.

FWIW, try googling on Lua IDE's and see what that throws up.  In some ways Lua and D have some commonality in trying to achieve big by being little. Also D and Lua communities are both relatively small (compared with Java, .Net, C++) so there might well be some mutual sympathies :-)

Here's a random link from stackoverflow that I just pulled up:

http://stackoverflow.com/questions/143939/whats-a-good-ide-to-use-for-lua

Anyway, my main reason for replying to your post is to encourage you in whatever you decide to do with Descent.  Myself though, I wouldn't waste too much time on moving targets.

Take care,

Justin Johansson

Ary Borenszweig Wrote:

> So... what should I do?

You've done a great job with Descent!

As long as D2 is not stable, you don't have to support DMD2's latest version - i doubt that there's a lot of ppl who will develop something serious on an alpha version of language (maybe except KorDen).

Please, do not drop D1 support for Descent! I've found it the only IDE fully suitable for D1 crossplatform development, and i'll use it a lot for a couple of projects. Java may be slower than $LANG, Eclipse may be huge, but Descent works good and there's really no alternatives for a good IDE for D.