Re: [EVALUATION] - E01: The Java Failure - May Ruby Helps?

On Tue, 15 Feb 2005 04:09:54 +0900, Ilias Lazaridis
<[e-mail]> wrote:
> Austin Ziegler wrote:
>> On Mon, 14 Feb 2005 17:49:18 +0900, Luke Graham <[e-mail]
>>> 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 * [e-mail]
               * Alternate: [e-mail]