>>> firstname.lastname@example.org.EDU (Olin Shivers) writes:
>>> Tk is a terrible choice for a Scheme GUI. Osterhout, for reasons I
>>> cannot fathom, built tcl into the Tk functionality. This is
>> Scott Schwartz writes:
>> I disagree. It was a brilliant engineering decision, in the spirit of
>> Gabriel's worse-is-better paper. Tcl/Tk is simple, small, and highly
> email@example.com (Mark Friedman) writes
> But it could have been all that and more if he had just done the right
> thing in the implementation and separated Tcl and Tk. It was just
> plain bad engineering.
Let's distinguish "design" from "engineering".
I would agree the dependency of Tk on Tcl is bad design -- it violates
Ousterhout's stated principle of "Design for reuse."
I'm not sure I agree that the dependency of Tk on Tcl is bad
engineering -- the design flaw is pretty minor and easily correctable
meaning that the design flaw is arguably *good* engineering, presuming
it saved work.
I sat down with nm, grep, etags and emacs one day and worked it out.
To make the core of Tk language independent (or at least suitable for
Scheme) is at most a few weeks work. "Somewhere I even have a spec
on-line" (tm). Various people have already carried out approximations
The real issues are entirely practical and political. Will Ousterhout
choose to fold changes into tk that remove the dependency on Tcl? If
not, is it practical to fork Tk into two tracks of development?
One way to make it practical to have a Tcl-less Tk is if several of us
agree to the design and if we share the burdon of maintaining a fork
of the Tk sources.
Can we assemble a list of 5 experienced and motivated people who will
each promise, say, 24 volunteer hours per month for the next six
months? With anything close to that, I'd bet we could fork Tk
successfully and usefully. Anyone?