[ruby-talk:28471] Re: RDE (was RE: RAA.succ (?))

"Curt Hibbs" <[e-mail]> wrote in message
news:[e-mail]...

> The binary download is about 15MB, 36MB is for the source. Personally, I'm
Fair enough. The J++ and .Net IDE's which clearly served as inspiration are
also huge.

> I'm less concerned about startup time, than I am about post-startup
> responsiveness -- this is what really counts.
True - it was merely an observation about Java load delays.
> On this score the Java
> implementation of Eclipse probably has an edge over Ruby, (that should
> change over time).

You should see the same Java delays whenever you start a new plugin in the
IDE.
For GUI development it is not the speed at which you can filter primenumbers
but the responsiveness that counts.
Ruby is very responsive if written cleverly. The FxRuby OpenGL is a clear
demonstration.
You can view Ruby in two ways

1) slow because it used hashes for method calls
2) fast because the unavoidable hash lookups are integrated with the core
language.

> I originally planned to do a pure Ruby implementation, and mostly I would
> even prefer to do that. But I this is also something that I want to use in
> my day-to-day work, and I don't want to wait several years to get there. A
> lot of volunteers to help could really push this into an all Ruby project,

We need a better understanding - what does eclipse provide and what do you
have to provide.
Where is the most work.
I agree that eclipse supporting the worlds languages would be cool - it may
also eventually be the case.

On the other hand I hate to think of Ruby as an inferior language where you
can't develop proper applications. One of the reasons that I do show some
interest in Ruby is because I believe it to have a potential that is beyond
what languages like Java has to offer. If I want to filter primer numbers
I'd choose another language anyway.

> hint, hint :-)

I'm convinced that if you can get the plugability organized by looking at
eclipse, you have a lot of very smart people ready to help you out.  I have
seen the speed at which applications gets developed in Ruby.
Nobody says that you can't have other languages developed in a Ruby IDE as
well.
This is a very real opportunity to show that Ruby kicks ass.

Back to the design - what can Eclipse provide, that you don't have - except
for 3 windows, a GUI toolkit and a great design? It may have a CVS plugin,
and it does have ActiveX support on Windows, but apart from that?

Here is the deal:
You need a source code editor with syntax highlighting. Granted - Ruby is
probably too slow for this. Wrap Scite in a ruby framework - at least for a
start. Be sure to keep a generic interface inspired by the eclipse model.
Use the JFace GUI-interaction model of eclipse to pass on GUI actions
(notice the clever action concept).

I do have an intercomponent cross-language datastructure named the
CellModel, that I haven't yet taken to Ruby, but expect to do so (an
interface to it, that is). This may form the core plugin framework. I'm not
fully decided on whether to go open source - it's not rocket science but
carefully designed - and far from complete. One inspiration for it was the
need to handle IDE infrastructure but the concept pops up everywhere. I may
elobarate in this concept sometime - but: A cell kan have a set ports, each
port has a set of receptors and one (possible more - undecided) signature. A
port can accept a connection from another port if the foregin signature
matches its receptor, likewise the foreign port will have to accept the
other port. A port a can accept, 0, 1 or more foreign ports, forming X-to-Y
relationships. It all boils down to fully navigationable cell relationships
that are very easily described. This means that you can add to a thingy to a
treelist control, and the thingy will know about the container, and the
container will know about you. Or you can use a variable in programming
language and associate it with scope, references and other relevant
concepts. If you change the name of the variable, all relationships remain
unchanged. This structure also extends to all kinds of pluggable
relationsships with very few lines of code. The prototype core runs in C/C++
and navigation objects can be written in any language (I have C++, C# and
soon OCaml I hope). Ruby is the perfect language for creating a transparent
interface to the model. Hence you can easily connect to objects handled in a
different programming language. The model is designed for distributed and
persistent operation as well - but that is only a design. This was before I
knew Ruby, but Ruby reflection and Mixins do have some similarities,
although the CellModel is not a programming language (at least not yet). It
is actually inspired by how biological processes dynamically interact with
things that match their perception of reality, but which they do not know
otherwise. Ruby is a bit of the same in that you can execute known messages
on unknown objects. The CellModel doesn't execute, but provides for
structure and therefore communication across boundaries. It is btw. also a
good way to implement UML diagrams. Other than Ruby being a surprise to the
CellModel, Apect Oriented Pogramming also popped up as an surprise, because
the CellModel do not support inheritence because there is not strict
hierarchy on realworld object relationships. It is more like Mixins and like
the way cells mutate by grabbing dna from elsewhere. Rubys ability to mutate
either using mixins or just extending an existing class builds on some of
the same concepts.

> SWG is very interesting. However, it would not be as easy as this to port
to
> Ruby. The C layer of SWG is purposefully designed to be as small as
> possible, with as much of the code as possible being written in Java.
That's the interesting part of it.

> They use native widgets where possible, and where there is no sufficiently
> functional native widget, they implement their own.

To speed up the porting process, this can be wrapped into FxRuby or the
like, but given the standard interface, you can replace any SWG widget with
Ruby / C source as you like. The key is that they defined the interface at
the right place, not too low, not too high.

> and we would miss out on having a single integrated environment that can
> easily handle projects with mixed technologies (is my bias towards larger
> applications showing here?).

This is very true. An IDE only doing Ruby is of limited relevance compared
to the mixed language approach.
Anyway given the speed people work with in Ruby, it may get the innner lane
on this.
I mean - in other languages - cooool a distributed application. In Ruby, oh
business as usual - whats the big deal. What!? - my XML parser is only 90%
compliant - well here's the fix.

Get the IDE up in Ruby - as they say at Eclipse: The proof of the pudding is
in the eating. Eventually we will have better engines to execute Ruby on.