Is Tcl work for large programs?
tclnew...@yahoo.com.tw
I'm a newbie in Tcl, I feel it is a script language with simple syntax,
very easy to learn. But I have some questions about Tcl language: Is
Tcl work for large projects? Is it work for a commercial software? Is
Tk good for complex GUI? What about the Tcl script's reusibility,
Portability, performance and maintainability ?
Regards
Robert Heller
Tcl is fine for large projects. Investigate the use of pkgIndex.tcl
files and package provide/package require.
Yes, there is commercial software written in Tcl.
Tk is good for a complex GUI, although it is helpful to use one of the
metawidget packages (such as BWidget).
Tcl scripts are often quite reusable.
Portability, performance and maintainability are excelent.
>
> Regards
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Arjen Markus
tclnew...@yahoo.com.tw schreef:
I have seen references to commercial applications in Tcl that have
several hundreds of thousands lines of code. That could be an
indication
that it fits your requirements.
The Wiki, http://wiki.tcl.tk, contains lots of material that you will
benefit
from, but answering such general questions as you posed is a trifle
tough. Portability is almost guaranteed - unless you use some platform-
specific commands or conventions, your program will run on a wide
variety of platforms, some you may never have heard of even.
Maintainability and reusability are not intrinsic qualities of the
programming language,
your style of programming is at least as important, but the simplicity
of the syntax certainly helps both.
Tk GUIs can be as simple and as complicated as you want ... It has two
very powerful
widgets, the text widget and the canvas - you can build whole
applications
with just a few lines of code with these - the Wiki holds a lot of
examples.
Could you be more specific about the sort of software you are thinking
of?
That may help refine any question on performance for instance.
Regards,
Arjen
MartinLemburg@UGS
from my experience ... yes ... definitely is tcl fine to build large
applications!
But my professional experiences are restricted to non Tk applications.
Our application has only a small MFC GUI kernel and some widely
comparable with the MetaKit a kind of structure and database toolkit.
But the real application is completely written in tcl and tcl controls
the MFC GUI.
Its an application used in automotive production tool design and
verification for sheet metal manifacturing, die and press lines
simulations with OpenGL - 4D simulation of the production process.
The only thing is ... everybody has to have an eye on the architecture,
on the complexity of each modul to allow a good maintainability, to
easy the way to extend it.
If it is about performance ... our application won't suffer really on
tcl performance, because the time critical kinematic calculations are
mostly done by the structure and database toolkit. And additional
needed mathmatics is on one hand optimized in tcl or pushed to C++
extensions, like the interface layers to 3rd party CAD systems, etc..
My private experiences with Tk tell me ... reuse existing Tk extensions
like the Bwidgets, write own packages or mega widgets (e.g. using the
snit package) ... and it will be much easier to create good, complex
GUIs, which have good reaction times and allow multiple ways of to get
to the same results (Mouse, Keyboard, Menus, etc.) to support different
workstyles.
So - simply think about architecture, modularizing, reusing, and to
don't reinvent the wheel if possible!
A good time and a happy christmas!
Martin Lemburg
UGS - Transforming the Process of Innovation
Donal K. Fellows
> Is Tcl work for large projects? Is it work for a commercial software?
There are commercial applications with millions of lines of Tcl out
there, and Tcl's in just about every EDA application in existence.
> Is Tk good for complex GUI?
I've written complex IDEs for graphical programming languages using
Tcl and Tk. If you're doing this sort of thing, the [text] and
[canvas] widgets are likely to be of particular interest. (There are
packages from the wider Tcl/Tk community that supply similarly-powerful
table and tree widgets.)
> What about the Tcl script's reusability,
> Portability, performance and maintainability ?
Taking these points one at a time:
reusability: code has to be written to be reusable to be reusable
at all, but that's true of any other language you care to name
too. Mind you, much of my code isn't actually reusable because
it takes so little time to write that I might as well write it
fresh each time. ;-)
portability: Tcl/Tk code tends to be *very* portable, even more so
than say Java code.
performance: Tcl's pretty good these days (and Tk's always been
pretty quick in practice) but if you have a particular problem,
linking some extra C/C++ or FORTRAN code in to give it a bit of
extra zip is easy.
maintainability: Tcl/Tk code tends to be pretty easy to maintain,
especially when it follows the Style Guide. We also have a good
test suite support package; write tests for your code that use
it to help out, and you'll find your code is very maintainable.
But the best thing of all I've found is that the Tcl community here is
very supportive. If you have any problems, do ask. Someone's bound to
either know the answer or know how to work it out, and we're pretty
much universally glad to help. Also don't forget to use the Tcler's
Wiki (http://wiki.tcl.tk/). There's also a chatroom; the details are
in the wiki...
Donal.
Cameron Laird
Robert Heller <hel...@deepsoft.com> wrote:
>At 22 Dec 2006 20:23:07 -0800 tclnew...@yahoo.com.tw wrote:
.
.
>Yes, there is commercial software written in Tcl.
.
.
MUCH <URL: http://wiki.tcl.tk/1887 >.
George Peter Staplin
> Hi all,
>
> I'm a newbie in Tcl, I feel it is a script language with simple syntax,
> very easy to learn. But I have some questions about Tcl language: Is
> Tcl work for large projects? Is it work for a commercial software?
It's easy to learn Tcl if you forget nearly everything you know about
C-like languages when working with it.
> Is Tk good for complex GUI?
It depends on what you require and what "complex" means to you. The
printing support is poor. The image support and manipulation support is
slow. You can however use many image formats with the Img package.
> What about the Tcl script's reusibility,
> Portability, performance and maintainability ?
Expect problems/differences with Tk in MacOS X. Expect a visual
difference between Tk apps in Unix (GNOME/KDE), unless you use the
unreleased Tk 8.5 with ttk, and happen to have a default theme that
matches the desktop.
Have you looked into Qt? It's used a lot for commercial products, and
has a scripting language based on ECMAscript/Javascript.
-George
Donal K. Fellows
> Expect problems/differences with Tk in MacOS X. Expect a visual
> difference between Tk apps in Unix (GNOME/KDE), unless you use the
> unreleased Tk 8.5 with ttk, and happen to have a default theme that
> matches the desktop.
I should note here that the key difference between "native"-looking apps
on OSX/Aqua and X11/KDE (and, for that matter, Windows) is that the way
you design interactions on the different platforms is quite different.
If you take an application that functions in way that is a descendent of
the IBM CUA guidelines (e.g. a Windows, KDE or GNOME app) it simply will
not behave in a native fashion when ported to Aqua; Aqua applications
follow a different basic set of rules and users use them in different
ways. (NB: not better, not worse, just different.) Truly satisfactory
porting between the two systems requires a considerable amount of
redesign anyway, and Tk simply can't hide that (I also think that the
other cross-platform toolkits can't hide it either; things like dialog
interaction models aren't concealable in any practical way). But it's
quite able at doing both Aqua-style and CUA-style apps. :-)
And definitely use tile with 8.4 or 8.5's ttk. It might not make a big
difference on Unix (yet) but it *really* matters on Windows and OSX.
Donal.
Why Tea
provide useful information into some of the problems of TCL
http://www.perl.com/doc/FMTEYEWTK/versus/tcl-discussion.html
http://www.perl.com/doc/FMTEYEWTK/versus/asherman-on-tcl.html
I would like to see some repudiation from the TCL experts here.
/Why Tea
Stéphane A.
Hi,
I am not a Tcl expert, but I have read those two references, and I can
tell
you they are much outdated. They complained rightfully when they
appeared
(Tcl 7.5 was beta !), but in 2006, hopefully, Tcl 'sucks' much less.
The main complaints were:
* Tcl variables are just C strings, thus:
-- cannot handle binary data (as a NULL terminates every string)
-- do not store numbers as numbers (expr has to convert from and to
string)
and math is slow due to that
-- cannot efficiently manage lists (we have to traverse completely
a list to get the last element)
Now that we have Tcl_Objs, we can handle binary data, have fast math,
and manage lists as fast as can be.
* Tcl code is interpreted, and not bytecoded: that is not true these
days,
since Tcl 8.x proc bodies are bytecoded.
* Tcl has no namespaces (Tcl 8.x has it)
* Tcl cannot pass arrays by value nor by reference. [dict] allows us
to pass arrays by value. (to be seen in upcoming 8.5, but already
done via a 8.4 package)
* Tcl has no object-oriented programming: not true anymore,
now it has [Incr Tcl], XOTcl and Snit, and TIP #257 is planned
to provide a unified OO system to Tcl 8.6
Some complaints must be taken into consideration:
* No built-in debugger. (but some IDEs provide such functionality
and so does Tkcon)
* No closures and first-class functions. (but it is possible to emulate
it
see http://wiki.tcl.tk/2918)
And I would have some complaints about Perl, but I do not want to flame
here,
so I omit it deliberatly.
Regards
Stephane
Stephan Kuhagen
Obviously the articles are somewhat aged. You can see that in the statement
that perl will be recognized as _the_ cgi-language in the future (first
article), when cgi comes to it's full prime. Well, cgi prime of life was
some years ago and the article is full of statements, that may have been
true in the past, but not today (no compilation in Tcl etc).
The same seems to be true for the second article. I disagree to many of the
statements in the first article, although it makes no sense to argue
against them, because if you know some Tcl, you also know, that they are
mostly not reflecting your Tcl experience. And people here in c.l.t are
normally not interested in doing these childish "mine is better than
yours"-wars, and I really appreciate that. So I won't argue, that Tcl is
better than Perl or what ever and I won't analyze every statement in these
articles. Instead I only pick the first one from the second article, since
it is very simple to compare, and then let all of you (especially the OP)
decide, what you think in this context about the credibility of the
remaining parts:
First, I think, it is always a big mistake to write such comparisons without
giving some specs of the hardware and operating system and other
environment (perl version, Tcl version?), where the test was done. It makes
it very hard to reproduce the results.
My specs:
Pentium 4, 2.6 GHz
Linux (Fedora Core 6) Kernel 2.6.18
Tcl 8.5a4
Perl 5.8.8
The following Tcl-Script was used:
---
proc measure {s} {
puts [time {
set len 0
for {set i 0} {$i<100000} {incr i} {
incr len [string le $s]
}
puts $len
} 10]
}
measure [string repeat "." 64]
measure [string repeat "." 128]
measure [string repeat "." 256]
---
The following Perl-Script was used (I'm not a Perl programmer, so this might
look a little bit nasty - I have no clue, what is perls equivalent of
[string repeat]...):
---
sub measure {
timethese(10, { slen => '
for($i=0;$i<100000;$i++) {
$len+=length(@_[0])
}
print $len '
});
}
measure "................................................................";
measure "................................................................................................................................";
measure ".........................................................................................................................................................................................................................................................................";
---
The Tcl timing results are:
155522.7 microseconds per iteration
158602.4 microseconds per iteration
153494.4 microseconds per iteration
The Perl timing results are:
Benchmark: timing 10 iterations of slen...
0000000000 slen: 1 wallclock secs ( 0.78 usr + 0.00 sys = 0.78 CPU)
@ 12.82/s (n=10)
Benchmark: timing 10 iterations of slen...
0000000000 slen: 0 wallclock secs ( 0.78 usr + 0.00 sys = 0.78 CPU)
@ 12.82/s (n=10)
Benchmark: timing 10 iterations of slen...
0000000000 slen: 0 wallclock secs ( 0.75 usr + 0.03 sys = 0.78 CPU)
@ 12.82/s (n=10)
Indeed, Perl is about twice as fast as Tcl in this comparison, but that
_far_ _away_ from the factor 27 which was mentioned in the article...
So given this first statement comes to very unreliable results, one might
think about the reliability of the remaining parts of the documents and how
appropriate the comparisons were chosen.
Regards
Stephan
Stephan Kuhagen
> And I would have some complaints about Perl, but I do not want to flame
> here, so I omit it deliberatly.
@/Why Tea
See, what I meant, when I wrote "And people here in c.l.t are
normally not interested in doing these childish "mine is better than
yours"-wars, and I really appreciate that."...? ;-)
Advice: Let only the really relevant facts speak, and check statements for
truth and importance to the problem.
Regards
Stephan
Why Tea
I did notice the maturity of the people here as you pointed out. I can
also get help quite easily from the group, which is great. I have
learned Tcl/Tk and Expect just enough to get the job done. So far, it
hasn't failed me. But what I have written is generally not time
critical, so speed is not important.
I believe those two articles were written with good intentions, we
probably shouldn't judge them as out to degrade Tcl.
Stephan Kuhagen
> I believe those two articles were written with good intentions, we
> probably shouldn't judge them as out to degrade Tcl.
I can believe that too, and I do not think, that your intention was to start
some childish "Tcl vs. Something"-Thread. My point was, that the articles
do not make sense anymore, since they are really outdated. There has been
much improvement since Tcl 7.5. When I started learning Tcl about '94, I
think, speed clearly wasn't the reason, what fascinated me (especially
because before I did mostly assembler) and I also think, that Tcl is not a
very fast language at the scripting level. But much optimization was done
since then, and often I hear people talking about the slowness of Tcl, but
all they know is Tcl from years ago. In fact, I wrote a parser for compiler
output this year in Tcl and in Python. They both do the same thing and are
fairly good optimized. The Tcl version is, depending on the amount of
input, up to 7 times faster. This is clearly not true for all comparisons,
and I do not want to compare Tcl in such a way. But I really would like to
have this preconception eliminated, that Tcl is nothing more than slow. It
is not, and it is easily powerful enough for really big software projects.
This is why I rejected these articles: they are outdated and keep old and
wrong preconceptions alive.
Regards
Stephan
Kevin Kenny
Those articles are an excellent summary of the faults of Tcl as it
stood in July of 1995. Alas, they (and Stallman's screed from
roughly the same time) are still presented as if they are the
current state of the art. And we spend an inordinate amount of
time trying to refute them.
Aaron Sherman's list of complaints is perhaps the most comprehensive,
so let me detail those. (Tom Christiansen's essay pretty much covers
a subset of the points, and the points he mentions have largely
been cleaned up *without* sacrificing the benefits of a dynamic
language.)
1. Tcl's strings are straight C strings, making length-dependent
operations slow. Tcl's list operations are equally slow, because
lists are strings.
Untrue since 1997. The Tcl_Obj structure has a string length.
The internal representation of a Tcl list is an array.
2. Tcl cannot deal with binary data because everything must be a
null-terminated string.
Untrue since 1999. When Unicode compliance was added, Tcl's
basic string represetation became UTF-8, with an added twist
that the invalid UTF-8 byte sequence C0 80 is used to represent
a null byte in binary data. Binary data can be held efficiently
in byte arrays.
3. Tcl cannot pass arrays by value or by reference, only by name.
This is largely a question of style. [array get] and
[array set] can indeed be used to pass by value. Passing
any object (not just an array) by reference is accomplished
using pass-by-name and [upvar]. That's just how you spell
it in Tcl, and somewhat a matter of personal taste.
4. Tcl lacks an installation mechanism and set of standard paths
for new packages.
This comment predates the [package] command, added in 1996.
5. Tcl stores numbers as strings, slowing its arithmetic.
Not since 1997.
6. Tcl is a pure interpreter; Perl uses a bytecode engine.
Tcl has been bytecoded since 1997.
7. Perl comes with a full debugger, closely integrated with the
language.
The best Tcl debuggers have always been add-ons. The core
developers have typically not been interested in adding
this functionality, partly because we don't miss it much
ourselves (there are so many other ways of introspecting
a Tcl program's behaviour), and partly so as not to bite
the hand that feeds us (sales of TclPro from Scriptics and
TDK from ActiveState have funded considerable Tcl development).
This could be seen as a valid complaint.
8. Perl has namespaces that can export their sumbols.
So does Tcl. Since 1997.
9. Perl allows dynamic loading of object modules.
So does Tcl. Since 1996.
10. Perl has anonymous subroutines. Tcl lacks them.
True. I've wanted anonymous lambdas for some time; there
are a lot of details that have to be hashed out. The
presence of [apply] in 8.5 will help some, and "auto-{*}
on the leading word" would help even more, but would
need a major release to get in.
11. Perl's list is numerically indexed, and Perl also has hashes.
Ditto Tcl, since 1999.
12. Perl's extension mechanism (a C preprocessor that turns prototype-
like definitions into interface code) is more convenient than
Tcl's binary API.
This is somewhat a matter of opinion. I happen to prefer
TEA to Perl's mechanisms; then again, Tcl's interfacing
has improved enormously in the last decade.
13. Perl has references which allows arbitrarily complex data
structures including structures that are self-referential.
Indeed it does. There is some dispute as to whether this
is a good thing. Many Tcl'ers believe that sort of thing
is for a lower-level language. I'll concede this round
to Perl.
14. Perl can analyze a script for syntax errors without executing it.
Tcl's dynamic nature, where virtually anything but the twelve
syntax rules can be redefined at run time, makes this
inordinately difficult to get right in the most general case.
For less wizardly uses, the TDK checker (payware) and Frink
(open source) do quite a creditable job. Admittedly, neither
is "in the core". Tcl suffers a great deal from disparagement
of extensions. I'll give Perl a slight edge on this point,
but only a slight one.
15. Perl has an object programming model.
Tcl's problem isn't that it lacks an object programming model,
but that it's agnostic about object programming. It's
possible to do quite a creditable job of object programming
even in pure Tcl using a script-level package such as Snit.
Yes, we're currently debating "OO in the core," but that
debate is primarily driven by politics and to a lesser extent
by run-time performance, not by capability.
16. Perl provides an interface to all the Posix (.1) routines.
Pray be more specific. Tcl has an awful lot, but often it
doesn't precisely mirror Posix. Intentionally. Tcl runs
quite well on systems that do not have workable Posix
libraries - such as Windows - without resorting to emulation
layers. There are a couple of gaps - generally in
Posix API's that do not port gracefully to other platforms -
and those gaps are filled quite nicely with extensions.
Of course, many Tcl detractors, and some enthusiasts,
disparage extensions for various reasons, many of which
I fail to comprehend.
In short, virtually all of the points in Mr Sherman's article have been
addressed years ago. Circulating this article and presenting it as if
it's the current state of affairs is little short of libellous.
--
73 de ke9tv/2, Kevin
Stephan Kuhagen
...
> In short, virtually all of the points in Mr Sherman's article have been
> addressed years ago. Circulating this article and presenting it as if
> it's the current state of affairs is little short of libellous.
Bang! - Thanks for the effort. I think, this list of correction, maybe
completed by some other old myths about Tcl should be presented in a good
readable form at wiki.tcl.tk, so one can simply point at the article and
say: here, look, it's all there since years.
Regards
Stephan
Ian Bell
> * Tcl cannot pass arrays by value nor by reference. [dict] allows us
> to pass arrays by value. (to be seen in upcoming 8.5, but already
> done via a 8.4 package)
>
Maybe I am missing something here but surely it must be one or the other -
or is there a THIRD WAY (tm).
Ian
Uwe Klein
Stephan Kuhagen
>> I think, this list of correction, maybe
>> completed by some other old myths about Tcl should be presented in a good
>> readable form at wiki.tcl.tk, so one can simply point at the article and
>> say: here, look, it's all there since years.
...
> Done: http://wiki.tcl.tk/12366
I'm starting to like wikis - and the people who fill them, of course.
Regards
Stephan
Cameron Laird
Kevin Kenny <ken...@acm.org> wrote:
.
[Kevin conscientiously
is more than fair in
his accurate recital of
many points]
.
.
> 12. Perl's extension mechanism (a C preprocessor that turns prototype-
> like definitions into interface code) is more convenient than
> Tcl's binary API.
> This is somewhat a matter of opinion. I happen to prefer
> TEA to Perl's mechanisms; then again, Tcl's interfacing
> has improved enormously in the last decade.
most ... zealous Perlites agree that h2xs, xsubpp, and
the rest might be many things, but, in even the rosiest
view, aren't "convenient". Committed Perl advocates
have written for years about the "embarrassment" of
existing extension mechanisms on that side.
Kevin knows this, of course, and probably is just too
courteous to make it explicit. My own position is that
'twould be an injustice for me not to say this clearly.
.
.
.
> 16. Perl provides an interface to all the Posix (.1) routines.
> Pray be more specific. Tcl has an awful lot, but often it
"... UNDER UNIX." The article leaves out several key
qualifications, like this one.
.
.
.
>addressed years ago. Circulating this article and presenting it as if
>it's the current state of affairs is little short of libellous.
I have nothing more to add.
.
.
.
sleb...@gmail.com
Strictly speaking, Tcl passes "native arrays"* by name. The classic way
to pass an array is to pass a 'string' which happens to be the array
name and then to use upvar to create an alias of that array in the
local scope. This is neither by value nor by reference in the strictest
sense since true references in other languages are something quite
different. Although passing by name does feel like passing by reference
similar to how C's passing by value-of-address feels like passing by
reference.
* note: syntactic arrays as opposed to command supported 'array'
analog: dict
sleb...@gmail.com
> I believe those two articles were written with good intentions, we
> probably shouldn't judge them as out to degrade Tcl.
But they are obsolete. Tcl is generally no longer like that. Most
people here at c.l.c can no longer identify what they describe as Tcl.
It is similar to claiming that Linux doesn't support loading device
drivers at runtime or Windows doesn't have built-in support for USB or
MacOS doesn't have memory protection. All the claims above were once
true but became false at roughly the same timeframe around 1996-2000.
Nobody today would seriously claim what Windows don't support USB.
suchenwi
of code, it is also possible (and more fun) to write relatively small
scripts which still do big things :)
Kevin Kenny
> It's not even "a matter of opinion"; all but the
> most ... zealous Perlites agree that h2xs, xsubpp, and
> the rest might be many things, but, in even the rosiest
> view, aren't "convenient". Committed Perl advocates
> have written for years about the "embarrassment" of
> existing extension mechanisms on that side.
I wrote that answer at least partly from ignorance. I had
not used Perl's extension mechanism since the days of Tcl 7.3
or so, when extending Tcl meant embedding it in another application,
and combining, say, Tk and Expect was not for the faint of heart.
The possibilities that I saw in Perl's approach to extension
were a major motivator for implementing the [load] command in
Tcl. I presumed that many of Perl's inconveniences were
teething pains that had been addressed in the intervening time.
>> 16. Perl provides an interface to all the Posix (.1) routines.
>> Pray be more specific. Tcl has an awful lot, but often it
>
> "... UNDER UNIX." The article leaves out several key
> qualifications, like this one.
Indeed, one mark of the article's obsolescence is that it predates the
first credible implementations of either Tcl/Tk or Perl on Windows.
(Tcl by itself ran on Windows fairly early, but Tk wasn't stable
and supported there until 7.5 or so.)
Ian Bell
> Ian Bell wrote:
>> Stéphane A. wrote:
>>
>> > * Tcl cannot pass arrays by value nor by reference. [dict] allows us
>> > to pass arrays by value. (to be seen in upcoming 8.5, but already
>> > done via a 8.4 package)
>> >
>>
>> Maybe I am missing something here but surely it must be one or the other
>> - or is there a THIRD WAY (tm).
>
> Strictly speaking, Tcl passes "native arrays"* by name. The classic way
> to pass an array is to pass a 'string' which happens to be the array
> name and then to use upvar to create an alias of that array in the
> local scope.
Do you know, I read the OP I don't know how many times and it is only this
time I saw the word 'array'
Doh!!
Ian
Mike
Small tcl scripts or small shell scripts. The only heartburn I have with
tcl is the lack of a native debugger. I'm a unix-head for many years. I
prefer command line. I don't want a gui. I like that perl has 'perl -d'
to see what is happening inside the script. I would like tcl to be as easy.
Mike
Donal K. Fellows
> Small tcl scripts or small shell scripts.
Knowing Richard, definitely "small Tcl scripts". :-)
> The only heartburn I have with
> tcl is the lack of a native debugger. I'm a unix-head for many years. I
> prefer command line. I don't want a gui. I like that perl has 'perl -d'
> to see what is happening inside the script. I would like tcl to be as easy.
With some experience of Perl's debugging mode, at least some of the
functionality can be had just through tclsh's normal interactive mode
console. OK, so that doesn't do everything - it's no substitute for a
real debugger - but that's largely because the Tcl community has
(historically) tended to prefer keeping the Tcl library a bit more
heavily stripped down. I know of several third-party debugging tools
though; right now, I'd claim that the main things to look at are either
the (commercial) tools produced/maintained by ActiveState, or the
(open/free) DLTK plugin for Eclipse. Both have far more sophistication
than it would make sense to place in a standard tclsh installation.
Remember, third-party does not mean second-class!
Donal.
sleb...@gmail.com
> sleb...@yahoo.com wrote:
> > Strictly speaking, Tcl passes "native arrays"* by name. The classic way
> > to pass an array is to pass a 'string' which happens to be the array
> > name and then to use upvar to create an alias of that array in the
> > local scope.
>
> Do you know, I read the OP I don't know how many times and it is only this
> time I saw the word 'array'
No problem. Although it should be noted that arrays aren't the only
things that Tcl can pass using the THIRD WAY (tm). Ordinary variables
can be passed by name.
Gerald W. Lester
As can code fragments and used via uplevel.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Robert Heller
>
> sleb...@yahoo.com wrote:
> > Ian Bell wrote:
> >> sleb...@yahoo.com wrote:
> >>> Strictly speaking, Tcl passes "native arrays"* by name. The classic way
> >>> to pass an array is to pass a 'string' which happens to be the array
> >>> name and then to use upvar to create an alias of that array in the
> >>> local scope.
> >> Do you know, I read the OP I don't know how many times and it is only this
> >> time I saw the word 'array'
> >
> > No problem. Although it should be noted that arrays aren't the only
> > things that Tcl can pass using the THIRD WAY (tm). Ordinary variables
> > can be passed by name.
> >
>
> As can code fragments and used via uplevel.
Which *as far as I can tell* is pretty much a unique feature of Tcl (vs
other 'modern' scripting languages).
Tcl's uplevel + catch is a very powerfull feature, one that is generally
overlooked when comparing it to other scripting languages (like Perl,
Python, php, or Ruby).
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Ian Bell
> At Thu, 28 Dec 2006 07:43:41 -0600 "Gerald W. Lester"
> <Gerald...@cox.net> wrote:
>
>>
>> sleb...@yahoo.com wrote:
>> > Ian Bell wrote:
>> >> sleb...@yahoo.com wrote:
>> >>> Strictly speaking, Tcl passes "native arrays"* by name. The classic
>> >>> way to pass an array is to pass a 'string' which happens to be the
>> >>> array name and then to use upvar to create an alias of that array in
>> >>> the local scope.
>> >> Do you know, I read the OP I don't know how many times and it is only
>> >> this time I saw the word 'array'
>> >
>> > No problem. Although it should be noted that arrays aren't the only
>> > things that Tcl can pass using the THIRD WAY (tm). Ordinary variables
>> > can be passed by name.
>> >
>>
>> As can code fragments and used via uplevel.
>
> Which *as far as I can tell* is pretty much a unique feature of Tcl (vs
> other 'modern' scripting languages).
>
> Tcl's uplevel + catch is a very powerfull feature, one that is generally
> overlooked when comparing it to other scripting languages (like Perl,
> Python, php, or Ruby).
>
>>
>
This language continues to astound me. The potential for incredibly elegant
coding is virtually limitless.
Ian
Donald Arseneau
> Here are two articles, which could be biased towards Perl, but they do
> provide useful information into some of the problems of TCL
>
> http://www.perl.com/doc/FMTEYEWTK/versus/tcl-discussion.html
which begins "In comp.lang.perl, mcdo...@cs.sfu.ca" ...
Google/groups locates it easily:
Perl vs TCL (was: Execution speed of Perl?)
...
comp.lang.perl - Apr 16 1995, 1:59 pm by Tom Christiansen - 12 messages - 10 authors
That perl.com web site is disingenuous for posting the message without
any date or context.
--
Donald Arseneau as...@triumf.ca
Arjen Markus
Kevin Kenny schreef:
>
> 7. Perl comes with a full debugger, closely integrated with the
> language.
> The best Tcl debuggers have always been add-ons. The core
> developers have typically not been interested in adding
> this functionality, partly because we don't miss it much
> ourselves (there are so many other ways of introspecting
> a Tcl program's behaviour), and partly so as not to bite
> the hand that feeds us (sales of TclPro from Scriptics and
> TDK from ActiveState have funded considerable Tcl development).
> This could be seen as a valid complaint.
>
We can also turn this around:
Tcl is by itself powerful enough to allow programmers to develop their
own debuggers. It has been done with various levels of sophistication,
the Wiki is my witness, and last night I whipped up a little debugger
of
my own in just a couple of hours. Nothing great, and it is almost
guaranteed
to fail with more complex source code than I used, but I regard the
fact that
this is possible as a very strong point in favour of Tcl.
Regards,
Arjen
Donal K. Fellows
> Gerald W. Lester wrote:
>> As can code fragments and used via uplevel.
>
> Which *as far as I can tell* is pretty much a unique feature of Tcl (vs
> other 'modern' scripting languages).
You can do something that is very much like the way that Tcl programmers
normally use [uplevel] (to run some code supplied by the caller) in
Perl, as can be seen from the appropriate manual page.
http://search.cpan.org/dist/perl/pod/perlsub.pod#Prototypes__
However, the syntax for doing so is distinctly icky (but then again,
it's Perl so what's new?) and other uses (e.g., running code generated
dynamically in the caller's context) are not supported. Perl doesn't
work like that so Tcl is strictly richer here, though this does allow
for further optimization opportunities...
Donal.
David N. Welton
> Perl vs TCL (was: Execution speed of Perl?)
> ...
> comp.lang.perl - Apr 16 1995, 1:59 pm by Tom Christiansen - 12 messages - 10 authors
>
>
> That perl.com web site is disingenuous for posting the message without
> any date or context.
Perl vs Tcl is, in some ways, like two old men trying to feebly punch
one another... The "action" as it were, these days is with Python and
Ruby, in terms of scripting languages, Java and C# for big clunky
languages, with some hints of smoke on the horizon from things like
Erlang and Haskell.
Doesn't mean Perl or Tcl are dead (far from it), just the rate at which
people adopt them for new projects, compared with other languages, has
slowed.
When considering Tcl for a Big Project, you probably want to compare it
against Python, Ruby, and maybe Java or C# to see what each one's
strengths and weaknesses are.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
Eckhard Lehmann
Stéphane A. schrieb:
> * No built-in debugger. (but some IDEs provide such functionality
> and so does Tkcon)
TIP #290 targets a part of this problem, namely trapping errors. But
there needs to be done a bit more - especially stepwise code
execution... maybe this can be done via some [trace execution] magic.
But in my opinion it is better to have it built in, so that the whole
debugging functionality is there in a clean "all-in-one package".
Eckhard
Earl Greida
"David N. Welton" <dav...@dedasys.com> wrote in message
news:45956690$0$19092$4faf...@reader4.news.tin.it...
>
> Perl vs Tcl is, in some ways, like two old men trying
> to feebly punch one another... The "action" as it were,
> these days is with Python and Ruby, in terms of scripting
> languages, Java and C# for big clunky languages, with some
> hints of smoke on the horizon from things like Erlang and Haskell.
>
> Doesn't mean Perl or Tcl are dead (far from it), just the rate at
> which people adopt them for new projects, compared with other
> languages, has slowed.
>
> When considering Tcl for a Big Project, you probably want to
> compare it against Python, Ruby, and maybe Java or C# to see
> what each one's strengths and weaknesses are.
>
[soapbox]
Other than marketing, and/or language author ego, I just cannot see why we
need to continue to create a Tower of Babel with programming languages.
Improve the existing languages with the new ideas.
Is it really necessary to have C/C++->Java->C#, or Tcl, Perl, Python, Ruby,
etc? Other than being a pain in the rear to have to deal with, just what
benefit is derived from all these languages, versus one complete compiled
language, and one complete interpreted language? I wouldn't be surprised if
over 50% of language keywords, and concepts are common to all these
languages. Do the differences really justify creating an entirely new
language?
Personally, I think Stroustrup had the right idea when he decided to enhance
C, rather than creating a new language. I wish these, and any current or
future, language authors would show the same common sense and restraint.
Basically, it irritates me to no end to see jobs that are perfectly suited
for Tcl being advertised as requiring Perl or Python. It seems that the
main "benefit" of having multiple languages that pretty much do the same
thing is lost productivity.
David N. Welton
> Other than marketing, and/or language author ego, I just cannot see why we
> need to continue to create a Tower of Babel with programming languages.
> Improve the existing languages with the new ideas.
On a practical level, that's difficult because big changes require a
long time, or simply might not be possible due to backwards
compatibility issues.
On a more philosophical level, the reason there are so many languages is
that programming languages exist entirely for the benefit of human
beings, who tend to vary a lot in their tastes, abilities and
objectives. Some people really love Python, others think that Erlang is
the cat's pajamas, while others don't see anything at all wrong with
Fortran.
And furthermore, if you think about it, it's such a new field that we
have a lot to learn. Any problem that involves creating a bridge
between rapidly evolving, extremely complex machines, and somewhat
evolved hairless apes is bound to be a tough nut to crack!
We are, however, fortunate to get so many language implementations as
open source, so that it's possible to fiddle with them.
Gerald W. Lester
> ...
> [soapbox]
> Other than marketing, and/or language author ego, I just cannot see why we
> need to continue to create a Tower of Babel with programming languages.
> Improve the existing languages with the new ideas.
>
> Is it really necessary to have C/C++->Java->C#, or Tcl, Perl, Python, Ruby,
> etc? Other than being a pain in the rear to have to deal with, just what
> benefit is derived from all these languages, versus one complete compiled
Hmmm, as I recall that was the justification for creating and the main goal
of Ada.
My take is that the one language just has to have to much baggage to be
everything to everyone to be usable -- in the sense that it is too difficult
for most people to get their heads around the "mega-language".
Donald Arseneau
> [soapbox]
> Other than marketing, and/or language author ego, I just cannot see why we
> need to continue to create a Tower of Babel with programming languages.
> Improve the existing languages with the new ideas.
I particularly disagree with that sentiment because of the atrocities
it generates. When new features get added to an old language they get
squeezed into the unused niches of possible syntax, and wind up deformed.
--
Donald Arseneau as...@triumf.ca
Earl Greida
"Donald Arseneau" <as...@triumf.ca> wrote in message
news:yfimz56...@triumf.ca...
That makes sense. I guess that means that ActiveState will announce that
Tcl is at its end of life and no new features will be added. Time to throw
it away and create a new language.
David N. Welton
> Tcl is at its end of life and no new features will be added. Time to throw
> it away and create a new language.
Well... not quite. You might want to read some other writings of mine
on the economics of programming languages:
http://www.dedasys.com/articles/programming_language_economics.html
It explains why Tcl will be with us for a long time yet.
If, however, you're interested in a new language, you might check out
Jim, or Hecl:-)
Cameron Laird
.
.
Yes.
I want to emphasize, also, that the differences between
languages are of different sorts. Superficially and
subjectively, many practitioners think of Python vs. Tcl
as about whitespace and quoting rules. As it turns out,
both languages are flexible enough to mimic the other in
these regards. However, Python doesn't have safe inter-
preters, and won't have them; safe interpretation turns
out to be deeply incompatible with other Python attri-
butes.
This illustrates that Earl's right that different
languages--certainly those in the Perl-Python-Ruby-
Tcl-... range--certainly exhibit much that's merely a
relabeling of what's present in another, BUT that there
also are serious distinctions. Many programmers operate
at a level where Unicode model or multiple inheritance
or ... never matter; for them, the differences between
languages are just annoyances. Progress in languages as
a whole, though, depends on exploration of the unique
capabilities of Tcl or Erlang or Forth or ...