5 ms·

Loved this from the announcement: In other words, Tcl as a language is what would happen if Lisp and csh met at a party, got way too drunk, hooked up, got preg

by Toenex 13y ago

Loved this from the announcement: In other words, Tcl as a language is what would happen if Lisp and csh met at a party, got way too drunk, hooked up, got pregnant, and kept drinking throughout the pregnancy. When I was using it (early 1990's) I really appreciated that Tcl provided C coders with an easy way to create a scripting environment for your libraries. And with Tk you could get a GUI running pretty quickly as well. The structure of the source code was also very neat and well managed making it easy to understand and extend. In many ways I see Lua as the spiritual successor to Tcl; neatly designed for embedding and extension.

kingmanaz 13y ago
>Tcl as a language is what would happen if Lisp and csh met at a party, got way too drunk, hooked up, got pregnant, and kept drinking throughout the pregnancy. Below is one of the SICP authors writing on the lispish nature of Tcl. (TL;DR: Tcl is like a lisp that exchanged theoretical purity for pragmatic simplicity of implementation): """ If in reading this introduction, you've come to realize that "Hey, Tcl is just like Lisp, but without a brain, and with syntax on steroids", you might wonder why Lisp isn't a more popular scripting language than Tcl. Lisp hasn't been a complete failure, by the way; it is used as an extension language by users of some popular programs, notably AutoCAD. But Tcl has been much more successful. It has been compiled into hundreds of larger programs, including AOLserver, which is why we wrote this book. As a software developer, you're unlikely to get rich. So you might as well try to get through your life in such a way that you make a difference to the world. Tcl illustrates one way: * make something that is simple enough for almost everyone to understand * give away your source code * explain how to weave your source code in with other systems In the case of AOLserver, for example, Jim Davidson and Doug McKee had only a few months to build the whole server from scratch. They wanted users to be able to write small programs that ran inside the server process. They therefore needed a safe interpreted language so that a programming error by one user didn't crash the server and bring down all the Web services for an organization. Tcl was available. Tcl was easy to download and designed to fit inside larger application programs. But the Tcl interpreter as distributed had one terrible bug: it wasn't thread safe, i.e., you couldn't have two copies of the Tcl interpreter running inside the same program at the same time. Doug and Jim had to read through the Tcl source code and modify it to be thread safe. So it was critically important for them that Tcl was open-source and simple enough so as to not require months or years of study to understand the whole system. Compare this to Lisp. Some of the best and brightest computer scientists raised money to build commercial Lisp implementations that they then went out and hawked in an indifferent and confused marketplace. They succeeded only in breaking their hearts and their investors' wallets. A handful of academics produced free open-source implementations, notably CMU Common Lisp (see http://www.cons.org/cmucl/ http://www.cons.org/cmucl/) and various versions of Scheme (see the links from http://en.wikipedia.org/wiki/Scheme_(programming_language); http://en.wikipedia.org/wiki/Scheme_(programming_language); Scheme 48 is the closest to Tcl in spirit). But these multi-megabyte monsters weren't designed to fit neatly into someone else's program. Nor was there any document explaining how to do it. Lisp developers have the satisfaction of knowing that they got it right 30 years before anyone else. But that's about all they have to show for 40 years of hard work and hundreds of millions of dollars in government and private funding. These days, most former Lisp programmers are stuck using Unix and Microsoft programming environments and, not only do they have to put up with these inferior environments, but they're saddled with the mournful knowledge that these environments are inferior. """ http://philip.greenspun.com/tcl/introduction.adp http://philip.greenspun.com/tcl/introduction.adp
- davidw 13y ago
  One of the things that Tcl - and also to some degree Perl and Python got right is that they are 'promiscuous' in that they are happy to integrate with the rest of the world. Languages like Lisp and Forth tend to have more 'turtles all the way down' philosophies. Tcl's C is very clean and pleasant code to read, by the way.

by Toenex 13y ago

kingmanaz 13y ago

>Tcl as a language is what would happen if Lisp and csh met at a party, got way too drunk, hooked up, got pregnant, and kept drinking throughout the pregnancy. Below is one of the SICP authors writing on the lispish nature of Tcl. (TL;DR: Tcl is like a lisp that exchanged theoretical purity for pragmatic simplicity of implementation): """ If in reading this introduction, you've come to realize that "Hey, Tcl is just like Lisp, but without a brain, and with syntax on steroids", you might wonder why Lisp isn't a more popular scripting language than Tcl. Lisp hasn't been a complete failure, by the way; it is used as an extension language by users of some popular programs, notably AutoCAD. But Tcl has been much more successful. It has been compiled into hundreds of larger programs, including AOLserver, which is why we wrote this book. As a software developer, you're unlikely to get rich. So you might as well try to get through your life in such a way that you make a difference to the world. Tcl illustrates one way: * make something that is simple enough for almost everyone to understand * give away your source code * explain how to weave your source code in with other systems In the case of AOLserver, for example, Jim Davidson and Doug McKee had only a few months to build the whole server from scratch. They wanted users to be able to write small programs that ran inside the server process. They therefore needed a safe interpreted language so that a programming error by one user didn't crash the server and bring down all the Web services for an organization. Tcl was available. Tcl was easy to download and designed to fit inside larger application programs. But the Tcl interpreter as distributed had one terrible bug: it wasn't thread safe, i.e., you couldn't have two copies of the Tcl interpreter running inside the same program at the same time. Doug and Jim had to read through the Tcl source code and modify it to be thread safe. So it was critically important for them that Tcl was open-source and simple enough so as to not require months or years of study to understand the whole system. Compare this to Lisp. Some of the best and brightest computer scientists raised money to build commercial Lisp implementations that they then went out and hawked in an indifferent and confused marketplace. They succeeded only in breaking their hearts and their investors' wallets. A handful of academics produced free open-source implementations, notably CMU Common Lisp (see http://www.cons.org/cmucl/ http://www.cons.org/cmucl/) and various versions of Scheme (see the links from http://en.wikipedia.org/wiki/Scheme_(programming_language); http://en.wikipedia.org/wiki/Scheme_(programming_language); Scheme 48 is the closest to Tcl in spirit). But these multi-megabyte monsters weren't designed to fit neatly into someone else's program. Nor was there any document explaining how to do it. Lisp developers have the satisfaction of knowing that they got it right 30 years before anyone else. But that's about all they have to show for 40 years of hard work and hundreds of millions of dollars in government and private funding. These days, most former Lisp programmers are stuck using Unix and Microsoft programming environments and, not only do they have to put up with these inferior environments, but they're saddled with the mournful knowledge that these environments are inferior. """ http://philip.greenspun.com/tcl/introduction.adp http://philip.greenspun.com/tcl/introduction.adp

davidw 13y ago
One of the things that Tcl - and also to some degree Perl and Python got right is that they are 'promiscuous' in that they are happy to integrate with the rest of the world. Languages like Lisp and Forth tend to have more 'turtles all the way down' philosophies. Tcl's C is very clean and pleasant code to read, by the way.