Should I use Tcl/tk or Motif
Fan Jiao
I have been doing Motif since '90 and just finished one project using
Tcl/Tk.
First of all Tcl is an interp. lang so it runs slower than compiled
programs especially if you are using a RISC machine.
Secondly, Tk is not Object-Oriented - Motif is, although both are
implemented in C. For example in Motif, one can implement a customized dialog
by subclassing it from either XmFormDialog or XmPromptDlalog.
Moreover, Tk is built on top of X, not Xt - that prevent one to use any
good public domain Motif widgets in Tk. And one cannot use Tk widgets in
Motif either. Tk is not "Open Architecture".
With Motif 2.0, one would get much more functionalities, much more C++
support, and much more stable code - one won't look back for Tcl/Tk.
Enclosed please find some other interesting e-mail about Tcl.
Article: 288 of gnu.announce
Date: Fri, 23 Sep 94 19:14:52 -0400
From: r...@gnu.ai.mit.edu (Richard Stallman)
Message-ID: <940923231...@mole.gnu.ai.mit.edu>
To: g...@prep.ai.mit.edu
Subject: Why you should not use Tcl
Distribution: world
Approved: info...@prep.ai.mit.edu
Path: cronkite.cisco.com!ames!agate!library.ucla.edu!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!bloom-beacon.mit.edu!ai-lab!prep.ai.mit.edu!gnu
Newsgroups: gnu.announce,gnu.utils.bug,gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.windows.x.apps,comp.unix.misc
Followup-To: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme
Lines: 62
Xref: cronkite.cisco.com gnu.announce:288 gnu.utils.bug:5811 gnu.misc.discuss:10287 comp.lang.tcl:17180 comp.lang.scheme:4162 comp.windows.x.apps:6307 comp.unix.misc:9429
[Please redistribute wherever appropriate.]
Why you should not use Tcl
Richard Stallman, GNU Project
As interest builds in extensible application programs and tools, and
some programmers are tempted to use Tcl, we should not forget the
lessons learned from the first widely used extensible text
editor--Emacs.
The principal lesson of Emacs is that a language for extensions should
not be a mere "extension language". It should be a real programming
language, designed for writing and maintaining substantial programs.
Because people will want to do that!
Extensions are often large, complex programs in their own right, and
the people who write them deserve the same facilities that other
programmers rely on.
The first Emacs used a string-processing language, TECO, which was
inadequate. We made it serve, but it kept getting in our way. It
made maintenance harder, and it made extensions harder to write.
Later Emacs implementations have used more powerful languages because
implementors learned from the problems of the first one.
Another lesson from Emacs is that the way to make sure an extension
facility is really flexible is to use it to write a large portion of
the ordinary released system. If you try to do that with Tcl, you
will encounter its limitations.
Tcl was not designed to be a serious programming language. It was
designed to be a "scripting language", on the assumption that a
"scripting language" need not try to be a real programming language.
So Tcl doesn't have the capabilities of one. It lacks arrays; it
lacks structures from which you can make linked lists. It fakes
having numbers, which works, but has to be slow. Tcl is ok for
writing small programs, but when you push it beyond that, it becomes
insufficient.
Tcl has a peculiar syntax that appeals to hackers because of its
simplicity. But Tcl syntax seems strange to most users. If Tcl does
become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.
For these reasons, the GNU project is not going to use Tcl in GNU
software. Instead we want to provide two languages, similar in
semantics but with different syntaxes. One will be Lisp-like, and one
will have a more traditional algebraic syntax. Both will provide
useful data types such as structures and arrays. The former will
provide a simple syntax that hackers like; the latter will offer
non-hackers a syntax that they are more comfortable with.
Some people plan to use Tcl because they want to use Tk. Thankfully,
it is possible to use Tk without Tcl. A Scheme interpreter called STk
is already available. Please, if you want to use Tk, use it with STk,
not with Tcl. One place to get STk is from
ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
Article: 17183 of comp.lang.tcl
Path: cronkite.cisco.com!ames!lll-winken.llnl.gov!decwrl!svc.portal.com!shell.portal.com!hfinney
From: hfi...@shell.portal.com (Hal)
Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme
Subject: Re: Why you should not use Tcl
Date: 24 Sep 1994 16:07:22 GMT
Organization: Portal Communications (shell)
Lines: 52
Message-ID: <361irr$j...@news1.shell>
References: <940923231...@mole.gnu.ai.mit.edu>
NNTP-Posting-Host: jobe.shell.portal.com
Xref: cronkite.cisco.com gnu.misc.discuss:10290 comp.lang.tcl:17183 comp.lang.scheme:4164
r...@gnu.ai.mit.edu (Richard Stallman) writes:
> Why you should not use Tcl
> Richard Stallman, GNU Project
Stallman's article seems short on specific criticisms. I see:
1) Tcl was not designed to be a serious programming language.
2) Tcl lacks arrays.
3) Tcl lacks structures from which you can make linked lists.
4) Tcl is inherently slow.
5) End-users do not like Tcl syntax.
I would point out:
1) I can find no documentation that Tcl was not designed to be suitable
for serious programs. It is clearly based on LISP, which has been
widely used in the AI community among others for very serious programming.
2) Tcl has content addressable arrays, which are a superset of ordinary
arrays in functionality.
3) Tcl has no pointers, and shares this property with most LISP like
languages. Deeply nested list structures can be created, though, which
provide much of the functionality of linked lists.
4) It remains to be seen whether performance improvements are possible
to Tcl. There has been discussion on comp.lang.tcl on compilers. On-
the-fly compilation would combine interactivity with performance. Other
optimizations such as speedups for arrays whose index elements are
numbers should be possible.
5) I agree that LISP-like languages can be hard for amateurs to use.
It should be possible to make Tcl more usable by, for instance, creating
easier-to-use control structures. Stallman's idea for two compatible
languages with different syntax is perhaps worth looking at, but frankly
I suspect that programming is an inherently difficult process and it
will be hard to dumb it down much and still retain the needed power.
One other point - Stallman mentions TECO as a language with limitations
similar to those he sees in Tcl. I did considerable programming in
TECO back in the early days and IMO Tcl has practically nothing in
common with it. Tcl is far more similar to the LISP variant used in
present-day Emacs and again IMO is considerably more readable. The
shareware text editor Alpha for the Macintosh is Emacs-like, uses Tcl
in place of Emacs LISP, and the performance is fine.
Hal Finney
hfi...@shell.portal.com
Article: 18665 of comp.windows.x.motif
Path: cronkite.cisco.com!ames!hookup!swrinde!cs.utexas.edu!utnut!torn!fonorola!inforamp.net !inforamp.net!not-for-mail
From: kar...@inforamp.net (Kareem Arafat)
Newsgroups: comp.windows.x.motif,comp.windows.x
Subject: Re: X11/Motif vs. Tcl/Tk for commercial product?
Followup-To: comp.windows.x.motif,comp.windows.x
Date: 23 Aug 1994 11:08:24 -0400
Organization: InfoRamp inc., Toronto, Ontario (416) 363-9100
Lines: 41
Distribution: inet
Message-ID: <33d3d8$h...@inforamp.net>
References: <CuA6H...@amiserv.chi.il.us>
NNTP-Posting-Host: norm.inforamp.net
X-Newsreader: TIN [version 1.2 PL2]
Xref: cronkite.cisco.com comp.windows.x.motif:18665 comp.windows.x:26237
Doug Smith (do...@amiserv.xnet.com) wrote:
: Greetings!
:
: [ stuff deleted ]
:
: If any of you have opinions concerning this project, I would love to hear
: them. You may respond either by direct email to me or by posts to this
: newsgroup. Thanks for the help!
I've used both Tcl/Tk and Xt/Motif for a long time and modirately consider
myself to have very good knowledge of both. I do recomend to you to use Xt/Motif
for the following reasons:
- Tcl/Tk is an interpreted lanuage and requires yoiu to deliver the source
code along with the product since these scripts are read at run time.
- When you interface your C/C++ functions with Tcl/Tk your functions
will receive argc, argv type arguments so there is an overhead
of argument conversion, and no pointers! But that can be avoided if
you use libtcl.a but then again in this case why not use Xt/Motif.
- I think if you you right a truely object-oriented GUI using Xt/Motif
along with the consept of Command Classes. You will come out a winner!
If you have any more question please dont hesitate to e-mail me.
---------------------------------------------------------
Kareem M. Arafat, M.Eng.
Graphics Interface Group,
CAE Electronics Ltd.
Montreal, CANADA
-------------------------------------------------------
Article: 295 of gnu.announce
Date: Wed, 19 Oct 94 00:20:18 -0400
Original-From: r...@gnu.ai.mit.edu (Richard Stallman)
From: Tom Lord <lo...@gnu.ai.mit.edu>
Message-ID: <941019042...@mole.gnu.ai.mit.edu>
Distribution: world
Approved: info...@prep.ai.mit.edu
Path: cronkite.cisco.com!decwrl!elroy.jpl.nasa.gov!netline-fddi.jpl.nasa.gov!nntp-server.caltech.edu!pagesat.net!internet.spss.com!insosf1.infonet.net!solaris.cc.vt.edu!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!prep.ai.mit.edu!gnu
Newsgroups: gnu.announce,gnu.utils.bug,comp.os.linux.misc,comp.lang.tcl,comp.lang.scheme,comp.lang.misc
Followup-To: poster
Subject: GNU Extension Language Plans
Reply-To: Tom Lord <lo...@gnu.ai.mit.edu>
Lines: 258
Xref: cronkite.cisco.com gnu.announce:295 gnu.utils.bug:5948 comp.os.linux.misc:30223 comp.lang.tcl:18649 comp.lang.scheme:4798 comp.lang.misc:5520
GNU Extension Language Plans
Richard Stallman, GNU Project
[Please redistribute widely]
Many software packages need an extension language to make it easier
for users to add to and modify the package.
In a previous message I explained why Tcl is inadequate as an
extension language, and stated some design goals for the extension
language for the GNU system, but I did not choose a specific
alternative.
At the time, I had not come to a conclusion about what to do. I knew
what sort of place I wanted to go, but not precisely where or how to
get there.
Since then, I've learned a lot more about the topic. I've read about
scsh, Rush and Python, and talked with people working on using Scheme
as an extension and scripting language. Now I have formulated a
specific plan for providing extensibility in the GNU system.
Who chooses which language?
Ousterhour, the author of Tcl, responded to my previous message by
citing a "Law" that users choose the language they prefer, and
suggested that we each implement our favorite languages, then sit back
and watch as the users make them succeed or fail.
Unfortunately, extension languages are the one case where users
*cannot* choose the language they use. They have to use the language
supported by the application or tool they want to extend. For
example, if you wanted to extend PDP-10 Emacs, you had to use TECO.
If you want to extend GNU Emacs, you have to use Lisp.
When users simply want "to write a program to do X or Y," they can use
any language the system supports. There's no reason for system
designers to try to decide which language is best. We can instead
provide as many languages as possible, to give each user the widest
possible choice. In the GNU system, I would like to support every
language people want to use--provided someone will implement them.
With the methods generally used today, we cannot easily provide many
languages for extending any particular utility or application package.
Supporting an extension language means a lot of work for the developer
of the package. Supporting two languages is twice as much work,
supposing the two fit together at all. In practice, the developer has
to choose a language--and then all users of the package are stuck with
that one. For example, when I wrote GNU Emacs, I had to decide which
language to support. I had no way to let the users decide.
When a developer chooses Tcl, that has two consequences for the
users of the package:
* They can use Tcl if they wish. That's fine with me.
* They can't use any other language. That I consider a problem.
Sometimes developers choose a language because they like it. But not
always. Sun recently announced a campaign to "make Tcl the universal
scripting language." This is a campaign to convince all the
developers who *don't* prefer Tcl that they really have no choice.
The idea is that each one of us will believe that Sun will inevitably
convince everyone else to use Tcl, and each of us will feel compelled
to follow where we believe the rest are going.
That campaign is what led me to decide that I needed to speak to the
community about the issue. By announcing on the net that GNU software
packages won't use Tcl, I hope to show programmers that not everyone
is going to jump on the Tcl bandwagon--so they don't have to feel
compelled to do so. If developers choose to support Tcl, it should be
because they want to, not because Sun convinces them they have no
choice.
Design goals for GNU
When you write a program, or when you modify a GNU program, I think
you should be the one who decides what to implement. I can't tell you
what language to support, and I wouldn't want to try.
But I am the leader of one particular project, the GNU project. So I
make the decision about which packages to include in the GNU operating
system, and which design goals to aim for in developing the GNU
system.
These are the design goals I've decided on concerning extension
languages in the GNU system:
* As far as possible, all GNU packages should support the same
extension languages, so that a user can learn one language (any one of
those we support) and use it in any package--including Emacs.
* The languages we support should not be limited to special, weak
"scripting languages". They should be designed to be good for writing
large programs as well as small ones.
My judgement is that Tcl can't satisfy this goal. (Ousterhout seems
to agree that Tcl doesn't serve this goal. He thinks that doesn't
constitute a problem--I think it does.) That's why I've decided not
to use Tcl as the main system-wide extension language of the GNU
system.
* It is important to support a Lisp-like language, because they
provide certain special kinds of power, such as representing programs
as data in a structured way that can be decoded without parsing.
** It is desirable to support Scheme, because it is simple and clean.
** It is desirable to support Emacs Lisp, for compatibility with Emacs
and the code already written for Emacs.
* It is important to support a more usual programming language syntax
for users who find Lisp syntax too strange.
* It would be good to support Tcl as well, if that is easy to do.
The GNU extension language plan
Here is the plan for achieving the design goals stated above.
* Step 1. The base language should be modified Scheme, with these features:
** Case-sensitive symbol names.
** No distinction between #f and (), for the sake of supporting Lisp
as well as Scheme.
** Convenient fast exception handling, and catch and throw.
** Extra slots in a symbol, to better support
translating other Lisp dialects into Scheme.
** Multiple obarrays.
** Flexible string manipulation functions.
** Access to all or most of the Unix system calls.
** Convenient facilities for forking pipelines,
making redirections, and so on.
** Two interfaces for call-outs to C code.
One allows the C code to work on arbitrary Scheme data.
The other passes strings only, and is compatible with Tcl
C callouts provided the C function does not try to call
the Tcl interpreter.
** Cheap built-in dynamic variables (as well as Scheme's lexical variables).
** Support for forwarding a dynamic variable's value
into a C variable.
** A way for applications to define additional Scheme data types
for application-specific purposes.
** A place in a function to record an interactive argument reading spec.
** An optional reader feature to convert nil to #f and t to #t,
for the sake of supporting Lisp as well as Scheme.
** An interface to the library version of expect.
** Backtrace and debugging facilities.
All of these things are either straightforward or have already been
done in Scheme systems; the task is to put them together. We are
going to start with SCM, add some of these features to it, and write
the rest in Scheme, using existing implementations where possible.
* Step 2. Other languages should be implemented on top of Scheme.
** Rush is a cleaned-up version of the Tcl language, which runs far
faster than Tcl itself, by means of translation into Scheme. Some
kludgy but necessary Tcl constructs don't work in Rush, and Tcl
aficionadoes may be unhappy about this; but Rush provides cleaner ways
to get the same results, so users who write extensions should like it
better. Developers looking for an extension language are likely to
prefer Rush to Tcl if they are not already attached to Tcl.
Here are a couple of examples supplied by Adam Sah:
*** To pass an array argument without copying it, in Tcl you must use
upvar or make the array a global variable. In Rush, you can simply
declare the argument "pass by reference".
*** To extract values from a list and pass them as separate arguments
to a function, in Tcl you must construct a function call expression
using that list, and then evaluate it. This can cause trouble if the
other arguments contain text that includes any special Tcl syntax. In
Rush, the apply function handles this simply and reliably.
*** Rush eliminates the need for the "expr" command by allowing infix
mathematical expressions and statements. For example, the Tcl
computation `"set a [expr $b*$c]' can be written as `a = b*c' in
Rush. (The Tcl syntax works also.)
Some references:
[SBD94] Adam Sah, Jon Blow and Brian Dennis. "An Introduction to the Rush
Language." Proc. Tcl'94 Workshop. June, 1994.
ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-tcl94.*
[SB94] Adam Sah and Jon Blow. "A New Architecture for the Implementation of
Scripting Languages." Proc. USENIX Symp. on Very High Level Languages.
October, 1994. to appear.
ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-vhll94.*
** It appears that Emacs Lisp can be implemented efficiently by
translation into modified Scheme (the modifications are important).
** Python appears suitable for such an implementation, as far as I can
tell from a quick look. By "suitable" I mean that mostly the same
language could be implemented--minor changes in semantics would be ok.
(It would be useful for someone to check this carefully.)
** A C-like language syntax can certainly be implemented this way.
* Distribution conditions.
We will permit use of the modified Scheme interpreter in proprietary
programs, so as to compete effectively with alternative extensibility
packages.
Translators from other languages to modified Scheme will not be part
of any application; each individual user will decide when to use one
of these. Therefore, there is no special reason not to use the GPL as
the distribution terms for translators. So we will encourage
developers of translators to use the GPL as distribution terms.
Conclusion
Until today, users have not been able to choose which extension
language to use. They have always been compelled to use whichever
language is supposed by the tool they wish to extend. And that has
meant many different languages for different tools.
Adopting Tcl as the universal scripting language offers the
possibility of eliminating the incompatibility--users would be able to
extend everything with just one language. But they wouldn't be able
to choose which language. They would be compelled to use Tcl and
nothing else.
By making modified Scheme the universal extension language, we can
give users a choice of which language to write extensions in. We can
implement other languages, including modified Tcl (Rush), a Python
variant, and a C-like language, through translation into Scheme, so
that each user can choose the language to use. Even users who choose
modified Tcl will benefit from this decision--they will be happy with
the speedup they get from an implementation that translates into
Scheme.
Only Scheme, or something close to Scheme, can serve this purpose.
Tcl won't do the job. You can't implement Scheme or Python or Emacs
Lisp with reasonable performance on top of Tcl. But modified Scheme
can support them all, and many others.
The universal extension language should be modified Scheme.
Request for Volunteers
If you understand Scheme implementation well, and you want to
contribute a substantial amount of time to this project, please send
mail to Tom Lord, lo...@gnu.ai.mit.edu.
If you expect to have time later but don't have time now, please send
mail when you do have time to work. Participation in a small way is
probably not useful until after the package is released.
=================
Fan Jiao
Ron Natalie
: I don't think there are much comparisons between Motif and Tcl/Tk.
: I have been doing Motif since '90 and just finished one project using
: Tcl/Tk.
I've been doing Motif since version 1.0 and also have been doing much
work with Tk.
: First of all Tcl is an interp. lang so it runs slower than compiled
: programs especially if you are using a RISC machine.
Yes, but you have to ask yourself if the part you've coded in Tcl is
the critical part? Motif is *NOT* the most efficent code in the
world.
: Secondly, Tk is not Object-Oriented - Motif is,
Hails of derive laughter. Motif is only half-assed object oriented
as is anything that uses the Xt abomination. There are all kinds of
disgusting cross class hacks all over it.
: For example in Motif, one can implement a customized dialog
: by subclassing it from either XmFormDialog or XmPromptDlalog.
Yeah, but it's not exactly easy and again you have to ask yourself
if you are going to do that.
: Moreover, Tk is built on top of X, not Xt - that prevent one to use any
: good public domain Motif widgets in Tk. And one cannot use Tk widgets in
: Motif either. Tk is not "Open Architecture".
I'm not sure what you consider "Open Archtiecture" Xt is just as closed
or open as Tk is. They are just incomptible. There are much better
contributed widgets in for Tk than I've seen for Motif.
: With Motif 2.0, one would get much more functionalities, much more C++
: support, and much more stable code - one won't look back for Tcl/Tk.
Don't talk to me about MOTIF stability. I can't vouch for 2.0, but
I'll take Tk over 1.2 or earlier Motif's. At least when I find some
stupid bug in something like text widget margining, I can fix it in
my source code and not be encumbered from using the fixed code in my
distributed applicatons.
: Enclosed please find some other interesting e-mail about Tcl.
[RMS's paranoid not-invented-here ravings deleted.]
Sriram Srinivasan
In article <3gofh4$i...@cronkite.cisco.com>, fj...@fjiao-ss10.cisco.com (Fan Jiao) writes:
: I don't think there are much comparisons between Motif and Tcl/Tk.
:
I thought I should put in my 2c. worth on this, in support of Tcl/Tk
: First of all Tcl is an interp. lang so it runs slower than compiled
: programs especially if you are using a RISC machine.
:
This is debatable. TCL is interpreted, but all the UIs I have seen with
Tk seem to come up at least as fast as eqvt. Motif screens, if not faster.
Take a look at Ptolemy, or SimCity for Unix. These have fairly complex
UI requirements, but performance is not an issue (at least because of TCL).
TCL is used as a glue language to set up the different widgets, and the
idea always has been that the majority of the time is spent executing C code.
: Secondly, Tk is not Object-Oriented - Motif is, although both are
: implemented in C. For example in Motif, one can implement a customized dialog
: by subclassing it from either XmFormDialog or XmPromptDlalog.
Just because it has inheritance doen't mean much . The question is ,
what does it take to build a custom dialog? I do the same thing in Motif
that I do in Tk - use composition. If anything, I find it far more easy
to write a widget in Tk than to write a corresponding one in Motif. Strings
such as "inheritance", "object-oriented" don't mean much - simplicity of
usage and extensibility do.
Incidentally, there is an extremely nice object-oriented extension
available for TCL, called "incr TCL", which has become a standard of sorts
within the TCL community. There are a number of compound-widgets
available using this extension.
:
: Moreover, Tk is built on top of X, not Xt - that prevent one to use any
: good public domain Motif widgets in Tk. And one cannot use Tk widgets in
: Motif either. Tk is not "Open Architecture".
:
: With Motif 2.0, one would get much more functionalities, much more C++
: support, and much more stable code - one won't look back for Tcl/Tk.
:
: Enclosed please find some other interesting e-mail about Tcl.
:
["Interesting" stuff deleted]
- I'd like to know your definition of "Open". It is true that the two widget
sets don't co-exist, but the implication above is that Tk is not open,
but Motif is. How so ? Xaw and Motif are both Xt based widget sets, but
they don't coexist too well themselves.
Moreover, Tcl and Tk are free, and in my book, as open as Xaw is,
in this regard.
- Tk has tonnes of public domain widgets, including a pretty decent canvas
widget, and an excellent text widget.
- What does "much more functionalities" mean here ? The fact that the Motif
text widget gets to do compound strings ? Or that there is a combo-box ?
What does "much more C++ support" mean ? One can subclass from the
Primitive and Manager classes, but what does one do if one wants to
subclass from existing widgets ?
- Compare Tk4.0 with what Motif 2.0 provides. Motif is still catching up.
From the list of interesting material that you provide, your complaint seems
to be with TCL primarily. You should compare Tk development with Motif
development. Performance should not be an issue, if you consider that
TCL is intended to be a glue language - one is not expected to write entire
applications in TCL. Even if one does so, there are enuf respectable
applications that are written completely in TCL/Tk that have good
performance. Compare xman and TkMan. Lemme know what it would take to
write TkMan's functionality using Motif.
I do apologize if the above stuff sounds harsh - the fault lies is in the
choice of words, not in how I feel or intend. I would be interested in
hearing more arguments about Motif vs. Tcl/Tk.
Thanx.
Sriram
(sri...@tcs.com)
Michael Hoegeman
You can say that again. Motif pales in comparison ;-)
|> I have been doing Motif since '90 and just finished one project using
|> Tcl/Tk.
|>
|> First of all Tcl is an interp. lang so it runs slower than compiled
|> programs especially if you are using a RISC machine.
Tcl runs slower than C but for the type of stuff you use Tk for
(namely creating and manipulating X widgets) I don't think you can
demonstrate to me or the anyone else an appreciable run-time difference.
This is open for endless debate but just keep in mind that Motif isn't
exactly lean and mean speed-wise either. Do you really think that
Plowing through endless X Resource database records isn't all that far
removed from "Interpretation"?
|> Secondly, Tk is not Object-Oriented - Motif is, although both are
|> implemented in C.
Calling Motif "Object-Oriented" is being very liberal minded of you I
think. The Xt widget system was the first toolkit created
for X and it's really showing it's age. Xt is dead. Not only is dead,
it's starting to smell real bad too.
I grant you that there are some very primive object oriented concept's
in the Motif toolkit. However, when you actually get around to trying
to use them in practice, they are a complete headache.
I have written C based widgets in both Tk and Motif and from my
personal experience I think it's easier to write them with the Tk
toolkit. I'm willing to account for personal tastes and say it's
equally hard to write widgets in both of them though. The Real
difference in my mind is that it's rare that you actually have to write
a Tk widget in C. And when you do have to write one it automatically
works in harmony with all the other Tk widgets. If a write a graphing
widget i can use it in canvas widget or inside a text widget or I can
place it in a dialog etc.. etc..
|> For example in Motif, one can implement a customized
|> dialog by subclassing it from either XmFormDialog or XmPromptDlalog.
The question that counts regarding things like customs dialogs is
"How easy is it to make my own flavor of form Dialog or Prompt Dialog"
And the answer is that in Motif it's pretty darn hard whereas in Tk
it's pretty easy. It takes you lots of C-code to "subclass" a dialog
and endless tinkering to get it right. To be honest with you, I fail to
see how it is a superior solution to composing a 50 line Tcl/TK
script.
Unfortunately, you have seem to missed entirely the "Tk way of doing
things" The way the Tk allows you to create your own dialogs and such
is through *composition*. All the Tk Widget's are designed to be
composed in any arbitrary combination with one another. The scrollbar
is designed to be composed seamlessly in conjunction with a graphics
canvas, or a entry widget or a text widget or any other widget you care
to use it with.
|>
|> Moreover, Tk is built on top of X, not Xt - that prevent one to use any
|> good public domain Motif widgets in Tk. And one cannot use Tk widgets in
I have seen very little available in the way of good public domain
widgets written for Motif. There are some commercial ones that seem
useful but even there I would not say the cup runneth over with such
offerings.
|> Motif either. Tk is not "Open Architecture".
|>
You have a very strange notion of "Open architecture". The Tcl/Tk
source is freely available. The Developers of Tcl/Tk Have a very open
dialog with users right here on comp.lang.tcl and at the yearly tcl
conferences. When I encounter bugs in Tk/Tcl and I send in patches to
fix them they show up (usually in the next release) It'll be a cold day
in Hell when I ever get that out of the Motif boys. Given all this,
maybe you can enlighten me on how Motif is more "Open" than Tk.
|>
|> With Motif 2.0, one would get much more functionalities, much more C++
|> support, and much more stable code - one won't look back for Tcl/Tk.
|>
Your vacuous assertions seem to to know no bounds. Simply stating that
Motif has "much more functionalities" and "much more C++" support
does not magically make it so. If you're going to make such claims, at
least a feeble attempt at justifying them would be in order I think.
--
------------------------------------------------------------------------------
Mike Hoegeman email: m...@wx.gtegsc.com tel: (818)706-4145
GTE Weather Systems Group 31717 La Tienda Dr, Westlake Village CA. 91359
Peter.DeRijk
: I don't think there are much comparisons between Motif and Tcl/Tk.
:
: I have been doing Motif since '90 and just finished one project using
: Tcl/Tk.
:
: First of all Tcl is an interp. lang so it runs slower than compiled
: programs especially if you are using a RISC machine.
If you use the right level (C or Tcl) for the appropriate tasks, this is not
a problem. I have made a fairly large program using Tcl/Tk and extensions
(about 40,000 lines of C and 10,000 lines of Tcl), and it is NOT slow.
:
: Secondly, Tk is not Object-Oriented - Motif is, although both are
: implemented in C. For example in Motif, one can implement a customized dialog
: by subclassing it from either XmFormDialog or XmPromptDlalog.
incr Tcl (Maybe it should move into the core, but dynamic loading does come
first)
:
: Moreover, Tk is built on top of X, not Xt - that prevent one to use any
: good public domain Motif widgets in Tk. And one cannot use Tk widgets in
: Motif either. Tk is not "Open Architecture".
There are also lots of good PD widgets for Tk. The base widgets of Tk are
very good. And as for open architecture: Tk is COMPLETELY FREE. You get
sources and can do anything you like with them. I find this more interesting
than having to licence some 'open architecture', especially when developing
freeware programs.
:
: With Motif 2.0, one would get much more functionalities, much more C++
: support, and much more stable code - one won't look back for Tcl/Tk.
Tcl/Tk also has some functionalities over other environments:
- the posibilty to make a clean seperation between program and interface,
while the interface can have a degree of inteligence.
- rapid prototyping / Run-time changing of the interface
- extreme user customisability.
- easy glueing in of foreign programs, even interactive ones (expect).
- the possibility to send commands or small parts of programs over networks,
and execute them on the other machine (whatever processor, or
architecture that may have, as long as it runs Tcl).
- simple and short code
:
: Enclosed please find some other interesting e-mail about Tcl.
:
: [lots of stuf we have unfortunately already have been
: priviliged to see before]
:
We have seen these mails here before, and they started a lengthy flame
war. Suffice to say: When something actually comes out of it, ie. there
is a useable, ready to install alternative GNU language, then come back
and tell us, we will then maybe try it, and judge it. Please do not paste
out the virtues of vapourware over an existing, nice and working system.
By the way, after that flame war, I have taken a (short) look at scheme.
It might be a nice language, but it does not look nice (IMHO). I first
tried reading the intro about Scheme on some of the Web pages about it,
and I didn't understand a word of it. (I consider myself reasonably computer
literate, so I wouldn't want to put the users of my programs, which are
very often computer illiterate through that.) I also looked at some code,
and, honestly, all those braces give me a splitting headache. Maybe I should
dig deeper into the language to find the pearls hidden in it, but fact is,
that Tcl looks a lot more natural (at least to me). You can easily learn
it by looking at code. This is probably also the main reason of the
the problems mentioned that some beginners have with Tcl (mainly quoting);
This requires to read a few pages and to know a few simple rules, which
is often not done because Tcl is so easy to learn.
Peter
----
Peter De Rijk der...@reks.uia.ac.be
<a href="http://indigo2.uia.ac.be/~peter/personal/peter.html">Peter</a>
To achieve the impossible, one must think the absurd.
to look where everyone else has looked, but to see what no one else has seen.
Koert Zeilstra
[tons of stuff deleted]
: With Motif 2.0, one would get much more functionalities, much more C++
: support, and much more stable code - one won't look back for Tcl/Tk.
: =================
: Fan Jiao
Maybe I'm a lousy programmer, but when I was doing Motif, I usually went
from core dump to core dump, bombing deep inside Motif internals. With
Tcl/Tk I rarely have core dumps, maybe a few times a week, where Motif
was dumping several times a day. Not to mention long hours waiting for
the compiler to finish.
Oh well, just another flame war. Flame on Garth!
And why quoting the entire flame war Tcl vs. Scheme ?
--
Koert Zeilstra (kz...@comsearch.com)
MIME mail welcome
"Friends don't let friends use DOS"
Richard Hipp
>>>>> "Fan" == Fan Jiao <fj...@fjiao-ss10.cisco.com> writes:
Fan> First of all Tcl is an interp. lang so it runs slower than compiled
Fan> programs especially if you are using a RISC machine.
In my experience, The GUI parts of a Tcl/Tk program tend to run FASTER
than Motif. This is especially true when the X client and X server are
connected by a slow wire (i.e. a 14400bps modem). I don't know why
Tcl/Tk is faster, I've just observed this to be the case.
On the other hand, Tcl/Tk is painfully slow at doing computation. But
that really isn't a problem. Do you computation in C and the GUI in
Tcl/Tk and you get a really fast program.
Ralf B. Lukner
people are using Tcl/Tk instead of commercial apps due to
financial/license reasons or because they really like Tcl/Tk over all
other Motif GUI tools.
--Ralf
Ralf B. Lukner
> In my experience, The GUI parts of a Tcl/Tk program tend to run FASTER
> than Motif. This is especially true when the X client and X server are
> connected by a slow wire (i.e. a 14400bps modem). I don't know why
Although I haven't used Tcl/Tk apps over a modem line, I have (tried to)
use Motif apps over modem lines (14400bps vbis32). Motif apps were all
but unusable over modem lines, whereas many X apps (even graphical) were
actually quite acceptable in speed. I guess Motif must be doing something
to occupy significant serial bandwidth compared to many X apps (and I
guess Tck/Tk doesn't share Motif's problem in this respect).
--Ralf
Jagadeesh Krishnamurthy Venugopal
Fan> I don't think there are much comparisons between Motif and Tcl/Tk. I
Fan> have been doing Motif since '90 and just finished one project using
Fan> Tcl/Tk.
Fan> First of all Tcl is an interp. lang so it runs slower than compiled
Fan> programs especially if you are using a RISC machine.
Fan> Secondly, Tk is not Object-Oriented - Motif is, although both are
Fan> implemented in C. For example in Motif, one can implement a customized
Fan> dialog by subclassing it from either XmFormDialog or XmPromptDlalog.
Friend,
I find motif excessively complicated and very cumbersome.
Motif is not a paragon of virtue when it comes to efficiency.
I do not want to put in all that effort to learn motif.
I do not have the money or the inclination to pay for motif.
The good professor Ousterhout's contribution is free.
As for OO, try [incr tcl]. it is highly regarded in these parts.
it is extremely easy to use. Brings back the joy to programming.
I get fast prototyping. I write gui's in fractions of an hour now.
If it meets my speed criteria I am happy. If it doesn't I can easily recode
the offending part in C while still retaining the rest of the tcl code.
I run the same program on all variations of Unix with hardly a recompile.
A lot of people on this newsgroup are willing to help if I have trouble with
tcl.
I like the FSF's work. But one thing it is great at doing is announcing
vaporware.If indeed it produces a better tk without tcl then we all will use
it. We will most certainly consider the language as and when it becomes
available. At that point the forces of the free market will decide which is
better.
Until then we will stick with tcl. it is simple, and it gets the job done
easily without fuss.
Jagadeesh
by the way, I suggest a look at Brent Welch's book to all netters. I just saw
the first few chapters of the Jan draft and it is definitely worth a read.
Pick it up from parcftp.xerox.com:/pub/sprite/welch
--
Jagadeesh K. Venugopal | The more you study,
Grad Student, CCS | the more you realize,
Northeastern University | that there is a lot in your field
Boston, MA 02115 | you don't know a thing about.
Mikpf
The above question is the one I asked 6 months ago. My
answers were in principle Tcl/Tk is good enough, usually more
efficient, better to learn, enjoyable... etc. The conclusion was
Tk seems to be the way to go unless you are really tied in
developing shoftware which needs to be used
by peoople who prefer Motif.
I have seen a commercial software (Biological, molecular) by
one of the biggest company in the field, coded in Tk (surprised to
see how fast the implementation has been and this means it
was really easy to code with it. I felt Tk has a good future.
Also, Perl has an extension called TkPerl which becomes
popular in Perl users.
Jong
Tcl/Tk).
--
_________________________________________________
jo...@mrc-lmb.cam.ac.uk Tim Hubbard's student
_________________________________________________
Warner Losh
>: Moreover, Tk is built on top of X, not Xt - that prevent one to use any
>: good public domain Motif widgets in Tk. And one cannot use Tk widgets in
>: Motif either. Tk is not "Open Architecture".
>
>I'm not sure what you consider "Open Archtiecture" Xt is just as closed
>or open as Tk is. They are just incomptible. There are much better
>contributed widgets in for Tk than I've seen for Motif.
It should be possible for Tk to wrap Motif and/or Xt based widget sets
so that one might incorporate them into a Tk program. I know this is
possible because OI (Object Interface from Openware (formerly
Solbourne and Parcplace)) does exactly this, and it is built on top of
Xlib, not Xt. I've not looked deeply at the Tk stuff, so there may be
some deep, dark assumptions that permeate the code that might preclude
this sort of thing, so caveat emptor.
In theory, it should be possible to have Tk widgets inside a Xt
program. All that needs to happen is to ensure that Tk gets its
events at the right time, and that TCL code can execute properly.
It is all a small matter of programming :-).
Warner
P.S. For a truly OO Motif GUI written in a truly OO language (C++),
you might want to give OI/OB a try. sa...@boulder.openware.com for
more info.
--
Warner Losh i...@boulder.openware.com Openware Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
more serious personality disorders"
Gerald W. Lester
We use Tc;/Tk becuase we perfer it, not because of license issues. We
evaluated several Motif GUI tools (in fact the product we are based on comes
with one) but decided on Tcl/Tk. Factures that decided us was:
1) Ease of use
2) Speed of developement/change
3) Speed of applications (Tcl/Tk apps were in many cases *faster*)
4) Support (comp.lang.tcl and sources)
==========================================================================
* Gerald W. Lester ! Voice: (504)-889-2784 *
* Computerized Processes Unlimited ! FAX: (504)-889-2799 *
* 4200 S. I-10 Service Road, Suite #205 ! E-Mail: g...@cpu.com *
* Metairie, LA 70001 ! Hours: 09:00-17:00 CDT *
==========================================================================
Don Clayton
In article <3gogvi$9...@topaz.sensor.com>, r...@topaz.sensor.com (Ron Natalie) writes:
|> Don't talk to me about MOTIF stability. I can't vouch for 2.0, but
|> I'll take Tk over 1.2 or earlier Motif's. At least when I find some
|> stupid bug in something like text widget margining, I can fix it in
|> my source code and not be encumbered from using the fixed code in my
|> distributed applicatons.
You mean like the Tk bug with sticking menus, or the disappearing cursor or
how about it's inability to load when the Window Manager changes the colour
map. Motif has bugs (all programs do) but no where near as bad as Tk, and
I've never found a case where Motif totally fails to run.
I don't want to code the toolset I've chosen to develope in (a must if you
use Tk). I've never had to with Motif.
Don (a.k.a. Maverick)
dcla...@bnr.ca
If you're not living on the edge then you're taking up too much space.
Don Clayton
In article <1995Feb6.1...@cpu.com>, gwle...@CAPTAINHOOK.CPU.COM (Gerald W. Lester) writes:
|>
|> We use Tc;/Tk becuase we perfer it, not because of license issues. We
|> evaluated several Motif GUI tools (in fact the product we are based on comes
|> with one) but decided on Tcl/Tk. Factures that decided us was:
|>
|> 1) Ease of use
|> 2) Speed of developement/change
|> 3) Speed of applications (Tcl/Tk apps were in many cases *faster*)
|> 4) Support (comp.lang.tcl and sources)
We use C++/Motif because :
1) Speed of development/change (Tk lack of compiler makes it hell, as do
those damn bindings, which have to be rewritten evertime a window is
changed).
2) Speed of application (way faster than Tcl/Tk)
3) Support (Motif 1.1.x+ is stable, we don't code the library, well documented,
we don't have to recode it every release because some jerk changes the function
name or parameters).
4) Compatiblity with window managers.
5) Interactions with other programs.
6) Structured programming!
I'll give you ease of use, but only if you don't use a GUI builder for Motif,
in that case Motif is way easier to use.
As far as I'm concerned programmers that like Tcl/Tk usually lack formal Computer
Science training and instead prefer to use unstructured programming techniques
(such as no type checking and use of globals that Tcl/Tk promotes).
Koert Zeilstra
: Maybe I'm a lousy programmer, but when I was doing Motif, I usually went
: from core dump to core dump, bombing deep inside Motif internals. With
: Tcl/Tk I rarely have core dumps, maybe a few times a week, where Motif
: was dumping several times a day. Not to mention long hours waiting for
: the compiler to finish.
To clarify my rants (I was getting concerned email from Tcl/Tk wizards):
I use my own extensions to Tcl, written in C, which cause these crashes,
I have seen any crash related to the excellent code of Tcl itself. And
I can't say the same about Motif, many, many bugs in the commercial
distribution of Motif. Every Motif programmer probably knows this.
Even the guys at OSF are afraid of the Form Widget!
Koert
Ron Natalie
: I don't want to code the toolset I've chosen to develope in (a must if you
: use Tk). I've never had to with Motif.
Lets see, do you have to field complaints from users to figure out why
when they push the middle mouse button a little running man comes up
and locks up their session? Do you use text widgets with auto sizing
where the text is set before the widget is managed? I'm sorry, but
I have had to go in to the MOTIF source and find workarounds to disgusting
bugs, not fixes mind you, workarounds because even if I could fix the
code, I can't put that fix in the Motif that is compiled into my application
without paying extortion to OSF.
-Ron
F. Sullivan Segal
>
>With Motif 2.0, one would get much more functionalities, much more C++
>support, and much more stable code - one won't look back for Tcl/Tk.
>
>Enclosed please find some other interesting e-mail about Tcl.
>
If you are going to use Richard Stallman as a reference to the ills
of Tcl, it seems relevant to mention that RMS has also denounced
Motif (since it won't be able to run on top of GNU-Herd.)
--
-F. Sullivan Segal
_______________________________________________________________
_
/V\ E-Credibility: (n -- ME) The unguaranteed likelyhood that
' the electronic mail you are reading is genuine rather than
someone's made up crap.
_______________________________________________________________
GCS d-- p--(---) @c++ u e-(*) m+(-) s/+ @n++ h--- f+ g+(--)
w+(+++) t++(-)@ b5++ yij++ r(dm)+ y+(*)
Mail to: flet...@netcom.com
schm...@maroon.tc.umn.edu
Ralf B. Lukner <luk...@che.utexas.edu> wrote:
>I agree with the posts that compare Tcl/Tk with raw Motif, but I wonder if
>people are using Tcl/Tk instead of commercial apps due to
>financial/license reasons or because they really like Tcl/Tk over all
>other Motif GUI tools.
Well, when I was with IBM, the "management-approved" method was Motif.
This was because Motif was "officially supported" via our AIX license and
therefore any bugs, etc., could filter through the official channels. Hence,
most of the projects that I worked on used Motif.
HOWEVER, when it came to doing anything for my own use, I used Tcl and Tk.
Why? Because it was so much simpler than hacking up something quick and
dirty using Motif. Of course, now that I can release things to the net,
I plan on doing any projects using Tcl and Tk. This may in fact lessen
use of anything I release because Motif has been more or less standardized
on, and so should be generally available on most platforms. On the other
hand, my home box is Linux and I haven't (yet) the disk space for Motif.
Plus, I just plain like Tcl and Tk more than I like Motif :).
That's my rationale, anyways.
: jay
(Hi, Scott -- what, no email? :)
Rick D. Hebert
*> As far as I'm concerned programmers that like Tcl/Tk usually lack
*> formal Computer Science training and instead prefer to use unstructured
*> programming techniques (such as no type checking and use of globals
*> that Tcl/Tk promotes).
Boy, what a snotty attitude. There are plenty of us out here in
net-land that don't have formal CS training but still need to write code.
Also, we don't all have access to Motif GUI builders. For those of us
that aren't super-high-quality-o-o-programmers like yourself with
lots of development support, we will continue to use Tcl/Tk until
something better comes along.
Gerald W. Lester
>
>In article <1995Feb6.1...@cpu.com>, gwle...@CAPTAINHOOK.CPU.COM (Gerald W. Lester) writes:
>|>
>|> We use Tc;/Tk becuase we perfer it, not because of license issues. We
>|> evaluated several Motif GUI tools (in fact the product we are based on comes
>|> with one) but decided on Tcl/Tk. Factures that decided us was:
>|>
>|> 1) Ease of use
>|> 2) Speed of developement/change
>|> 3) Speed of applications (Tcl/Tk apps were in many cases *faster*)
>|> 4) Support (comp.lang.tcl and sources)
>
>We use C++/Motif because :
>
> 1) Speed of development/change (Tk lack of compiler makes it hell, as do
> those damn bindings, which have to be rewritten evertime a window is
> changed).
Not having to go through a compile cycle makes this phase much faster
in Tk. Particularly since I can debug/fix the code while it is actually
running.
> 2) Speed of application (way faster than Tcl/Tk)
Funny, our Tcl/Tk applications seem to generally run faster. Of course
I guess if you are pulling your Tcl/Tk files off of a NFS mounted disk that
does not give good performance and you're Motif programs are local with the
sticky bit on, then the Motif code *might be faster.
> 3) Support (Motif 1.1.x+ is stable, we don't code the library, well documented,
> we don't have to recode it every release because some jerk changes the function
> name or parameters).
Right, of course my machines seem to have Motif 1.2 on them with 2.0
coming down the road. I guess if you stayed at the same version of Tk you
would not have to recode anything either. Than again, considering the develop
ment effort in Motif, I'd stay frozen at a particular version too.
> 4) Compatiblity with window managers.
Both are as the same here.
> 5) Interactions with other programs.
This is not consistant accross Motif applications from HP and DEC.
Among one vendor things seem to *ussally* work. Then again I can cut/paste
find from my DecTerm or Xterm to my Tk entry widgets.
> 6) Structured programming!
You mean structed language. Structured programming is something that
can be done in almost any language. It is a discipline not an attribute of a
language.
>
>I'll give you ease of use, but only if you don't use a GUI builder for Motif,
>in that case Motif is way easier to use.
We've tried several. Whenever you have to resort to C for callbacks
you lose whatever you gain from a GUI builder. Also it is very straight
forward to write a program to generate Tcl/Tk from UIL.
>As far as I'm concerned programmers that like Tcl/Tk usually lack formal Computer
>Science training and instead prefer to use unstructured programming techniques
>(such as no type checking and use of globals that Tcl/Tk promotes).
Wrong oh, at least here!
I have both a B.S. and M.S. in CSCI. My first language was Pascal
learned form copies of the galley proofs of the revised standard (with N.W.'s
handwritten corrections) on the compiler his graduate compiler class built
(BTW, before I fixed a bug in it,it had 3 GOTOs, after it only had 1). Tcl
is not strongly typed, other than that it is a *MORE* structured language than
C/C++ since it does not contain a GOTO statement. Since you seem to have some
confusion about what is Structured Programming and what makes a language
structured, I suggest that you read several of Wirth's and DeMarco's papers
about structured langauages and structured programming respectively.
Don Clayton
In article <1995Feb7.1...@cpu.com>, gwle...@CAPTAINHOOK.CPU.COM (Gerald W. Lester) writes:
|> In article <3h63gd$7...@bcarh8ab.bnr.ca>, dcla...@bnr.ca (Don Clayton) writes:
|> >We use C++/Motif because :
|> >
|> > 1) Speed of development/change (Tk lack of compiler makes it hell, as do
|> > those damn bindings, which have to be rewritten evertime a window is
|> > changed).
|>
|> Not having to go through a compile cycle makes this phase much faster
|> in Tk. Particularly since I can debug/fix the code while it is actually
|> running.
My HP 700 compiles 70,000 of C++/Motif in under 1.5 minutes - well worth the
time for syntax/type checking.
|> > 2) Speed of application (way faster than Tcl/Tk)
|>
|> Funny, our Tcl/Tk applications seem to generally run faster. Of course
|> I guess if you are pulling your Tcl/Tk files off of a NFS mounted disk that
|> does not give good performance and you're Motif programs are local with the
|> sticky bit on, then the Motif code *might be faster.
Perhaps Tcl/Tk on HP is something different than what you have, but our compiled
Motif applications load/run way faster than the Tcl/Tk ones, and they're on the
same NFS mounts.
|> > 3) Support (Motif 1.1.x+ is stable, we don't code the library, well documented,
|> > we don't have to recode it every release because some jerk changes the function
|> > name or parameters).
|>
|> Right, of course my machines seem to have Motif 1.2 on them with 2.0
|> coming down the road. I guess if you stayed at the same version of Tk you
|> would not have to recode anything either. Than again, considering the develop
|> ment effort in Motif, I'd stay frozen at a particular version too.
We upgraded from Motif 1.1.1 to 1.2.4 and changed 4 lines of code out of 75,000.
It took about an hour. We upgrade from Tcl/Tk (can't remember which versions) and
it took months (matter in fact it is not done yet because we had to modify the
shell to support our own widgets and the upgrade is gross!).
Of course we use Motif++ to protect us from Motif changes.
|> > 4) Compatiblity with window managers.
|>
|> Both are as the same here.
Tcl/Tk is grossly incompatible with HP-VUE and mwm. Try swapping your colour map
using VUE's colour pallet and then loading a Tk program - they won't even start.
Ditto for fonts.
|> > 5) Interactions with other programs.
|>
|> This is not consistant accross Motif applications from HP and DEC.
|> Among one vendor things seem to *ussally* work. Then again I can cut/paste
|> find from my DecTerm or Xterm to my Tk entry widgets.
Sure, some work, some don't. Why? Because Tk is not based on Xt and doesn't
quite use the same rules - a real pain (ps. try FrameBuilder).
|> > 6) Structured programming!
|>
|> You mean structed language. Structured programming is something that
|> can be done in almost any language. It is a discipline not an attribute of a
|> language.
Fine. Some languages promote structure programming and some don't. Tcl doesn't
(better?).
|> >
|> >I'll give you ease of use, but only if you don't use a GUI builder for Motif,
|> >in that case Motif is way easier to use.
|>
|> We've tried several. Whenever you have to resort to C for callbacks
|> you lose whatever you gain from a GUI builder. Also it is very straight
|> forward to write a program to generate Tcl/Tk from UIL.
Try X-Designer 3.0.
|> >As far as I'm concerned programmers that like Tcl/Tk usually lack formal Computer
|> >Science training and instead prefer to use unstructured programming techniques
|> >(such as no type checking and use of globals that Tcl/Tk promotes).
|>
|> Wrong oh, at least here!
|>
|> I have both a B.S. and M.S. in CSCI. My first language was Pascal
|> learned form copies of the galley proofs of the revised standard (with N.W.'s
|> handwritten corrections) on the compiler his graduate compiler class built
|> (BTW, before I fixed a bug in it,it had 3 GOTOs, after it only had 1). Tcl
|> is not strongly typed, other than that it is a *MORE* structured language than
|> C/C++ since it does not contain a GOTO statement. Since you seem to have some
|> confusion about what is Structured Programming and what makes a language
|> structured, I suggest that you read several of Wirth's and DeMarco's papers
|> about structured langauages and structured programming respectively.
The use of a goto was an automatic fail at my school (unless you could
really really justify it).
As I said above Tcl/Tk does not promote the use of structure programming
techniques. Sure you can produce good structured code in assembler if you
try hard enough. It's a lot easier if the language helps you, and Tcl/Tk
do not in any way. A problem that becomes significant if the person
programming lacks the training in the first place (like the 100s of
electrical engineers around here); how do they know if they're doing
it wrong?
Hume C.L. Smith
RDH> Don Clayton (dcla...@bnr.ca) wrote:
RDH> *> As far as I'm concerned programmers that like Tcl/Tk usually lack
RDH> *> formal Computer Science training and instead prefer to use unstructured
RDH> *> programming techniques (such as no type checking and use of globals
RDH> *> that Tcl/Tk promotes).
RDH> Boy, what a snotty attitude.
well, those making lifestyle critiques in their sigs generally have such
attitudes. i'm hoping he'll fall off his edge and make more room for
the rest of us.
RDH> There are plenty of us out here in
RDH> net-land that don't have formal CS training but still need to write code.
there's also those with some formal CS, who'd like an OO Tcl (and want to
try [incr tcl], and see how strong it is a few formal senses), but who also
like to be able to READ the code they have to deal with, and thus like
being able to avoid C++ The Syntax Monster.
RDH> Also, we don't all have access to Motif GUI builders. For those of us
RDH> that aren't super-high-quality-o-o-programmers like yourself with
RDH> lots of development support, we will continue to use Tcl/Tk until
RDH> something better comes along.
--
Hume Smith (613)SOFINER 9-5 EST hcls...@ra.isisnet.com
(Sometimes I quote evocatives rather than intrinsics. Big Deal.)
"Oh Buster, we have a small problem." "What, no towels? B&B Go Hawaiian
Peter da Silva
you're writing. Tcl/Tk excels at system configuration support, installation,
program support, all the stuff we used to have shell script front ends are
now Tcl/Tk. We have some applications in Tcl/Tk, too. We use Motif for
marketing reasons, because it has i18n support, and less because of other
issues.
If you're trying to write *every* component of a complex system in the same
tool I have to wonder if you're suffering from baby duck syndrome.
In article <3h63gd$7...@bcarh8ab.bnr.ca>, Don Clayton <dcla...@bnr.ca> wrote:
> I'll give you ease of use, but only if you don't use a GUI builder for Motif,
> in that case Motif is way easier to use.
I haven't found a GUI builder that's sufficiently flexible except for really
trivial stuff... and for that it's easier to just write a script in Tk.
> As far as I'm concerned programmers that like Tcl/Tk usually lack formal Computer
> Science training and instead prefer to use unstructured programming techniques
> (such as no type checking and use of globals that Tcl/Tk promotes).
As far as I'm concerned people who make ad-hominem attacks are... no, I won't
descend to your level.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast du heute schon deinen wolf umarmt?"
Susan J. Larson
|> *> formal Computer Science training and instead prefer to use unstructured
|> *> programming techniques (such as no type checking and use of globals
|> *> that Tcl/Tk promotes).
|>
|>
Not only that, but quite a credulous statement, I'd say. There are
plenty of programmers *with* formal computer science training who believe
that Tcl and Tk are great tools, especially when used as intended.
Tony Schleizer
> We use Tc;/Tk becuase we perfer it, not because of license issues. We
Have you perhaps compared it with recent versions of Openware's
ObjectBuilder, ILOG Views, Visix Galaxy (using G/Script perhaps),
Hewlett-Packard UIM/X, Thomson Software's TeleUSE, or Centerline
ViewCenter?
--Ralf
Tom Tromey
Don> We use C++/Motif because :
Don> 1) Speed of development/change (Tk lack of compiler makes it hell, as do
Don> those damn bindings, which have to be rewritten evertime a window is
Don> changed).
This is really strange, because it is exactly opposite to my
experience when programming C and C++ based toolkits (XView, Xt, OI).
I've generally found I can write a simple applicationg in Tcl much
faster than I can in C. And in larger applications I've found that I
can change the interface much more quickly using Tcl. In many
instances I can change the interface while the application is running.
My experience has been that making a good GUI requires much
back-and-forth work; trying out an interface on the users, and
changing it in response to suggestions. This process proceeds much
more quickly when you can literally change it in seconds.
Don> 2) Speed of application (way faster than Tcl/Tk)
I guess it depends on how you structure your application. If you are
doing computation in Tcl, then you just deserve to die.
Don> 3) Support (Motif 1.1.x+ is stable, we don't code the library,
Don> well documented, we don't have to recode it every release
Don> because some jerk changes the function name or parameters).
Its true that Tk's interface instability has been a problem lately.
Hopefully that is stopping. Were earlier releases of Motif any
better? (I'm asking; I really don't know).
I'm not sure that characterizing Ousterhout as a jerk is really
appropriate.
Don> 4) Compatiblity with window managers.
Never had a problem here.
Don> 5) Interactions with other programs.
Perhaps you can give an example of what you mean?
Don> 6) Structured programming!
I think that claming that using Motif results in structured
programming is stretching it pretty far. I've generally found that
bad programmers write bad code in any language, and that good
programmers write good code in any language.
For instance in some Tcl/Tk applications (even without itcl), you will
see all the windows witten as composite widgets. This is actually
pretty easy to do, and meshes well with the Tcl programmer's
expectations. (Aside: I certainly never did this when writing Xt
code; composites were just too much of a pain to write).
Don> I'll give you ease of use, but only if you don't use a GUI
Don> builder for Motif, in that case Motif is way easier to use.
Maybe interface builders are a lot better than they used to be. The
big programs I've written would never work well with an interface
builder. They generally are too dynamic in nature. Anyway, isn't
this just a side issue? Tk has an interface builder.
Don> As far as I'm concerned programmers that like Tcl/Tk usually lack
Don> formal Computer Science training and instead prefer to use
Don> unstructured programming techniques (such as no type checking and
Don> use of globals that Tcl/Tk promotes).
I guess you include Ousterhout in this category? Seriously, I doubt
you can tell anything about Tcl/Tk programmers in general, any more
than you can tell anything about Motif programmers in general.
I'm not trying to claim that Tcl and Tk area panacea. In fact, I'm
usually quite critical of them. But I don't really think you've come
close to the mark here.
Tom
--
tro...@cns.caltech.edu Member, League for Programming Freedom
"Sadism and farce are always inexplicably linked"
-- Alexander Theroux
Francis John Hibbert
> Also it is very straight forward to write a program to generate
> Tcl/Tk from UIL.
Do you have one or know where I might be able to FTP one? I would find
such a tool very useful indeed but my Tk is not up to writing one (yet).
John
Ron Natalie
UIM/X is not a Hewlett-Packard product, but that of Visual Edge.
HP sells it under the name of Interface Architect as does CenterLine
under ViewCenter.
Yes, I have used it. While it is a superlative way of dealing with
Motif, it's just that, sugar coating on Motif. It does nothing to
remedy Motif's problms, but does greatly speed up the development of
Motif applications.
However, we've found that a combination of Tk and the Tix widgets
yields just as speedy development and a higher quality end product.
-Ron
Sim Harbert
--Ralf
We use Tcl/Tk for various reasons. Its portability (on Unix systems),
and ease of licensing are a couple of the reasons.
I have tried UIM/X on a Sun, and after fiddling for a while to get the
licensing software to run the demo version, we did get to try it. It
was very slow, and we could not get it to do what we wanted. Those
problems may have been fixed, but we needed something then. Rather
than go through months of searching for other systems for building
GUI's and demoing them we chose to go with Tcl/Tk, coupled with Xf.
Xf leaves much to be desired, but overall I think the choice was good.
I don't have a problem with paying for tools to do these kinds of
things (since I don't pay for them). But, when everything is taken
into account, including the licensing restrictions, portability,
support, demoing the software, and getting the funding approved, it
seems that many free software systems like Tcl/Tk come out on top.
Sim
--
Sim Harbert E-mail: Sim.H...@GTRI.GaTech.edu
Research Scientist I Mail: Georgia Institute of Technology
GTRI / EOEML / Baker 250
Voice: +1 404 853-3079 Atlanta, Georgia 30332-0834
Fax: +1 404 894-6285 WWW: http://EOEML-www.GTRI.GaTech.edu/~sim/
Kent Williams
brought up TCL/TK, and the flamewar that made me unsubscribe from
the gnu.misc.discuss group erupts anew here.
PROS FOR TCL/TK: Ease of use. User Extensibility. Segregation of
functionality.
If you build an application with TCL/TK you in effect partition your
program into two parts: The application problem solving part, and the
user interface part. This is, in fact, an excellent approach to
implementing an application.
In effect you ship two things when you ship your application: An
interpreter that implements solution in your problem domain, and a
text file implementing the user interface. Users are free to
customize the user interface, or write one of their own, or go into
raw TCL interpreter mode and poke around.
The Xwindows part (TK) is fairly solid, and provides nearly everything
you might need. It's not difficult to extend with your own custom
widgets.
CONS FOR TCL/TK: Clumsy Syntax. Poor support for modularity, information
hiding, and object orientation. What you have is a funky language
that looks a little like Smalltalk, does clumsy things with arrays and lists,
and has goofy ways of handling local variables and parameters. And the
performance isn't that great.
Given that you're going to write an interpreter, why not write a
compiler for a reasonable subset of a common programming language,
like C or C++, so that people aren't learning a new syntax they won't
use anywere else? Hell, the cheesy BASIC interpreters they've cobbled
into Microsoft applications are a step up from TCL. It's a scripting
language run amok. Not unlike the Korn Shell. (and the Windowing Korn
Shell? Be very afraid!).
My conclusion: What we need is a UI scripting language based on some
sort of standard syntax, with a well defined extension mechanism. It
should be free, easily ported, and support Industry standards like
Motif. UIL isn't a bad alternative, but it doesn't really handle the
scripting end of things.
Now there are many Motif detractors, but the more I work with it, the
more I believe there simply isn't another X windows library that does
what it does, and is available on virtually every X windows platform
as an included part of the software development kit. Since I live and
die by being able to port to everything under the sun (no pun
intended), it works for me.
Now if someone would get off the stick and sell me X11R6+Motif
for NT, I can die a happy man.
--
Kent Williams -- ke...@cadsi.com | Opinions expressed here are those of |
"A man who has nothing in | a two headed peg-legged midget who |
particular to recommend him | lives in my ear, not CADSI's |
discusses all sorts of subjects at+--------------------------------------+
random as though he knew everything."-One of Sei Shonagon's Hateful Things
Gerald G. Washington
: As far as I'm concerned programmers that like Tcl/Tk usually lack formal Computer
: Science training and instead prefer to use unstructured programming techniques
: (such as no type checking and use of globals that Tcl/Tk promotes).
Of course, any programmer with more than half a brain would get down off of his
damn high-horse and examine all options objectively, without turning his snotty
little nose up at options. Us real programmers can perform structured
programming in Assembly.
Just had to be said. :)
By the way, I've just started looking at Tcl/Tk, so I'm not defending it--just
defending the programmers who lack my formal Computer Science training.
-- Gerald
Don Clayton
I find it odd that everyone seems to think that it's ok for anyone who wants to
program should hack any way they like. Would you expect the same for jet design
or open heart surgery? I don't think so.
Tcl/Tk really promotes the development of unstructured code. It is incredibly
easy to use global varibles, create self modifying code, and use implicit goto's.
It violates just about every "good" programming technique I have every learned
or seen.
Perhaps those of you who consider your ego has been hurt should take a course
in software engineering, or at least try to remember the one you took.
Jan Newmarch
I would find this an interesting tool too, since the Motif widget set
used in UIL does not map onto the Tk set very cleanly (e.g.
internationalised text in a label). I don't particularly want to start
another thread in this, but tclMotif (tcl interface to the Motif widget
set) can take the output from the UIL compiler directly.
Jan
--
Jan Newmarch, Information Science and Engineering,
University of Canberra, PO Box 1, Belconnen, Act 2616
Australia. Tel: (Aust) 6-2012422. Fax: (Aust) 6-2015041
AARNet: j...@ise.canberra.edu.au
Gerald G. Washington
: I find it odd that everyone seems to think that it's ok for anyone who wants to
: program should hack any way they like.
Curious. Who has said this is okay, besides yourself?
: Tcl/Tk really promotes the development of unstructured code. It is incredibly
: easy to use global varibles, create self modifying code, and use implicit goto's.
From my limited exposure to Tcl/Tk, it is also incredibly easy not to use any of
the horrors you mention. I really have no interest in Tcl itself; I wish to use
Tk as a fast GUI builder with C++. Tcl seems the best way to do this quickly,
though I haven't looked at Perl.
: Perhaps those of you who consider your ego has been hurt should take a course
: in software engineering, or at least try to remember the one you took.
Yeah, maybe they can remember how to use the globals, self modifying code, and
implicit gotos that seem to plague your attempts at using Tcl. :)
-- Gerald
Lionel Mallet
> Computer
> Science training and instead prefer to use unstructured programming
> techniques
> (such as no type checking and use of globals that Tcl/Tk promotes).
Wanna start a flame war out there?
If not, keep this kind of biased views for yourself. I personally know at
least two Tcl/Tk programmers that certainly don't lack Computer Science
training (Hi Chris ;-). And both of them would never argue that C/Motif is
definitely better than Tcl/Tk. Instead, they may say that they've both reduced
the time to develop a small/medium sized project using Tcl/Tk.
And surely the Tcl/Tk programmers community is way larger than 2! Read
comp.lang.tcl for a few days and look at [incr Tcl] front line. It seems really
impressive.
And you know what? There are UI Builders for Tcl/Tk too. And they're way better
than their equivalent in the C/Motif world! Try playing a little bit with XF
and you'll see.
Do you really want to say that C provides better structured programming and
type checking?
Please don't :-)
Finally just let me add that I've developped in C/Motif as well as Tcl/Tk.
--
Lionel...@sophia.inria.fr
Don Clayton
In article <3hb2d0$5...@booz.bah.com>, ger...@warbird.usae.bah.com (Gerald G. Washington) writes:
|> Don Clayton (dcla...@bnr.ca) wrote:
|>
|>
|> : Tcl/Tk really promotes the development of unstructured code. It is incredibly
|> : easy to use global varibles, create self modifying code, and use implicit goto's.
|>
|> From my limited exposure to Tcl/Tk, it is also incredibly easy not to use any of
|> the horrors you mention. I really have no interest in Tcl itself; I wish to use
|> Tk as a fast GUI builder with C++. Tcl seems the best way to do this quickly,
|> though I haven't looked at Perl.
So you don't use procs, returns or cataches and upvar perfomance for huge strings
is acceptable to you?
|> : Perhaps those of you who consider your ego has been hurt should take a course
|> : in software engineering, or at least try to remember the one you took.
|>
|> Yeah, maybe they can remember how to use the globals, self modifying code, and
|> implicit gotos that seem to plague your attempts at using Tcl. :)
I did everything I could to avoid these "features" of Tcl (I can still remember the
code inspections - "christ look for procs not in catches and returns without
values!").
The problem is you have to work so hard in Tcl to catch these problems. The don't
even begin to occur in C++.
BTW, I don't use Tcl/Tk anymore, but I do have to support an existing code base
(S/W support, another concept foreign to Tcl, just look at the version upgrades).
Don Clayton
In article <3hcr3p$8...@sophia.inria.fr>, lma...@babar.inria.fr (Lionel Mallet) writes:
|> In article <3h63gd$7...@bcarh8ab.bnr.ca>, dcla...@bnr.ca (Don Clayton) writes:
|> > As far as I'm concerned programmers that like Tcl/Tk usually lack formal
|> > Computer
|> > Science training and instead prefer to use unstructured programming
|> > techniques
|> > (such as no type checking and use of globals that Tcl/Tk promotes).
|>
|> Wanna start a flame war out there?
Not really. I don't even read comp.lang.tcl. Perhaps the Tcl/Tk fanatics
who hate Motif should keep their opinions out of comp.windows.x.motif.
|> And you know what? There are UI Builders for Tcl/Tk too. And they're way better
|> than their equivalent in the C/Motif world! Try playing a little bit with XF
|> and you'll see.
Does XF allow you to define widget subsets as a class and add them to your palette
for reuse? Does is allow you to graphic develope binds? I'm not sure as I haven't
seen it, but X-Designer allows you to do these things.
|> Do you really want to say that C provides better structured programming and
|> type checking?
Considering that Tcl does not provide any type checking and other than proc {}
provides no structure, yes I do want to say this. Please note that I use
ANSI C and C++, not K&R C (who does?).
|> Please don't :-)
|>
|> Finally just let me add that I've developped in C/Motif as well as Tcl/Tk.
Don (a.k.a. Maverick)
Ron Natalie
: |> Do you really want to say that C provides better structured programming and
: |> type checking?
: Considering that Tcl does not provide any type checking and other than proc {}
: provides no structure, yes I do want to say this. Please note that I use
: ANSI C and C++, not K&R C (who does?).
C is not the issue. You want to make any wagers on the type checking
features of the Xt widget resource code. 90% of of my complaints
(and probaby the real problems with Motif) have to do with this
section of Xt.
If you want to argue the merits of C vs. TCL, I'll entertain that.
However, if we want to compare Tk vs. Motif, you need to hold it up
to the Motif and X Toolkit functions.
-Ron
Peter da Silva
> I find it odd that everyone seems to think that it's ok for anyone who
> wants to program should hack any way they like.
More unsupported ad-hominem attacks.
Perhaps you would better make your points with concrete examples?
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast du Heute schon deinen Wolf umarmt?"
Jon Leech
>The problem is you have to work so hard in Tcl to catch these problems. The don't
>even begin to occur in C++.
>
>BTW, I don't use Tcl/Tk anymore, but I do have to support an existing code base
>(S/W support, another concept foreign to Tcl, just look at the version upgrades).
Indeed. As we all know, C++ has never had version upgrades, or backwards
compatibility problems, or inter-vendor compatibility problems either.
Jon
__@/
John Ousterhout
individual people love or hate (usually hate) particular languages
get a little tiresome after a while. It's hard to tell whether the
hate mail reflects the feelings of the community or just a few
vociferous individuals So, with your help I propose to make the
Tcl vs. Motif discussion a tiny bit more quantitative.
If you have used both Tcl and native Motif at some time in your
career, please send me a short response with the following
information:
(a) Which system did you use first?
(b) Which system would you prefer to use?
I'll collect the answers and post a summary.
Ioi Kim Lam
: : programs especially if you are using a RISC machine.
: Yes, but you have to ask yourself if the part you've coded in Tcl is
: the critical part? Motif is *NOT* the most efficent code in the
: world.
If you have the chance to look at the Motif source you will find out
that it is the most disgusting piece of code even written on this
planet (well, after xterm). Take a look at the TK source code you'd
see an entirly different world. So we have a bunch of hackers who
write spaghetti code as they eat pizza, and we have JO who churns out
clean, readable code. Which code do you think is more stable and
efficient?
Don't tell me that you can hack away with 5meg of source
(Motif 1.2). I believe that good source expresses ideas and
understandings of the problems at hand. Bad source reveals confusion
and clumsiness.
Ioi.
John Ousterhout
I use" discussion out of boredom and hence might not have seen my
earlier posting. So, here it is again with a fresh title that will
hopefully get your attention. Apologies to those of you that read
it twice.
Perhaps it's just me, but all these anecdotal descriptions of why
individual people love or hate (usually hate) particular systems
Mark A Harrison
: Not really. I don't even read comp.lang.tcl. Perhaps the Tcl/Tk fanatics
: who hate Motif should keep their opinions out of comp.windows.x.motif.
If you would check the headers in your own posting, you would realize
that this thread was started when fj...@fjiao-ss10.cisco.com posted
message 3gofh4$i...@cronkite.cisco.com to comp.windows.x.motif and
comp.lang.tcl. It's the one that started with
> I don't think there are much comparisons between Motif and Tcl/Tk.
and went on for about 500 lines.
: If you're not living on the edge then you're taking up too much space.
It would seem that even living on the edge is no assurance that
one is no taking up too much space.
Cheers,
Mark.
Mark Ulferts
: As far as I'm concerned programmers that like Tcl/Tk usually lack formal Computer
: Science training and instead prefer to use unstructured programming techniques
: (such as no type checking and use of globals that Tcl/Tk promotes).
This doesn't say much for your company. I happen to know several people
at BNR who are spreading the gospel about Tcl/Tk/[incr Tcl].
: Don (a.k.a. Maverick)
: dcla...@bnr.ca
: If you're not living on the edge then you're taking up too much space.
^^^^
Seems like your sitting in the middle, stuck on a standard. Seriously,
consider changing your signature.
--
__________________ "There I go ... Turn the page" - Seger __________________
_/_/ _/_/ _/ _/ _/ Mark L. Ulferts
_/ _/ _/ _/ _/ _/ _/ mulf...@spd.dsccc.com
_/ _/ _/ _/ _/_/_/ _/ _/_/_/_/ _/ DSC Communications Corp, Plano Texas
_ "It's a half an inch of water and you think you're gonna drown" - Prine __
Ioi Kim Lam
: : As far as I'm concerned programmers that like Tcl/Tk usually lack formal Computer
: : Science training and instead prefer to use unstructured programming techniques
: : (such as no type checking and use of globals that Tcl/Tk promotes).
Well, programmers with formal Computer Science training love to use
assembler, NOT!
If I want to impress a Professor, I'd describe myself as a
Lisp/Scheme/Prolog/ML/ guy, someone who severly lacks the formal
Computer Science training from Joe's Computer Learning Center and
knows nothing about C.
Ioi.
Patrik Floding
>
> I find it odd that everyone seems to think that it's ok for anyone who wants to
> program should hack any way they like. Would you expect the same for jet design
> or open heart surgery? I don't think so.
Maybe Tcl/Tk is not the obvious choice for mission-critical applications. On the other hand, when the code has a flaw, Tcl/Tk normally recovers helpfully, while a C/C++ program would dump core.
>
> Tcl/Tk really promotes the development of unstructured code. It is incredibly
> easy to use global varibles, create self modifying code, and use implicit goto's.
> It violates just about every "good" programming technique I have every learned
> or seen.
Since the art of programming is relatively young, perhaps we don't really yet know the most efficient way to solve our problems? Do you really believe all main-stream choices of tools are based on what's the best?
>
> Perhaps those of you who consider your ego has been hurt should take a course
> in software engineering, or at least try to remember the one you took.
My ego is untouched, I can assure you :-)
>
> Don (a.k.a. Maverick)
> dcla...@bnr.ca
> If you're not living on the edge then you're taking up too much space.
Patrik
Patrik
Patrik Floding
>
> I find it odd that everyone seems to think that it's ok for anyone who wants to
> program should hack any way they like. Would you expect the same for jet design
> or open heart surgery? I don't think so.
Maybe Tcl/Tk is not the obvious choice for mission-critical applications. On the other hand, when the code has a flaw, Tcl/Tk normally recovers helpfully, while a C/C++ program would dump core.
>
> Tcl/Tk really promotes the development of unstructured code. It is incredibly
> easy to use global varibles, create self modifying code, and use implicit goto's.
> It violates just about every "good" programming technique I have every learned
> or seen.
Since the art of programming is relatively young, perhaps we don't really yet know the most efficient way to solve our problems? Do you really believe all main-stream choices of tools are based on what's the best?
>
> Perhaps those of you who consider your ego has been hurt should take a course
> in software engineering, or at least try to remember the one you took.
My ego is untouched, I can assure you :-)
>
> Don (a.k.a. Maverick)
> dcla...@bnr.ca
> If you're not living on the edge then you're taking up too much space.
Patrik
Richard L. Goerwitz
>We use Tc;/Tk becuase we perfer it, not because of license issues. We
>evaluated several Motif GUI tools (in fact the product we are based on comes
>with one) but decided on Tcl/Tk. Factures that decided us was:
>
> 1) Ease of use
> 2) Speed of developement/change
> 3) Speed of applications (Tcl/Tk apps were in many cases *faster*)
> 4) Support (comp.lang.tcl and sources)
How do the two compare as far as internationalized and multilingual
applications go?
--
Richard L. Goerwitz *** go...@midway.uchicago.edu
Colman Reilly
>dcla...@bnr.ca (Don Clayton) wrote:
>>
>> I find it odd that everyone seems to think that it's ok for anyone who wants to
>> program should hack any way they like. Would you expect the same for jet design
>> or open heart surgery? I don't think so.
>Maybe Tcl/Tk is not the obvious choice for mission-critical applications. On the other hand, when the code has a flaw, Tcl/Tk normally recovers helpfully, while a C/C++ program would dump core.
And you know what? I'd feel a whole lot happier writing a formal semantics for
tcl than I would for C++. Writing provable mission critical software doesn't
really look like a problem in it, and the syntax is nice and easy.
And most programs aren't jet airplanes or open heart surgery by a long way.
>>
>> Tcl/Tk really promotes the development of unstructured code. It is incredibly
>> easy to use global varibles, create self modifying code, and use implicit goto's.
>> It violates just about every "good" programming technique I have every learned
>> or seen.
Which is fine for short bits of code. Good programming techniques are really
only needed for long bitys of code, and they don't even work well there, as we
see every day in all sorts of applications. You can't blame a language for
people making mistakes: thats a terribly computer science approach to the
problem. "It's ok, we'll just write a new language and it'll fix all our
problems".
It's prefectly possible to write reasonable structured code in tcl, and
prefectly possible (and not very hard) to write illegible rubbish in C++.
>Since the art of programming is relatively young, perhaps we don't really yet know the most efficient way to solve our problems? Do you really believe all main-stream choices of tools are based on what's the best?
And in any case, it doesn't encourage bad style as much as (say) Perl.
>> Perhaps those of you who consider your ego has been hurt should take a course
>> in software engineering, or at least try to remember the one you took.
>My ego is untouched, I can assure you :-)
Mine is rather amused at Mr Clayton.
Colman
--
Colman Reilly (cre...@maths.tcd.ie) [+353-(0)1-7022280]
c/o School of Mathematics,18.05 Westland Row,Trinity College,Dublin.
PGP Public Key on Request MIME OK
"Nothing so strong as gentleness; nothing so gentle as real strength."
Rene Dekker
with lines of more than 80 characters:
>I find it odd that everyone seems to think that it's ok for anyone who
>wants to program should hack any way they like. Would you expect the
>same for jet design or open heart surgery? I don't think so.
>
>Tcl/Tk really promotes the development of unstructured code. It is
>incredibly easy to use global varibles, create self modifying code, and
>use implicit goto's. It violates just about every "good" programming
>technique I have every learned or seen.
>
>Perhaps those of you who consider your ego has been hurt should take a
>course in software engineering, or at least try to remember the one you
>took.
The "good" programming techniques you mention are vital for building
large software systems. But Tcl/Tk was never intended for writing
large programs. It is intended to be an extension language that lets
you write small scripts fast and intuitively. When writing scripts,
"good" programming techniques are usually more hampering than helping.
It is not Tcl/Tk's fault that people seem to think it is a
you-can-do-everthing-with-it kind of tool. Perhaps these are the same
people that seem to think that software engineering is a
you-can-do-everthing-with-it kind of methodology.
If you know a programming language that is embedable, lets you write
small programs fast, lets you build GUIs fast, AND promotes "good"
programming techniques, PLEASE let me know.
Ciao,
Rene'
"
--
Rene Dekker Delft University of Technology
R.De...@twi.tudelft.nl Department of Technical Mathematics and Informatics
Tel: +3115 783850 Julianalaan 132
Fax: +3115 787141 2628 BL Delft, The Netherlands
Dan Blanks
[some comments deleted]
> If you have used both Tcl and native Motif at some time in your
> career, please send me a short response with the following
> information:
>
> (a) Which system did you use first?
>
> (b) Which system would you prefer to use?
>
> I'll collect the answers and post a summary.
Pertinent questions. Let me add a few of my own. Please do not
interpret these as "flames". I honestly do not know the answers to these
questions.
(c) Is there a well-defined standard for Tcl? If so, where is it located?
(d) Assuming there is such a standard, is there any organization analogous to
OSF that will stand behind a Tcl "standard" and be responsible for updates,
bug fixes, etc?
(e) Are there any companies that are designing custom Tcl widgets as is the
case for Motif (like ICS and XRT)? If so, could I get table, 2-d plot, and
3-d plot widgets with the same functionality as the XRT widgets?
(f) Have there been any major *commercial* Unix software products built on
Tcl/Tk, or has is it only used for quick GUI development for in-house programs?
(g) Do any of the major Unix vendors have any official policy with regard to
Tcl/Tk? If so, please specify the vendor and the policy statement.
Please feel free to forward this to the Tcl newsgroup. I would request
that they send the responses to this group as I assume the Tcl crown already
knows the answers).
Thanks,
Dan Blanks
Texas Instruments
Larry M Headlund
>In article <3hbcke$4...@nexus.uiowa.edu>,
>Kent Williams <will...@herky.cs.uiowa.edu> wrote:
>> Given that you're going to write an interpreter, why not write a
>> compiler for a reasonable subset of a common programming language,
>> like C or C++, so that people aren't learning a new syntax they won't
>> use anywere else?
>
>purpose programming language. You create a little meta-language to
>describe your application domain and write the application in that.
>You need to be able to do this dynamically, so you can use the meta-
>language to save and restore configurations.
>
To summarize, a scripting language which was a subset of
C could be an awkward construct.
Larry "I hope there is no penalty for puns" Headlund
--
Larry Headlund l...@world.std.com Eikonal Systems (617) 482-3345
Unix, X and Motif Consulting Motif on Ascii Terminals!
Speaking for myself at most.
Koert Zeilstra
: We use C++/Motif because :
: 1) Speed of development/change (Tk lack of compiler makes it hell, as do
: those damn bindings, which have to be rewritten evertime a window is
: changed).
: 2) Speed of application (way faster than Tcl/Tk)
: 3) Support (Motif 1.1.x+ is stable, we don't code the library, well documented,
: we don't have to recode it every release because some jerk changes the function
: name or parameters).
: 4) Compatiblity with window managers.
: 5) Interactions with other programs.
: 6) Structured programming!
: I'll give you ease of use, but only if you don't use a GUI builder for Motif,
: in that case Motif is way easier to use.
: As far as I'm concerned programmers that like Tcl/Tk usually lack formal Computer
: Science training and instead prefer to use unstructured programming techniques
: (such as no type checking and use of globals that Tcl/Tk promotes).
: Don (a.k.a. Maverick)
: dcla...@bnr.ca
Funny, your points 1, 2, 3, and 5 are also used by Tcl/Tk advocates about
Tcl/Tk! As far as structured programming concerned, you should be more open
to other programming paradigms. Plain Tcl is unstructured, and is intended
to be so to keep the language simple. If you need more structure for large
projects, use [incr tcl], a pretty good OO extension.
The common oversight is that you can make your own Tcl commands, using
either C or C++, so you still have the benefits of rigid typechecking for
your important code. Besides, C++ and Motif don't really go together well;
you always need clumsy C code in between. In any case, I think Tcl/Tk and Motif
can coexist peacefully, and you can even do interprocess communication. I have
worked on a hybrid system, and it works great!
Please don't start a religious war saying that Tcl not scientific enough!
We should be using ML or another functional language, if you really want
a Computer Science 'approved' language.
Koert
--
Koert Zeilstra (kz...@comsearch.com)
MIME mail welcome
"Friends don't let friends use DOS"
Peter da Silva
> compiler for a reasonable subset of a common programming language,
> like C or C++, so that people aren't learning a new syntax they won't
> use anywere else?
Because a scripting language has different requirements from a general
purpose programming language. You create a little meta-language to
describe your application domain and write the application in that.
You need to be able to do this dynamically, so you can use the meta-
language to save and restore configurations.
Smalltalk, Lisp, Forth, Logo, Tcl, all designed to support this model.
They all make decent scripting environments. I would say Smalltalk syntax
is the best, from the point of view of ease of use and familiarity, but
Tcl comes next.
Wayne A. Christopher
is that you can't check for undefined variables at compile time.
Most of the bugs in my Tcl code are undefined variables, and these
are generally bugs that wouldn't appear in C code.
I think the solution for this is to have a compiler or code checker that
can do enough flow analysis to warn about potential problems. Maybe
optional declarations would help also. Of course, there will always
be cases that it can't handle, since you can do lots of wierd stuff in
Tcl, but I would say that if I good code checker complains about something
it will either be a bug or bad style.
Wayne
Terry Lambert
] (c) Is there a well-defined standard for Tcl? If so, where is it located?
This is implies a public standard, rather than a standard sold by
a standards body. It's sort of a trick question, since there is
a well defined standard for OSF/Motif, but because of that, I can't
answer the question "where is it located?".
] (d) Assuming there is such a standard, is there any organization
] analogous to OSF that will stand behind a Tcl "standard" and be
] responsible for updates, bug fixes, etc?
You mean "is there a commercial reference implementation?". I think
Sun was working on one. Unfortunately, unlike Motif, but like X,
Tcl/Tk is available as source code without charge.
] (f) Have there been any major *commercial* Unix software products
] built on Tcl/Tk, or has is it only used for quick GUI development
] for in-house programs?
If I had to guess at this one, I'd say that it was unlikely that a
commercial software vendor would ship the source for their products
to consumers. I'd put Tcl/Tk in the same category as Visual BASIC
(a highly successful product without a well defined standard).
Regards,
Terry Lambert
te...@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Ron Natalie
: This is implies a public standard, rather than a standard sold by
: a standards body. It's sort of a trick question, since there is
: a well defined standard for OSF/Motif, but because of that, I can't
: answer the question "where is it located?".
Really? Would you care to point it out to me? The Style Guide
is nice for appearance, but doesn't specify the interface (and last
I check the official product still doesn't match it). Of course
since the people producing the code are also responsible for the
standard, they can just revise the "standard" to match what they
have. You can argue that such a sham isn't really a standard anyhow.
: ] (d) Assuming there is such a standard, is there any organization
: ] analogous to OSF that will stand behind a Tcl "standard" and be
: ] responsible for updates, bug fixes, etc?
I would just be as happy that an organziation populated 90% by
industry lawyers was *NOT* behind controlling the standard.
: You mean "is there a commercial reference implementation?". I think
: Sun was working on one. Unfortunately, unlike Motif, but like X,
: Tcl/Tk is available as source code without charge.
Actually, X has an independently dervied standard. However one may
argue that it hasn't much benefitted from having doe so.
: If I had to guess at this one, I'd say that it was unlikely that a
: commercial software vendor would ship the source for their products
: to consumers. I'd put Tcl/Tk in the same category as Visual BASIC
: (a highly successful product without a well defined standard).
Actually, I consider MOTIF to be exactly in the same boat. As Tk
and Visual Basic standardswise.
-Ron
Don Clayton
Ron Natalie <r...@topaz.sensor.com> wrote:
>Don Clayton (dcla...@bnr.ca) wrote:
>
>: |> Do you really want to say that C provides better structured programming and
>: |> type checking?
>
>: Considering that Tcl does not provide any type checking and other than proc {}
>: provides no structure, yes I do want to say this. Please note that I use
>: ANSI C and C++, not K&R C (who does?).
>
>C is not the issue. You want to make any wagers on the type checking
>features of the Xt widget resource code. 90% of of my complaints
>(and probaby the real problems with Motif) have to do with this
>section of Xt.
The problems can be overcome by using C++ and Motif wrappers like
Motif++, and yes most of my problems with Motif are with XtGet and
XtSetValues.
Keep in mind I made no claims about Motif, other than it was better
than Tk. I know Motif has bugs and I've encountered most of them.
>If you want to argue the merits of C vs. TCL, I'll entertain that.
>However, if we want to compare Tk vs. Motif, you need to hold it up
>to the Motif and X Toolkit functions.
Ok, things I don't like about Tk when compared to Motif (up until now
I guess most of my complaints were against Tcl) :
- lack of widgets : all dialogs (Selection, prompt, file, error,
message), paned, rowcolumn, form, and Motif 2.0 only makes
this problem more evident
- inability to unmanage windows (like the first one)
- inability to correctly load X-Resources when working with mwm
and derivatives of it, and as a result inability for program
to load and run - serious bug!
- bugs : stuck menus, missing cursors, text highlight and scroll,
cut and paste doesn't work correctly
- limited backward compatibility makes upgrade on reasonably
large programs very difficult
- inability to expand widget set without rebuilding entire shell
- same as above when trying to use anything other than Tcl as
implementation language
- confusing C code like Xterm (try and find anyone around
here who wants to look at either)
- difficulty when using binds compared to rowcolumn and form
- very bad resource names (what this App*App.geometry crap)
- gross 2D look
- very slow
- no debugger or syntax checker
- lack of any support - I have to support what I make
That's it for now. I haven't used it in a while and I'm sure I
could come up with many more if I looked through our bug report
library.
>-Ron
Peter da Silva
Wayne A. Christopher <fau...@remarque.berkeley.edu> wrote:
> I think the one big problem that Tcl has for production quality code
> is that you can't check for undefined variables at compile time.
> Most of the bugs in my Tcl code are undefined variables, and these
> are generally bugs that wouldn't appear in C code.
I think one big problem C has for production quality code is that you
can't check for dangling pointers at compile time. Most of the bugs in
my C code are dangling pointers, and these are bugs that generally wouldn't
appear in Tcl code.
> I think the solution for this is to have a compiler or code checker that
> can do enough flow analysis to warn about potential problems.
I think the solution is to have a language that doesn't have the concept of
pointers. I came up with "handles" for Tcl to avoid the problems of moving
pointers from the underlying C space to the tcl space, and they seem to have
caught on, preventing the sort of pointer related problems I've seen in other
scripting languages that deal with lower level objects like AREXX.
<I code in C and Tcl and shell and any other language that will help me
solve a problem. These wars are silly.>
Ioi Kim Lam
: Ok, things I don't like about Tk when compared to Motif (up until now
: - lack of widgets : all dialogs (Selection, prompt, file, error,
: message), paned, rowcolumn, form, and Motif 2.0 only makes
: this problem more evident
Obvious you have missed Tix: All the widget you mentioned
above (except rowcolumn) are in the Tix library, and the Tix
library is growing faster than ever because developing widgets
in TCL is more than 10 times faster than in C.
: - inability to unmanage windows (like the first one)
wm withdraw
pack forget
Care to read the TCL book before making more assertions?
: - inability to correctly load X-Resources when working with mwm
: and derivatives of it, and as a result inability for program
: to load and run - serious bug!
There is a tixMwm command in the Tix library that allows you
to communicate with mwm. It allows you to do everything you can do
with libXm, e.g. XmAddWmProtocols(), etc.
: - bugs : stuck menus, missing cursors, text highlight and scroll,
: cut and paste doesn't work correctly
This one I give up. I can only mention the fact that every new
Motif release comes with "list of 1000 more bugs fixed".
: - limited backward compatibility makes upgrade on reasonably
: large programs very difficult
: - inability to expand widget set without rebuilding entire shell
With many mega widget library such as Tix and the upcoming
[incr Tk], you can add in widgets *after you started
wish*. Now talk about re-compilation of your Motif app
every time you need to add one more semi-colon in you C code.
: - same as above when trying to use anything other than Tcl as
: implementation language
See the FAQ. There is more TK-XYZ language bindings than
Motif-XYZ.
: - confusing C code like Xterm (try and find anyone around
: here who wants to look at either)
Read the Motif source if you have it.
: - difficulty when using binds compared to rowcolumn and form
Compare apples to oranges?
: - very bad resource names (what this App*App.geometry crap)
Tk 4.0 has changed a lot to conform with stardard X/Motif
resource names. I agree, it still needs more modifications.
But what is this *XTerm*geometry: 80x24 crap?
: - gross 2D look
TK 3.6 is gross. 4.0 is getting better. If you have the
change, take a look at Tix. Now compare it with the gross
look of Motif 1.2 defaults -- blue background with an idiotic
fonts that says, "boy, you can't read small prints".
: - very slow
Show me figures. I am not sure about whether Motif is slower
or TK. But experience has shown Windows users can't tell the
speed between applications implemented in Visual Basic and
C. That is because normal apps spend less that 5% of
their times in GUI glue code (C or TCL or Basic).
Now unless you tell me that the implementation of Motif is
faster than TK, I won't be convinced. And I doubt you can
because TK is implemented as one flat level while Motif is
implemented in a hierachy.
Read the Motif and see how they implement the XtSetValues().
: - no debugger or syntax checker
: - lack of any support - I have to support what I make
I agree with these two points.
: That's it for now. I haven't used it in a while and I'm sure I
: could come up with many more if I looked through our bug report
: library.
If you want to make some valid claims about TK, you'd better speak it
out of your experience, not imagination.
Larry Weiss
>In article <1995Feb6.1...@cpu.com>, gwle...@CAPTAINHOOK.CPU.COM wrote:
>> We use Tc;/Tk becuase we perfer it, not because of license issues. We
>Have you perhaps compared it with recent versions of Openware's
>ObjectBuilder, ILOG Views, Visix Galaxy (using G/Script perhaps),
>Hewlett-Packard UIM/X, Thomson Software's TeleUSE, or Centerline
>ViewCenter?
What is G/Script ?
--
Larry Weiss, l...@oc.com
214/888-0471
Don Clayton
In article <3hjdgm$5...@netnews.upenn.edu>, i...@red.seas.upenn.edu (Ioi Kim Lam) writes:
|> Don Clayton (dcla...@bnr.ca) wrote:
|> : Ok, things I don't like about Tk when compared to Motif (up until now
|> : I guess most of my complaints were against Tcl) :
|>
|> : - lack of widgets : all dialogs (Selection, prompt, file, error,
|> : message), paned, rowcolumn, form, and Motif 2.0 only makes
|> : this problem more evident
|>
|> Obvious you have missed Tix: All the widget you mentioned
|> above (except rowcolumn) are in the Tix library, and the Tix
|> library is growing faster than ever because developing widgets
|> in TCL is more than 10 times faster than in C.
Ah, battle cry of the emacs users (what, you don't have emacs 19.1432b -
you're obviously an idiot!). However, I am glad that these widgets
are finally available.
|> : - inability to unmanage windows (like the first one)
|>
|> wm withdraw
|> pack forget
|> Care to read the TCL book before making more assertions?
|>
Had a look at are manual, and the withdraw command wasn't there.
Had a look at the book on Tcl/Tk we got last year, Tcl and the Tk
Toolkit, and it was there.
|> : - inability to correctly load X-Resources when working with mwm
|> : and derivatives of it, and as a result inability for program
|> : to load and run - serious bug!
|>
|> There is a tixMwm command in the Tix library that allows you
|> to communicate with mwm. It allows you to do everything you can do
|> with libXm, e.g. XmAddWmProtocols(), etc.
Again, good.
|> : - bugs : stuck menus, missing cursors, text highlight and scroll,
|> : cut and paste doesn't work correctly
|>
|> This one I give up. I can only mention the fact that every new
|> Motif release comes with "list of 1000 more bugs fixed".
True, however much of the basic Motif functionality has been stable
since 1.1.x.
|> : - limited backward compatibility makes upgrade on reasonably
|> : large programs very difficult
|> : - inability to expand widget set without rebuilding entire shell
|>
|> With many mega widget library such as Tix and the upcoming
|> [incr Tk], you can add in widgets *after you started
|> wish*. Now talk about re-compilation of your Motif app
|> every time you need to add one more semi-colon in you C code.
The nice part about syntax checking is that I don't find out about
the missing semi-colon while the program is running, or when a user
runs down a test path we missed.
|> : - same as above when trying to use anything other than Tcl as
|> : implementation language
|>
|> See the FAQ. There is more TK-XYZ language bindings than
|> Motif-XYZ.
I still have to recompile all of Tk if I want to modify them.
|> : - confusing C code like Xterm (try and find anyone around
|> : here who wants to look at either)
|>
|> Read the Motif source if you have it.
I have. It's an object-oriented implementation, unlike the 20
levels of switches in Tk.
|> : - difficulty when using binds compared to rowcolumn and form
|>
|> Compare apples to oranges?
Oh, is there another way to perform geometry management in Tk than
the bind and pack commands (I'm sure our books are out of date,
they're almost 6 months old).
|> : - very bad resource names (what this App*App.geometry crap)
|>
|> Tk 4.0 has changed a lot to conform with stardard X/Motif
|> resource names. I agree, it still needs more modifications.
|>
|> But what is this *XTerm*geometry: 80x24 crap?
Xterm is a Xlib application, not and Xt application.
|> : - gross 2D look
|>
|> TK 3.6 is gross. 4.0 is getting better. If you have the
|> change, take a look at Tix. Now compare it with the gross
|> look of Motif 1.2 defaults -- blue background with an idiotic
|> fonts that says, "boy, you can't read small prints".
I wasn't talking about the default fonts or colours (I know how to
change these). I was talking about the advanced 2d look of Tk.
|> : - very slow
|>
|> Show me figures. I am not sure about whether Motif is slower
|> or TK. But experience has shown Windows users can't tell the
|> speed between applications implemented in Visual Basic and
|> C. That is because normal apps spend less that 5% of
|> their times in GUI glue code (C or TCL or Basic).
|>
|>
|>
|> Now unless you tell me that the implementation of Motif is
|> faster than TK, I won't be convinced. And I doubt you can
|> because TK is implemented as one flat level while Motif is
|> implemented in a hierachy.
|>
|> Read the Motif and see how they implement the XtSetValues().
Please tell me how I can get our interpreted Tcl/Tk code to run
faster than our compiled Motif code - please oh please!
|> : - no debugger or syntax checker
|> : - lack of any support - I have to support what I make
|>
|> I agree with these two points.
|>
|>
|> : That's it for now. I haven't used it in a while and I'm sure I
|> : could come up with many more if I looked through our bug report
|> : library.
|>
|> If you want to make some valid claims about TK, you'd better speak it
|> out of your experience, not imagination.
I guess 10,000 lines and 2 years of experience isn't enough. Perhaps
I should have been on the design team to be a "worthy of commenting on
Tk" person. I beg your humble forgiveness for my obvious inadequacies.
Ioi Kim Lam
: |>
: |> Compare apples to oranges?
: Oh, is there another way to perform geometry management in Tk than
: the bind and pack commands (I'm sure our books are out of date,
: they're almost 6 months old).
Again (with the emacs-19.24.5.6 syndrome), there are many more
geometry managers in Tix : Form, PanedWindow, NoteBook,
ScrolledWindow, MDIWindow ...
: |> : - very slow
: |>
: |> Show me figures. I am not sure about whether Motif is slower
: |> or TK. But experience has shown Windows users can't tell the
: |> speed between applications implemented in Visual Basic and
: |> C. That is because normal apps spend less that 5% of
: |> their times in GUI glue code (C or TCL or Basic).
: |>
: |> Now unless you tell me that the implementation of Motif is
: |> faster than TK, I won't be convinced. And I doubt you can
: |> because TK is implemented as one flat level while Motif is
: |> implemented in a hierachy.
: |>
: |> Read the Motif and see how they implement the XtSetValues().
: Please tell me how I can get our interpreted Tcl/Tk code to run
: faster than our compiled Motif code - please oh please!
Of course TCL code runs slower than C. But you always have the
option to rewrite critical parts of your program in C. Usually
the user won't notice any performance difference between a
Motif and a TCL/TK app. That is my point.
: |> If you want to make some valid claims about TK, you'd better speak it
: |> out of your experience, not imagination.
: I guess 10,000 lines and 2 years of experience isn't enough. Perhaps
: I should have been on the design team to be a "worthy of commenting on
: Tk" person. I beg your humble forgiveness for my obvious inadequacies.
That sounds enough. My apologies. But still, when someone
complains, "there is no equivalence to XtUnmanageChild()", I
would have the doubt that all those 10,000 lines of TCL code
are of the form:
button .a.b.c -text "a button"
button .a.b.c -text "a button"
button .a.b.c -text "a button"
button .a.b.c -text "a button"
button .a.b.c -text "a button"
button .a.b.c -text "a button"
button .a.b.c -text "a button"
Grant R Gainey
Larry Weiss <l...@pssparc2.oc.com> wrote:
>schl...@che.utexas.edu (Tony Schleizer) writes:
>
> >Have you perhaps compared [Tcl/Tk] with...Visix Galaxy
> >(using G/Script perhaps)...
>
>What is G/Script ?
<I really, really, REALLY need to do the writeup of G/script for the
Tcl FAQ!>
G/script is a Tcl cover for most of the Galaxy API. It allows nearly
complete access to Galaxy from Tcl scripts. It was built by Bellcore
Inc., and is used extensively in-house; the commercial version is
distributed by Widget Workshop, Inc., in Cary, NC. Call Mike Freeman
at (919)481-3352, or email mi...@ivc.com.
<BIAS ALERT: I work for Widget Workshop, and having been doing A LOT
of G/scripting recently.>
Grant
--
Grant Gainey. gga...@io.com
You can't have everything. Where would you put all the packing materials?
Ralf B. Lukner
Natalie) wrote:
> UIM/X is not a Hewlett-Packard product, but that of Visual Edge.
HP sells a product called UIM/X.
> HP sells it under the name of Interface Architect
Wrong. HP calls it UIM/X now.
> as does CenterLine
> under ViewCenter.
Centerline claims to have made some improvements. I don't know if this is true.
>
> Yes, I have used it. While it is a superlative way of dealing with
> Motif, it's just that, sugar coating on Motif. It does nothing to
> remedy Motif's problms, but does greatly speed up the development of
> Motif applications.
>
> However, we've found that a combination of Tk and the Tix widgets
> yields just as speedy development and a higher quality end product.
Have you tried TeleUSE, Openware's ObjectBuilder, or ILOG Views?
--Ralf
Ralf B. Lukner
wrote:
> What is G/Script ?
G/Script is a scripting language for Galaxy.
--Ralf
Gerald G. Washington
: In article <3he71f$i...@news.utdallas.edu>, mhar...@utdallas.edu (Mark A Harrison) writes:
: |> Don Clayton (dcla...@bnr.ca) wrote:
: |>
: |>
: |> It would seem that even living on the edge is no assurance that
: |> one is no taking up too much space.
: The second lowest form of net life is someone who attacks grammar.
: The lowest form is someone who attacks sigs.
Who makes up these rules? I couldn't find them in the FAQ.
-- Gerald
Don Clayton
Ok, ok, ok. Tcl is great! Tk is great! Use 'sh' to write your applications
for all I care, just stop sending me email!
Christ, this is worse than a pack of rabid emacs users.
Don (a.k.a. Maverick)
dcla...@bnr.ca
Hoshi Takanori
> Xterm is a Xlib application, not and Xt application.
XTerm *is* an Xt (and Xaw) program. It uses Athena's Scrollbar and
Menu widgets, and defines its own VT100 widget as an Xt widget.
hoshi
John Goodsen
|> : - confusing C code like Xterm (try and find anyone around
|> : here who wants to look at either)
|>
|> Read the Motif source if you have it.
I have. It's an object-oriented implementation, unlike the 20
levels of switches in Tk.
Although I'm very much an OO person, I am not convinced that the Tk
switch statement approach is bad, just because it's not an OO solution.
I haven't found many programmers who feel comfortable in using the Xt
_object model_ to implement new subclasses of widgets. I _am_ seeing
a LOT of nice widgets based upon Tk (Tix, Blt, etc.). It makes me wonder
why these are coming out so fast and the Motif widget industry seems
relatively idle. I suspect it's due to the complexity of the Xt toolkit,
-- "all in the being object oriented". Let's face it, the Xt object model
is an OO kludge. If C weren't the language, Xt would not exist and developers
would not be so intimidated in learning a complex OO engine (e.g. Xt), simply
to say they are developing in an object oriented fashion.
Meanwhile, in the Tk world, it would appear that the switch
statement approach is easy enough to understand that many people are
successfully making the leap into custom widget building using Tk.
|> : - difficulty when using binds compared to rowcolumn and form
|>
|> Compare apples to oranges?
Oh, is there another way to perform geometry management in Tk than
the bind and pack commands (I'm sure our books are out of date,
they're almost 6 months old).
IMHO, both are crap. What we *really* want is constraint based layout
algorithms. Tcl is set up to plug in a constraint engine right now.
As soon as you see a DeltaBlue or Skyblue constraint engine on top of
Tcl, we will probably start forgetting about fixed layout managers like
the XmForm, packer, table widgets, etc.
|> : - very slow
|>
|> Show me figures. I am not sure about whether Motif is slower
|> or TK. But experience has shown Windows users can't tell the
|> speed between applications implemented in Visual Basic and
|> C. That is because normal apps spend less that 5% of
|> their times in GUI glue code (C or TCL or Basic).
|>
|>
|>
|> Now unless you tell me that the implementation of Motif is
|> faster than TK, I won't be convinced. And I doubt you can
|> because TK is implemented as one flat level while Motif is
|> implemented in a hierachy.
|>
|> Read the Motif and see how they implement the XtSetValues().
This recurring argument of "which toolkit is faster" is pointless.
A user can't tell a &*(^#$ difference if it's a Tk or Motif application,
in terms of response time. If you have a slow application, either you
have some application design/code to rethink or you haven't developed
your GUI properly. Also, I've built both Tcl/Tk GUIs and Tcl/Motif GUI's.
I challenge anyone to tell me which one is _faster_ just by experiencing
the user interface. You can't.
> Please tell me how I can get our interpreted Tcl/Tk code to run
> faster than our compiled Motif code - please oh please!
Fast turnaround time. In fact, if you aren't using either Tcl/Motif
or a solution like TeleUSE's D scripting language (an quasi-interpreted language)
then you are probably spending an order of magnitude in your code/debug cycles
than you need to. Not matter what GUI toolkit I use, I'd be serious
considering using something like Tcl to implement the GUI behavior.
User's can't tell the difference in the GUI if it's implemented using an
interpreter or if it's compiled, unless you start doing application logic
in the interpreter that is probably better implemented in a compiled language.
If this is the case, then you've got a design problem, not a language problem.
--
--
John Goodsen Currently On-Site:
Rapid Engineering Specialist Motorola Satellite Communications
The Dalmatian Group, Inc. Phoenix, AZ
jgoo...@radsoft.com Todays Weather: SUNNY and WARM ;-)
Mike Hopkirk
>] (f) Have there been any major *commercial* Unix software products
>] built on Tcl/Tk, or has is it only used for quick GUI development
>] for in-house programs?
>
>If I had to guess at this one, I'd say that it was unlikely that a
>commercial software vendor would ship the source for their products
>to consumers. I'd put Tcl/Tk in the same category as Visual BASIC
>(a highly successful product without a well defined standard).
Have a look at the Tcl-Commercial-Uses FAQ
- You'll find a few (admitted to) there.
--
- hops
Everything disclaimed (including disclaimer)
------< ho...@sco.com>--------------------------------------
Mike Hopkirk ( hops ) | Whenever possible steal code.
SCO Inc | Tom Duff. Bell Labs
Rony Shapiro
|> In article <3hlku5$d...@bcarh8ab.bnr.ca> dcla...@bnr.ca (Don Clayton) writes:
[...]
|>
|> Oh, is there another way to perform geometry management in Tk than
|> the bind and pack commands (I'm sure our books are out of date,
|> they're almost 6 months old).
|>
|> IMHO, both are crap. What we *really* want is constraint based layout
|> algorithms. Tcl is set up to plug in a constraint engine right now.
|> As soon as you see a DeltaBlue or Skyblue constraint engine on top of
|> Tcl, we will probably start forgetting about fixed layout managers like
|> the XmForm, packer, table widgets, etc.
|>
[...]
|>
|> --
|> --
|> John Goodsen Currently On-Site:
|> Rapid Engineering Specialist Motorola Satellite Communications
|> The Dalmatian Group, Inc. Phoenix, AZ
|> jgoo...@radsoft.com Todays Weather: SUNNY and WARM ;-)
Hi,
As part of my Master's thesis, I've "plugged in" the DeltaBlue
constraint engine to Tcl, and am in the middle of "upgrading" to
Skyblue.
My work is more about basic 2D drawing (canvas items) than GUI
elements, but it should be applicable.
If anyone is interested in the code, let me know.
If anyone has suggestions/ideas about using the constraint engine for
layout (or anything else for that matter), dittto.
Cheers,
--
Rony Shapiro
Tecnomatix Technologies Ltd. UUCP: uunet!robcad!ronys
Delta House Internet: ronys...@uunet.uu.net
16 Hagalim Ave. Voice: 972-9-594718
Herzeliya 46733, Israel Fax: 972-9-544402
Don Clayton
In article <GOODSE_J.95...@eggbeater.motsat.sat.mot.com>, good...@eggbeater.motsat.sat.mot.com (John Goodsen) writes:
|> In article <3hlku5$d...@bcarh8ab.bnr.ca> dcla...@bnr.ca (Don Clayton) writes:
|>
|>
|> |> : here who wants to look at either)
|> |>
|> |> Read the Motif source if you have it.
|>
|> I have. It's an object-oriented implementation, unlike the 20
|> levels of switches in Tk.
|>
|> switch statement approach is bad, just because it's not an OO solution.
|> I haven't found many programmers who feel comfortable in using the Xt
|> _object model_ to implement new subclasses of widgets. I _am_ seeing
|> a LOT of nice widgets based upon Tk (Tix, Blt, etc.). It makes me wonder
|> why these are coming out so fast and the Motif widget industry seems
|> relatively idle. I suspect it's due to the complexity of the Xt toolkit,
|> -- "all in the being object oriented". Let's face it, the Xt object model
|> is an OO kludge. If C weren't the language, Xt would not exist and developers
|> would not be so intimidated in learning a complex OO engine (e.g. Xt), simply
|> to say they are developing in an object oriented fashion.
|> Meanwhile, in the Tk world, it would appear that the switch
|> statement approach is easy enough to understand that many people are
|> successfully making the leap into custom widget building using Tk.
Agreed. Motif's OO model is hard to follow because of the C implementation
(note that Motif 2.0 now has a C++ implementation for some widgets).
As for seeing more widgets based on Tk I would imagine it's because 1) you
haven't looked at the 100s of widgets available for Motif, 2) it's free -
let's face it free S/W will always have more people working on it.
As for people being able to understand switches easier than object-oriented
techniques I would assume that has more to do with their computer science
education, or lack there of (polymorphism requires a fair amount of language
knowledge to fully understand). Which comes right back to my assertion that
Tcl/Tk is a language for hacks (all you Tcl/Tk fans can go balistic again!).
|> > Please tell me how I can get our interpreted Tcl/Tk code to run
|> > faster than our compiled Motif code - please oh please!
|>
|> Fast turnaround time. In fact, if you aren't using either Tcl/Motif
|> or a solution like TeleUSE's D scripting language (an quasi-interpreted language)
|> then you are probably spending an order of magnitude in your code/debug cycles
|> than you need to. Not matter what GUI toolkit I use, I'd be serious
|> considering using something like Tcl to implement the GUI behavior.
|> User's can't tell the difference in the GUI if it's implemented using an
|> interpreter or if it's compiled, unless you start doing application logic
|> in the interpreter that is probably better implemented in a compiled language.
|> If this is the case, then you've got a design problem, not a language problem.
Fast turn-around time has nothing to do with execution speed. It is a feature
that is beneficial to the programmer, not the user, whereas fast execution
speed is a benifit to the user. As for developement time I would wager I can
develope a Motif application faster than you can develope a Tk application
(and probably faster using Motif libs not just a GUI builder). I can say this
because I've done both and Motif was signifcantly faster for me than Tk was.
Tk may be just as fast as Motif doing "Hello World", but try putting up a couple
of hundred widgets or inserting thousands of entries into a list. This is where
the interpreted execution speed really shows.
Ioi K. Lam
:
: As for developement time I would wager I can
: develope a Motif application faster than you can develope a Tk application
: (and probably faster using Motif libs not just a GUI builder).
:
I think this guy is nuts. If you dare, go and post this on
comp.lang.basic.visual :
"Working with bare-bone C++/MFC is actually faster than VB"
You will get some much mail your computer will explode and kill you.
Ioi.
J.M. Ivler
: >] (f) Have there been any major *commercial* Unix software products
: >] built on Tcl/Tk, or has is it only used for quick GUI development
: >] for in-house programs?
: >
: >If I had to guess at this one, I'd say that it was unlikely that a
: >commercial software vendor would ship the source for their products
: >to consumers. I'd put Tcl/Tk in the same category as Visual BASIC
: >(a highly successful product without a well defined standard).
: Have a look at the Tcl-Commercial-Uses FAQ
: - You'll find a few (admitted to) there.
: --
: - hops
And there are many of us who just write stuff in broad strokes and make
it available free... (see the software available at the FTP site).
Additionally, I would like to remind you that unlike some "free software"
organizations, Tcl/Tk doesn't come with the copy-whatever baggage the
stops a person from distributing it along with their code, while
maintaining ownership of that code...
*****
J.M. Ivler E-mail address by preference: iv...@crl.com
Infobahn Xpress iv...@eisner.decus.org
Los Alamitos, CA iv...@bbs.ug.eds.com
(310) 596 3753
WWW Servers, CGI, HTML, Web-based Solutions, Tcl/Tk, Training and Development
*****
There is a purpose to time you know. It keeps everything from happening
all at once. - _Disaster In Time_ (okay, and Einstein...)
Michael Hoegeman
: In article <3i2hqa$e...@netnews.upenn.edu>, i...@red.seas.upenn.edu (Ioi K. Lam) writes:
: VB is a GUI builder, not a interpreter. I'm not so nuts that I don't
: understand the difference.
It's *BOTH* a GUI builder *AND* and interpreter. You probably would'nt
get flamed so much if you were not fast and loose with your postings.
--
------------------------------------------------------------------------------
Mike Hoegeman email: m...@wx.gtegsc.com tel: (818)706-4145
GTE Weather Systems Group 31717 La Tienda Dr, Westlake Village CA. 91359
Don Clayton
In article <D4ACJ...@wlbr.iipo.gtegsc.com>, m...@wx.gtegsc.com (Michael Hoegeman) writes:
|> Don Clayton (dcla...@bnr.ca) wrote:
|>
|> : In article <3i2hqa$e...@netnews.upenn.edu>, i...@red.seas.upenn.edu (Ioi K. Lam) writes:
|> : |> Don Clayton (dcla...@bnr.ca) wrote:
|> : |> : As for developement time I would wager I can
|> : |> : develope a Motif application faster than you can develope a Tk application
|> : |> : (and probably faster using Motif libs not just a GUI builder).
|> : |>
|> : |> I think this guy is nuts. If you dare, go and post this on
|> : |> comp.lang.basic.visual :
|> : |> "Working with bare-bone C++/MFC is actually faster than VB"
|> : |> You will get some much mail your computer will explode and kill you.
|>
|> : VB is a GUI builder, not a interpreter. I'm not so nuts that I don't
|> : understand the difference.
|>
|> It's *BOTH* a GUI builder *AND* and interpreter. You probably would'nt
|> get flamed so much if you were not fast and loose with your postings.
No, it's not. A GUI builder allows you to interactively build interfaces
without writing code. I have to write code to use Tcl/Tk, and while there
may be a GUI builder available for it, wish is not one.
Don Clayton
My mistake, I misread. Yes VB is a GUI builder and interpreter. I meant to
state that there was no comparison between VB and Tcl/Tk because VB is a GUI
builder and Tcl/Tk is not.
Sorry,
Hume C.L. Smith
DC> My mistake, I misread. Yes VB is a GUI builder and interpreter. I meant to
DC> state that there was no comparison between VB and Tcl/Tk because VB is a GUI
DC> builder and Tcl/Tk is not.
so how about comparing VB and XF then.
--
Hume Smith hcls...@ra.isisnet.com
"Oh no, I hate the way they drew me in that episode.
(I hate the way they drew me in this episode, too.)" Babs
Don Clayton
In article <STU7X93.95...@bmerhaeb.bnr.ca>, stu...@bmerhaeb.bnr.ca (Hume C.L. Smith) writes:
|> >>>>> "DC" == Don Clayton <dcla...@bnr.ca> writes:
|>
|> DC> My mistake, I misread. Yes VB is a GUI builder and interpreter. I meant to
|> DC> state that there was no comparison between VB and Tcl/Tk because VB is a GUI
|> DC> builder and Tcl/Tk is not.
|>
|> so how about comparing VB and XF then.
Sure, but I haven't used XF. Of course the comparison shouldn't be one sided, so
you should also compare ObjectCenter and ViewCenter which are a C++/Motif interpreter
and GUI builder.
Personally I use Softbench/Purify (after tying both Tcl/Tk and ObjectCenter), but to
each their own.
Nenad Ivezic
I would like to see this discussion take place on this (or some other bboard),
if at all possible.
Thanks.
- Nenad Ivezic
Civil and Environmental Engineering Department
Carnegie Mellon University
Pittsburgh, PA 15213
Mike Eggleston
I'd be very interested in discussing how you integrated tcl and your
constraint engines.
Mine
--
--
Mike Eggleston Walker Financial, Inc.
(817)732-0398 3909 Hulen Street
(817)735-1726 (FAX) Fort Worth, Texas 76107
Only my opinions.
John Goodsen
I would like to see this discussion take place on this (or some other bboard),
if at all possible.
Possibly you are not familiar with Tcl enough to know why it is relevant.
This conversation is very relevent to comp.lang.tcl. The discussion
is based upon taking advantage of Tcl variable monitoring as the integration
point into a general purpose constraint engine. Don't move the conversation
to another newsgroup!
Marius Jurgutis
> Don Clayton (dcla...@bnr.ca) wrote:
> : I don't want to code the toolset I've chosen to develope in (a must if you
> : use Tk). I've never had to with Motif.
> Lets see, do you have to field complaints from users to figure out why
> when they push the middle mouse button a little running man comes up
> and locks up their session? Do you use text widgets with auto sizing
> where the text is set before the widget is managed? I'm sorry, but
> I have had to go in to the MOTIF source and find workarounds to disgusting
> bugs, not fixes mind you, workarounds because even if I could fix the
> code, I can't put that fix in the Motif that is compiled into my application
> without paying extortion to OSF.
> -Ron