It may be too late, but I was just reading an article about the One
Laptop Per Child project, and was wondering whether anyone here had
considered contacting the project and pointing out how well Tcl might
fit into that domain. They are building extremely low cost hardware, a
hardened Linux OS, and building software that can be used for
education.
It seems to me that having a really decent, multilingual dynamic
language would be a really useful thing.
Hello Larry
i agree with your idea that Tcl/Tk is extremely well adapted for
teaching programming to young people. A few years ago Rice
university was teaching to young people with Scheme and they
wrote an IDE (well functionning) for windows. Since i met
Tcl/Tk i wondered why utilizing Scheme when these people
probably knew about Tcl/Tk ??
friendly
jerome
While I don't know the specifics at Rice, I do know that the book
Structure and Interpretation of Computer Programs in which the examples
are written in Scheme. That book seems to be be highly regarded.
Perhaps that influenced such decisions
Just curious -- and please *no* flame wars. I simply want to get up to speed!
--
duke
*) It is badly publicized. There are almost never any Tcl people or
presentations at conferences anymore.
*) Tk languished for years, and gained a reputation for being old and
ugly looking, not to mention poorly integrated with modern Linux
desktops (which, alongside Macs, is where a lot of the 'buzz' is), which
rubbed off on Tcl.
*) Standard Tcl on many Linux systems is underpowered compared to the
competition - it has no readline support, no standard library, doesn't
have many useful packages (thread), and so on.
*) People are naturally curious about 'new' things, so it's difficult to
keep people interested in something "old".
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
> tutorials) I find Tcl charming as well as quite capable for most applications.
It is, indeed.
> What happened to its reputation?
It seems to me that Tcl has always had problems with its reputation.
Probably, it's the prefix notation and/or the "everything is a string"
paradigm. Most Developers are obviously addicted to C like languages.
> Is it simply that Java and OOP have gotten
> all the attention from the IT/IS managers?
Yes, if you want to start something in Tcl, most people (coworkers,
managers etc.) are sceptical immediately. If you like to start the same
thing e.g. in Java, they are on your site - although it probably will
take you 4-5 times as long (depending on experience even more) and is
partly much more complicated and less readable code.
A pity that... and pure psychological reasons. There is no technical
reason to abandon Tcl.
> Just curious -- and please *no* flame wars. I simply want to get up to speed!
With Tcl you will get up to speed immediately. And you will stay up to
speed even if you don't develop fulltime. That's the good news - you
will see...
And we are here to help you if you get stuck somewhere ;-).
Eckhard
I just might have found a home.... Thanks!
--
duke
> *) Tk languished for years, and gained a reputation for being old and
> ugly looking, not to mention poorly integrated with modern Linux
> desktops (which, alongside Macs, is where a lot of the 'buzz' is), which
> rubbed off on Tcl.
>
Surely *this* can be fixed as well! After all, is not Tk simply an IDE from
which to work in? It really has nothing to do with Tcl's functionality, does
it? How can we fix the integration thing?
> *) Standard Tcl on many Linux systems is underpowered compared to the
> competition - it has no readline support, no standard library, doesn't
> have many useful packages (thread), and so on.
>
By "the competition", I take it you mean ActiveState? *That's bad!* What I
mean is -- Tcl for the various Unices should be able to go toe-to-toe, as an
advocacy thing for *both* Unix and Tcl.
> *) People are naturally curious about 'new' things, so it's difficult to
> keep people interested in something "old".
>
I agree! So what kick-butt *new* Tcl thing can we as a group, come up with, to
wow "geek-dom"? Tcl can do it, all it takes is the will and an idea! How can
I help? Later....
--
duke
One reason that the language seems to be dead is the unablilty to
market products that were written in it or for it such as some fancy
IDE or program that can be marketed.
There is not a snappy IDE such as Visual Studious for which a company
might make a bundle on, or some game such as WOW.
Tcl on the whole is a very good tool building enviroment.
There are, but IMHO the new things in the language are mainly of
interest to the existing user community.
> > *) Tk languished for years, and gained a reputation for being old and
> > ugly looking, not to mention poorly integrated with modern Linux
> > desktops (which, alongside Macs, is where a lot of the 'buzz' is), which
> > rubbed off on Tcl.
> >
> Surely *this* can be fixed as well! After all, is not Tk simply an IDE from
> which to work in? It really has nothing to do with Tcl's functionality, does
> it? How can we fix the integration thing?
>
Actually, it's not an IDE - it's a graphics toolkit. It makes it
drop-dead simple to create GUI programs in Tcl. It is especially easy
to wrap a command-line program with a GUI. I love it, and I think it's
not that hard to make it look "nice". With Tile it's now possible to
make it look "native", too.
> > *) Standard Tcl on many Linux systems is underpowered compared to the
> > competition - it has no readline support, no standard library, doesn't
> > have many useful packages (thread), and so on.
> >
> By "the competition", I take it you mean ActiveState? *That's bad!* What I
> mean is -- Tcl for the various Unices should be able to go toe-to-toe, as an
> advocacy thing for *both* Unix and Tcl.
>
I suspect that the "competition" in this case is with other scripting
languages like Perl. The standard distributions of Perl include
powerful libraries. Tcl *has* powerful libraries, but they aren't in
standard linux distros. It creates a real hurdle.
I also think it doesn't help that books about Perl are shelved in the
"programming language" section in bookstores, while books about Tcl are
shelved in the "Unix" section. It gives the impression that Tcl is a
comfortable old Unix utility, like sed or awk, rather than a flexible
and useful modern language.
> > *) People are naturally curious about 'new' things, so it's difficult to
> > keep people interested in something "old".
> >
>
> I agree! So what kick-butt *new* Tcl thing can we as a group, come up with, to
> wow "geek-dom"? Tcl can do it, all it takes is the will and an idea! How can
> I help? Later....
Well, Tcl *is* old (even though it's also modern and up-to-date), and
that can't be changed. An all-new FORTRAN is still FORTRAN, and a
batteries-included Tcl is still Tcl. I interpreted this comment as
covering the situation in which a young and amiable developer with a
cool nickname (say, something like "Matz") comes up with a really nice
and useful new language (say, something like "Ruby") :-) People are
more likely to go and look into that than to look and see what is being
added to ver 8.5 of Tcl, no matter how new and nifty it is. (And it
is!)
Meanwhile, applications of Tcl keep appearing with astonishing
regularity at the Tcler's Wiki (http://wiki.tcl.tk/)
> --
> duke
I sometimes think, though, that the real problem with Tcl is that the
user community is nice, helpful, and open to other languages. It lacks
absolutists and evangelists. (Of course, that's also one reason I like
it so much.)
Just my 2 cents.
Eric
Another possible factor is that if a mainstream program *were* written
in Tcl, you might not know it. It's possible to distribute an
executable with the Tcl script wrapped up in it. This is not the case,
for example, with Java or .NET, where you *know* you have just
installed a Java or .NET program.
Also, I have a hunch as to why visual IDEs for Tcl/Tk come and go, but
none seem to stick. In short, it's because there's no need for them. I
ready a history of Visual Basic and its famous IDE (can't remember the
source, sorry), and basically the reason why the IDE appeared is
because you had to specify the precise location, *in pixels* of each
widget. This was a huge headache without a visual window building tool.
It is so easy to make Tk apps that after a little practice, a visual
tool can actually be a hindrance rather than a help.
Eric
True enough!
>> *) Tk languished for years, and gained a reputation for being old and
>> ugly looking, not to mention poorly integrated with modern Linux
>> desktops (which, alongside Macs, is where a lot of the 'buzz' is), which
>> rubbed off on Tcl.
>>
>Surely *this* can be fixed as well! After all, is not Tk simply an IDE from
>which to work in? It really has nothing to do with Tcl's functionality, does
>it? How can we fix the integration thing?
No, Tk is THE Tcl technology for doing graphics. Until 8.5 is released, if
you want your Tcl to ANYTHING graphical, you use Tk.
>> *) Standard Tcl on many Linux systems is underpowered compared to the
>> competition - it has no readline support, no standard library, doesn't
>> have many useful packages (thread), and so on.
>>
>By "the competition", I take it you mean ActiveState? *That's bad!* What I
>mean is -- Tcl for the various Unices should be able to go toe-to-toe, as an
>advocacy thing for *both* Unix and Tcl.
At the risk of putting words in David's mouth, I'm going to say, "no", he
does NOT mean ActiveState (at least not ActiveState Tcl). ActiveState Tcl is
one of the reasons Tcl is happily chugging along, as far as I can tell. I
_THINK_ David means perl, python, ruby, etc.
MH
Ugh. I'm simply wrong. I mixed my messages, obviously; it's
clear here that David was talking about Ruby, Perl, ... as
the competition (although, as Kevin and others of us have
pointed out many times, in fact those languages do NOT have
the cool threading, readline, ... they appear to have).
> I sometimes think, though, that the real problem with Tcl is that the
> user community is nice, helpful, and open to other languages. It lacks
> absolutists and evangelists. (Of course, that's also one reason I like
> it so much.)
QOTW?
> Actually, it's not an IDE - it's a graphics toolkit. It makes it
> drop-dead simple to create GUI programs in Tcl. It is especially easy
> to wrap a command-line program with a GUI. I love it, and I think it's
> not that hard to make it look "nice". With Tile it's now possible to
> make it look "native", too.
I stand corrected! After I finish the Tcl tutorial, I'll be looking at Tk for
sure.
[snip]
> languages like Perl. The standard distributions of Perl include
> powerful libraries. Tcl *has* powerful libraries, but they aren't in
> standard linux distros. It creates a real hurdle.
Is there a reason why the standard Linux distros don't include the libraries?
Be-that-as-it-may, it seems to me that it should not make a difference one way
or another if these libraries are easily and resdily available -- like Perl
modules at CPAN, e.g. Is there anything that we can do as a community to
mitigate this unfortunate oversight?
>
> I also think it doesn't help that books about Perl are shelved in the
> "programming language" section in bookstores, while books about Tcl are
> shelved in the "Unix" section. It gives the impression that Tcl is a
> comfortable old Unix utility, like sed or awk, rather than a flexible
> and useful modern language.
Maybe a few emails to Indigo, Chapters, et al might be of some help?
>> > *) People are naturally curious about 'new' things, so it's difficult to
>> > keep people interested in something "old".
>> >
>>
>> I agree! So what kick-butt *new* Tcl thing can we as a group, come up with, to
>> wow "geek-dom"? Tcl can do it, all it takes is the will and an idea! How can
>> I help? Later....
>
> Well, Tcl *is* old (even though it's also modern and up-to-date), and
> that can't be changed. An all-new FORTRAN is still FORTRAN, and a
> batteries-included Tcl is still Tcl. I interpreted this comment as
> covering the situation in which a young and amiable developer with a
> cool nickname (say, something like "Matz") comes up with a really nice
> and useful new language (say, something like "Ruby") :-) People are
> more likely to go and look into that than to look and see what is being
> added to ver 8.5 of Tcl, no matter how new and nifty it is. (And it
> is!)
Yup! I read the comment the same way! All I was trying to say was, that in
spite of its age, it seems to me that Tcl still has the horsepower to *wow*
the socks off "geekdom" and regain the stature that it appears to richly
deserve. The trick is to come up with project that will *make* folks pay
attention. What do you think?
> I sometimes think, though, that the real problem with Tcl is that the
> user community is nice, helpful, and open to other languages. It lacks
> absolutists and evangelists. (Of course, that's also one reason I like
> it so much.)
and I hope that the community *never* changes from this attitude. The blatant
arragance of *a lot* of participants in the "competitions' " newsgroups is
one of the reasons I went searching for another language to adopt. Having said
that, I'm certainly *not* opposed to courteous and respectful advocacy. I also
think that the *best* advocacy is performance and functionality. I'm sure that
Tcl can sell itself once again -- its up to all of us to make it so.
Thanks for your thoughts. Later...
--
duke
Yes it is quite capable for most applications, about the only thing that I'd
avoid using it for is *heavy* numeric computation.
> What happened to its reputation? Is it simply that Java and OOP have gotten
> all the attention from the IT/IS managers?
The latest buzz words get the attention, plus Java is much closer to the
C/C++ that a lot of the manager grew up with.
BTW, Tcl has several OO extensions if you feel you really must do OOP -- I
do believe all of the different types/models of OO are represented (Java
only has one OO model).
> Just curious -- and please *no* flame wars.
Attempts to start a flame war on c.l.t mostly get met with people quickly
ignoring the post. We pride ourselves on a very civil newsgroup with a very
high signal to noise ration.
> I simply want to get up to speed!
Post questions here, people will assist -- be warned sometimes the
assistance may be of the form "read this man/help page" or try it in the
"interactive shell". Believe it or not, this is helpful advise and not
people attempting to get rid of you -- you will tend to learn more faster.
As a group we have a lot of experience on bring people up to speed the
faster way if they will let us lead them.
You may also want to check out http:://wiki.tcl.tk/tkchat
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
> On 2006-10-16, Larry W. Virden <lvi...@gmail.com> wrote:
>
>>For years, there has been the debate concerning marketing of Tcl, Tcl's
>>"dying" reputation, etc.
>>
>
> I'm a newbie...and I'm curious -- why has Tcl fallen from grace? I'm *not*
> a professional programmer, nor a young student, but just a middle-aged geek
> wannabe. I've come over from Perl, and so far (3 days worth of online
> tutorials) I find Tcl charming as well as quite capable for most applications.
> What happened to its reputation? Is it simply that Java and OOP have gotten
> all the attention from the IT/IS managers?
>
In my opinion, the ... less elegant systems will generate more
traffic in online forums and more pages in bookstores because
the learning curve is steeper for them. With Tcl, it's close to
an order of magnitude shorter, so there's less chat about it.
And I'm not convinced, from an evolutionary perspective, that
this is not in Tcl's long term survival benefeit.
> Just curious -- and please *no* flame wars. I simply want to get up to speed!
> --
> duke
--
Les Cargill
On Nov 21, 1:18 am, "dinkalopo...@gmail.com" <dinkalopo...@gmail.com>
wrote:
> There is not a snappy IDE such as Visual Studious for which a company
> might make a bundle on, or some game such as WOW.
There is a try to make a "snappy" IDE. Far from feature complete but
useful and stable (I hope) in the existing functionality:
http://www.tloona.tk/
It doesn't contain a visual building tool for Tk and never will (unless
someone dives into that and provides some code). The main focus is the
management, development and deployment of big Tcl/Tk and Itcl projects.
Eckhard
That's a good point. It is very easy to install a Tcl/Tk package, but
not as easy as dropping something in from CPAN, and it doesn't offer
the "one-stop shopping" of CPAN. That should be doable.
> >
> > I also think it doesn't help that books about Perl are shelved in the
> > "programming language" section in bookstores, while books about Tcl are
> > shelved in the "Unix" section. It gives the impression that Tcl is a
> > comfortable old Unix utility, like sed or awk, rather than a flexible
> > and useful modern language.
>
> Maybe a few emails to Indigo, Chapters, et al might be of some help?
Maybe so. I think it's the publishers who set the categories.
>
> >> > *) People are naturally curious about 'new' things, so it's difficult to
> >> > keep people interested in something "old".
> >> >
> >>
> >> I agree! So what kick-butt *new* Tcl thing can we as a group, come up with, to
> >> wow "geek-dom"? Tcl can do it, all it takes is the will and an idea! How can
> >> I help? Later....
> >
> > Well, Tcl *is* old (even though it's also modern and up-to-date), and
> > that can't be changed. An all-new FORTRAN is still FORTRAN, and a
> > batteries-included Tcl is still Tcl. I interpreted this comment as
> > covering the situation in which a young and amiable developer with a
> > cool nickname (say, something like "Matz") comes up with a really nice
> > and useful new language (say, something like "Ruby") :-) People are
> > more likely to go and look into that than to look and see what is being
> > added to ver 8.5 of Tcl, no matter how new and nifty it is. (And it
> > is!)
>
> Yup! I read the comment the same way! All I was trying to say was, that in
> spite of its age, it seems to me that Tcl still has the horsepower to *wow*
> the socks off "geekdom" and regain the stature that it appears to richly
> deserve. The trick is to come up with project that will *make* folks pay
> attention. What do you think?
>
Fair enough! :-)
> One reason that the language seems to be dead is the unablilty to
> market products that were written in it or for it such as some fancy
> IDE or program that can be marketed.
How many products do you see advertise they are written in Perl, or for
that matter Python or Ruby? Java and .Net are about the only two
"environments" that software marketers bother to advertise . Why?
Because that's something that media outlets grab onto.
I agree that someone writing applications in Tcl will, often, be quite
happy with the results.
The period of time where Tcl was "in grace" was relatively small, due,
in my opinion, to the timing, which corresponded to the time when Java
began getting attention. And of course, the money behind pushing Java
was much greater.
Don't choose a programming language based on how popular it is, unless
you plan on having everyone else do your programming for you. If YOU
plan on programming, then pick a programming language that provides
what you need, in a manner that is comfortable and productive for you.
Many people complain about the look and feel of Tk - but despite the
popularity of Tk, Tk is not an essential part of Tcl. One can use other
toolkits with Tcl, if some other look and feel is desired.
Other people complain because other languages have larger initial
libraries than Tcl. Again, there are many libraries available for Tcl
developers. Yes, you have to download them. When I look at other
langauge environments, I see many examples of libraries that one has to
download for them as well.
The real need, in the Tcl community, is positive contributions from the
community. If more community members contribute bug reports,
enhancement reports, code for enhancements, as well as volunteer to
actually get involved in improving Tcl, it will continue to florish.
No I think he means on languages (Python, Perl, etc.) as competition.
Those two at least are usually "batteries included" installs.
I think at a minimum Tcl should install with tcllib (if it doesn't
already).
Robert
Maybe would could GPL Tcl and get Stallman to sing us praises like he
is doing with Java?
<ducks for cover>
Robert
Very few employers are looking for pure Tcl programmers. Through
postings in this newsgroup I found two employers (in California)
interested. Search agents on CareerBuilder, Dice, and Indeed, focused
on my area (Central NJ, but with a range broad enough to include NYC and
the NJ "Hudson Gold Coast" [Jersey City, Hoboken, etc., home to lots of
Wall Street back office operations, because it's just across the river
and a ten minute train ride away]) show lots of jobs for System
Administrators, Network Administrators, Configuration Control
Administrators, Build Administrators, et al., with Tcl/Tk and/or Expect
either required as an adjunct skill or listed as a "plus". I also see a
few postings for Electronic Design Engineers with Tcl experience as an
adjunct skill to make them better users of CAD/CAE/simulation tools.
I have some more general search agents that I glance at, and from those
I see that if I knew the language in question, I could find a good job
as a Perl programmer (especially hot is Perl with SQL), as a Java
Programmer (especially w/ SQL), and as a C++ programmer (but only with
deep OO skills, threading, STL, etc., and/or in conjunction with SQL).
Oh, and I saw two openings (both from the same employer) requiring Ada!
I currently have under consideration an oral job offer (awaiting
paperwork) to go back to doing embedded programming in C for a major
national consulting company. One regret is that I will be for the most
part leaving behind Tcl/Tk and this great community. It is truly the
easiest and best language I've encountered, though I admit I have a
narrow sample: lots of Tcl and C experience, lost of 25+ year old
Fortran experience, several assemblers, a bit of C++ experience, some
shell scripting (including awk), and a 4-day course in Java with no
followup practical experience.
--
Rich Wurth / rwu...@att.net / Rumson, NJ
> I've been in the job market about 7 weeks, and I have some
> observations about Tcl/Tk and skills marketability. Tcl in the market
> is mostly seen as an adjunct to some other career.
>
> Very few employers are looking for pure Tcl programmers.
[too-short list of opportunities omitted]
I left out another (dying) source of Tcl-as-adjunct skill, employers
looking to convert Vignette Story Server web sites to use the latest
Vignette release which replaces Tcl with some other language (Java, I
think).
> Maybe would could GPL Tcl and get Stallman to sing us praises like he
> is doing with Java?
Won't happen, even if Tcl were double-GPL...
> <ducks for cover>
Ever read this transcript of a Stallman-Speach...?
http://www.gnu.org/gnu/rms-lisp.html
"At the time, TCL was being pushed heavily for this purpose. I had a very
low opinion of TCL, basically because it wasn't Lisp. It looks a tiny bit
like Lisp, but semantically it isn't, and it's not as clean. Then someone
showed me an ad where Sun was trying to hire somebody to work on TCL to
make it the ``de-facto standard extension language'' of the world. And I
thought, ``We've got to stop that from happening.'' So we started to make
Scheme the standard extensibility language for GNU. Not Common Lisp,
because it was too large. The idea was that we would have a Scheme
interpreter designed to be linked into applications in the same way TCL was
linked into applications. We would then recommend that as the preferred
extensibility package for all Gnu programs."
Although I think, he is in many ways a great person and one of the most
important to free software... sometimes I really don't understand him...
Regards
Stephan
"Eckhard Lehmann" <eck...@web.de> wrote:
> It seems to me that Tcl has always had problems with its reputation.
> Probably, it's the prefix notation and/or the "everything is a string"
> paradigm. Most Developers are obviously addicted to C like languages.
>
> Yes, if you want to start something in Tcl, most people (coworkers,
> managers etc.) are sceptical immediately. If you like to start the same
> thing e.g. in Java, they are on your site - although it probably will
> take you 4-5 times as long (depending on experience even more) and is
> partly much more complicated and less readable code.
> A pity that... and pure psychological reasons. There is no technical
> reason to abandon Tcl.
>
> For some reason, the phrase "sees the world through bisque colored
> glasses" comes to mind...
How do you mean that?
Eckhard
Oh, I know. I was just goofin'.
Robert
> "At the time, TCL was being pushed heavily for this purpose. I had a very
> low opinion of TCL, basically because it wasn't Lisp. It looks a tiny bit
> like Lisp, but semantically it isn't, and it's not as clean. Then someone
> showed me an ad where Sun was trying to hire somebody to work on TCL to
> make it the ``de-facto standard extension language'' of the world. And I
> thought, ``We've got to stop that from happening.'' So we started to make
> Scheme the standard extensibility language for GNU. Not Common Lisp,
> because it was too large. The idea was that we would have a Scheme
> interpreter designed to be linked into applications in the same way TCL was
> linked into applications. We would then recommend that as the preferred
> extensibility package for all Gnu programs."
So where does Scheme stand today - is that any better than Tcl? No, imo
it's even worse.
> Although I think, he is in many ways a great person and one of the most
> important to free software... sometimes I really don't understand him...
In some aspects he seems to be slightly underexposed...
Eckhard
> In some aspects he seems to be slightly underexposed...
I should clarify how I mean that. He is of course not underexposed as
such.
But he seems to have a militant opinion against closed source and
commercial software distribution. This opinion, if pushed in that way,
is imo worse than commercial and closed source software licenses in
general. It's a bit short-sighted to say that closed source or
commercially licensed software is at all bad. Actually, most of the
commercial software is better quality than many GPL software projects
(which is no wonder).
So he could publish GPL software more as that what it is - an
alternative to commercial licensed software - rather than always raise
it above as the only truth on earth.
Sorry for being off topic ;-)
Eckhard
As well it should be; the purpose of programming is to solve a problem,
not to write a program. It's "those other languages" that have
the wrong attitude.
> I have some more general search agents that I glance at, and from those
> I see that if I knew the language in question, I could find a good job
> as a Perl programmer (especially hot is Perl with SQL), as a Java
> Programmer (especially w/ SQL), and as a C++ programmer (but only with
> deep OO skills, threading, STL, etc., and/or in conjunction with SQL).
Hmmm. If you're doing any programming for a large organization, SQL
is pretty much a necessary skill, whatever language you use. A lot of
organizations resort to C++ only when they've outgrown a scripting
language (usually VB), and so deep OO skills or threading are likely
to be needed. And Perl, well, I've done Perl programming. I wonder
what would have become of Perl if Dan LaLiberte hadn't thrown in
a few Perl demo scripts with the first release of NCSA httpd that
supported CGI.
A lot of us sell ourselves as C/C++ programmers (with skills to match)
and then treat Tcl as this really cool porting library that happens to
come with a scripting language. Oh yeah, and well, why not replace the
config files with scripts? Oh, you want another GUI? Well, if I
use VC++ or Qt, I'll have a prototype to show you in two weeks, would
you like to see a Tcl/Tk/Tile mockup this afternoon? Oh, by the way,
the mockup works... what's that you say? Just deploy it?
In short, we present the Tcl stuff as a "prototype" and await the
management decision - do we go with something that works, or do we
pay to do it over the hard way? From that point of view, the answer
is a no-brainer. The managers who then turn around and slam you
on your performance review for "not doing it the company way" after
you've got their arses out of a sling are ones that you don't want
anyway. You even come to *think* of the Tcl stuff as prototyping -
with any prototype, you might get lucky and *not* have to throw
it away.
(Of course, I often treat job hunting from the perspective of
"how can I solve the problem you didn't know you had?")
--
73 de ke9tv/2, Kevin
It'll be sad to see you go. Most important, though, is that your own
career work out; good luck.
I hear you! But once I'm "on a mission", they'll *get it* ;) They might not
re-act, but at least we'll have *made* the point.
--
duke
what I've seen is a distain for scripting programmers, period.
Regardless of whether it was perl, python, ruby, tcl, shell, awk or
whatever, the attitude too frequently is "oh, that isn't real
programming - anyone could do that". Shrug - so they lose... they
spend way too much getting way too little done. I sat in a presentation
a year or two ago where the presentor mentioned in a manner of fact
manner that a new java programmer would take 18 months to get to the
point of being able to program well in the language. For Tcl, it's less
than 18 hours...
> I currently have under consideration an oral job offer (awaiting
> paperwork) to go back to doing embedded programming in C for a major
> national consulting company. One regret is that I will be for the most
> part leaving behind Tcl/Tk and this great community.
Interestingly enough, in the Tcl workships and conferences I've
attended, I've enjoyed talking to the people using Tcl in embedded
application so much. For instance, I remember some fellows talking
about embedding tcl within their hardware, so they could connect,
remotely, to the devices, and display status info in a Tk GUI, send new
commands to reconfigure the devices, etc.
I'd sure like to get involved with the project. As soon as I learn enough Tcl
and Tk I would want to contribute. Is there *anything* that I could do now?
Any *grunt* work?
BTW, would it not be grand if the entire Tcl community got behind *this*
project? Maybe this could be the beginning of "Tcl - the 2nd Generation" ;)
As well, if Tcl/Tk could position itself *with* the *Ubuntu(s) in the Unix
world, and benefit from what appears to me to be their (Ubuntu's) motto:
KISS. Would *that* not be a perfect fit! Afterwards, it would be up to us to
*make* Tcl rock-n-roll. No? Later...
--
duke
> Don't choose a programming language based on how popular it is, unless
> you plan on having everyone else do your programming for you. If YOU
> plan on programming, then pick a programming language that provides
> what you need, in a manner that is comfortable and productive for you.
I agree! I first learned Perl4. I didn't mind it at all. When Perl5 and OOP
appeared, the whole syntax felt cumbersome and un-intuitive *to me*. Before
that I had a go at Turbo Pascal - found it too wordy. Modula2, the same. I
tried C - but I don't think I hung in there long enough. I don't find myself
regretting it though.
So far, Tcl feels really comfortable. Once I rally begin to put it work, I'll
be in a better position to see how it works for me and for the project.
> Other people complain because other languages have larger initial
> libraries than Tcl. Again, there are many libraries available for Tcl
> developers. Yes, you have to download them. When I look at other
> langauge environments, I see many examples of libraries that one has to
> download for them as well.
I agree! If the libraries *are* freely available, then the issue of "bundling"
them with the interpreter is only one of convenience. It wouldn't hurt if
there was a central repository for these libraries though - like CPAN, e.g.
> The real need, in the Tcl community, is positive contributions from the
> community. If more community members contribute bug reports,
> enhancement reports, code for enhancements, as well as volunteer to
> actually get involved in improving Tcl, it will continue to florish.
I agree! It's my understanding that Tcl *has* the "horesepower" to get most
jobs done. We as a community need to publicize that fact in various ways, and
manuever ourselves into the limelight somehow - kick-butt projects;
side-saddling with Ubuntu et al; and, like you say above, have a well-organized
administration. We need to get back into the game!! What do you think?
--
duke
> I'd sure like to get involved with the project. As soon as I learn enough Tcl
> and Tk I would want to contribute. Is there *anything* that I could do now?
> Any *grunt* work?
I would never designate any participation in Tloona as "grunt" work
;-).
If you mean work that does not involve coding - yes, there is something
you can do:
- use it and test it, provide bug reports (by Email for now - later I
will set up a bug tracker if it hurts)
- write some user documentation, tutorials, howto's etc.. If it gets
too big to manage that, I can also setup a wiki. For now, the
documentation section on the Tloona homepage is probably fine.
People who like to provide content for the Tloona website (e.g.
documentation) can register there - just want to point that out. Later
I can assign author privileges to you... more on that by Email.
> BTW, would it not be grand if the entire Tcl community got behind *this*
> project? Maybe this could be the beginning of "Tcl - the 2nd Generation" ;)
Absolutely ;-). The more users and contributors, the better.
Eckhard
You know what I envision? Introduce sensible regression tests for
embedded systems.
Simply put: Surround the device in question with gizmos acting as
actors and / or sensors, have them stimulate the device and collect /
survey its reactions. These gizmos will be programmed to understand a
simple language:
DigiOut[0] = 1
AnaOut[3] = 3.5
Wait 10 msec
if AnaIn[2] < 1.5 then
report "Failure on test X"
(you get the idea).
The backend will feed the test scripts to the gizmos and collect their
results. It can probably by itself handle serial connections to the
device and / or throw TCP/IP packets at it and record its reactions as
well as the timing.
Guess in what language this backend will be written in? :) (What an
exciting application for Tcl's excellent tcltest package.)
So even in the embedded world I am sure that there will be lots of
opportunities to improve the overall situation - and why would I want
to use C for these?
Well, we'll see.
Good luck to you
Helmut Giese
You might want to look at something called ATLAS instead. No sense
reinventing the wheel. :-)
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
ATLAS is a programming language designed to write test scripts for
hardware. I ran into it a few years ago, where it was being used to
drive the test equipment diagnosing fighter jets and such. It looks ever
so vaguely like COBOL. :-)
Terms like "ATLAS test program" and "ATLAS hardware test" turn up some
links, as well as a lot of bogus stuff.
http://grouper.ieee.org/groups/scc20/td/ATLAS%20Standard.htm
Of course, if your systems don't support it, then it's not too useful to
you. But if you're testing embedded systems, you can at least sound
smart by knowing what it is when your peers don't. ;-)
>>> *) Standard Tcl on many Linux systems is underpowered compared to the
>>> competition - it has no readline support, no standard library, doesn't
>>> have many useful packages (thread), and so on.
>>>
>> By "the competition", I take it you mean ActiveState? *That's bad!* What I
>> mean is -- Tcl for the various Unices should be able to go toe-to-toe, as an
>> advocacy thing for *both* Unix and Tcl.
>
> At the risk of putting words in David's mouth, I'm going to say, "no", he
> does NOT mean ActiveState (at least not ActiveState Tcl). ActiveState Tcl is
> one of the reasons Tcl is happily chugging along, as far as I can tell. I
> _THINK_ David means perl, python, ruby, etc.
Yes, of course. ActiveState is part of the Tcl... ahem...'ecosystem',
as they say in the glossy magazines;-) They have an interest in
promoting it, and employ two people to work on it full time.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
> In my opinion, the ... less elegant systems will generate more
> traffic in online forums and more pages in bookstores because
> the learning curve is steeper for them. With Tcl, it's close to
> an order of magnitude shorter, so there's less chat about it.
Python and Ruby are as easy or easier than Tcl in some ways, a bit
harder in others, but I'd say they all group pretty similarly, depending
on who is doing the grouping and what their experience and biases are.
I wouldn't say there is any order of magnitude differences between the
three, though.
> Don't choose a programming language based on how popular it is, unless
> you plan on having everyone else do your programming for you.
Having a wide variety of readily usable libraries *is* "having everyone
else do your programming for you". Traditionally, Tcl *has* had that
compared to a lot of languages, all things considered. It's losing bits
and pieces along the wayside though.
I'm pretty sure that one of the reasons I GOT my current (California) CAD
development job is that I had a fair amount of Tcl/Tk experience already.
The company has a Tcl/Tk guru, but he's not in North Amreica for 10+ months
a year, so in essence, I'm the resident Tcl/Tk expert.. I probably do mix of
45-55% Tcl, 35-40% C/C++ and 5-20% unix/system/troubleshooting. Something
like that. And I end up defending our Tcl front-end (a decision which was
made long before I arrived) on a monthly, if not weekly basis :-)
MH
Well.. I'd say I picked up a working subset of Java "on the job", when I
joined some friends with a consulting firm in '00, coming from a C/C++
background (and some Tcl/Tk).
Within a month I was quite comfortable, and after 3-6 months I was writing
code deployed in production settings, IIRC.
18 months maybe starting from NOTHING, or to have memorized 85%+ of all
libraries. The great thing about Java is that they have good online docs for
all library calls, etc. Java in a Nutshell is really all you need, + online
docs, IMHO.
Starting from nothing, Tcl takes more than 18 hours. I've been working with
it about 40-60% of the time for 1.5 years, after having written some
reasonably complicated stuff over the previous 10 years, and it STILL throws
me for a loop once in a while. Usually with args and quoting, and passing
"args" from one proc to another as multiple args, not as a big string. What
works in one place seems to break in another.
In fact, even though I haven't worked with Java past 1.4 or 1.5 (no
experience with generics, etc), I'd say on a daily basis, Tcl still has more
gotchas for me than Java/C/C++.
YMMV.
MH
>Of course, if your systems don't support it, then it's not too useful to
>you. But if you're testing embedded systems, you can at least sound
>smart by knowing what it is when your peers don't. ;-)
Yeah, there are always lots of different aspects to consider. :)
Thanks for an interesting info and best regards
Helmut Giese
>>So where does Scheme stand today - is that any better than Tcl? No, imo
>>it's even worse.
> .
> .
> .
> It's a bit hard to say. Incidentally, as the transcript Stephan
> cited makes clear just a couple paragraphs below, the keyword that
> might interest you most is Guile <URL: http://wiki.tcl.tk/guile >,
> "our scheme interpreter". Please be aware that non-negligible
> attention in the Lisp community goes to fussing about whether
> Scheme is Lisp, Guile is Scheme, Guile is worth support, and so
> on. For me, Guile's been mostly a ... disappointment.
Me too, but I also never really got friend with any lisp-alike, my
Emacs-functions are far from being elegant.
Since I read the Stallman interview the first time, I have the idea, that
someone should write a Tcl binding for GNU Emacs and ask Stallman to
include it into the Emacs distro... ;-)
Stephan
>>Helmut Giese wrote:
>>> You know what I envision? Introduce sensible regression tests for
>>> embedded systems.
If you are interested in testing, there is also a commercial package for
software testing and verification (CSP checking, model refinement and such)
that I remember from my university time. It's called "FDR" and it also
makes heavy use of Tcl/Tix. You can find it here:
http://www.fsel.com/software.html
Although I find those tools very hard to use (CSP really killed me...), they
are a very good inspiration when you think about testing.
Regards
Stephan
> Since I read the Stallman interview the first time, I have the idea, that
> someone should write a Tcl binding for GNU Emacs and ask Stallman to
> include it into the Emacs distro... ;-)
As far as I know, it is part of the standard Emacs distribution.
> Stephan Kuhagen wrote:
>
>> Since I read the Stallman interview the first time, I have the idea, that
>> someone should write a Tcl binding for GNU Emacs and ask Stallman to
>> include it into the Emacs distro... ;-)
>
> As far as I know, it is part of the standard Emacs distribution.
WHAT??? - But how... I mean... WHAT???
You mean I spend 15 Years using Emacs without noticing, that there is a Tcl
binding for it? - I hope you do not mean the Tcl mode (which I always use
of course), but a Tcl binding, that allows one to program emacs in Tcl
instead of EmacsLisp. If this is the case, would you please point me to
some docs how to do that?
Regards
Stephan
Hi Stephan,
>Although I find those tools very hard to use (CSP really killed me...), they
>are a very good inspiration when you think about testing.
one can never have too many sources for inspiration ...
Thanks for the link, I tug it away for further reference.
Best regards
Helmut Giese
> I agree! If the libraries *are* freely available, then the issue of "bundling"
> them with the interpreter is only one of convenience. It wouldn't hurt if
> there was a central repository for these libraries though - like CPAN, e.g.
There's been, in the past, several attempts at this. A new effort was
announced at the recent Tcl workshop - I suspect we'll begin to hear
more about this as Tcl 8.5 moves into beta.
> We as a community need to publicize that fact in various ways, and
> manuever ourselves into the limelight somehow - kick-butt projects;
> side-saddling with Ubuntu et al; and, like you say above, have a well-organized
> administration. We need to get back into the game!! What do you think?
I agree. And it doesn't take a lot of technical expertise for this to
happen. What will it take? Involvement by community members. When you
write a Tcl program that you are making available for others, mention
Tcl in the announcement. Copy comp.lang.tcl when you post an
announcement about your program in other newsgroups. Create a page on
http://wiki.tcl.tk/ and a link to the page from an appropriate page.
Write an article about your program for one of the various online web
magazines - and drop a reference to Tcl in the article. And so forth.
Within the tcl community itself, plan on working with the repository
team to contact the authors of your favorite extensions, volunteering
to help them (if necessary) to set up the formatting of the extension
into a format suitable for the repository and putting things in place
so that updates automatically get reflected to the repository. Send a
letter to the "editor" of your favorite technical magazine, mentioning
the repository, etc.
Then, those of you so anxious to get hoards of new Tcl users -
volunteer to answer questions here , on the wiki, and elsewhere. I
mean, if you want lots of people, then you need to step up to the plate
to hold their hands as they begin to use Tcl. Because the few resources
we have now are spread thin across working on the Tcl code, etc.
And, finally, help out with that job. If you know C, help with
debugging. If you know Tcl, help with debugging that portion, or
writing new test cases, or writing demos for code which doesn't have
demos yet. If you want some place to get your feet wet, help work on
the tutorial, submit bug reports about typos or missing info in the man
pages. If you have web experience, volunteer to help with
http://www.tcl.tk/ . The more of these things that you do - the less
that the C and Tcl programmers have to do relating to the less
technical aspects ... which means more features and bug fixes. You
could even help with the bug database - look at open bug reports,
attempt to reproduce the problems with the current version of Tcl, and
add a comment showing people what you've found.
I think David did mean the "mode" and not a "binding". Who wants RMS
showing up at your doorstep demanding that a Tcl binding be changed to
a Guile one.
Robert
I would gladly volunteer to help "convert" extensions to the correct
format once I learn what it is supposed to be. : )
> If you want some place to get your feet wet, help work on
> the tutorial, submit bug reports about typos or missing info in the man
> pages. If you have web experience, volunteer to help with
> http://www.tcl.tk/ .
What needs doing on there?
> The more of these things that you do - the less
> that the C and Tcl programmers have to do relating to the less
> technical aspects ... which means more features and bug fixes. You
> could even help with the bug database - look at open bug reports,
> attempt to reproduce the problems with the current version of Tcl, and
> add a comment showing people what you've found.
Glad to do it.
Robert
> I think David did mean the "mode" and not a "binding".
Yes, I already was sure he meant the mode. It would have been too strange.
> Who wants RMS
> showing up at your doorstep demanding that a Tcl binding be changed to
> a Guile one.
Me. Because it would mean, that there is one and I could just slap the door
and go back to Tcl-ling Emacs... ;-)
Regards
Stephan
> Me. Because it would mean, that there is one and I could just slap the door
> and go back to Tcl-ling Emacs... ;-)
You mean *step forward* to Tcl-ling Emacs ;-). (Vim has this, by the
way...)
Eckhard
On Nov 21, 2:23 pm, "Robert Hicks" <sigz...@gmail.com> wrote:
> Eckhard Lehmann wrote:
> > Merrilee Larson schrieb:
>
> > > tutorials) I find Tcl charming as well as quite capable for most applications.
>
> > It is, indeed.
>
> > > What happened to its reputation?
>
> > It seems to me that Tcl has always had problems with its reputation.
> > Probably, it's the prefix notation and/or the "everything is a string"
> > paradigm. Most Developers are obviously addicted to C like languages.Maybe would could GPL Tcl and get Stallman to sing us praises like he
> is doing with Java?
Then the last stand of Tcl will be lost: EDA. I don't think Cadence,
Synopsys, Mentor et al would be very happy if you "force" them to
rearrange their code just to get Tcl on "an armlength distance" due to
the GPL-2 license. I guess the GPL-3 license will be even worse for
them to accept.
Why do you want to run Mr. Stallmans errand? In the case of Tcl, I
think he has done unhealable damage to Tcl, even if Tcl is the first
open source tool, or at least one of the first open source tools, to
break the barriers of the very proprietary EDA world. I would guess
that even a man like Ousterhout has a limit of how much and what kind
of critics he can take.
And since Sun had most of the rights on Tcl for a while, and this
company decided to focus on a different programming paradigm it will be
hard for the ugly duckling to rise again after the mother has wiped the
nest.
The problem with Tcl is that once you are inside it, you never get out.
I keep myself comparing "everything" with Tcl when it comes to speed of
whipping up some command line tools. That I can attach a GUI on top is
a piece of sugar for _my_ cup of tea.
I am sorry that Tcl won't have OO in the core like Python.
--
Svenn
--
Svenn
It will. Just not in 8.5.
Donal.
Where did you get that? I have been following talks on the TCT list and
while it has been decided not to include it in 8.5 for a variety of
reasons it is supposed to hit a point release within a reasonable
amount of time.
Tcl will have OO in the core.
Robert
Or, at least, never *want* out.
> I keep myself comparing "everything" with Tcl when it comes to speed of
> whipping up some command line tools. That I can attach a GUI on top is
> a piece of sugar for _my_ cup of tea.
>
> I am sorry that Tcl won't have OO in the core like Python.
It will, just not in 8.5.
Consider it a testament to Tcl's strength as a language that even
without "OO in the core" you can do a whole lot of OO programming with
Tcl if that's what you want.
How many other languages that lack OO give you the ability to add OO in
whenever you want? You get the best of both words, just not (yet) in a
convenient easy-to-open bottle.
Tcl, the language with a child-protective cap! :-)
QOTW!!!
If you look at Perl it has OO. Most people will tell you it sucks
though. It doesn't feel natural. I looked and I agree, it sucks and I
like Perl.
If you look at Tcl and how Snit (my fav) and XOTcl (learning) work with
it, to me those to extensions don't feel like they are forcing Tcl to
be something its not. They (to me at least) feel pretty natural (Snit
especially in my mind). OO is just going to enhance that.
The year: Sometime in the near future
Dave: Hal?
Hal9000: Yes Dave?
Dave: What is happening to Tcl, Hal?
Hal9000: Something wonderful.
: )
Robert
I can only think of two such other popular languages, off the top of my
head. :-)
Well, that was peculiar. What I wrote isn't what showed up here!
Anyways, I seem to recall that what I wrote involved contacting the
webmaster, and volunteering to update news information as it appears in
Tcl-URL!, comp.lang.tcl, etc. and discussing with the community what
other features would be valuable to add.
First time I thought about this one, was when www.tcl.tk was updated
some time ago. Second time I thought about this, was when the thread
"is tcl/tk dying out?!" appeared on c.l.t.:
http://groups.google.de/group/comp.lang.tcl/browse_thread/thread/a9ff5bd741ee1635/7d7b1cd5a05024a5
Originally I wanted to wait, but perhaps I should step forward now. I
would like to volunteer! My vision is to have a kind of portal for
information on Tcl. It should be similar to the info on www.tcl.tk but
contain a lot more information and be updated on a regular basis. So I
collected ideas on what should be in there and hammered together a
prototype here:
http://tcl.typoscriptics.de/portal
This site is of course far from complete. Consider these pages as a
skeleton filled with ideas and beginning to be filled up with real
information. I have already "stolen" text from www.tcl.tk, the wiki,
and other places. This is a lot of work, and this is why I hesitate.
But I will have some time to spend from January (I hope). The design
and implementation was done with Rapidweaver (a Mac software) because I
wanted to concentrate on the content and not on web design as such. I
wanted to get up to speed quickly.
What is the final goal?
- replace www.tcl.tk with a new design
- getting all infos from the current www.tcl.tk into the new pages
- add additional information on all aspects of Tcl/Tk
- update information on a regular basis
- incorporate bits and pieces from c.l.t., Tcl-URL, chat and other
places
- ... add what you think it should contain ...
In one sentence: Make www.tcl.tk the best, easiest, and most fun
starting point for Tcl/Tk.
So, what do you think? Am I being too optimistic or is this something
the community would embrace, helping me with content here and there?
Torsten
> In one sentence: Make www.tcl.tk the best, easiest, and most fun
> starting point for Tcl/Tk.
Really good idea. I'd appreciate it...
I like to propose only one addition to the prototype: A feed aggregator
for Tcl developer blogs. There is such software around (called
planetplanet: http://www.planetplanet.org/). Maybe this or a similar
solution fits in your concept?
> So, what do you think? Am I being too optimistic or is this something
> the community would embrace, helping me with content here and there?
Of course I like to help out with content. If the site is made up like
a community portal (and it seems to be that), there are lots of easy
ways to get content in...
Eckhard
> Guile is a competitor to Tcl only in the sense that RMS prefers it.
> For everybody else, the real competitors are Python, PERL, and Ruby.
Guile is a competitor to Tcl in the sense that neither is any
competition to Python, PERL, and Ruby :-(
--
Donald Arseneau as...@triumf.ca
I think:
..you have done the right thing at the right time.
..you are actually going to get some help.
..I am going to help.
..It's going to be fun.
Good Job.
Mark
I think a lot of people would help this effort.
Robert
> The other thing to note about Guile is that hardly anybody uses it. It
> is required as an extension language for official GNU programs, but
> offhand I can't think of any non-GNU program that uses Guile as its
> extension language or of any program that uses it as a scripting-level
> implementation language. Even hard-core FOSS advocates and hackers
> rarely consider LISP to be the ideal extension language.
well let's see
Emacs (extension language Emacs Lisp)
Autocad (extension language Autocad Lisp
> This is one of the rare cases in
> which RMS has, I think, taken a position that conflicts with that of
> most of his constituency. Guile is a competitor to Tcl only in the
> sense that RMS prefers it.
I can not see this
> For everybody else, the real competitors are
> Python, PERL, and Ruby.
Well IMHO they all are quite good in that area and "could"
compete. Howerver it seems that prefix notation is *not* what most
prefer....
Howerver Tcl/Tk is another wonderful language and worth learning it,
but I'd argue that holds for qute a few other languages also ;-)
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
> Mark Smithfield wrote:
> > > So, what do you think? Am I being too optimistic or is this something
> > > the community would embrace, helping me with content here and there?
[...]
> > I think:
> > ..you have done the right thing at the right time.
> > ..you are actually going to get some help.
> > ..I am going to help.
> > ..It's going to be fun.
[...]
> > Mark
>
> I think a lot of people would help this effort.
>
> Robert
All right then. 3 positive feedbacks from the community is enough to
get me started. I will start a wiki page for this in the next weeks and
begin putting more stuff into the web pages as I get the time for it.
Don't expect much before January 2007. I will also look into the
proposals that have been made here.
Torsten
> All right then. 3 positive feedbacks from the community is enough to
> get me started. I will start a wiki page for this in the next weeks and
> begin putting more stuff into the web pages as I get the time for it.
> Don't expect much before January 2007. I will also look into the
> proposals that have been made here.
various items:
I had thought about using one wiki-page as a staging area for the Tcl-URL
with the idea in mind that others could add items or corrections/commentary.
My Tcl-URL stuff includes some leaching scripts that follow state for the TIPs repository.
I could supply you with a running commentary on an automatic basis.
I am thinking about following package announcements/developement in the same vein.
The wiki could use some kind of templates mechanism
to express sametype items in a consistent ( and leachable) way.
and
i want tables!
>
> Torsten
uwe
>
If you would like access directly to tcl.tk (via ssh), please send me an
email. Then you could play around with the actual content on either a
parallel site (different port), or just in some subdir area.
--
Jeff Hobbs, The Tcl Guy, http://www.activestate.com/