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

On Sun, 25 Nov 2001, MikkelFJ wrote:

> > 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.
> 
Ok, now I see.

> > 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.
> 
Yes, its pure XML rendering.

> > 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.
>
Out of curiosity could you mention the other languages you considered in
the same deal? You seem to have done a pretty extensive survey.

> 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.
>
Yes, they seem to have problems; I recently found Clean and am not
up-to-date here. In a personal mail one of their researchers said they are
actively pushing for a release of 2.0 this year. But maybe they've been
saying that a couple of years... ;-)

> 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.
>
Oh yeah, thats right.

> 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.
>
Ok, but if you're used to laziness it can help you express difficult
things. Have you seen the combinator parser by Swiestra (I never get his
name right... ;-))? He builds table-driven parsers on the fly as the
combinator parser is used.

And you've seen that you can specify strictness in clean? Have you tried
it? I haven't had 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.
> 
You've convined me; I will take a deeper look at OCaml. Some problems I've
encountered the last time I took a look at it is that there is not much
papers/docs on its internals. Have you found something? I'd like to know
my tools to depth. I'm still very impressed with the speed the Clean team
can get in a lazy fp lang though.

Especially I'd be interested in documentation on the OCaml code
generator. Could be something to ponder for RubyVM.

> 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.
> 
No, I guess cleanliness is a main factor in making Ruby and Haskell my main
languages. Sometimes I need to add some C so its been Haskell for the
mathematician/logician in me, C for the speed-craving and low-level
tinkering engineer and Ruby for the human! Since I found Clean I'm
considering using it over Haskell. Seems to be few drawbacks and quite a
few advantages.

I'm a bit at odds with ML syntax after using Haskell for a couple of
years. I guess OCaml "feels" like ML?

> OCaml and Ruby have very compact code as a common denominator. Apart from
>
Yeah, but IMHO Clean would probably beat them both?!

> 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++.
> 
Interesting; I'll definetely check it out.

Thanks for your very informative post,

Robert