Two interesting tcl posts on reddit
in [TCL]
|
Prev: Text on canvas
Next: Global hotkeys under X11
From: tom.rmadilo on 5 Apr 2010 14:00 On Apr 2, 11:43 pm, JonoK <jonke...(a)fastmail.fm> wrote: > On Apr 3, 5:50 am, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > > Erlang is a very interesting language, but it is also obviously > > designed as a switch/proxy language. It is hard to imagine this > > language ever evolving or radically transforming into a general > > purpose language. > > Well, general purpose enough to produce this:http://www.wings3d.com/ You can use Erlang as an example of the problems faced with any language: 1. How to interface with hardware, 2. How to interface with the OS, 3. How to interface with other applications 4. How to manage application growth across: a. modules and packages in the application, b. additional local processors c. threads in a process, d. machines on a network 5. How to manage application competition for shared resources Guess which language has solved all of these problems: C. Tcl, just co-ops the vast infrastructure of C. It is hard to overestimate the value of this connection. You can write a module in Tcl which interfaces to a C library. As the C library maintainers update their code, your code also gets updated. At the very least, the C library development serves as a guide for Tcl development. This also ensures that anyone familiar with the C library will understand the Tcl API. The main goal of application development is to solve some useful problem for an end user. This is a vastly different goal than any particular function, module or library. Tcl seems designed to leverage all available resources, and this requires a rather flexible interface with the external world. This flexibility also includes the 1-5 problems listed above that each language must address. It isn't uncommon for a simple Tcl script to access an Oracle/ PostgreSQL database, a shell script, an external networked resource, the local file system, shared memory and thread local storage. In fact, what is uncommon is to use Tcl as a shell/console. However, Tcl shell scripts are much easier to write/read/maintain. They are also a little more safe than /bin/sh.
From: Frédéric Bonnet on 5 Apr 2010 17:01 tom.rmadilo wrote: > Guess which language has solved all of these problems: C. > > Tcl, just co-ops the vast infrastructure of C. QOTW
From: David N. Welton on 5 Apr 2010 17:03 > Tcl, just co-ops the vast infrastructure of C. > > It is hard to overestimate the value of this connection. You can write > a module in Tcl which interfaces to a C library. As the C library > maintainers update their code, your code also gets updated. At the > very least, the C library development serves as a guide for Tcl > development. This also ensures that anyone familiar with the C library > will understand the Tcl API. Tcl, Perl, Python, Ruby, PHP, Lua, etc... all get this right. They are "promiscuous" languages in that they're happy to talk with the rest of the world and don't claim to have all the answers. They're happy to interface with other systems in various ways. In my opinion, this is in contrast to the "turtles, all the way down" approach taken by Lisp, Smalltalk, and to some degree Java and Erlang, where there is a culture of wanting *everything* to be in the language in question, for various reasons. It's not working out too badly for Java, because it had a lot of money behind it and then became popular. However, it's a very good strategy to follow if you don't have massive resources behind you. Incidentally, Erlang doesn't do a bad job of interfacing with C, but the language has a constraint which makes it clearer why it's a bit less happy than Tcl et al to interface with various systems via a C API: Erlang should basically *never* block. It's like a Tcl event loop on steroids, complete with its own internal scheduler. So as along as it's happily computing things based on Erlang, the scheduler ensures that you won't wedge the system, and that it even manages to have something approaching soft real-time properties. However, the whole system is (well, in its simplest form, conceptually, at least), one Unix process, so that if you were to link in some "bad" C code, where you call out to it and it takes 1 minute to return, you've essentially wrecked the nice, orderly execution of Erlang. They do have strategies for this kind of thing, but this requirement is what complicates life for Erlang.
From: tom.rmadilo on 5 Apr 2010 18:01 On Apr 5, 2:03 pm, "David N. Welton" <davidnwel...(a)gmail.com> wrote: > > Tcl, just co-ops the vast infrastructure of C. > > > It is hard to overestimate the value of this connection. You can write > > a module in Tcl which interfaces to a C library. As the C library > > maintainers update their code, your code also gets updated. At the > > very least, the C library development serves as a guide for Tcl > > development. This also ensures that anyone familiar with the C library > > will understand the Tcl API. > > Tcl, Perl, Python, Ruby, PHP, Lua, etc... all get this right. They > are "promiscuous" languages in that they're happy to talk with the > rest of the world and don't claim to have all the answers. They're > happy to interface with other systems in various ways. > > In my opinion, this is in contrast to the "turtles, all the way down" > approach taken by Lisp, Smalltalk, and to some degree Java and Erlang, > where there is a culture of wanting *everything* to be in the language > in question, for various reasons. It's not working out too badly for > Java, because it had a lot of money behind it and then became > popular. However, it's a very good strategy to follow if you don't > have massive resources behind you. > > Incidentally, Erlang doesn't do a bad job of interfacing with C, but > the language has a constraint which makes it clearer why it's a bit > less happy than Tcl et al to interface with various systems via a C > API: Erlang should basically *never* block. It's like a Tcl event > loop on steroids, complete with its own internal scheduler. So as > along as it's happily computing things based on Erlang, the scheduler > ensures that you won't wedge the system, and that it even manages to > have something approaching soft real-time properties. However, the > whole system is (well, in its simplest form, conceptually, at least), > one Unix process, so that if you were to link in some "bad" C code, > where you call out to it and it takes 1 minute to return, you've > essentially wrecked the nice, orderly execution of Erlang. One major complication with Erlang is that you must have a separate scheduler/manager for each processor. This is not a big deal with many identical Erlang processes, but for a generic complex application, how to divide up an application to take full advantage of the available hardware is a difficult issue. Still Erlang is well designed, it just isn't my cup of tea. With Java, note that it took until Java 5 for them to add the facilities available in AOLserver. http://www.javamex.com/tutorials/synchronization_concurrency_1.shtml (and similar pages) Of course, Java is far ahead of all the other non-mentioned languages in this respect, excepting C, C++ and Tcl.
From: Robert H on 5 Apr 2010 18:10
On Apr 5, 5:01 pm, Frédéric Bonnet <fredericbon...(a)free.fr> wrote: > tom.rmadilo wrote: > > Guess which language has solved all of these problems: C. > > > Tcl, just co-ops the vast infrastructure of C. > > QOTW Do we put those anywhere on the wiki? Robert |