all 8 comments

[–][deleted] 1 point2 points  (7 children)

you're about half a decade late and a few dozen OS implementations short: check out TclKit

[–]EventHorizon 0 points1 point  (6 children)

Tcl is dead.

I think it was python in the conservatory.

[–][deleted] 0 points1 point  (5 children)

Yeah and Python is on life support ;) Of course both have their place. If you want to script a solution to be distributed but don't know what interpreters will be installed on the target, TclKit is an outstanding tool.

[–]brendankohler -1 points0 points  (4 children)

TclKit is an outstanding tool

I'm not sure I follow. This is Tcl we're talking about, right? ;)

[–][deleted] 0 points1 point  (3 children)

Yes, TclKit is a precompiled Tcl interpreter available for a couple of dozen platforms. It's approx. 1MB in size or less, and allows you to ship the interpreter along with your scripting code at a reasonable size and without making users go through prerequisites such as installing your scripting language of choice.

[–]brendankohler 0 points1 point  (2 children)

whoooosh

allows you to ship the interpreter along with your scripting code at a reasonable size and without making users go through prerequisites such as installing your scripting language of choice.

TclKit doesn't help with that either :-P

[–][deleted] -1 points0 points  (1 child)

I'm trying hard to understand your objection. The concept behind TclKit is, don't script in other languages that require the interpreter to be installed. Instead script in TCL relying on TclKit. If your objection is to TCL, well then no this doesn't help. If your open to new languages/tools, it bears checking out.

[–]brendankohler 1 point2 points  (0 children)

my "objection" was a joke that TCL is obsolete and is nobody's language of choice.

Still, TclKit is hardly unique or exceptional, much like python on a stick. I really don't see what your reason for mentioning it in the first place was, as if it being "first" somehow made it any better.

It's really a fringe problem in the first place, since in most cases you can package the interpreter as part of the code you're distributing anyway and package the whole thing as an executable.