[ruby-talk:26411] Re: generating and serving SVG

"Robert Feldt" <[e-mail]> wrote in message
news:[e-mail]...
> On Sun, 25 Nov 2001, MikkelFJ wrote:
>
> > Primarily I would like a foreign function interface for SVG. Today there
are
> > documented very few language bindings (JavaScript) and I've found
nothing
> > about how to extend on this.
> >
> Please enlighten me as to what FFI means in this context?

It means Foreign Function Interface. Perhaps a better term would be Foreign
Object Interface or Foreign Class Interface.
In this context is means how the SVG engine can call external functions upon
events, and how external functions can modify the state of objects inside
the SVG engine.

> FYI: The existing Ruby SVG lib has the basic drawing primitives covered,
> as well as Style and a top document class.

I looked at the recent SVG posting about the GraphWiz/DOT library, but not
SVG lib. I assume SVG lib is pure XML rendering. While this has many
benefits, it is non-interactive and therefore a different issue. I have btw.
also looked at the GraphWiz tool which is also a rather cool technology
[I've seen so many cool things recently that it has been rather
counterproductive in terms of time spend]. I actually considered using SVG
for rendering GraphWiz output. It is therefore interesting to see this
solution posted in comp.lang.ruby. My current solution was simply to use the
postscript output with GS-view. Eventually it would be nice to interactively
be able to manipulate a graph... perhaps in SVGRuby.

> > If I may add a third cool technology of my 2001 discoveries, it should
be
> > OCaml (www.ocaml.org) - and I'd like SVG bindings to a GUI toolkit here
as
> > well.
> >
> If you like OCaml you might want to check out Clean. It's like Haskell but

I've been looking on many different languages recently, including Clean.
OCaml is cool because of a lot more things than just the language. OCaml has
some syntax quirks, just as Ruby has some quirks with e.g. @@ syntax. But
OCaml as a total package is the best development tool IMO compared to other
functional languages. And OCaml is actively developed by some extremely
competent people.

> with uniqueness typing (you can have destructive updates etc) and a
> compiler producing really fast code.

Clean was one of the closest competitors to OCaml in my investigation.
Clean appears to have a possibly competent but  immature development team.
The system appears to be more complex than the team is able to manage -
hence multi-year delays.
It is tied to one giant add-on library and is not easy to port.
Laziness is very powerfull. I've seen some scary stuff in Haskell. But most
actual applications seems to blow up until enough strictness is given that
you might as well have started out without the laziness. This is the number
one beginner problem in Haskell: "These four lines executes extremely slow
and uses all the memory. I've spend the entire weekend and don't know what
to do." The solution is usually simple once you get it.
In any case I considered the laziness to provide more damage than good from
a production point of view. In the cases where you really need laziness it
can also be done by other means like using higher order functions or using
Lazy stream libraries. Combinator parsers often mentioned with lazy
evalution can also be implemented in strict evaluation.
The OCaml  team decided on purpose to prefer strict evaluation because it is
the most useful evaluation most of the time.
Clean is fast - I've played a game implented in Clean. Really cool stuff
(and a decent Giana Sisters/Mario Bros ripoff featuring ducks :). OCaml is
also fast and has a very efficient garbage collector that IBM has now
grabbed and modified for an experimental Java platform. OCaml is just as
much imperative and object oriented as it is functional.

OCaml generates object code to many processors and platforms and bytecodes
to even more. It links directly with your C-compiler, C++ compiler, assember
and whatever. And you can create executable OCaml on the fly using the
bytecode compiler - which has been used to have OCaml being the syntax for
configuration scripts. (Ruby's load syntax easily does the same, but it
isn't statically typed and compiled).

Clean is a nice language no doubt about that and Clean'er the OCaml for
sure. OCaml never stroke me as beatiful like Ruby or Clean can be.

OCaml and Ruby have very compact code as a common denominator. Apart from
that they are very different and then strangely similar (in that you don't
have to write the types). Ruby is certainly easier to grasp at a first
encounter. I see Ruby is good tool for GUI development where OCaml can take
the place for most hardcore development that you would otherwise do in C++.

> Free but not fully opened yet but
> version 2.0 is about to be released and is rumoured to be open. This is
> strong stuff if your into lazy functional proggramming.

These rumours have been going on forever. I'm sure it will be open source
eventually.
But there are no plans for Unix support. (Funny since they do support Mac,
which meanwhile went Unix...).

MikkelFJ