Re: Availability of OS X-specific features

Kevin Walzer wrote:

> One of the things I'm finding with Tcl/Tk is that they are a very
> powerful programming toolkit, but a knowledge of lower-level, more
> hardcore programming (specifically C) is necessary if you want to
> customize or extend the functionality of the language.

Kevin,

That is pretty much true of any "interpreted" language. By definition.

Any given language [X] includes a core set {A} of features. Utilizing
those features, and those only, contained in {A} is referred to as
"programming" in language [X], and is the design of language [X].

Extending the feature set {A} of language [X] requires modifying
language [X] itself, usually in the language [Y] that language [X] is
written in.

The only exceptions to this rule are "languages" which are
feature-complete for their given platform: machine code, assembly.

C and other languages might be considered in this category if their
compiler package supports generating ALL opcodes for their given
chipset, but, generally speaking, even C is used 99.9% in the same
manner that Tcl is...

That is, Tcl and other languages, generally speaking, are different by
design. I tend to think of them as running on a "platform" which is an
OS, not directly on hardware. It is the abstraction that makes them
efficient, but which also makes them harder to extend by the average
user, because it requires programming in the parent language.
Unfortunately, an OS and its graphical extensions is a much more complex
"platform" than a processor, so these languages tend to be less
feature-complete.

> Hence I am wading
> slowly into the complexities of programming C. It's the only way to
> really get what you want from Tcl/Tk if you don't want to depend on the
> kindness of others.

True enough. A measure of a language's utility is perhaps given by the
ratio:

   feature_completeness / complexity

> Of course, even though learning C is no picnic, you don't have to spend
> all your time there: moving into C for the Tcl/Tk additions that you
> want and then moving back into Tcl/Tk is certainly easier than becoming
> a full-bore C/C++/Objective-C Carbon or Cocoa programmer.

Indeed, and extensions for accessing binary libraries native to the OS
are a stopgap measure intended to bring the feature-completeness factor
up to 100%. Unfortunately, from what I've seen, they have the tendency
to increase the complexity factor significantly, by essentially
requiring EVERYONE WHO USES THEM to learn C in order to comprehend the
library functions you will be calling; a vast increase in
feature-completeness with a corresponding increase in complexity.

In such a case, it may, at times, be worthwhile for the user to drop
directly into C/C++/Whatever using the Tcl libraries (change of language
entirely), or to write a Tcl extension to make a small subset of new
feature available at the Tcl level (small incremental increase in
feature-completeness without increasing complexity).

I'm not knocking extensions such as ffidl. They do what they're
intended to do, for their intended users. Just that their user-base is
not the same as the entire Tcl/Tk user-base.

Good luck!

-- 
MKS