Skip to main content

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


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

Back to the top