As a person who's degenerated from budding contributor to lurker, I will second the notion that the Tcl code base does turn people away from contributing, but I would be surprised if it's enough people to make it worth changing. Incidentally, and FWIW, I did have to learn a language recently to work on a project (SCons, specifically), and I found Python somewhat easier to pick up that Tcl/Tk, but that could be specific to my background. Keep up the good work! Some day when I have time to learn Tcl, I'll be back. -- Sal smile. On Fri, 29 Dec 2006, Jordan K. Hubbard wrote: o No offense, but I think it's "just you". If MacPorts were written in o Python, you'd have Python haters jumping up and down saying that if o were only written in Ruby, they'd be happy to contribute to it. If o it were written in Ruby, you'd have Ruby haters saying the same o thing. If it were written in Perl, well, nobody at all would be able o to read the code and even the maintainers wouldn't know what it o did. :-) [OK, sorry, I couldn't resist]. o o The only argument that really has demonstrable merit is that Tcl o isn't as sexy or popular as, say, Ruby and if we'd gone with sex o appeal over simplicity, we'd probably get more people willing to o contribute for the sex appeal alone. That's true enough. However, o if it had been written in Ruby (or even C), I think it's also fair to o say that the Portfile syntax would look completely different since o you wouldn't get the basic "key value" notation for free and the o Portfiles would be some intermediate form with some sort of Fink-like o "escape" syntax for diving into Ruby (or, in Fink's case, shell) and o I think the Portfiles would be far more convoluted in exchange for a o sexier implementation language. But I'm just guessing here since o nobody really knows what would have happened had a different o evolutionary path been chosen. o o What is clear is that the existing Tcl code definitely needs to be o _refactored_ such that some of the data structures and routines for o manipulating them are re-written in C (all the ditem handling stuff, o for example) since nobody will argue that the current MacPorts o implementation is SLOW in the extreme. Tcl was never meant to do as o much of the heavy lifting as it is in MacPorts - it was specifically o designed to encourage the implementor to move performance-critical o stuff into C and easily move back and forth between the two realms. o Unfortunately, that "cleanup phase" hasn't happened yet. o o - Jordan o o On Dec 29, 2006, at 4:14 AM, Luc Heinrich wrote: o o > On 28 d�c. 06, at 00:13, Kevin Ballard wrote: o > o >> http://www.opendarwin.org/pipermail/darwinports/2002-October/ o >> 015354.html o > o > In my very own and personal opinion, Tcl is the single reason why o > MacPorts doesn't get as many external contributions as it should o > and is therefore so awfully slow to evolve. I have tried to dive in o > the MacPorts sources many times, read the Welch book, yadda yadda, o > and I still can't get past 3 or 4 lines of Tcl without giving up in o > disgust. Ok, maybe that's just me but still... o > o > -- o > Luc Heinrich - luc@honk-honk.com - http://www.honk-honk.com o > o > o > _______________________________________________ o > macports-dev mailing list o > macports-dev@lists.macosforge.org o > http://lists.macosforge.org/mailman/listinfo/macports-dev o o _______________________________________________ o macports-dev mailing list o macports-dev@lists.macosforge.org o http://lists.macosforge.org/mailman/listinfo/macports-dev o o -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University