Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] DLTK Ruby

Hi Daniel,

This is a great news and my failure not to contacting Chris before... Some time ago I tried to join forces with PHPEclipse project 3 times but do not succeed, because of 1) projects has own vision 2) concerns around platform vs. specialization, like PyDev developer thoughts at ...

So I believe this would not be easy to argue benefits and reasons for both projects after merging. As for RDT and DLTK Ruby everything happened very quickly: DLTK guys started to work on Ruby support heavily in February, after TCL 0.7 release. And on March, 5th (EclipseCon) suddenly both projects became "competitors"... Definitely no time to think and to talk about joining forces.

I do not know if we lost a time, but anyway I'll try to write Chris to hear from him on this issue.

Thank you for the message, and
Kind Regards,

Daniel Spiewak wrote:
Andrey, I talked to Chris Williams a while back and he said that he's never received an invitation to donate time to DLTK in the past, but he implied that he'd be quite willing. Are there any plans in the works to bring the RDT team into the mix?


On 4/7/07, *Andrey Platov* <andrey@xxxxxxxxx <mailto:andrey@xxxxxxxxx>> wrote:


    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
    (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
    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
    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
    of view Eclipse is little bit "strange" thing. End-user can install
    Eclipse Platform (about 40 MB of binaries with something probably
    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
    numbers shows interesting 10% trend, and very cool end-user user
    features definitely on the top of this trend (like 10% of 10% of
    = 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
    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
    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
    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
    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
    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
    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
    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
    > 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
    > 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 <mailto:dltk-dev@xxxxxxxxxxx>

    dltk-dev mailing list
    dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>


dltk-dev mailing list

Back to the top