This seems to be the start of that thread: http://www.opendarwin.org/pipermail/darwinports/2002-October/015354.html And actually, the explanation was by Landon Fuller. On Dec 27, 2006, at 4:22 AM, Pierre Queinnec wrote:

Search the old ML archives, that is DarwinPorts', not the MacPorts one. IIRC there's a mail by jkh@ explaining just that. -- Pierre

Jin Hyung Park wrote:

...

Hello :) Today morning, I just wonder Why does darwinports developers choose the tcl/tk for darwinports project? After 2001, there are lots of languages not only tcl/tk.. are there specific reasons for choosing tcl/tk? if anyone know, could explain for me?

-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com

On Dec 29, 2006, at 7:14 AM, Luc Heinrich wrote:

In my very own and personal opinion, Tcl is the single reason why MacPorts doesn't get as many external contributions as it should and is therefore so awfully slow to evolve. I have tried to dive in the MacPorts sources many times, read the Welch book, yadda yadda, and I still can't get past 3 or 4 lines of Tcl without giving up in disgust. Ok, maybe that's just me but still...

Maybe, but it was at least a sensible choice when the project was started and it's probably unreasonable to switch to something else given that we have over 3,702 ports (which are really just tcl programs). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+

On Dec 29, 2006, at 4:14 AM, Luc Heinrich wrote:

On 28 déc. 06, at 00:13, Kevin Ballard wrote:

...

http://www.opendarwin.org/pipermail/darwinports/2002-October/ 015354.html

In my very own and personal opinion, Tcl is the single reason why MacPorts doesn't get as many external contributions as it should and is therefore so awfully slow to evolve. I have tried to dive in the MacPorts sources many times, read the Welch book, yadda yadda, and I still can't get past 3 or 4 lines of Tcl without giving up in disgust. Ok, maybe that's just me but still...

Hey Luc, Yeah, Tcl is a bit hard to get used to. I had to learn it in order to make any progress on the MacPorts code. I have to admit that once I got into the mind set, I found it not so difficult...but it is different from many other scripting languages, though probably not so different as something like ruby or python. I agree that Tcl has held MacPorts back some. Another problem is just a lack of people with the time or inclination to work on base. I'd encourage anybody so incline to speak up and get involved. If there's enough mass, perhaps there's also some energy to do MacPorts 2.0 in ruby, or pyhon, or C, or... ;) And to make major steps forward in doing so. On "problem" with MacPorts at the moment is that it works "pretty well", which means that there's not as much energy to improve it, since it does almost all the job almost all the time. It's the more exceptional cases that bring in the difficulties. James

On Dec 29, 2006, at 2:43 PM, Jordan K. Hubbard wrote:

No offense, but I think it's "just you".

Despite how it's been a repeated complaint over time on the mailing list? :) There are at least few people who think it's a problem (not that I know one way or the other).

If MacPorts were written in Python, you'd have Python haters jumping up and down saying that if were only written in Ruby, they'd be happy to contribute to it. If it were written in Ruby, you'd have Ruby haters saying the same thing.

Perhaps, but in either case the pool of people who are familiar with the language is probably greater than the pool of people who are familiar with tcl.

If it were written in Perl, well, nobody at all would be able to read the code and even the maintainers wouldn't know what it did. :-) [OK, sorry, I couldn't resist].

It's possible to write good perl (just as it's possible to write difficult to maintain code in any other language), and it's silly to blame the language. [The International Obfuscated C Code Contest started in 1984, perl wasn't even released by Larry Wall until 1987].

The only argument that really has demonstrable merit is that Tcl isn't as sexy or popular as, say, Ruby and if we'd gone with sex appeal over simplicity, we'd probably get more people willing to contribute for the sex appeal alone. That's true enough.

Indeed. I imagine that most people working on this kind of thing for 'fun' are more interested in learning something new/interesting instead of tcl.

What is clear is that the existing Tcl code definitely needs to be _refactored_ such that some of the data structures and routines for manipulating them are re-written in C (all the ditem handling stuff, for example) since nobody will argue that the current MacPorts implementation is SLOW in the extreme. Tcl was never meant to do as much of the heavy lifting as it is in MacPorts - it was specifically designed to encourage the implementor to move performance-critical stuff into C and easily move back and forth between the two realms. Unfortunately, that "cleanup phase" hasn't happened yet.

Since things 'mostly work' and no one (that I know of, who is also currently active) has really bothered to get a good feel about base/ (combined with a lack of architectural documentation), it seems likely that this isn't going to happen any time soon either. [ Unless I get really really bored, or someone else decides to do it :-) ] -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+

On Dec 29, 2006, at 3:35 PM, Daniel J. Luke wrote:

On Dec 29, 2006, at 2:43 PM, Jordan K. Hubbard wrote:

...

No offense, but I think it's "just you".

Despite how it's been a repeated complaint over time on the mailing list? :)

I did state fairly clearly that Tcl obviously wasn't as popular or sexy, so sure, it stands to reason that we're going to see "Hey, why didn't you choose a more popular/sexy implementation language!" on the mailing list from time to time. Just as clearly, however, it's not unpopular or unsexy enough for some Ruby advocate to go re- implement MacPorts in that language, so this whole thread appears to be largely academic. If somebody feels strongly enough about the issue to actually come up with a replacement, they should do so. If they don't feel that strongly, then what we have is obviously good enough and there's no point debating the merits of Tcl if the only incentive is language bashing since there are better forums for pure language bashing than macports-dev.

...

If MacPorts were written in Python, you'd have Python haters jumping up and down saying that if were only written in Ruby, they'd be happy to contribute to it. If it were written in Ruby, you'd have Ruby haters saying the same thing.

Perhaps, but in either case the pool of people who are familiar with the language is probably greater than the pool of people who are familiar with tcl.

And, just to reinforce the point I made above, if someone from that pool would care to sit down and write a better software management system than macports, I think it would be well received since macports (or fink or gentoo or pkgsrc or ...) is clearly not the last word in software husbandry. I think the last word is quite a ways off from being written, in fact, given all the limitations that people have run into while trying to use those systems. The world is ready for a revolutionary approach, so bring it on. :-)

...

If it were written in Perl, well, nobody at all would be able to read the code and even the maintainers wouldn't know what it did. :-) [OK, sorry, I couldn't resist].

It's possible to write good perl (just as it's possible to write difficult to maintain code in any other language), and it's silly to blame the language. [The International Obfuscated C Code Contest started in 1984, perl wasn't even released by Larry Wall until 1987].

That was a joke, son. Not meant to be taken seriously. :) - Jordan