[handly-dev] Fw: Re[3]: working copy

[Vladimir Piskarev <pisv@xxxxx>]

I'm posting Vlad's response back to the list with his permission.

Vlad shares his real world experience and makes some excellent points
that I think would be of interest to Handly developers and might spur
an interesting discussion.

-Vladimir


> Hi! 
> 
> 
> It would be great to have another pair of eyes looking at my code, since almost a year now I am working on it all by myself. I'm taking the conversation off-list, as it might not be of general interest, but feel free to post back to the list if you think it is relevant..
> 
> 
> There are however some details that affect the way erlide and handly will benefit each other. The biggest problem with this project has always been that it's difficult to find people that know both Java+Eclipse and Erlang. I try to find ways to address this issue and I had two main alternatives: 
> - minimize the Java-related code by using Xtext
> - minimize the Java-related code by implementing the core functionality in Erlang
> 
> 
> I gave Xtext a try for a couple of years ago. It went well, but there were two big issues: Erlang has a C-like preprocessor with macros that may make the code look malformed and the Xtext parser choked on that; and there were performance issues for large files. So I was forced to abandon this track...
> 
> 
> There is already a lot of functionality that is implemented in Erlang, so the other option might work better. The idea is to have the model and all the IDE services implemented in Erlang, which would also let them be used by other IDEs than Eclipse. So on the Eclipse side there should only be a thin layer that delegates to the Erlang implementation.
> 
> 
> At the moment I'm trying to separate the functionality that will end up being reimplemented in Erlang, so that the work can be done without affecting other parts. The code model is only one part of it, but an important one. I think that the main problem will be how to keep the model synchronized between Java and Erlang -- change notifications would have to flow back and forth quite a lot. Here I think that a well thought-out independent framework like Handly would help a lot, because it extracts the generic parts that can be reviewed and tested separately. 
> 
> 
> Like I mentioned before, it would be great if there was such a framework for the rest of the generic language support; Xtext has something but is dependent on its own parser; DLTK has barely any documentation and is not very active either. Actually, I wasn't very hopeful about Handly either, until I read your "Get Handly" tutorials that are just great -- they make all the difference.
> 
> 
> Well, that was a rather long introduction, let's keep in touch.
> 
> 
> 
> best regards,
> 
> Vlad