Two interesting tcl posts on reddit
keithv
generating some interesting comments.
The first was "Tcl still in use, still improving", linking to an
article by Cameron Laird
http://www.reddit.com/r/programming/comments/bjonx/tcl_still_in_use_still_improving/
(article at http://www.itworld.com/development/102598/tcl-tips-timestamps)
The second was by David Welton, motivated by "after seeing the recent
thread about Tcl and Tk, I decided it was finally time to write up
some of
what I saw go wrong with Tcl and Tk."
http://www.reddit.com/r/programming/comments/bk87r/where_tcl_and_tk_went_wrong/
(article at http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong)
Keith
Robert H
> Two interesting items appeared recently on Reddit/programming,
> generating some interesting comments.
>
> The first was "Tcl still in use, still improving", linking to an
> (article athttp://www.itworld.com/development/102598/tcl-tips-timestamps)
>
> The second was by David Welton, motivated by "after seeing the recent
> thread about Tcl and Tk, I decided it was finally time to write up
> some of
> (article athttp://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong)
>
> Keith
Both are interesting reads.
Robert
tom.rmadilo
> On Mar 30, 2:45 pm, keithv <kvet...@gmail.com> wrote:
>
> > http://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong
> Both are interesting reads.
The first article, by Cameron Laird hints at another article, coming
out next week about concurrency in Tcl.
Basically, concurrency, and the thread/memory model is what sets Tcl
far apart from all the other mentioned languages in the first article.
The second article is only interesting as one person's opinion based
upon a somewhat unsuccessful project: Apache Rivet...one of several
not very usable Tcl engines for Apache, and also based upon his
knowledge of public/open source projects. The comments about Tk seems
strange: it is so easy to use, there are too many examples of poorly
designed applications floating around. Also not very clear why php is
included in the list of languages.
Still both are worth reading.
Donal K. Fellows
> The second article is only interesting as one person's opinion based
> upon a somewhat unsuccessful project: Apache Rivet...one of several
> not very usable Tcl engines for Apache, and also based upon his
> knowledge of public/open source projects.
The deep problem is a fundamental difference between Apache2's thread
model and Tcl's. (IIRC, they assume a shared memory model and Tcl uses
an apartment model.) That made porting Rivet to a more recent Apache
than it was designed for almost impossible.
Or at least that was how I understood it.
Donal.
David N. Welton
> strange: it is so easy to use, there are too many examples of poorly
> designed applications floating around.
It's not a problem limited to Tk. PHP has the exact same problem: it
made web stuff really easy, but gained a lot of users who did not
write good code. Lowering the barrier to entry is generally a
positive thing, but it often results in a lot of "marginal"
programmers and projects. Over time, with PHP, that has given the
resulting code a less than stellar reputation (and it doesn't help
that the language itself isn't really a thing of beauty, either).
It's something you have to manage, and in hindsight, the Tk community
probably ought to have done more to foster a culture of creating good
GUIs. If you look at otherwise excellent books, like Brent Welch's,
you'll find all kinds of details about how to use the Tk widgets, but
not much material telling the reader how to go about creating a "good"
GUI.
The point is that "enabling" people isn't enough, you have to help
give them some direction too, which is ultimately a cultural thing,
rather than a technological thing.
> Also not very clear why php is
> included in the list of languages.
I'm not sure I follow you. PHP is a programming language that is very
widely used, which makes it quite sensible to compare it to Tcl.
David N. Welton
<donal.k.fell...@manchester.ac.uk> wrote:
> The deep problem is a fundamental difference between Apache2's thread
> model and Tcl's. (IIRC, they assume a shared memory model and Tcl uses
> an apartment model.) That made porting Rivet to a more recent Apache
> than it was designed for almost impossible.
>
> Or at least that was how I understood it.
You can make Tcl work with Apache2 as long as you stick to the prefork
model (Websh does this just fine), and you could probably get things
working with threads if you put some serious effort into it, but it
got to be something that was just not an itch I wanted to scratch by
myself, and by the time others came along to work on it, I was already
getting busy with other things.
Incidentally, IIRC, Rasmus of PHP fame also was unenthusiastic about
the threaded Apache2 hassle for a long time, and continued to
recommend Apache 1.3 where at all possible.
Along those lines, the trendy web server these days is nginx, which is
an event-based system...
Also, for Tom, Rivet was usable enough for Karl Lehenbauer to base
this site/company on it:
At least originally - I don't know what it's running these days, but
there are still .rvt extensions here and there.
Building a company on a "niche" technology is a much more sensible
approach than trying to do consulting; you don't have to worry nearly
as much about selling anyone on the technology, you just get on with
making a product. I on the other hand was trying to both develop the
underlying system, get people to use it, and do work based on it,
which was just too much.
tom.rmadilo
My main point is that Rivet is embedded in Apache, which has a rather
unfortunate API. This architecture, forked or threaded doesn't make
good use of Tcl's model. If the article stuck to noticing that Tcl
doesn't work very well with Apache, all is fine, but Tcl works well
outside of Apache. Does PHP? If you use threads, how well do the other
languages stack up? If one interaction requires multiple threads to
communicate with each other before returning a response, is this
possible with other languages? If you have multiple CPUs, can you take
advantage of this within one application?
Apache works great for 10k low volume independent hosts, but not so
well for one high volume host that might even span many physical
machines.
Tcl is also a safe language. Part of this safely is gained by a hidden
interface. It is hidden because nobody refers to it as an interface.
This is the hash table. The hash table forces application code to use
strings to look up references to objects which exist. Some languages
allow you to make up a reference and possibly access non-application
objects, or just crash the application.
Tcl forces you to know the name of the resource as well as the domain.
Files are stored in one hash table (domain), commands in another.
tomk
I wound up using PHP for my web applications (instead of tcl) mostly
because it integrated
well with MySQL. What I found interesting was how popular it was and
yet how totally screwed up
the language was. In particular the Class stuff was basically a joke
that was unuseable. This
was eventually fixed in a later major release but that release
completely broke all my old code.
I think the its popularity was a direct result of the batteries
included++ approch used by the
PHP community and the developers focus on web applications. A lot of
the stuff that distributed
may be broken but it gives new users the feeling that it is a serious
language.
I think both of these observations reinforce what David said in his
article, but with a slight
twist. I consider PHP to be a nich language that only competes for web
application. Tcl on the
other hand is a far more flexible language that can compete in
virtually any application space
but tends to be viewed poorly in most because it doesn't have "more"
than anyone elses language
in any of the application spaces.
So to sum up, if you want to be a popular language:
1) focus on one application space
2) provide everything including the kitchen sink right from the start
(even if they doesn't work)
3) make major changes to the language when substantive problems become
apparent (even if it breaks
backwards compatibility)
Or you can take the slow and steady tcl approach.
tomk
Robert H
>
> You can make Tcl work with Apache2 as long as you stick to the prefork
> model (Websh does this just fine), and you could probably get things
> working with threads if you put some serious effort into it, but it
> got to be something that was just not an itch I wanted to scratch by
> myself, and by the time others came along to work on it, I was already
> getting busy with other things.
>
What was Rivet trying to solve that websh didn't do?
Robert
David N. Welton
> I wound up using PHP for my web applications (instead of tcl) mostly
> because it integrated
> well with MySQL. What I found interesting was how popular it was and
> yet how totally screwed up
> the language was. In particular the Class stuff was basically a joke
> that was unuseable. This
This is part of what made me so curious about the situation. I still
think of Tcl as a first-rate language developed by first-rate people.
If you accept that, you have to look elsewhere, at human/marketing/
economics factors for its declining popularity.
> 1) focus on one application space
That's actually fairly similar to the strategy proposed in a well-
known business book, "Crossing the Chasm":
http://www.squeezedbooks.com/book/show/14/crossing-the-chasm
> 2) provide everything including the kitchen sink right from the start
> (even if they doesn't work)
> 3) make major changes to the language when substantive problems become
> apparent (even if it breaks
> backwards compatibility)
The backwards compatibility issue is tricky, and something I hinted at
in the article that Erlang suffers from as well. Erlang had a big,
important early adopter in Ericsson, which was good because they paid
people to work on the language. It was also bad because they lost the
freedom to radically modify their language fairly early on, and so it
has some fairly odd warts that they will not be able to change
easily. Managing that is certainly tricky.
tom.rmadilo
> The backwards compatibility issue is tricky, and something I hinted at
> in the article that Erlang suffers from as well. Erlang had a big,
> important early adopter in Ericsson, which was good because they paid
> people to work on the language. It was also bad because they lost the
> freedom to radically modify their language fairly early on, and so it
> has some fairly odd warts that they will not be able to change
> easily. Managing that is certainly tricky.
"Lost the freedom to radically modify their language"?
For people who love syntax, this statement may resonate. I'm not sure
how you radically modify Tcl, it is perhaps the most simple from a
language perspective: no hard coded syntax, no reserved words, etc.
That means that users can radically modify the language/syntax however
they wish. You don't need holy blessings from above.
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.
Probably the most politically correct criticism of Tcl is the so-
called lack of an object system.
If you define an object as something which hides/protects access to
internal structure and requires an message passing interface for
communication, then Tcl has many objects: interps, file/socket
handles, arrays, commands, etc.
The main problem is that the Tcl community didn't think it necessary
to identify these things as objects. We could have gone so far as
calling strings "self describing objects", or "object code", code
which describes how to create an object.
As I said before, the main advantage for Tcl is how certain Tcl
objects are allowed to take advantage of computer resources: multiple
threads, multiple processors, multiple machines and existing non-Tcl
applications reachable via exec/pipe/tcp to create a larger efficient
application.
JonoK
> On Apr 1, 11:18 pm, "David N. Welton" <davidnwel...@gmail.com> wrote:
>
> > The backwards compatibility issue is tricky, and something I hinted at
> > in the article that Erlang suffers from as well. Erlang had a big,
> > important early adopter in Ericsson, which was good because they paid
> > people to work on the language. It was also bad because they lost the
> > freedom to radically modify their language fairly early on, and so it
> > has some fairly odd warts that they will not be able to change
> > easily. Managing that is certainly tricky.
>
> "Lost the freedom to radically modify their language"?
>
> For people who love syntax, this statement may resonate. I'm not sure
> how you radically modify Tcl, it is perhaps the most simple from a
> language perspective: no hard coded syntax, no reserved words, etc.
> That means that users can radically modify the language/syntax however
> they wish. You don't need holy blessings from above.
>
> 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/
Alexandre Ferrieux
>
> This is part of what made me so curious about the situation. I still
> think of Tcl as a first-rate language developed by first-rate people.
> If you accept that, you have to look elsewhere, at human/marketing/
> economics factors for its declining popularity.
I'm curious: what can be said of /bin/sh's "popularity" ? Is it low ?
Is it declining ?
IMHO, Tcl is /bin/sh "on steroids", and following its venerable
ancestor in its resistance to featuritis is not a bad idea. Freezing
into perfection is not dying.
-Alex
tomk
wrote:
Alex,
I've also had thoughts along this line (i.e. sh on steroids) but there
is a problem (mentioned by David) which is the lack of a terminal on
all supported platforms. I think David was spot on when he points out
that for new users tcl is very unfriendly because when a copy of tcl/
tk is download (1) there isn't a terminal included with the software
(a big problem on windows) and (2) there isn't a package repository
where the user can go to hunt up packages. Yes, I know about the AS
teapot but it has a limited set of packages and the repository client
(which has no gui) doesn't really support multi-platform downloads or
dependency downloading.
tomk
pmarin
If for "lack of a terminal" you mean readline, I use rlfe. rlwrap is
another.
tom.rmadilo
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.
Frédéric Bonnet
> Guess which language has solved all of these problems: C.
>
> Tcl, just co-ops the vast infrastructure of C.
QOTW
David N. Welton
>
> 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.
tom.rmadilo
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.
Robert H
Do we put those anywhere on the wiki?
Robert
cattaghia
> ... the Tk community probably ought to have done more to foster a culture
> of creating good GUIs. If you look at otherwise excellent books, like
> Brent Welch's, you'll find all kinds of details about how to use the Tk
> widgets, but not much material telling the reader how to go about creating
> a "good" GUI.
I have observed this already and I remember to have written about this
(I'm not sure if it was here or in the Tclers wiki). I really miss
something fo Tk in the lines of the famous Gnome Human Interface
Guidelines or the Apple's equivalent. Sure, there's the fundamental
difference that those guides refer to their own desktop environments,
while cross-platform Tk runs on them and other dozens of graphical
environments. But this portability sets another challenge in the
development of good Tk GUIs which remain good when crossing platforms,
and this would be a very important chapter in such a guide. I can not
say I have enough experience with Tk, nor that I know a lot about the
subject, but it's an area of personal interest and I would be glad to
help to write this guide if there's more people engaged on it.
David Welton wrote:
> I still think of Tcl as a first-rate language developed by
> first-rate people. If you accept that, you have to look elsewhere,
> at human/marketing/economics factors for its declining popularity.
As I said, I still feel I'm a rookie in Tcl/Tk, and I feel a bit wary
to throw my two cents in a discussion among the Tcl monsters which
write the books and tutorials I study. But it's strange that here in
Brazil the largest group of Tclers on the web (in a Orkut community)
has few more than 100 members, and whenever I talk to IT professionals
about my programming hobby with Tcl/Tk they say they never heard about
the language.
This may be off-topic, but it seems to me that most people (including
Tcl monsters mentioned above) are so focused in the "engineering" and
the academic features of Tcl that the "marketing" and the practical
matters were left behind; and it's really strange that this people
seems quite unwilling to think about and work around this. Tcl is
classified as an "academic language" in the portuguese Wikipedia.
There is a lot of pages in the Wiki discussing things like lambda
procedures, emulation of other languages, advanced mathematics code
and algorithms, and while I can't argue against the importance of
these subjects, I believe (as a hobbyist programmer with no CS
background) that all this stuff will not attract new Tcl/Tk
programmers while there is not a decent printing solution (after all
those years, and I'm not talking about hackish workarounds); while
mobile and cloud computing support is still experimental and
theoretical; while the language, its extensions and programming tools
all look like ActiveState properties (I know this is not exactly true,
but many people have this impression); while there is a lot of
different OO systems and we can not find good documentation and
newcomers tutorials for any of them; while there is not a complete, up-
to-date and open-source visual programming environment because people
insist that Tcl/Tk is so easy that writing code in emacs or Vi is
faster; while there is not a freely available guide for Tk GUIs design
like the one mentioned previously; and so on.
I tend to think that all those lacks and problems are due to a reduced
number of developers in the TCT, and that this few (brilliant and
dedicated) people who maintains Tcl/Tk must do N other things for
feeding themselves and their families. But if this is the case, maybe
it would be good if the evolution and the decisions about Tcl/Tk were
not so much centered in the TCT and/or ActiveState. Or, who knows, it
would be useful to split the TCT in two teams, the "technical" and the
"marketing & advocacy" ones. Perhaps a modern, community-based, open
repository for code and extensions would bring more users. I don't
know, surely there's a lot of people with ideas to help Tcl/Tk, and
maybe it's time to open the doors to these ideas. Tcl/Tk is too good
and versatile for being passively left in a "declining popularity"...
Larry W. Virden
Not consistently - they often appear in the Tcl-URL! postings and
there is http://wiki.tcl.tk/qotw but not all appear.