[Gridflow-dev] [piksel] Embedded Langs, was (open source hosting)

[Mathieu Bouchard]

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 
> beat.

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