[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse.org-architecture-council] Javascript: a bug that makes me really sad....
|
On 2015-07-07 8:11, Sven Efftinge wrote:>
> That might work if that work is super cheap, but that is usually not > the case.
Running external parsers (actually having a parser service running, that got notified when files are changing) worked 25 years ago quite well, when workstations had single core processors running at 20Mhz. Today each of the 8 or 16 cores is 100 times faster, why should this suddenly be a problem ;-)….
If you still work with the same tools and the same amount of code, than that’s not a problem ;-) The real problem starts with the fact that each *DT maintains its own index and there is no higher level structure that allows defining dependencies between sub-parts of the system. In some way there has to be a hierarchy of scopes that goes beyond a single language.
Xtext has that and so does IntelliJ.
> IMHO it is a good idea having a dedicated plug-in that is > tailored to leverage exactly that (like Max mentioned) rather than > building a generic framework for possibly existing external tools.
Both approaches have their use cases....
In some way each *DT is a silo in eclipse. There is almost no code sharing between them. There is not even a common index or a common way to integrate external tools that provide information about file locations that works with all *DTs. Xtext simplifies that process by generating a good portion of that silo for each new language. But it's still silos….
That’s simply not true. Xtext provides a generic infrastructure for many languages, to play nicely together. As I said before keys to that are a common notion of ASTs and an index.
Sven |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail