Skip to main content
[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-04 18:05, Max Rydahl Andersen wrote:

On 1 Jul 2015, at 20:56, Oberhuber, Martin wrote:


With tern claiming support for Eclipse/Java , I'm wondering how much of a parser JSDT even needs ?
Perhaps syntax highlighting would be sufficient, with the rest offloaded to tern ?
http://ternjs.net/doc/manual.html#tern_java


You guys should come to our talks and discussions on this ;)

You just described what we are trying to get to. Allow us to use external tools (like tern etc.) since
the javascript world moves way faster than we can currently efficiently implement it in eclipse/java.


I really think this is an interesting eclipse architectural issue. The
level at which the eclipse platform supports language integration
great to build something like JDK. The building blocks are very low
level and many projects started by copying JDK or some similar project
The platform has no mechanisms to simply contribute any kind of
external (or even internal) tools. Each *DK creates its own editors,
views, index and extension points. They are not interoperable.

There seem to be a few attempts to solve the problem, like

- Xtext https://eclipse.org/Xtext/ (which is extreme, because it generates a *DK for
  each language)
- DLTK https://www.eclipse.org/dltk/ or http://www.ibm.com/developerworks/opensource/tutorials/os-eclipse-octave/
- LangEclipseIDE: https://github.com/bruno-medeiros/LangEclipseIDE/blob/master/README-LangEclipseIDE.md
- LiCLipse http://www.liclipse.com/supported_languages.html
- AntLng https://github.com/dschaefer/antlng
- ... (I am sure that there 5-10 more attempts to solve the problem)

There is not clear winner. It is the beauty of the bazaar.

The eclipse platform does not provide anything that allows to easily
add external tools and language support the way the popular editors
allow it (like Emacs, vim, Sublime, Atom, TextMate, Notepad++)...

Erich Gamma and his team believe the pendulum is swinging
from IDEs to (smart) editors:

   https://channel9.msdn.com/Events/Build/2015/3-680

Therefore VS Code takes the approach to integrate with external
tools. He also talks about progressive support for languages, starting
form simple syntax highlighting...

The really interesting thing is, that Walter Bischofberger
(he was on Erichs team in the early 90ies) wrote an interesting
paper on a lightweight IDE architecture for a tool called
sniff:
   "Sniff—A Pragmatic Approach to a C++ Programming Environment."
   http://www.ubilab.org/publications/print_versions/pdf/sniff_usenix_92.pdf

This paper is 23 years old, but I think the ideas described in the
paper are still very valid. I can see, how some of those (old) ideas
enter into VS Code. I have been working on the commercial version of
sniff for many years, and that my cause a bias in my thinking into
direction of that kind of architecture. (sorry Doug for repeating
myself for many years...)

I am not sure if a "council" can do anything about architecture, but I
believe that all the knowledge to do something is within the architecture
council. The question is how to execute to turn the bazaar a little
bit more into a cathedral. A cathedral needs architecture a bazaar only
needs a bit of coordination.

I hope eclipse is not one of the cathedrals that was created by great
architects, but the architects are gone, and the walls are still there
and although they provide nice places for the bazaar, the cathedral
slowly falls apart...


Michael


/max




Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6


-----Original Message-----
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of Michael Scharf
Sent: Wednesday, July 01, 2015 3:01 PM
To: Max Rydahl Andersen; eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] Javascript: a bug that makes me really sad....


Thus you at least don't get these bogus warnings/error markers.


+1 excellent. Not having some warnings is way better than
polluting the workspace with wrong error messages...

Does the parser work in that case correctly. I think the change in JavaScript that causes lots of problems is that keywords can be used as keys of objects and when there is a `.` before the word.

Classical lexer/parsers handle language keywords special.
I guess the PR solves this problem....

Michael

On 2015-07-01 13:45, Max Rydahl Andersen wrote:


wtp-dev is where you should raise this.

We have a PR for SR1 that will go in an disable this 1998 crappy validation.

Thus you at least don't get these bogus warnings/error markers.

/max



I am excited about mars being out. But there is a bug, that makes me
really really sad. The most popular eclipse package is JavaEE and it
contains JavaScript. But eclipse supports only JavaScript 1998.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=223131

The most annoying problem is that modern versions of javascript allow
keywords if they are part of a data structure:

promise.catch(function(){...});
var foo {
default: 42
}




Many libraries use `throw` and `catch` as methods on objects and this
causes a lot of errors and the rest of the file cannot be parsed.

I know there are a lot of different javascript solutions out there
that work better than this. But, the out of box experience with
eclipse is, well suboptimal.

Is there anything the architecture council can do about this?


Michael


_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-cou
ncil

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



/max
http://about.me/maxandersen



_______________________________________________
eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



/max
http://about.me/maxandersen

Back to the top