[
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
