From: MikkelFJ Date: 2001-12-14T09:06:53+09:00 Subject: [ruby-talk:28471] Re: RDE (was RE: RAA.succ (?)) "Curt Hibbs" wrote in message news:INEGJNJOFAMNDPNEABNEAEKDCHAA.curt@hibbs.com... > 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.