Why does darwinports developers choose the tcl/tk for darwinports project?

[Salvatore Domenick Desiano]

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 at honk-honk.com - http://www.honk-honk.com
o >
o >
o > _______________________________________________
o > macports-dev mailing list
o > macports-dev at lists.macosforge.org
o > http://lists.macosforge.org/mailman/listinfo/macports-dev
o
o _______________________________________________
o macports-dev mailing list
o macports-dev at lists.macosforge.org
o http://lists.macosforge.org/mailman/listinfo/macports-dev
o
o

--------------
  Salvatore Domenick Desiano
    Doctoral Candidate
      Robotics Institute
        Carnegie Mellon University