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

[Daniel J. Luke]

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 at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20061229/b46a1806/PGP.bin