[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hello,
At the moment Ruby language gets most attention from DLTK developers.
The reasons are:
* We would not support Tcl OO extensions for 1.0 release, so Tcl support
(without OO stuff) is very strong (comparing to other languages), so
we're focusing on OO facilities for the core and languages we support.
* From implementation point of view (I'm not comparing languages
themselves here and further, just implementation issues), we found that
Ruby support would require some extra work and services within core
frameworks in comparison to Python... for example we could implement
Python code selection, infer and bind types less easily (this is
important entry point for many features like code complete and
refactoring). So if we'll do Ruby, we'll do most of other languages on
the same core.
As for DLTK and RDT, first of all our goal is not to overtake RDT in any
term, but become close to JDT in all terms... below some of my personal
random thoughts:
I'm trying to imagine roots of "hog wash" opinion. From the beginning
and up to M6 the team payed all the attention to the Core Framework.
Core is "Enabling Feature", and not end-user stuff. From end-user point
of view Eclipse is little bit "strange" thing. End-user can install
Eclipse Platform (about 40 MB of binaries with something probably useful
for end-user) and will get almost nothing in terms of the features. And
if end-user will add DLTK Core Framework (4 MB of binaries) to the
Platform, result will be the same: "nothing again". But... if end-user
will add DLTK TCL (0.4MB binaries) he will see explosion of the
features. So this 0.4MB (less than 1% of Platform + DLTK Core) will turn
"an IDE for anything and nothing" into fully-featured TCL IDE. BTW this
numbers shows interesting 10% trend, and very cool end-user user
features definitely on the top of this trend (like 10% of 10% of TCL IDE
= 4K of binary code, which is required to "materialize" another very
cool TCL IDE feature)...
There are not only technical reasons in putting a lot of efforts into
frameworks. Whole Eclipse ecosystem contribute to Eclipse Platform more
or less and in one or in another way. And amount of that efforts
definitely *huge*. DLTK is very young but DLTK Core already receives
contributions from different parties, and biggest "contribution" in
terms of reused (saved) efforts is JDT source code without any
exceptions... thanks EPL and Eclipse Foundation. Some interested in TCL
and contribute to TCL, others interested and contribute to Ruby, but
interesting fact, technically most of this contributions goes into core
frameworks and all the parties wins in terms of core stability,
improvements and common features... And this is great.
From technical point of view DLTK strategy is to build solid base for
language IDE implementors, and this is top priority task at the moment.
From community point of view strategy is the same: gather vendors and
interested parties around DLTK Core Frameworks. Important fact: since
project start DLTK's end-users were language implementors - not Ruby/etc
IDE users. This was absolute requirement to fulfill project technical
needs (see above). Does this mean we are not Ruby_IDE_user-oriented? No!
Now I believe all technical risks has been considered and we definitely
sure we're on the right way and DLTK Core Frameworks are quite stable
and complete, so development starting it's shift from the Core to
concrete languages. This is not fast process but it would not stop. On
the end of this process end-users shall receive powerful weapon, and
Eclipse Platform/DLTK Core/DLTK Ruby are the stages of ballistic missile
to deliver this weapon... And people who loads this missile with
concrete features will decide what kind of the weapon shall be.
If we'll continue analogy, RDT and some other projects, which are
initially IDE_end_user-oriented (and only this users forms their
community), we can compare their strategy with firing flares... Just
launch bla-bla flare of the week, and end-users are excited until the
next week. This is good approach to get a lot of users in short and
probably middle term, but I don't think it's good long-term strategy.
So back to initial question "how quickly could DLTK overtake RDT in
terms of its current feature set for Ruby development?". Honestly, not
an easy question. Keyword is *could*. If asked by engineer the answer is
"look into CVS - the answer is there", and I know the answer :)... If
asked by the end-user the answers like "tomorrow" and "never" are true.
Tomorrow because technically and in theory with or without RDT team we
*could* just copy-paste missed features from RDT code into DLTK core
and, hurrah, we took over them. Never because I believe there are some
features in RDT, which should not be responsibility of DLTK Ruby, but in
responsibility of the projects built on top of DLTK or other
Eclipse-based projects.
Anyway *do not* compete with RDT, but going to be close to JDT. And we'd
be happy if RDT guys could consider joining and/or contribute to DLTK to
develop JDT-alike tool for Ruby world.
As for summer, we're going to release great Ruby language support for
Eclipse with Europa, and if anyone would like to overtake RDT on top of
DLTK Ruby by summer I think this would be relatively easy task...
probably I'm wrong, but I'm not responsible for such a task :)
Kind Regards,
Andrey Platov
DLTK Team Lead
Mailing Lists wrote:
What is the commitment level of the DLTK developers to Ruby versus
other languages? It seems that with some of the commercial backers of
DLTK that Ruby support may not be a questionable priority versus some
other scripting languages.
Also, in terms of current DLTK development and RDT development,
realistically, how quickly could DLTK overtake RDT in terms of its
current feature set for Ruby development? I have seen that some folks
say that support could easily overtake RDT by summer while others have
said that this is "hog wash." Any thoughts/input?
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
