Are Tcl and Tk "inseparable"?
Surgeon
I am a Ruby user and probably I will have to use Tk in order to get
nice GUIs. Now, the problem is that: Learning a new language (Ruby) is
already time consuming enough. Do I have to learn also Tcl in order to
use Tk? Can't I use Tk alone? (Umm, well, not so alone, together with
Ruby, I mean)
Thanks in advance.
Michael Schlenker
The Perl community ripped Tcl from their PerlTk package, but it was just
slower, less up to date and more memory hungry. So in principle one
could separate Tk from Tcl, but its not worth it.
But your question goes in a different direction:
The Ruby/Tk binding wraps Tk into a set of Ruby Objects, so you are
using Ruby when you create Ruby/Tk programs. So you do not need to learn
Tcl to be able to use RubyTk, but it could help in translating advanced
Tk examples found on the Tcl'ers wiki (http://wiki.tcl.tk).
But you have to learn the options and functions of your libraries, as
you have to do for any other package.
Michael
Victor Wagner
It is definitely possible to separate Tk from Tcl.
There is Perl-Tk which don't use tcl interpreter to do callbacks and
such things - everything is rewritten on Perl. As far as I know, once
there was Scheme-Tk which was done same way.
Python people are more lazy - they just compile Tcl interpeter into
Python interpreter and call result Tkinter. It has obvois benefit that
it allows one to use Tcl/Tk extensions in Python/Tkinter. But typically
one don't need to know Tcl in order to use Python/Tkinter. Everything
can be done on Python, unless you want to do some very clever things,
such as incorporate some Tcl-based extension.
I don't know how Ruby bindings for Tk looks like, but in any case if
such bindings exists, you can use Tk from Ruby without using any other
language than Ruby. At least for simple things.
--
It's documented in The Book, somewhere...
-- Larry Wall in <10...@jpl-devvax.JPL.NASA.GOV>
Earl Grieda
"Surgeon" <biyok...@gmail.com> wrote in message
news:1136810351.2...@o13g2000cwo.googlegroups.com...
Why waste time learning Ruby, Python, Perl, etc. when you can do everything
easier, faster, and more reliably in Tcl?
Robert Hicks
My god man! Do you want to start a war! lol
Robert
Bryan Oakley
The original poster already knows Ruby. If they already know a language
that works for them there's no real reason to learn Tcl (*)
Except in this case, since the original poster has to use Tk. As others
have pointed out, other languages have bindings for Tk but it probably
helps to know a little Tcl, too. At least enough to be able to read the
Tk man pages.
As for doing things in Tcl "faster, easier and more reliable", that's
rather debatable but we'll let those other newsgroups sort it out.
Language wars are so '90s.
(*) except to become a better programmer :-)
Gerald W. Lester
Knowing multiple languages tends to make for a better
programmer/analysts/whatever.
No as to which one to use in any give situation ...
Surgeon
As a matter of fact, I heard Tcl so many times but I never tried it.
My area of interest is artificial intelligence. I tried C++, Java,
Prolog and Lisp. You know C++ and Java so no need to mention them
again. Prolog was a total culture shock. Lisp was good but I got tired
with thos parantheses and prefix notion.
Finally I decided to try Python and very liked it. As you can guess, I
thought "that's enough, I don't want to try another language, now I
must concentrate on my main domain".
One day, a Ruby user told me that "try Ruby a weekend and make your
decision". I did this half-heartedly. But when I saw Ruby I said
"That's it!".
Python is clean, Ruby is cleaner.
Studying Python is enjoyable, studying Ruby is more enjoyable.
Python is good, Ruby is better, IMHO.
But I am not a Tcl enemy ;-D because I don't know anything about it. I
love Ruby, that's all.
Lisa Pearlson
set iq 200
set brain [createneurons $iq]
set answer [askanyquestion "who's your daddy?"]
:)
"Surgeon" <biyok...@gmail.com> wrote in message
news:1136833555....@g44g2000cwa.googlegroups.com...
Donal K. Fellows
> One day, a Ruby user told me that "try Ruby a weekend and make your
> decision". I did this half-heartedly. But when I saw Ruby I said
> "That's it!".
>
> Python is clean, Ruby is cleaner.
> Studying Python is enjoyable, studying Ruby is more enjoyable.
> Python is good, Ruby is better, IMHO.
>
> But I am not a Tcl enemy ;-D because I don't know anything about it. I
> love Ruby, that's all.
The truth is that if you find something you *really* like, you should
stick with it. Programming's hard enough without doing it in a language
that doesn't suit.
Though you should probably try the different major paradigms out at some
point. If you know what C, Scheme, Lisp, Haskell and Prolog (plus your
favourite scripting language of course) are like and why they aren't
universal solutions, you'll be a much better programmer than if you
haven't tried them. This is because having seen all those different ways
of doing things changes how you think about writing code, making you
better able to see different ways of doing stuff.
And it's fun too. ;-)
Donal.
Neil Madden
>
> My area of interest is artificial intelligence. I tried C++, Java,
> Prolog and Lisp. You know C++ and Java so no need to mention them
> again. Prolog was a total culture shock. Lisp was good but I got tired
> with thos parantheses and prefix notion.
AIs my area too. Prolog and Lisp are both widely used, and good
languages. Prolog is a culture shock, but one which is well worth going
through.
If you don't like prefix notation, then Tcl probably isn't for you as it
too is prefix. Less parentheses, though, and a few bits of sugar over Lisp.
Things I tend to look for in languages for AI work are that they be
multi-paradigm (i.e. allowing you to code in functional, OO, rule-based
etc ways) and that they provide some means to extend the language with
new syntactic constructs, e.g. via macros or higher-order functions or
some other means (Tcl's basic procs are very flexible). Generally these
are features I look for in a language for *any* work.
> One day, a Ruby user told me that "try Ruby a weekend and make your
> decision". I did this half-heartedly. But when I saw Ruby I said
> "That's it!".
Glad you've found a language you like. Ruby is quite a nice language. I
like the notation for blocks/lambdas (as in Smalltalk).
Other languages you might like to look at:
Mercury (http://www.cs.mu.oz.au/research/mercury/): Basically a much
updated Prolog.
Oz (http://www.mozart-oz.org/): A new language with lots of interesting
features. It is a distant descendant of Prolog in that it uses
assign-once logic variables, and can do back-tracking search etc. Based
on constraint programming, and with cool ideas on concurrency etc. (The
book "Concepts, Techniques, and Models of Computer Programming" by the
Oz people is a great book.
Haskell (http://www.haskell.org/): Probably has the most language
research buzz around it. A pure (no side-effects) non-strict functional
language. This is another culture shock worth going through. Encourages
equational reasoning.
If you like Haskell and Oz, then you might also be interested in Alice
ML (http://www.ps.uni-sb.de/alice/) which is a strict functional
language (based on Standard ML, another major language family) but with
several of the features from Oz added.
-- Neil
Donal K. Fellows
> Haskell (http://www.haskell.org/): Probably has the most language
> research buzz around it. A pure (no side-effects) non-strict functional
> language. This is another culture shock worth going through. Encourages
> equational reasoning.
Oh, Haskell has side effects, but you've got to encapsulate them within
the right monad. The reason I recommend looking at it is that it is a
(largely) lazy programming language, in that it only computes a value
when it actually needs it. Makes it very natural to think in terms of
infinite data structures, which is quite different to just about any
other programming language most people have tried, where infinite stuff
is to be avoided like the plague.
Donal.
Neil Madden
> Neil Madden wrote:
>
>> Haskell (http://www.haskell.org/): Probably has the most language
>> research buzz around it. A pure (no side-effects) non-strict
>> functional language. This is another culture shock worth going
>> through. Encourages equational reasoning.
>
>
> Oh, Haskell has side effects, but you've got to encapsulate them within
> the right monad.
Well, that depends on your point of view. With monads you actually build
a sequence of actions (i.e. an imperative program) in a side-effect free
way. This sequence of actions is the returned as the result of the
program and executed. e.g. in the code:
main = do
line <- getLine
putStrLn line
the monadic "do" block creates an abstract operation (of type "IO ()")
that will perform an action (getting a line from stdin and then echoing
back to stdout) and returns this as the result of "main". So in Haskell
itself there are no side-effects, but instead you write a program that
builds a program that does use side-effects. This is related to
laziness, as the actions returned are unevaluated and (for the IO monad
at least) there is no way to "force" the actions to get their value.
> The reason I recommend looking at it is that it is a
> (largely) lazy programming language, in that it only computes a value
> when it actually needs it. Makes it very natural to think in terms of
> infinite data structures, which is quite different to just about any
> other programming language most people have tried, where infinite stuff
> is to be avoided like the plague.
Yeah, laziness is well worth experiencing. SICP explains [1] quite well
the difference between lazy and strict evaluation by showing the
possible design choices when writing an interpreter. Haskell is actually
non-strict (or call-by-need) rather than lazy (call-by-name) as it only
ever evaluates expressions once -- the result is "memoized" to avoid
recomputing it in future. Tcl supports a form of call-by-name laziness
via {} which allows the caller to package up an unevaluated expression
and pass it to a procedure unevaluated (useful for conditionals and
other custom control structures).
Simon Peyton Jones (one of Haskell's creators) has called laziness a
"hair-shirt" [2] that can be a pain, but keeps Haskell pure (laziness
and side-effects really don't mix well). Oz and Alice ML are strict by
default, but have support for optional laziness, e.g. (in Alice ML):
- fun lazy enumFrom n = n :: enumFrom (n+1);
val enumFrom : int -> int list = _fn
- val nats = enumFrom 1;
val nats : int list = _lazy
- List.take (nats, 10);
val it : int list = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
- nats;
val it : int list = 1 :: 2 :: 3 :: 4 :: 5 :: 6 :: 7 :: 8 :: 9 :: 10 :: _lazy
Alice is a really nice language. Laziness there is done via "futures"
which are also used for concurrency [3] and are one of the coolest new
language design features I've heard about for a while.
[1] http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-27.html#%_sec_4.2
(see also
http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/ for
video lectures, but that site is forever bogged down serving GB-size
video files...)
[2]
http://research.microsoft.com/Users/simonpj/papers/haskell-retrospective/
[3] http://www.ps.uni-sb.de/alice/manual/futures.html
-- Neil (rambling again!)
David N. Welton
> Simon Peyton Jones (one of Haskell's creators) has called laziness a
> "hair-shirt" [2] that can be a pain, but keeps Haskell pure (laziness
> and side-effects really don't mix well). Oz and Alice ML are strict by
> default, but have support for optional laziness, e.g. (in Alice ML):
I had the opportunity to meet that guy at a conference, and while
Haskell isn't my cup of tea, he was a great speaker, interesting to talk
to, and a nice, approachable person as well. Highly recommended, in
other words.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
tony summerfelt
<eASQWER...@VADFWEFyahoo.comical> wrote:
>Why waste time learning Ruby, Python, Perl, etc. when you can do everything
>easier, faster, and more reliably in Tcl?
ordinarily i'd agree with you. except for the 'easier, faster, and
more reilably' part when it comes to threading.
i find doing everything with threading in ruby easier, faster and
more reliable then hte rest of the languages.
the main reason i use tcl/tk is that there's no quicker way to write a
gui app.
if tk syntax could be used in ruby, i would have no wishlist :)
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Eric Junkermann
<snow...@hotmail.com> writes
But why do you _need_ threading?
--
Eric Junkermann
Jeff Hobbs
> On Mon, 09 Jan 2006 17:44:15 GMT, "Earl Grieda"
> <eASQWER...@VADFWEFyahoo.comical> wrote:
>
>> Why waste time learning Ruby, Python, Perl, etc. when you can do everything
>> easier, faster, and more reliably in Tcl?
>
> ordinarily i'd agree with you. except for the 'easier, faster, and
> more reilably' part when it comes to threading.
>
> i find doing everything with threading in ruby easier, faster and
> more reliable then hte rest of the languages.
>
> the main reason i use tcl/tk is that there's no quicker way to write a
> gui app.
>
> if tk syntax could be used in ruby, i would have no wishlist :)
Well, you have Ruby/Tk, but as to threading ... what's wrong
with what Tcl/Tk provides? Having used several other languages
threading, I find Tcl's to be very nice. In fact, I converted
a Ruby/Tk user over to Tcl/Tk based on threading simplicity the
last time I went on a query to learn more about Ruby/Tk's
internals (which was not my intention, but an interesting side
effect). Furthermore, Tcl gives you true native OS threads
(very scalable), not user level threads.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
Eckhard Lehmann
Eric Junkermann wrote:
> But why do you _need_ threading?
E.g. for non-blocking GUI-apps...
But - Tcl's threading model is quite ok for that (well, I don't know of
Ruby's).
Eckhard
Darren New
> But why do you _need_ threading?
When you're interfacing to something that blocks and you don't want to
block. E.g., accessing a database via a library that blocks, and you
want to serve multiple connections at once.
--
Darren New / San Diego, CA, USA (PST)
Is it OK to be obsessive-compulsive
as long as you're not disordered?
tony summerfelt
wrote:
>Eric Junkermann wrote:
>> But why do you _need_ threading?
two loops which have nothing to do with each other, use different
resources, but must execute before the rest of the code does. makes
sense to put both in a seperate thread.
i often have to iterate over large log files with more than one
operation performd on different lines. while they COULD be in one
loop, it doesn't make sense or readability later on.
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Uwe Klein
Bryan Oakley
If that's all you're doing, it's relatively easy to do without threads.
Do what you're comfortable with, of course, but realize that threads are
rarely needed with Tcl/Tk, even for apps which have to process data from
several sources "simultaneously".
--
Bryan Oakley
http://www.tclscripting.com
Robert Hicks
informative.
Robert
Bryan Oakley
> I just noticed your "tclscripting" sig. I visited it. Very cool and
> informative.
Thank you.
Gerald W. Lester
> On 17 Feb 2006 14:35:03 -0800, "Eckhard Lehmann" <eck...@web.de>
> wrote:
>
>
>
>>Eric Junkermann wrote:
>
>
>>>But why do you _need_ threading?
>
>
> two loops which have nothing to do with each other, use different
> resources, but must execute before the rest of the code does. makes
> sense to put both in a seperate thread.
>
> i often have to iterate over large log files with more than one
> operation performd on different lines. while they COULD be in one
> loop, it doesn't make sense or readability later on.
You do realize, unless you are on a multiprocessor system and the log files
are on different spindles (maybe even on different I/O channels), you may as
well process one file then the other -- threads here only give a false sense
of parallelism.
Before going to threading, one really needs to analyze, at the hardware
level, what can and can not be done in parallel.
tony summerfelt
<uwe_klein_...@t-online.de> wrote:
>What about fileevent, trace .. all that event stuff?
>http://wiki.tcl.tk/1904
not nearly as much fun :)
that link seemed to lean towards operstions that would affect each
other...i was referring to looping operations that needed to be
performed but had nothing to do with each other...
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
tony summerfelt
<oak...@bardo.clearlight.com> wrote:
>If that's all you're doing, it's relatively easy to do without threads.
that was just an example. sometimes i'm not working with files at all,
just a large hash that i need to extract information from for
different purposes.
>Do what you're comfortable with, of course, but realize that threads are
>rarely needed with Tcl/Tk, even for apps which have to process data from
>several sources "simultaneously".
after reading: http://wiki.tcl.tk/880
fileevent doesn't sound safe enough compared to using threads with
mutex's
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
tony summerfelt
<Gerald...@cox.net> wrote:
>You do realize, unless you are on a multiprocessor system and the log files
>are on different spindles (maybe even on different I/O channels), you may as
>well process one file then the other -- threads here only give a false sense
>of parallelism.
>Before going to threading, one really needs to analyze, at the hardware
>level, what can and can not be done in parallel.
is that with tcl/tk?
i have a project in ruby that uses threading. separate methods each
taking various amounts of time. running them one at a time gives me a
total time of about 15 seconds.
running each in it's own thread they finish around the 5 second mark
(ie. time of the longest thread). this is on an xp box with a single
cpu.
i realize that it's only a savings of 10 seconds :) but that starts to
add up if you run it several dozen times...
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org
Gerald W. Lester
> On Sat, 18 Feb 2006 21:23:54 -0600, "Gerald W. Lester"
> <Gerald...@cox.net> wrote:
>
>> You do realize, unless you are on a multiprocessor system and the log files
>> are on different spindles (maybe even on different I/O channels), you may as
>> well process one file then the other -- threads here only give a false sense
>> of parallelism.
>
>> Before going to threading, one really needs to analyze, at the hardware
>> level, what can and can not be done in parallel.
>
> is that with tcl/tk?
No it is with anything, please read the detailed remarks below.
> i have a project in ruby that uses threading. separate methods each
> taking various amounts of time. running them one at a time gives me a
> total time of about 15 seconds.
>
> running each in it's own thread they finish around the 5 second mark
> (ie. time of the longest thread). this is on an xp box with a single
> cpu.
>
> i realize that it's only a savings of 10 seconds :) but that starts to
> add up if you run it several dozen times...
If you are not running on a multiprocessor system and your log files are on
the same disk and you are not accessing resources remote to your machine,
then I really don't see where the time reduction can be coming from. Of
course if part of your processing involves doing things like a lookup of an
IP address from a name (or the reverse) then you are waiting on remote
resources (the DNS servers) and using either threads or event driven
programming can reduce the clock time to process everything.
A single processor only processes one instruction at a time, the disk can
only be transferring one block at a time -- and most systems implement read
ahead caching so that the next data block is ready for you before you need it.
Darren New
> fileevent doesn't sound safe enough compared to using threads with
> mutex's
What do you think is unsafe? No fileevent is going to run while another
fileevent is running, unless you ask explicitly for that behavior (by
invoking "update"). Fileevents are *far* safer than threads and mutexes
in a more traditional language. (Threads are pretty darn safe in Tcl,
too. Not sure why you'd even need a mutex in Tcl's implementation of
threads. I certainly never did.)
tony summerfelt
<Gerald...@cox.net> wrote:
>If you are not running on a multiprocessor system and your log files are on
>the same disk and you are not accessing resources remote to your machine,
sometimes they're on the same drive, sometimes not.
>A single processor only processes one instruction at a time,
when i was taking a cs course in college back in the '80's that was
one of the first things we learned. which is/was important when
you're designing microprocessor based circuits...
>only be transferring one block at a time -- and most systems implement read
>ahead caching so that the next data block is ready for you before you need it.
entire log files are read in to hashes, various operations performed
on the hashes, results written out to several places. in the middle of
any of those operations the log files get's written to, needs to re-
read again. ad nauseum...
having the various operations (which have nothing to do with reading
the log files once they are in a hash) as performed procedurally just
slows down the whole program. on top of that it doesn't do the job the
client asked for, but that's beside the point.
it shouldn't make any difference on a single cpu, but it does.
if nothing else threading lets me write code that makes more sense for
operations that should be happening at the "'same time".
other than that i don't know what to tell you :)
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org