From: Austin Ziegler Date: 2005-02-15T04:57:08+09:00 Subject: Re: [EVALUATION] - E01: The Java Failure - May Ruby Helps? On Tue, 15 Feb 2005 04:09:54 +0900, Ilias Lazaridis wrote: > Austin Ziegler wrote: >> On Mon, 14 Feb 2005 17:49:18 +0900, Luke Graham >> wrote: >>> Some of it is possible. I have created persistent Ruby objects, >>> for example. Persistent code is possible with some hacking, Ive >>> done something that at least looks like persistent Ruby code >>> from a distance, if you squint ;) Databases work. I use Ruby to >>> generate C code, so you can make generators with it. Its >>> open-source. It can be used remotely, there are packages around >>> to send code across networks. You can get stuck into a >>> reasonable amount of metadata for a language that isnt written >>> in itself. Anything else you really want to know? >> For everything except persistent code (e.g., persistent object >> state), you can use any number of options. > Can you name me a few, which would fulfill my stated requirements? > [like OOAD, scalability etc.] Your stated requirements are exceedingly vague, which makes it hard to recommend anything in particular, and I think that's part of the reason that your posts have not received much attention. It does *not* help that the format is hard to read and that the wording is (as I said) vague and buzz-wordish. >> However, for persistent object code (that is, saving the code >> behind a method), I think that the new work by Ryan Davis and >> Eric Hodel — especially the new AST to Ruby generator that was >> featured on RedHanded is probably a very good idea. I wouldn't >> be surprised if you could get the AST, store that, and then use >> the generator to restore and then #eval the resulting code >> later. > This sounds _very_ intresting to me, but I have to limit my > evaluation based on the current needs I'm not sure what you mean here, and what I'm talking about is a specific capability that I believe is able to be implemented through Ruby2C project offshoots. I will attempt to address your questions -- mostly with questions because I find your questions/requirements exceedingly vague. > http://lazaridis.com/case/stack/index.html The first question I have is -- what real solution are you trying to solve? Ultimately, the first paragraph of your linked page that you're not trying to solve a *real* problem, but rather trying to get a sense of what is possible and already available on various languages. > [simple] how can I create objects. > [simple] how can I make them persistent. > [simple] how can I create a generic GU > [simple] how can I create a generic Web GUI > [simple] how can I update the object model .... What do you mean by this? If you simply want to create a class and then instances of the class, it's very simply: class Foo ... # define your attributes and methods here[1] end x = Foo.new I'm not sure what you want beyond that. I've got several extensive projects -- as do many other people here -- which do a lot of object creation. My most complex example? PDF::Writer -- which is the *nastiest* object hierarchy that I've ever had to deal with, and it's because PDF is such a nasty, self-referential language. Persistence? Well, that depends on your persistence mechanism and framework. By default, as long as you don't have custom *executable* code that you need to save with your objects (e.g., callbacks), all Ruby objects are persistable. You can use the Marshal mechanisms (Marshal#dump and Marshal#load), you can write something yourself (as I did with Ruwiki::Exportable) or you can use YAML (thanks, _why) or XML (thanks SER). Ruby contains the PStore mechanism by default and the standard distribution provides dbd, sdbm, and gdbm backends. If you want live object stores, there's Madaleine (I think Anders B wrote this; there's actually two implementations of the concept, but this is the one that Instiki currently uses). If you want SQL-database backed stores you can choose from the DBI interfaces (providing Oracle, MySQL, Postgres) or other database interfaces (SQLite comes to mind). Don't want to interact with an SQL database directly? There's Og (thanks George), ActiveRecord (thanks Dave), Lafcadio (thanks Francis, and isn't there a Postgres equivalent by someone else?), and probably a few others that I've missed. ActiveRecord also integrates nicely with my own Transaction::Simple module that provides in-memory transaction support (which I must say is pretty darn cool). Og and ActiveRecord have application frameworks that surround them (Nitro and Rails, respectively), too, and they can be plugged into other frameworks with varying degrees of success and difficulty (Wee comes to mind, thanks Michael). Speaking of application frameworks, there's also Borges (thanks Eric), Iowa (thanks Kirk), and several others which I've heard mentioned but have never even looked at. Most of these contain templating engines, too, or use one of several other templating engines available -- Arrow (or is that a application framework), PageTemplate, the rdoc templating system (built into Ruby's distribution), ERB, Amrita, and others. Let's see -- that takes care of application frameworks, object creation and persistence and web UIs. With DRb, you can even build cluster support pretty easily -- and I wouldn't be surprised if the breakpoints framework that Florian Gross introduced could be made even cooler with DRb. Somehow. If it isn't already that cool, because Florian's a really cool guy and I can't keep up with everything that he does. GUI support? Well, it's a bit harder to have a generic GUI in Ruby. You can use Tk, but it's really not that pretty -- it won't look like anyone else's toolkit and I don't like using Tk applications. For some cross-platform GUI handling, you can use QtRuby, gtk-ruby, ruby-gnome, WxRuby (thanks Kurt and others), and the venerable FXRuby (thanks Lyle). I haven't used anything but FXRuby, but it took me less than two days to get an application running that supported either a command-line interface or a Windows GUI interface with FXRuby. Lyle was great in helping me to figure out a lot of this stuff. If you're not as interested in cross-platform stuff, then on Windows you can use swin and visualuruby; on MacOS X you can use the Cocoa bindings for Ruby. Generally, when you're creating an object model in Ruby, you have to design it by hand -- no UML tool outputs to Ruby (and UML is based around static class modeling in any case, so it's not an appropriate tool for Ruby projects). That's not nearly as big a deal as it sounds. Meta-programming is very easy in Ruby. I'm doing a bit of work with XBEL (XML Bookmarks Exchange Language) and I ported something from Python in about an hour -- and then I went on and created an XBEL::Node object that parses the XBEL information into Ruby objects in 41 lines of beautiful Ruby code. I think it could be 30 lines if I took out some XBEL-specific code I have in there. Ruby is the *perfect* choice for doing a lot of this stuff -- but there's a lot of choice out there, and you have to know a bit what you want to accomplish before the extremely helpful community can actually, you know, provide help. There's even some really cool technologies that Jamis Buck has done -- inversion of control in two different implementations (Needle looks interesting, but I still haven't played with it) and Net::SSH with Net::SFTP support. Indeed, Net::SSH can deal with the issue of remote deployment for you. FWIW, there's one thing that I'd recommend against very strongly -- you have a line-item in your requirements list about "migrade ORM/RDBMS to OODBMS." There's no such thing as a good OODBMS or XMLDBMS. You will *always* get better performance, flexibility, and scalability from a good relational database. OODBMS locks you into a particular data format (and it's one of the reasons that, although Madaleine is a cool technology and implementation, I think that prevalence databases are a very bad idea) that makes it hard to migrate real data. I've got a much longer rant on this that I did a year and a half ago or so on ruby-talk. There's a lot more, but the biggest problem that I see is that your requirements are so vague that just about anything could fulfill them. It's all a matter of how much pain you want to go through. Ruby decreases the pain you want to go through. Some of the technologies are new, but I've seen more well-designed code from the Ruby community than in the entire rest of my career. -austin [1] This is something that is able to be disputed. In Ruby, "attributes" are simply methods that are defined specially and appear to simply be attributes because Ruby encourages a principle of uniform access. -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca