report evaluating use of Tcl/Tk for an app
Mark Roseman
http://www.sei.cmu.edu/publications/documents/03.reports/03tn001/03tn001.html
While not exactly definitive, and I don't take too much stock
on it, it does probably portray a lot of things accurately, and
I think it may offer some useful insight into how newcomers and
outsiders would see the language.
It does base its findings on the sources that presumably they could
easily/quickly find; looking at the list, its obvious that its not
easy to find a solid collection of things. Some of the comments,
e.g. w.r.t. development personnel, were I thought very relevant.
In any case, just one report, not something to make a big deal out of,
but worth bringing some attention to.
Mark
Gary Seviour
before. I'm new to tcl, but i cant see any reason why you have to build tcl
according to the "classic Tcl/Tk windows" structure that Wilfred J. Hansen
states was used for SYS. "classic tcl windows" - sounds like a "cobbled
together" approach to me.
And if he's worried about scripts being used to violate business rules then
why does he not mention that on most DBMS you can write stored procedures to
access data and use security settings to prevent that data from being
accessed in any otherway. To me, his beef with TCL has nothing to do with
language specific issues but has more to do with early design decisions made
by the developers of SYS.
Am I talking nonsense?
Gary Seviour
Technology Obsessor
All this stuff about
Mark Roseman <ma...@markroseman.com> wrote in message
news:mark-10373A.0...@news.cogeco.ca...
Chang Li
"This system is written almost entirely in Tcl/Tk (Terminal Control
Language/Toolkit, pronounced "tickle-tee-kay"). "
Correct a simple error, Tcl is (Tool Control Language).
"The user interface is a large set of windows--over two hundred"
This is a GUI design fault not Tcl. How do you organize this large amount of
windows?
Without using object-orient programming the architecture may be not
scalable.
There are many ways to organize many windows(widgets): menu, megawidget (or
form),
pane window, wizard, etc. Web browser provides document based GUI. The
drawback
of web gui is the lack of the widgets. For example, there is no progress bar
in standard
HTML. It is also inconvenient for editing. Tcl/Tk GUI can do all the work of
classic
window's GUI.
Clicking buttons and popup windows full of the screen is not good in
usability. It is
possible to use window's stack rather than tree to improve usability.
Because Tcl is very flexible and lacks of design pattern we can easily say
that Tcl is the
reason of fault.
Chang
"Mark Roseman" <ma...@markroseman.com> wrote in message
news:mark-10373A.0...@news.cogeco.ca...
Roy Terry
>
> Stumbled across this report:
>
> http://www.sei.cmu.edu/publications/documents/03.reports/03tn001/03tn001.html
Interesting for its topic but not at all
impressive as a piece of analysis. In fact,
if you read section 1 closely you'll see that
the whole paper is basically a rebuttal
to the system developers who "not completely
sympathetic to our suggestion" [that "another
approach be taken" for subsequent development].
First off, the author doesn't even know
what TCL stands for:
Terminal Control Language! What's that?
Secondly it is populated with truisms and empty
assertions similar to what you'd find
on slashdot such as the idea that OO is a
sort of magic salve for design issues.
The author and his organization are not
neutral parties; CMU has a lot of image
issues it needs to protect[1]. And acknowledging
advantages and benefits for plain 'ol ugly TCL
couldn't go well.
There is much conflation and confusion
between using Tcl/Tk vs. the actual
architecture of the system and it's
strengths and weaknesses. In particular,
the author's invention of the term
"Classic Tcl/Tk Windows" represents
a straw man sort of put down that has
nothing to do with inherent abilities of Tcl/Tk
for GUIs. There is a section:
"6.1 Alternatives for the User Interface Architecture"
which actually entertains exactly one alternative - a
web page. Here you will find such analytic smoke as:
"the tradition with buttons is to place them at a specific
location with a cryptic word or two...[whereas]..links are often
associated with pictures to make their meaning clearer."
This is apparently a valid criticism of "Classic Tcl/Tk
Windows" but is not a reflection on Tcl/Tk as a programming
language since HTML is not a programming language.
Gee what about all those "Classic Windows Applications" like MS
Office? - I guess they will be getting rid of their buttons
now.)
There is the usual late-arriver phenomenon here:
1. The existing functionality is taken for granted.
2. The new approach is assumed to already have the
existing functionality (which it won't!)
3. Currently perceived limitations are attributed to
technology decisions when they are really design
decisions that may well have been necessary.
4. The proposed alternative technologies are presented
as having no drawbacks worthy of mention (the grass is
always greener!)
5. *No* mention is made of developer experiences as
to the advantages (or disadvantages) they perceived
in implementing the original system with Tcl/Tk.
6. *No* mention is made about how much work might
have been involved had the original system been
built using "another approach".
7. Exploration of alternatives was stilted. For
example, the main complaint of the existing system
was too many top level windows that don't scroll.
Alternatives that weren't mentioned include:
- Add a window manager layer (e.g. like an explorer
where a window list is on the left and windows are
popped into view on the right.
-or-
- Make a few larger windows that do scroll!
Overall, it seems the goal is to argue for a
new architecture. But with broad detours giving
an outsider's view of Tcl sufficient to trivialize it
and silence the critics.
So, again, pseudo sciences carries the day: untestable
claims, selective and non-quantitative "data",
dubious motivations, and shaky understandings.
I do give the author credit for a basic sense of fairness
while the licking was administered. He went out of
his way to state that the current system was not "BAD"
and that Tcl was not "BAD". ("I'm doing this for
your own good" ;-) I suspect that the orginal,
objected-to report was even less generous.
Oh well, at least it's a stimulating "think piece".
I guess I'll want to avoid using the Terminal Control
Language in the future.
Cheers,
Roy
PS: Seems many organizations that
got successful implementations with Tcl
suddenly decide it must have been a very
easy problem and life would be perfect if
they could just get rid of the schmuck
that brought them to the ball...
Veritas and ACS come to mind - (sigh).
----------------
[1] I bumped into image preservation when,
some time ago, I inquired about adopter contacts
for CMU's vaunted Capability Maturity Model. I was
immediately put off into official information sources
only! It's also notable the CMU has fielded books on
replacing legacy systems.
Jeffrey Hobbs
> Stumbled across this report:
>
> http://www.sei.cmu.edu/publications/documents/03.reports/03tn001/03tn001.html
>
> While not exactly definitive, and I don't take too much stock
> on it, it does probably portray a lot of things accurately, and
> I think it may offer some useful insight into how newcomers and
> outsiders would see the language.
While some things are accurate, some seem blatantly skewed to present
an unpalatable view.
His whole section on "Classic Tcl/Tk Windows" shows that he probably
has little knowledge of UI functionality and just based his ideas on
the limited UIs that he evaluated.
Take for example:
"Since classic Tcl/Tk windows generally do not scroll the entire window, they
must survive in constrained screen space. In consequence, there is a tradition
of cryptic button labels. Image tools are few, so icons are seldom developed.
Altogether, the window image for a classic Tcl/Tk window is functional, but
not always inviting."
This is a comment on whatever he evaluated, not what can be done.
Since most people are interested in having something that "just works",
it makes for an unbalanced example. He should have also considered
commercial UIs that use Tk. He likely had more limited access to such
because of license restrictions or the like, but that does not excuse
such incorrect blanket statements. All in all through the UI comments
section, it seems like these guys were in greater need of someone with
UI design skills than another UI toolkit. The ability to create
resizable windows with well-behaved resize behavior in Tk is
unsurpassed, and the basic ability to create fancy UIs with fully
scrolling screens and the like is all well within Tk's functionality.
The evaluation of commercial tools was also ... odd to me. Visual Gypsy
is quoted as "a drag-and-drop visual GUI builder for TclTk" yet he
qualified it as a web evnt "environments that create Web sites". He
lumped ActiveTcl (the dist) with Komodo and Tcl Dev Kit (the IDE and
developer tools) all as "dist". He followed ACS enough to label it
"defunct" following the move to Java and acquisition by RedHat, but
somehow ignored the well-known and still active www.openacs.org branch
of the Tcl implementation (which is what AOLServer stays closely
associated with - not the RedHat version).
Altogether, he does have some good points on why his architecture might
fit a web environment (or at least one that uses the http protocol), but
I don't see where the counterpoint to the high level of difficulty for
programming Java apps compared to Tcl/Tk was considered. In the end
though, you see that the subtitle for the paper is "Rendering Tcl/Tk
Windows as HTML", which is an odd thought in itself, but does sort of
explain more about the position of the results in the paper. It really
appears as if they had made the architectural decision that the next-gen
SYS must be a web-delivered environment and that they were trying to
reconcile with how to adapt the existing Tcl/Tk version to that. I'm
sure looking at things like the wiki (with Tk and HTML interfaces) may
have been interesting, and I can think of several related commercial
projects (again, S.A. restriction on access to commercial stuff ...).
There are some good general points in there as well which speaks to our
need to better organize community resources and awareness, but that is
always something that takes community time. Someone should follow up
with the author (and if possible, his whole group, since he may have had
foregone conclusions when authoring this paper) to at least address the
basic fallacies in the paper.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Rohan Pall
news:3E60F9DC...@ActiveState.com:
> Take for example:
>
> "Since classic Tcl/Tk windows generally do not scroll the
> entire window, they must survive in constrained screen
> space. In consequence, there is a tradition of cryptic
> button labels. Image tools are few, so icons are seldom
> developed. Altogether, the window image for a classic Tcl/Tk
> window is functional, but not always inviting."
As far as I can tell, Tigerbliss scrolls the entire window, it
shows images with an incredible amount of success, icons are
used, images are dynamically resized, its functional, and it
sure is inviting to me.
Tigerbliss accomplishes this feat with the use of a dizzying
array of tools, but in these featured feats of which I referred
to, it uses Img, BWidget, and of course classic tcltk. What
ever classic tcltk may be.
There is no way I could have developed this program in the time
frame I alloted myself if I were using other toolkits and
languages, including Perl, Python, and a host of Win32 specific
technologies.
The program may be unpalatable to some, but in deference to
technological truth and in direct conflict with the interests
that are at the heart of this paper so referenced, I have
spoken.
> This is a comment on whatever he evaluated, not what can be
> done. Since most people are interested in having something
> that "just works", it makes for an unbalanced example. He
> should have also considered commercial UIs that use Tk. He
> likely had more limited access to such because of license
> restrictions or the like, but that does not excuse such
> incorrect blanket statements. All in all through the UI
Yes, I should send him a copy of Tigerbliss. That will sway
him to the side of right, light and justice.
> comments section, it seems like these guys were in greater
> need of someone with UI design skills than another UI
> toolkit. The ability to create resizable windows with
> well-behaved resize behavior in Tk is unsurpassed, and the
> basic ability to create fancy UIs with fully scrolling
> screens and the like is all well within Tk's functionality.
Absolutely, this is known to the enlightened few. We must seek
to bring this knowlege to more, to the children of the corn.
> There are some good general points in there as well which
> speaks to our need to better organize community resources
> and awareness, but that is always something that takes
This is the most crucial aspect of this paper. Look at the
python guys, they have more than enough time to write position
papers, to spam the world with their righteous slogans, to
increase the alloted share of mind that they were given, look
to their PyPI, to their unashamed self-analysis that seeks out
weakness and crushes it. We are the Future.
> community time. Someone should follow up with the author
> (and if possible, his whole group, since he may have had
> foregone conclusions when authoring this paper) to at least
> address the basic fallacies in the paper.
Yes.
Jay Rohr
>
> There are some good general points in there as well which speaks to our
> need to better organize community resources and awareness, but that is
> always something that takes community time. Someone should follow up
> with the author (and if possible, his whole group, since he may have had
> foregone conclusions when authoring this paper) to at least address the
> basic fallacies in the paper.
>
As a CMU alumus, I have written the SEI at CMU and the author and
invited them to join this discussion.
John Seal
about rendering Tcl/Tk in HTML. I downloaded the PDFs and will make sure
my boss reads them. Now that we have delivered a major project written
in Tcl/Tk with C interfaces to 3rd-party libraries (e.g. GPIB drivers),
and others have seen how well it works and how fast I developed it,
there is suddenly lots of interest in Tcl/Tk.
I found the same errors already pointed out in this thread, and felt the
same undercurrent of anti-Tcl bias in the articles. I hope the author
does join this discussion.
In related news, I have been talking to my boss, and his boss, and
anyone who'd listen, about the need for automated regression testing on
our project. They finally told me to explore it, and 46 hours later I
had a package to demo! They were pleasantly surprised.
OT bragging: My employer, Raytheon Technical Services Co., Engineering
and Production Support, Indianapolis, just received a CMM Level 4 rating
on Friday. Woo Hoo!
se...@fishpool.com
> Stumbled across this report:
>
> http://www.sei.cmu.edu/publications/documents/03.reports/03tn001/03tn001.html
There's not much point commenting on the various issues on c.l.t. We all
know many parts of that report are wrong. The real way to go about it is
to email the author and comment on the various points in a fair, diplomatic
way. So has anybody done this?
Mark Roseman
> know many parts of that report are wrong. The real way to go about it is
> to email the author and comment on the various points in a fair, diplomatic
> way. So has anybody done this?
Incidentally, my point in bringing this up to the newsgroup was not
so much to address this specific report (its been written, its served
its purpose for the author, thought if it remains publically available,
it makes sense to correct any inaccuracies, as can be achieved by
people getting in touch with the original author).
Instead, I just wanted to again highlight, as Jeff and others alluded
to, that (my opinion) the current resources that are available for Tcl
make it far easier than it should be to draw such conclusions. So I
thought it obvious it was technically flawed; the more interesting point
was that our resources probably played a big part of that, though the
author's methodology is also weak. And second, that there were some
opinions in the report (non-technical ones especially, such as comments
about hiring people with Tcl skills) that to me seemed valid and
more troubling.
Having said that, right now I'm just going to be one of those whiners
who just sits and compains rather than try to do anything about it. ;-)
Arjen Markus
Hm, the summary talks of "Terminal Control Language" - are we talking
about the same language? Or did I miss something?
Regards,
Arjen
John Seal
Rendering Tcl/Tk Windows as HTML
CMU/SEI-2003-TN-002, February 2003
http://www.sei.cmu.edu/publications/documents/03.reports/03tn002.html
Why hack the Tk libraries to generate HTML, instead of using the Tcl plugin?
Rohan Pall
news:ImJ8a.59$35...@dfw-service2.ext.raytheon.com:
> Why hack the Tk libraries to generate HTML, instead of using
> the Tcl plugin?
They probably didn't get the newsflash -- that its available.
Bob Binder
>
> http://www.sei.cmu.edu/publications/documents/03.reports/03tn001/03tn001.html
>
> While not exactly definitive, and I don't take too much stock
> on it, it does probably portray a lot of things accurately, and
> I think it may offer some useful insight into how newcomers and
> outsiders would see the language.
>
I wrote to Mr. Hansen to let him know about "Terminal Control
Language" and a few other nits. He said he'd try to make corrections,
but wasn't sure if the SEI's publication office would allow that.
Part of Hansen's intent was to debunk the notion that Tcl/Tk was an
inherently bad language, because of one Tcl system (profiled in the
report) which had overly complex UI.
Since bad UI design is equally well-supported in any language, it
seemed axiomatic to me that this was a silly notion. However, Hansen
said that he thought the relative ease of creating Tk widgets was a
contributing factor for the developers of the system he studied. What
seemed peculiar to me was that blaming the language for an obvious
case of development by amateurs was apparently par for the course in
his context. This is reminiscent of blaming guns and SUVs for harm
caused by criminals and incompetents, and the process that gets us to
warnings on a chain saw that read "Do not attempt to stop blade with
bare hands."
I did like the inventory of large Tcl apps -- not definitive, but the
best single such list I've seen.
Bob Binder
Benjamin Riefenstahl
rbi...@rbsc.com (Bob Binder) writes:
> However, Hansen said that he thought the relative ease of creating
> Tk widgets was a contributing factor for the developers of the
> system he studied.
Gotta read that slowly. He is saying that because Tcl is so good at
creating interfaces, they did get a bad UI. Or in other words, he
prefers bad tools, because they require more design.
Why didn't he say so in the first place? Probably because the next
conclusion (at least for me) would be that the project didn't have
enough design, which means bad project management. On the other hand,
if they need an external party for a review, bad project management
(or company politics or both) is probably the major part of the
problem anyway. And this seems all the more certain, if the external
party is opposed by the team.
Sic transit gloria mundi...
so long, benny
Kevin Kenny
> Gotta read that slowly. He is saying that because Tcl is so good at
> creating interfaces, they did get a bad UI. Or in other words, he
> prefers bad tools, because they require more design.
Amazing how many software-engineering people agree with him on that
point. The idea seems to be that if you make it harder to program,
then it will be so painful that people will spend more time on
design and introduce fewer bugs. The weird thing is that statistics
from several studies bear out the idea. Although the issue more
often seems to be that there are fewer bugs because there's less
functionality there to be buggy.
--
73 de ke9tv/2, Kevin
Bob Binder
> Hi Bob, all,
>
>
> rbi...@rbsc.com (Bob Binder) writes:
> > However, Hansen said that he thought the relative ease of creating
> > Tk widgets was a contributing factor for the developers of the
> > system he studied.
>
> Gotta read that slowly. He is saying that because Tcl is so good at
> creating interfaces, they did get a bad UI.
The complaint was that there were too many little widgets (perhaps
each its own command at the command line?) so that resulting app was
hard to use. Something like the sorcerer's apprentice scenario.
>Or in other words, he
> prefers bad tools, because they require more design.
I don't think he said that.
Bob
Fred Hansen
modicum of truth mixed with considerable misunderstanding of my point.
I certainly screwed up the meaning of "Tcl." I can only offer the pale
defense that I am so familiar with the name "Tcl" that I have long
since forgotten what it means.
As to whether I was attacking Tcl: Not so. Tcl is one of a class of
languages and systems which are our best hope for developing systems
in a timely manner and in close cooperation with the user. Tcl/Tk
makes simple things simpler than most other approachs.
The moral to my story is that
Large systems are not simple
and need more care.
They need care in architecture, configuration management, testing,
security considerations, and on and on, and -- dear to my heart --
user interface design.
This moral remains true, no matter what language or tool you are using
and no matter how you measure size.
Fred Hansen
PS. The conclusion of the report sums it up pretty well:
http://www.sei.cmu.edu/publications/
documents/03.reports/03tn001/03tn001.html#conclusion
Conclusion
The basic claim questioned in this note is that Tcl/Tk and an
architecture of classic Tcl/Tk windows is an appropriate path for the
future of SYS. Examination of the Web site lists offered as evidence
in support of this claim showed that those lists are, at best,
irrelevant. No projects similar to SYS appear. In fact, projects
similar to SYS generally use enterprise framework tools like J2EE and
.Net.
Two architectures pervade classic Tcl/Tk windows, a user interface
architecture and an application architecture. Both are limited to
small systems because of the increasing complexity that arises as
their paradigms are extended to bigger systems. There is no question
that the current SYS implementation is working and can continue to
work. It should probably be retained as a component of any future
development. However, the present architecture should not be permitted
to dictate the architecture of extensions.
Even if the present user and software architectures are abandoned,
Tcl/Tk could still be retained as the development environment.
AOLserver would be one model that could be followed. Adoption of this
model should not be made lightly or without considering the many
factors explored above.
David N. Welton
I thought it was a pretty good, and certainly honest assesment, from
your point of view. I do think that it's not hard to write Tcl GUI
code that's not terribly well designed because it's so easy, but that
is something that can be resolved via evolutionary refinement of the
codebase, and learning on the part of developers. Throwing the baby
out with the bathwater and going to a new environment is likely to
earn developers not intimately familiar with it a similar lesson in
its particular foibles and pitfalls.
Hrm... it would be nice to write an article/tutorial of my own on Tcl
style, as there *is* a lot of code out there, written by bright people
who I respect, that does go for quick and dirty by doing things like
mixing the gui with the logic behind it. Just need some 30 hour days
to get it done.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
Rohan Pall
news:871y1mg...@dedasys.com:
> can be resolved via evolutionary refinement of the
> codebase, and learning on the part of developers. Throwing
> the baby out with the bathwater and going to a new
> environment is likely to earn developers not intimately
> familiar with it a similar lesson in its particular foibles
> and pitfalls.
I second that. Everything has problems and learning them is
painful. This is one of the reasons I didn't go to php and
mysql, and instead adapted jcw's metakit locking code from the
wikit. I'm not in the mood to be a newbie again.
The locking code
http://rohanpall.com/projects/locktower/