[Gridflow-dev] [piksel] Embedded Langs, was (open source hosting)
matju at artengine.ca
Wed Oct 25 09:29:23 EDT 2006
On Sun, 22 Oct 2006, Mathieu Bouchard wrote:
> On Fri, 20 Oct 2006, vze26m98 wrote:
>> I'm certainly aware of your objections to Forth, but considering it's
>> something you're still mentioning, I'd suggest you discuss your objections
>> with Neal Bridges (Quartus) who runs the freenode channel #forth.
> This could be cool, but now I don't think that I'll change my mind anymore
> about which language I'll pick, as I have additional reasons that are hard to
Oh and I'd like to apologise for not letting anyone much time to help me
decide. I should have posted earlier about it. Basically I had already
talked to the people that I wanted the most to talk to, that is, Tom,
Dave, Chun, Alex, and some more, and what was needed was just putting my
reasons together on paper so that I don't forget any of them.
For some people it wasn't clear that by replacing Ruby by something else I
meant in GridFlow. Well, GridFlow is my only remaining Ruby-based project:
I abandoned my other Ruby projects in late 2001. Anything else Ruby-based
that I worked on later, was connected to GridFlow in some way.
I must stress that I *need* SWIG support, or support for something similar
to SWIG, but we already have SWIG experience so if switching to a
SWIG-like software it should be much easier to use than SWIG in order for
it to be worth it.
I'm choosing Tcl because:
1. it's the same language as in DesireData; so that makes less languages
to learn, for people who are into both projects or would like to; and I'd
like to make GridFlow a lot closer to Pd (and Pd as a language already has
some points in common with Tcl, not even counting the use of Tcl for GUI)
2. its simple syntax makes it malleable in a Scheme/LISP kind of way, as
well as less complicated to parse than Ruby, and less subject to whims of
the language designers (Ruby syntax changes every few months in ways that
often break GridFlow)
3. just like FORTH, Tcl doesn't have any GC (mark-and-sweep or
mark-and-copy garbage collection) and thus doesn't have any troubles with
GC. The way I heard Tom talk about Forth-Scheme combinations, it sounded
like "to GC or not to GC" is a main issue. The presence of GC is already
an issue to me: some GC systems themselves are not bug-free, as I learned
the hard way; but beyond that, in general, GC is less trackable (in a
debugger) than other memory-allocation strategies are, and is more trouble
in the case of realtime applications. Realtime is not that important if
only doing video, but if GridFlow is going to expand into the audio realm
as well, tighter realtime is required.
4. Tcl has more potential for OOP, even though it still doesn't have a
standard OOP model. It was easy for me to invent my own style of Tcl OOP
within 100 lines of Tcl code.
If I'm hitting a wall with using Tcl for GridFlow, I might try something
else, but I'm not sure yet what my second choice would be.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada
More information about the Gridflow-dev