Imagine a language in which was so easy to write code that code flowed from a thousand keyboards, simply and correctly.

• nobody would ever re-use code, they'd just write it again from scratch.
• nobody would ever fix someone else's code, they'd just write another version with different bugs and more of the features they wanted.
• nobody would ever have to worry about the architecture of underlying code, because nobody would ever have to interface with their code anyway.
• there'd be little demand for repositories of code ... why bother? Except as templates for their personal rewrites, nobody ever need look at anothers' code.

Imagine a language where it is so easy to roll your own OO system that you forget that code reuse was one of the key reasons you did it.

Is that what we've got ourselves in Tcl?

If so, Tcl is a victim of its own success.

This page is for qualities of Tcl which properly fall simultaneously into both Things holding Tcl back and Things pushing Tcl forward, because the interplay between those two categories is what will steer Tcl toward what it will become, or will cause it to stick in place. Sometimes one relies too heavily on that which one does best, to the detriment of other things.

RS 2004-09-20: I have to admit that often in Tcl coding, my brain is the code repository - some frequently used procs like K, every, lambda, lpick, lreverse, or algorithms like cartesian/polar conversion, just flow into the keyboard as needed...

---

Imagine a language with a rich set of core features that work consistently and predictably. Imagine not having to rely on batteries included libraries outside of the core (i.e. libraries written in the language itself which aren't always subject to hardcore unit testing and regression testing and don't religiously catch every potential error condition). Hey, wait a minute. That's why I chose Tcl over other so-called scripting languages. Tcl's core language keywords (really more like libraries) work. While tcllib is wonderful, I tend not to rely on it for mission critical apps -- tcllib is great for getting things done quickly without duplicating a lot of effort. But, I tend to use C code (exposed to Tcl) for hardcore stuff where everything must work flawlessly and every potential error condition must be considered. This is not a criticism of tcllib, but a praising of Tcl core: Each core command must be carefully considered. Each operational behavior must be well defined. Each command must integrate with Tcl's error handling semantics and mesh well with others. For me, Tcl core is great because it works as expected -- always.

Like RS, I can roll my own procs on top of the core, without surprises. (I can't tell you how many times I've broken add on libraries written in Perl, Python and even Tcl). -- Todd Coram

jblz Colin, this reminds me very much of "The Lisp Curse": http://www.winestockwebdesign.com/Essays/Lisp_Curse.html And when I read that article, i kept thinking of Tcl :)

---

AKgnome - 2011-05-04 16:40:30

+1 (regarding Article on Lisp Curse, and how it could pretty much [string map {Lisp Tcl}])

---