I don't expect business as usual after the changes
from scriptics/ajuba/woven, but it appears to me
that the wheels have finally fallen off the
tcl cart in the script language race.

Where is the tcl development team?
Is it at sourceforge, dev.scriptics, or is it
here on a newsgroup buried in the noise and chaos.

Where is the direction, the future, the niche for
tcl? (on a wiki somewhere IIRC 4.x?).

For me tcl died when the core api changed from 8.0
to 8.1 and thousands of extensions were rendered
obsolete overnight. A move worthy of a Microsoft
marketing manager.

Was there a thrust by dedicated tcl developers to
upgrade their extensions
or did they feel betrayed and leave their work to
dissapate into
the ether like 8" floppy disk drives.

Look at the neosoft tcl archive, obsolete packages
discarded like used condoms.

Developers would rather use the abomination called
perl or python than use tcl
(but whose gui to they use when the users demand a
visual interface).

How many systems are still tcl8.0 and will never
upgrade.

I don't see the situations vacant (job adverts)
crying out for tcl developers.

Tcl may not be dead, its legacy may stay around
for a long time, but the will of the development
community to support tcl has long departed.

c'est la vie.

Sent via Deja.com
http://www.deja.com/

>I know the subject is highly emotive, but is it
>based in truth?

no.

--
  David Gravereaux <davy...@pobox.com>
  http://dev.scriptics.com/doc/integration.html#Tcl

>For me tcl died when the core api changed from 8.0
>to 8.1 and thousands of extensions were rendered
>obsolete overnight. A move worthy of a Microsoft
>marketing manager.

The need for Stubs (that's what you're referring to) was too important.  Any
Stubs extension made for 8.1 runs in 8.4 without recompiling!  Can you say that
for a 7.6 extension running in 8.0?

--
  David Gravereaux <davy...@pobox.com>
  http://dev.scriptics.com/doc/integration.html#Tcl

wowba...@my-deja.com wrote:
>
> I know the subject is highly emotive, but is it
> based in truth?

Tcl is as dead as you want it to be.  :)  

 
> I don't expect business as usual after the changes
> from scriptics/ajuba/woven, but it appears to me
> that the wheels have finally fallen off the
> tcl cart in the script language race.
>
> Where is the tcl development team?
> Is it at sourceforge, dev.scriptics, or is it
> here on a newsgroup buried in the noise and chaos.

http://mini.net/cgi-bin/wikit/977.html

 
> Where is the direction, the future, the niche for
> tcl? (on a wiki somewhere IIRC 4.x?).

The same could be asked about LISP and many other languages, but they
seem to keep rolling along.  It's not like Tcl has to dominate the
world.  Even if only one person continues to maintain Tcl it will still
remain a valuable tool.  From what I understand for a while at Scriptics
there were only two people continuously maintaining/improving Tcl.

 
> Developers would rather use the abomination called
> perl or python than use tcl
> (but whose gui to they use when the users demand a
> visual interface).

Many people are moving away from using Tk in the Python community.  See:
http://wxpython.org/
 
> c'est la vie.

George Peter Staplin <GeorgePS@XMission.com> wrote:

>From what I understand for a while at Scriptics
>there were only two people continuously maintaining/improving Tcl.

True.  With assistance from Scott Redman, Scott Stanton, Brent Welch and myself
when I started there last June.

--
  David Gravereaux <davy...@pobox.com>
  http://dev.scriptics.com/doc/integration.html#Tcl

George Peter Staplin  <GeorgePS@XMission.com> wrote:

                        .
>Many people are moving away from using Tk in the Python community.  See:
>http://wxpython.org/
>
>> c'est la vie.

"Tkinter" is how Pythonians spell their Tk binding.
Tkinter use continues to *grow*, from all I can tell;
John Grayson's book and Fredrik Lundh's development
make it an exciting technology.  Incidentally, these
and others have a lot to offer that can and does
nourish Tk proper.

HOWEVER, Python is blessed with a uniquely broad variety
of quality GUI toolkit bindings, and Tkinter's share of
the expanding pie is definitely shrinking.
--

Cameron Laird <claird@NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html

wowba...@my-deja.com wrote:
> I know the subject is highly emotive, but is it
> based in truth?

Oh please I hope not ... I have just invested some cash (books), and I
plan on investing some time in learning this neat tool along with some
extentions.  As someone (elsewhere) pointed out, it is not the best tool
for any one thing, but it is a very good tools for a lot of different
things.

> How many systems are still tcl8.0 and will never
> upgrade.

I am not sure if we are planning on upgrading, but we are currently at
8.0, and some of our products have embedded 7.6 (with custom
extentions).

Just my $0.02 worth ...

To what do you refer here?  Tcl has, since nearly the beginning, been
a community project.  There have been, at various times in Tcl's
history, between one and seventeen people managing the source of
the 'official' tcl distribution.  And the seventeen are the TCT who
are currently managing the sourceforge version of tcl and tk - the
current distribution considered by many to be 'official'.

:Is it at sourceforge,

yes

:dev.scriptics, or is it

Well, that's one of several web forums where people who grow weary of
trolls, flame wars and spam go to get answers to their questions.  Another
is <URL: http://purl.org/thecliff/tcl/wiki/> .

:here on a newsgroup buried in the noise and chaos.

The noise and chaos, which isn't all that large here, is the reason many
go to the other resources...

:Where is the direction, the future, the niche for

:tcl? (on a wiki somewhere IIRC 4.x?).

I would say that by watching the TIPs you will learn what the community
is interested in seeing happen to the core.  There is no 'development
team' as such writing new code.  There are only community members writing
specs, code, etc.  What have you contributed lately towards the future of
Tcl?

:For me tcl died when the core api changed from 8.0

:to 8.1 and thousands of extensions were rendered
:obsolete overnight. A move worthy of a Microsoft
:marketing manager.

I don't recall that event - and I've been managing a catalog of extensions
for years...

:Was there a thrust by dedicated tcl developers to

:upgrade their extensions
:or did they feel betrayed and leave their work to
:dissapate into
:the ether like 8" floppy disk drives.

Tcl developers are notorious (sic) for doing what they feel like doing.
Few have expressed any feelings of betrayal.  And certainly, if they
did feel 'betrayed' I feel sorry if they ran off to say Perl (can you
say perl 5.5 vs 5.6 vs 5.7 vs 6.0?), java (can you say microsoft vs sun),
etc.

:Look at the neosoft tcl archive, obsolete packages
:discarded like used condoms.

I assume that by 'discarded' you mean 'software which is not being maintained'?
I too see a lot of this.

<flame>
For whatever reason, people in the free software
community frequently (using that term to apply to 70% plus of the software
available) believe that once software is no longer necessary to them, someone
interested in using it should be doing the work of maintaining it.  And,
for about 95% percentage of users of the free software, they believe they
have the right to sit around on their seats and complain because the bottle
is empty and no one is stepping up to fill it again.
</flame>

:How many systems are still tcl8.0 and will never
:upgrade.

I don't know of many of these, personally  - I do know of some tcl 7.6 systems
that haven't upgraded yet.

:I don't see the situations vacant (job adverts)

:crying out for tcl developers.

Nope - but then, I don't see any for python and see few for perl.  Most
managers to whom I talk consider these 'simple' languages, not "real
programming like c++ or java"... Sigh.

:Tcl may not be dead, its legacy may stay around

:for a long time, but the will of the development
:community to support tcl has long departed.

I think it isn't that the will has long departed.  What I think is that
the community growth is more among 'users' than 'developers', which results
in there being a lot more people sitting around looking for hand outs than
looking for ways to contribute.

Perhaps you are working on some code you would like to share?
--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

If there is something that Tcl can do and other languages
can not do, then Tcl is not dead.

Chang LI
Neatware

wowba...@my-deja.com wrote in message <94oobh$tj7$1...@nnrp1.deja.com>...

From your comments (see thread) I see nothing in your reply that
either answers my question nor rebuts the assertions.

The question is "has tcl reached the end of its life cycle ?".
My assertion is that it has.
It peaked very early in its development and had huge potential which
for what ever reason was never realised.

If you look at what has been done with tcl, and the number of half
finished applications and extentions (my own included) it is clear
that developers saw the possibilities but couldn't get the result
with the effort available. Why it is I dont profess to know, but you
only have to compare tcl with other languages and acknowledge the fact
the tcl is not mainstream. Even sourceforge doesn't list tcl as a
developer skill (but applescript apparently is).

Scriptics used to compare tcl/tk to Visual basic, the reality is that
Visual basic is used for writing applications and Tcl isn't.
My preference would be to be using tcl but my clients keep demanding VB.

My question would be a serious one if there was a genuine concern or
commitment to see tcl continue and improve to the level that is is a
contender for a mainstream language but I don't see that commitment
coming from the TCT or the development community.

When there was a financial interest in tcl (from sun and scriptics) the
development had direction, what I don't see is any direction from the
TCT.

(Sorry for not replying yo your comments directly as you have taken the
time to write them but I dont think you understand what the point is
that I am making).

Sent via Deja.com
http://www.deja.com/

wowba...@my-deja.com wrote:
> I know the subject is highly emotive, but is it
> based in truth?

Not from where I'm sitting.

> Where is the tcl development team?

If you mean those that dedicated most of their time to Tcl,
then things did get a bit scattered by the Interwoven acquisition
of Ajuba.  However, that's slowly reversing as some of those
engineers leave for other jobs.  The count is 5, and likely to
go higher.  BTW, you can now officially include me in that count.

> Is it at sourceforge, dev.scriptics, or is it
> here on a newsgroup buried in the noise and chaos.

It's everywhere the community is, which include all of the
above and more.  SourceForge is used primarily for the source
code repository, bugs and patches.  Anyone can get the source,
play with it and submit bug reports or patches.  Lots of people
have been contributing to that.

> Where is the direction, the future, the niche for
> tcl? (on a wiki somewhere IIRC 4.x?).

Many would call Tcl mature, others would say it has another
phase of evolution or two.  The development process is open.
Instead of all the questions, perhaps you have ideas?

> For me tcl died when the core api changed from 8.0
> to 8.1 and thousands of extensions were rendered
> obsolete overnight. A move worthy of a Microsoft

Hmmm, then you evidently didn't understand the value of
the major features in 8.1 - unicode throughout and fully
thread-awareness in the core.  These are complex features
for a scripting language.  For Perl to get it all right,
they are starting over from scratch for Perl6.  Most of
the extensions were also ported (some for 7.6 never made
it forward though).  What Tcl really suffers from is no
equivalent to CPAN.

> How many systems are still tcl8.0 and will never
> upgrade.

A few that I know of, and fewer still in Tcl 7.x, but the
majority are actually 8.1+.

> I don't see the situations vacant (job adverts)
> crying out for tcl developers.

Are you interested?  I can point you out to several.

> Tcl may not be dead, its legacy may stay around
> for a long time, but the will of the development
> community to support tcl has long departed.

Sorry that you've lost heart, because your sweeping
statements don't apply to the community I know (and I
think I know it fairly well...).

Jeff

> I think it isn't that the will has long departed.  What I think is that
> the community growth is more among 'users' than 'developers', which
results
> in there being a lot more people sitting around looking for hand outs than
> looking for ways to contribute.

Sad truth.
Something very important had gone out of Tcl community - to the Python,
Perl, Java or (horror!) VB, I don't know. This clearly visible decline of
development spirit should be frankly acknowleged and discussed. It has some
reasons, doesn't it?
 Different people could have different reasons for not developing Tcl
anymore, or even not using it anymore. Does Tcl community have clear
understanding of those reasons? What about a  "Why do you dropped TCL" poll
in this newsgroup (and others too)?

Alexander Nosenko
<n...@cr.cyco.com>

:
:From your comments (see thread) I see nothing in your reply that
:either answers my question nor rebuts the assertions.

Sorry - it certainly wasn't my intention to avoid answering your question;
nor was it my intention to rebutt your assertions.

:The question is "has tcl reached the end of its life cycle ?".

I consider "end of life cycle" to mean "ready to be retired from all
machines".  If that's what you mean by end of life cycle, then I would
say the answer to your question is "no".  If however you mean "has tcl
reached the point at which no new major changes will be occuring to the
core, resulting in revitalized public recognition of the language", I would
say "yes" - but I wouldn't consider that the end of life cycle, but plateauing
at a stable point.

:My assertion is that it has.

:It peaked very early in its development and had huge potential which
:for what ever reason was never realised.

The potential that I saw for Tk in the beginning was in the hyper tool
arena, and I agree, this potential has never been realized.

:If you look at what has been done with tcl, and the number of half

:finished applications and extentions (my own included)

I would see a number significally less than I would see has been written
in C, C++, Java, Shell, awk, perl, python, ruby, etc.  

:it is clear

:that developers saw the possibilities but couldn't get the result
:with the effort available. Why it is I dont profess to know, but you
:only have to compare tcl with other languages and acknowledge the fact
:the tcl is not mainstream. Even sourceforge doesn't list tcl as a
:developer skill (but applescript apparently is).

Tcl is no more mainstream than python, ruby, and most other languages,
where mainstream means either "gets large amount of general developer community
attention" like perl or javascript  or "has large amount of commercial support"
like VisualBasic.  There are few other scripting languages than these that
get attention OUTSIDE of its own language community.  Few people in WWW
newsgroups are talking about Python or Ruby - most of the discussions there
are either Perl or JavaScript.  Few in the various scientific communities
are talking about any of these - most are either talking Java or Scheme/LISP
or some ML.

:Scriptics used to compare tcl/tk to Visual basic, the reality is that

:Visual basic is used for writing applications and Tcl isn't.

Well, Tcl is, but not the size or volume that VisualBasic is used.

:My preference would be to be using tcl but my clients keep demanding VB.

Yep - their people are somewhat familar with VB, it works naturally with
their Excel, etc. apps, etc.  I suspect that Tcl _could_ fit that
arena.  Few Windows _developers_ have chosen to develop with Tcl.

:My question would be a serious one if there was a genuine concern or

:commitment to see tcl continue and improve to the level that is is a
:contender for a mainstream language but I don't see that commitment
:coming from the TCT or the development community.

I think that the Tcl developer community is more than happy with the
mindshare currently held and has no generally agreed upon ambition
to 'take over the world'.

:When there was a financial interest in tcl (from sun and scriptics) the

:development had direction, what I don't see is any direction from the
:TCT.

When there was a financial interest in Tcl, there was commercial reason to
link about 'taking over the world' or at least some portion of it.  At
this time, that ambition does not seem to exist - nor, am I convinced,
needed.

:(Sorry for not replying yo your comments directly as you have taken the

:time to write them but I dont think you understand what the point is
:that I am making).

I think that I do understand a bit - but if after reading this message
you still believe I do not understand your point, then I will have to conceed
that somehow your point is eluding me.

--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

  "Chang LI" <cha...@neatware.com> wrote:
> Tcl is not dead. It slept in the winter :-)
> And many Tcl veterans took a break in the winter as well.
>
> If there is something that Tcl can do and other languages
> can not do, then Tcl is not dead.
>
> Chang LI
> Neatware
>

I believe one of the TLC's problems is, that the more
advanced extensions are well hidden from the beginner's view.

Newcomers usually start with the books by Ousterhout and Welch,
which, although great introductory books, wont' really impress
someone who eventually has had some previous encounter with other
modern toolkits.

Only if a TCL student is really stubborn, she eventually comes across
the more serious stuff (as, e.g., found in in Harrison's
"Tcl/Tk Tools") and won't loose interest prematurely.

I have gone through that and decided to stay, but I believe more people
would use TCL if they *knew* about [incr tcl/tk], expect, oracl, and
the like.

-km

Sent via Deja.com
http://www.deja.com/

: The question is "has tcl reached the end of its life cycle ?".

: My assertion is that it has.

In every comp. group on Usenet, the question is asked.  "Is
(topic) dead".  Is Unix dead?  Is NT dead?  Is Linux dead?
Is Emacs dead?  Is VI dead?  Is PERL dead?

It never is dead, and the discussions never get anywhere other
than to degrade into a big advocacy war.  Almost like, the
people who initiate the threads are intentionally trolling.

Just wanted to make that observation.  Not that it'll stop
anything, of course...

Dave Hinz

As to whether TCL will ever become, or will once again become, a
'mainstream' language; what would establish TCL as 'mainstream' ?
I'd think that the use of TCL in mission critical applications would
constitute a 'mainstream' acceptance of the language.

If this question is actually - "will the marketing guy , who
otherwise knows nothing of software development, advocate that we
use TCL ? "  - probably not.

$.02

dlb wrote:
>
> I don't quite understand the purpose these "are we dead yet" threads
> either.  For all of the times that TCL has ostensibly 'died' you'd
> have to assume the TCL is actually 'undead'  - it's perpetually
> wandering the countryside is search of new brains ;)

That has got to be the quote of the week. Tcl, scripting language
of the undead. I like it!

Kind of reminds me of those old Frankenstein movies, the
scientist hobbles together a monster from bits and pieces
he dug up in various places. Before long it "escapes" and
causes untold damage that needs to be cleaned up later
on. Kind of reminds me of some software projects I
have worked on.

Mo DeJong
Red Hat Inc

> The tcl community is everywhere ....
If there is no central place to go for TCL, how do new developers get
into developing with the langauge.
If where is no visible sign of life in the tcl community then there will
be no new developers , without new developers the language dies (as does
an oral one then no one speaks it).

Do you want to see all your hard effort and emotional investment you
have put into TCL be lost in the space of a few years?
(lost=achieve no purpose, ie not used by anyone)
> ...

> Instead of all the questions, perhaps you have ideas?

I have lots of ideas, but I dont conduct academic exercises, so where
would I put my ideas so that they would reach those who may be
interested. TIPS are not an open form of exchange and the news group
is not an efficient place for exchange.
Perhaps there is an appropriate mailing list?

> Hmmm, then you evidently didn't understand the value of
> the major features in 8.1 - unicode throughout and fully

> Are you interested?  I can point you out to several jobs.

Please do.

Sent via Deja.com
http://www.deja.com/

  semi...@worldnet.att.net wrote:
> I don't quite understand the purpose these "are we dead yet" threads

Its quite simple.
Any title that is less emotive would not have stimulated debate.

Whould you have even bothered to read the post if it was titled:
"What are the future directions of tcl development and what is its
relevance to emerging trends of the 21 century"

Sent via Deja.com
http://www.deja.com/

<wowba...@my-deja.com> wrote in message
news:94vmlp$jkm$1@nnrp1.deja.com...

wowba...@my-deja.com writes:
 
> I have lots of ideas, but I dont conduct academic exercises, so
> where would I put my ideas so that they would reach those who may be
> interested. TIPS are not an open form of exchange

What makes you believe this ?

> and the news group is not an efficient place for exchange.
> Perhaps there is an appropriate mailing list?

--
Sincerely,
        Andreas Kupries <a.ku...@westend.com>
                <http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

>> interested. TIPS are not an open form of exchange
> What makes you believe this ?

1. Tips must be approved before being registered.
2. Tips are a formalised process. Once at the end of the process the
    document becomes fixed.
3. The structure of the TIP is based around a technical improvement
   ie a patch to the code rather than a non technical discussion of
   if any changes should be made.
4. Ammendments to the TIP (ie feedback) must be controlled by the TIP
   author.
5. There is no visible evidence of anyone being interested in TIPS
other            than the TCT and the TIP author.

All the above has nothing to to with my desire (among other things) to
see some direction come from the TCT as the stimulus for the continued
development of TCL.
(development=evolution).

Sent via Deja.com
http://www.deja.com/

> > Hmmm, then you evidently didn't understand the value of
> > the major features in 8.1 - unicode throughout and fully
> > ....
> And you don't acknowledge the negative impact on the TCL community that
> that decision had. I believe that the momentum went from tcl development
> (in the community) at this time and it has never been regained.

This Unicode thingie killed tcl development here in Russia (i.e. non-ASCII
charset) for shure...
The local mailing list is virtually dead ever since.

Any comments from eastern (big charsets) users ?

Alexander Nosenko
<n...@cr.cyco.com>

>This Unicode thingie killed tcl development here in Russia

How so?  Did tcl do unicode incorrectly?

--
  David Gravereaux <davy...@pobox.com>
  http://dev.scriptics.com/doc/integration.html#Tcl

Yes, on the other hand unicode was extremely useful for us :-)
In our institute we use tcl every day for natural language processing
and the fact of supporting many languages (including Greek) is vital...
It seems very strange to me, how adding unicode support and ensuring
that text in non latin-1 encoding is displayed correctly on tk widgets
has killed tcl development in a country with a non-latin-1 alphabet...

George

wowba...@my-deja.com wrote:
>
> In article <3A7323AE...@worldnet.att.net>,
>   semi...@worldnet.att.net wrote:
> > I don't quite understand the purpose these "are we dead yet" threads
>
> Its quite simple.
> Any title that is less emotive would not have stimulated debate.
>
> Whould you have even bothered to read the post if it was titled:
> "What are the future directions of tcl development and what is its
> relevance to emerging trends of the 21 century"

YES.

On the contrary, I tend to run away from "is Tcl dead"-like threads, unless I
see valuable replies from fine peoples.
--
Frédéric BONNET                          frederi...@free.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
                                                    George Bain

FYI, I've not dropped Tcl.  I just can't work on it full-time due to
having development papers to write.  :^)

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk
-- "I'm going to open a new xterm. This one's pissing me off" Anon. (overheard)

Why?  I express my opinion below, but what is yours on this matter?

> Yes, on the other hand unicode was extremely useful for us :-)
> In our institute we use tcl every day for natural language processing
> and the fact of supporting many languages (including Greek) is vital...
> It seems very strange to me, how adding unicode support and ensuring
> that text in non latin-1 encoding is displayed correctly on tk widgets
> has killed tcl development in a country with a non-latin-1 alphabet...

I suspect (but cannot prove, of course) that the problem in Russia was that
many fonts were encoded incorrectly, so it is the sloppiness on the part
of system- and font-vendors that is causing the problem there.  If there is
some kind of fix that could be cheaply applied (e.g. an additional encoding
and a little code to detect when to apply it) then for goodness sake, tell
us what it is.

But backing out of UNICODE is not a fix, since it breaks support for other
languages (especially those which need more than 256 characters) and
completely stuffs anyone wanting to properly work with multiple languages
in the same context.

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk
-- "I'm going to open a new xterm. This one's pissing me off" Anon. (overheard)

"Donal K. Fellows" <fell...@cs.man.ac.uk> wrote:
> I suspect (but cannot prove, of course) that the problem in Russia was
that
> many fonts were encoded incorrectly, so it is the sloppiness on the part
> of system- and font-vendors that is causing the problem there.  If there
is
> some kind of fix that could be cheaply applied (e.g. an additional
encoding
> and a little code to detect when to apply it) then for goodness sake, tell
> us what it is.

My personal problem was with canvas Postscript output. Tcl Unicode part was
OK (save for internal design I quite don't like), but Postscript was totally
broken with no chance of repair but total redesign. One just can't use
different glyph sets in the same canvas. And in the WinWorld "you can't
print it" class of problems is death sentence for any program. All my canvas
extensions went to hell too, but it's The Price Of Progress (I've rehacked
some back... for the third time ;-)

On the other hand, it could be pure coincidence... but the mailing list is
dead nevertheless. The meter is far below critical mass now, I suppose.

Alexander Nosenko
<n...@cr.cyco.com>

PS: The unique Russian problem is (at least ) three encodings in everyday
use on any single system - koi8r, cp866 and cp1251.

"Donal K. Fellows" <fell...@cs.man.ac.uk> wrote

> FYI, I've not dropped Tcl.  I just can't work on it full-time due to
> having development papers to write.  :^)
>

Lucky for you ;-)

I've did (almost). Many others did too. No one really studied why. The "XYZ
is dead" stuff is rarely the reason to change the development tool. The
laziness, the lack of support, the missing features, the honest disbelief in
the tool's future, the administrative pressure... they are.

From my POW, some of advantages of 8.1+ over 8.0.5 were good enough reasons
to stop struggling and switch to VB and Delphi. This and "everything is a
string" in the object-based world. Other Tcl ex-users and ex-developers have
other pet  reasons. No one yet make a table with "number of users who are no
more " against  "this great new (or old missing) feature", however. It could
be a great revelation for all concerned, even if only revelation of human
prejudices.

Alexander Nosenko
<n...@cr.cyco.com>

Alexander Nosenko wrote:
> PS: The unique Russian problem is (at least ) three encodings in everyday
> use on any single system - koi8r, cp866 and cp1251.

Three encodings?  That sucks.  It also reminds me of when I used to work
with PCs, DECStations and IBM mainframes.  <shudder>

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk
-- "I'm going to open a new xterm. This one's pissing me off" Anon. (overheard)

Which race is that? It depends upon what features you
are talking about. If you mean OO then I would agree
that Tcl may be seriously wounded. The same may apply
to some of the extensions such as Tk. But there are
still some things which Tcl does best.

> Developers would rather use the abomination called
> perl or python than use tcl
> (but whose gui to they use when the users demand a
> visual interface).

Not me, I like Scheme, but Scheme does not have a
universal GUI package, and although they may be more
powerful, none of them are as easy to use as Tk.

> Tcl may not be dead, its legacy may stay around
> for a long time, but the will of the development
> community to support tcl has long departed.

This may be true. I have noticed a lack of spirit
lately which I saw when I first started using Tcl.
I think the real question is whether the fire can
be restarted before it becomes obsolete.
--
**********************************************************************
Cris A. Fugate          Lucent Technologies, Robust Process Automation
fug...@lucent.com       http://ihgpweb.ih.lucent.com/~fugate
630 713-8255            Creator of framesets, a frames implementation

"Donal K. Fellows" <fell...@cs.man.ac.uk> wrote:
> Three encodings?  That sucks.  It also reminds me of when I used to work
> with PCs, DECStations and IBM mainframes.  <shudder>

In those times we had also EBCDIC, koi7 (2 species), and a mutated bulgarian
clone of cp437. Now things are a bit simpler: Cyrillic Win encoding is
cp1251, Windows keeps filenames in FAT partitions in the cp866 and this
e-mail is in koi8-r... all these not just in one system, but in one
application! Ough, I've forget to count the Unicode... looks like it's used
too somehow...
Cool like a dead alligator.

Alexander

> in this newsgroup (and others too)?
>

Once upon a time not too long ago I was an everyday tcl programmer -
well actually I was an everyday [incr Tcl] programmer. I was hired in
1996 at my current company to be "the Tcl expert". Upon being hired it
was up to me to build the GUI of a hotshot new networking product based
on ATM technology. What a cool position to be in! I naturally chose
[incr Tcl] as my base language for all the reasons I'm sure everyone's
heard: maintainability, scalability, flexibility, etc. etc, as opposed
to using a function-oriented approach.

I was happy as a lark for the next 2 years. But then things started
changing a little. I started to get pressured on why I hadn't chosen
Java. (My manager selected Tcl for the simple reason that Java was too
unstable at that time, but the questions still came.) Everyone was on
the Java bandwagon. I got concerned questions that filtered their way to
me from visitors who saw our product display at SuperComm asking why we
didn't use Java like everyone else. "What's this Tcl stuff anyway?" I
would frequently here. "Shareware? That's ridiculous. Who's going to
support field problems?" Customer, or potential customer, comments
matter, and eventually this filtered its way up the chain to Corporate
such that policy here was changed to use Java for all new projects. I
and several other engineers were luckily able to fend off efforts to
actually convert all the code on my project to Java! I couldn't believe
Corporate actually wanted to do that.

For quite some time I shook this off and plugged away. I was technical
lead and taught/led a small group of dedicated engineers how to use
Tcl/[incr Tcl] for building our GUI, which ended up consisting of about
200K loc. It was very successful and I heard numerous compliments from
customers, both external and internal. Additionally I heard several
comments from developers who'd not programmed in Tcl prior to joining
the team. "Man this is easy! I love being able to throw a screen
together so quickly! Debugging is awesome!" It was a fun environment.

In the meantime I'm starting to wonder if other folks/projects in the
area are using Tcl for mission-critical applications (and ours IS). Over
a period of probably 18 months I became disheartened at the reality of
very few. I was genuinely impressed with Kevin Kenny's presentation of
the GEnesis Broadcast Automation System at NBC Studios in September 1998
at the 6th Annual Tcl/Tk Convention. And I was even more impressed last
year at Tcl2k when I talked to Kevin and he told me that the 75% of
airtime controlled by tcl/tk-based apps was then 100%. But alas, this is
more the exception than the rule.

Regardless of the popular opinion around the area and the cold reality
that I would likely not be able to get a full-time job again doing tcl
programming, I was a hard-core advocate - though pretty soft-spoken. I
was asked to write a book on tcl in December 1998 by Osborne. I ended up
spending the next 10 months writing a book on [incr Tcl]. Being married,
a family man, and a man of faith, this was a massive undertaking because
it put strain on my relationship with everyone but me, my PC, my
monitor, and my ergonomic keyboard. Not to elicit praise at all, but
this is just to say I would not have given up so much for so long had I
not genuinely been excited about the language. And I still am! I would
do it all over again in a hearbeat. That book is indeed a blessing and
it makes me extremely happy to hear from folks who tell me how much they
enjoy it and how it's helped them in their programming endeavors.

But when I look in the 'help wanted' section in the newspaper, I don't
see a single need for a Tcl programmer. This became readily apparent
when my company cancelled the project on which I was working last
November. I offer a heartfelt thanks to the many people I heard from
when I announced this in November. The encouragement and potential job
offers were overwhelming. But alas, nothing really in my area. I have
several opportunities I can readily pursue, none of which entail Tcl
development. I ended up getting offered a short-term contract to stay on
here and finish some contractual obligations to existing customers. But
my days to get paid for Tcl programming are unfortunately numbered.

So the point of this message is simply to say that, having been a Tcl
developer for the last several years in the heart of Telecom Corridor
just north of Dallas TX, I must agree that Tcl is simply not mainstream
here. I really really hate to say that. But of all the Tcl-developing
members of my group that were laid off, not a single one found a job
developing Tcl. Believe me, there's nothing I would like more than for
Tcl to have the momentum of Java. Maybe it's just the Dallas area? I
hope so, but I'm inclined to think not.

I don't think Tcl will _ever_ be dead, but I do think that it's true
potential may never be reached because the demand is simply not there.

Just my humble opinions,
-chad

On Mon, 29 Jan 2001 11:34:43 -0600, Chad Smith <chad_...@adc.com> wrote:

>But when I look in the 'help wanted' section in the newspaper, I don't
>see a single need for a Tcl programmer. This became readily apparent
>when my company cancelled the project on which I was working last
>November.

Vignette development is the section of the paper that is hoovering up TCL
talent (actually, in many cases, converting non-TCL talent into TCL talent,
albeit with much carping...)

--
Rodger Donaldson                rodgerd@diaspora.gen.nz
"Democracy is the worst form of government.  Except, of course, for all
those other forms of government mankind has tried."

well, i have 2 times posted for wanted tcl developers,
and did not get more then a couple of hits.
I guees that means that all are really busy working on.

Mads

Andreas Kupries <a.ku...@westend.com> wrote:
>> What makes you believe this ?

<wowba...@my-deja.com> wrote:
...
>4. Ammendments to the TIP (ie feedback) must be controlled by the TIP
>   author.

As of last week, the TCT approved TIP 13 -- a service for Wiki-style
editing of TIPs that are still in "Draft" state.  See

        http://www.scriptics.com:8080/cgi-bin/tct/tip

Using this service, anyone may add any comment they like to any TIP
during its Draft phase.  Just click on the [Edit] link at the bottom
of the TIP.

--
| Don Porter          Mathematical and Computational Sciences Division |
| donald...@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

It was a two-edged sword.  It actually picked up quite a few people
with the i18n features (mr. nosenko excluded).  Note that AOLServer
uses 8.3 as a base now, whereas they used to require a highly hacked
version of 7.6 (8.0 wouldn't have worked).  I'm not quite sure what
extensions you lost that you're so bitter about.

> > Are you interested?  I can point you out to several jobs.
>
> Please do.

I'll send them in mail if you narrow down what you use Tcl for
(and send a mail address that works...).

Jeff

> > > Hmmm, then you evidently didn't understand the value of
> > > the major features in 8.1 - unicode throughout and fully
> > > ....
> > And you don't acknowledge the negative impact on the TCL community that
> > that decision had. I believe that the momentum went from tcl development
> > (in the community) at this time and it has never been regained.
>

> This Unicode thingie killed tcl development here in Russia (i.e. non-ASCII
> charset) for shure...
> The local mailing list is virtually dead ever since.
>

Extreme happiness?  Really.  They loved the i18n stuff, grimaced a
bit about the canvas postscript thing, then hacked it.  The lack of
IME/XIM support was a problem - they provided patches (which were
incorporated).

I understand your problem with the canvas and lack of printing
support (everybody hates that), but I don't see what's wrong with
generic encoding handling.

Jeff

Shawn

 In article <954fco$lp2$1...@talia.mad.ttd.net>,

Sent via Deja.com
http://www.deja.com/

  ski...@my-deja.com wrote:
> A simple search for tcl on www.dice.com produces 1200+ positions -
>
> Shawn

It could be too simple.  How many perl positions?  c?  c++?
Are these cases where they mention 5 other languages first and then say
it would be nice if you also know tcl, just in case?  I know, its better
than nothing.

If you have to sell your house and move 500 miles, you probably wouldn't
do it.  Geography matters too.  I think they tend to be concentrated in
a few areas.

bob

Sent via Deja.com
http://www.deja.com/

Jeffrey Hobbs wrote:
> I understand your problem with the canvas and lack of printing
> support (everybody hates that), but I don't see what's wrong with
> generic encoding handling.

Jeff, (and Fréderic too, if you're listening!)

Have you heard anything about TkGS lately?  I'd like to work on the
printing problems, but there's no payoff until we have a better
abstraction for the device context.  Printing via PostScript in
Windows is lame.

--
73 de ke9tv/2, Kevin KENNY        GE Corporate R&D, Niskayuna, New York, USA

>  "What's this Tcl stuff anyway?" I would frequently hear. "Shareware?

> That's ridiculous.  Who's going to support field problems?"

My 2cents revolve around these statements/questions from management
and "developers" afraid to take a chance. I was one of those developers at
one time. Wanted to port the test engine we had from Borland C on a PC
to gcc, or whatever, if we had to run it on a Unix box.

Someone showed me the light, though.  Tcl/Tk will never die. Too bad
it just never got the press that Java & Perl received. Had that press been
there, had the books followed, had the core Tcl folks been able to
convince management folks that a nifty set of bound manuals and a
"license" didn't make a good software package, then Tcl would have
done quite well.

Too often developers who like to hide what they do (i often wondered
if they were hiding something) would cozzy up to management and
lament the license & manual argument about Tcl.

DSC (now Alcatel) had a very good thing going when Mark Harrison
was around and the project did all their customer GUIs in Tk.  Sure made
testing easier too. Then he left and the ones left didn't want to have to
"maintain" anything, they just wanted to plug and play with Java.  Testing
on that project, I was last told, has functionality & GUI testing as close
to 100% as one might hope for on any sizeable project. BUT the questions
still persist.

I paraphrase the attitude this way: If I can't spend money on it, it must not
be very good.

> From my POW, some of advantages of 8.1+ over 8.0.5 were good enough reasons
> to stop struggling and switch to VB and Delphi. This and "everything is a
> string" in the object-based world. Other Tcl ex-users and ex-developers have
> other pet  reasons.

I'm working on making everything an object in Tcl.  I've started a page
called Playing Smalltalk at the Wiki.

> No one yet make a table with "number of users who are no
> more " against  "this great new (or old missing) feature", however. It could
> be a great revelation for all concerned, even if only revelation of human
> prejudices.

I agree.
 
> Alexander Nosenko
> <n...@cr.cyco.com>

> > What makes you believe this ?
>

> 4. Ammendments to the TIP (ie feedback) must be controlled by the TIP
>    author.

I had hoped that the Wiki wishlist would be the most valuable way to
contribute ideas and discuss them, but now people have accepted the TIP
style.  I share your concern about the TIP process.  

The Wiki Tcl 9.0 Wishlist:
http://mini.net/cgi-bin/wikit/883.html

>Believe me, there's nothing I would like more than for  Tcl to have the
momentum of Java.

Momentum = management visibility = user visibility = desktops = Windows =
ActiveX + GUI.

How many times and how many people told that... Scriptics never believed,
not a single day.
There are cases where "voluntary efforts" model just doesn't work - it
doesn't produce good enough code fast enough. The "Tcl on Win32" case looks
like one of those.

Alexander

Kevin Kenny wrote:
>
> Jeffrey Hobbs wrote:
> > I understand your problem with the canvas and lack of printing
> > support (everybody hates that), but I don't see what's wrong with
> > generic encoding handling.
>
> Jeff, (and Fréderic too, if you're listening!)

I'm only lurking these days (too busy) until interesting discussions pop up ;-)

> Have you heard anything about TkGS lately?  I'd like to work on the
> printing problems, but there's no payoff until we have a better
> abstraction for the device context.  Printing via PostScript in
> Windows is lame.

That's a coincidence, but I've sent last week to Jeff my preliminary work on
font & text handling. Currently it only consists of an overhaul of existing Tk
features. I discovered that the Unix, Windows and Mac packages were extremely
similar. By reorganizing the code I managed to somewhat separate cross-platform
code, cross platform _algorithm_ and platform-specific stuff. Since it is only
reorganization, there is no loss nor gain of functionality. I rebuilt the whole
stuff on Windows and Unix and it works OK. I believe this is the same for Mac
too but I didn't have time to test it, as I must first configure my environment
(yes, I have a Mac in my office!!!).

I've done all this work in the perspective of integrating the existing Tk code
in TkGS with as much compatibility as possible. Tk's font fallback mechanism is
especially clever so we must keep it as is (or improve it). The goal is to move
the guts in the Tk core and not in the drivers. I could have integrated the
current code directly in drivers and get instant font handling on Windows and
Unix, but the philosophy of TkGS is to incorporate the complexity in the core to
ease driver development. In the case of font handling, moving all the font
handling algorithm to the core allows the drivers to be kept simple (only
providing basic stuff), but also allows other drivers to be implemented much
more easily. Taking the example of the PostScript driver: for now only 8-bit
latin output is implemented by the canvas postscript command. If the PS driver
can tell which font and which glyph to use for which Unicode character, then the
TkGS core will be able to draw any Unicode string provided the character is
present somewhere, the same way Windows Tk can draw Unicode strings by mixing
non Unicode fonts.

About printing on Windows, this is hopefully much simpler, since Windows already
provides some kind of abstraction between display and printer contexts. The work
to be done is mainly at the drawable initialization level. Implementing a draft
printer driver would be interesting since we would also have to work on device
capabilities, introspection, and coordinates systems. A good start would be to
take TkPrint or something similar and rewrite it using TkGS instead of plain
GDI.

For now the main work to be done on TkGS is on the model. We can work on the
draft implementation in parallel, so that they refine each other. Tell me if
you're interested. TkGS definitely needs more grey matter. For now Mo DeJong has
worked on the build system, Jeff has taken care of administrative tasks such as
moving the project to SourceForge, but I am still the only specs writer and
developer., and my schedule doesn't leave me much time to work on it regularily
(it's rather once in a while, like last week).

See you, Fred

--
Frédéric BONNET                          frederi...@free.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
                                                    George Bain

> it forward though).  What Tcl really suffers from is no
> equivalent to CPAN.

Very true! But anyway, tcllib is getting better from day to day!

Sven

--
Microsoft Outlook, the Software which made the "Good Times"
Email-virus Hoax a reality.

/me is giggls@ircnet, http://geggus.net/sven/ on the Web

Alexander Nosenko wrote:
> Momentum = management visibility = user visibility = desktops = Windows =
> ActiveX + GUI.
>
> How many times and how many people told that... Scriptics never believed,
> not a single day.
> There are cases where "voluntary efforts" model just doesn't work - it
> doesn't produce good enough code fast enough. The "Tcl on Win32" case looks
> like one of those.

If you believe that, then *you* (that's you there in the corner) develop
the code necessary.  I personally don't believe it, but I have absolutely
no objection to someone else stepping up to the plate.  If there are
specific changes that are needed, or you wish to get some code distributed
with Tcl on Windows, then by all means pipe up.  (The TCT is 100% not
anti-change!  We just don't believe in busting things that ain't broke...)

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk

"Donal K. Fellows" <fell...@cs.man.ac.uk> wrote:

> If you believe that, then *you* (that's you there in the corner) develop
> the code necessary

A hundred of us rabbits (lurking in the corners) wouldn't make one elephant
in anything but squeeking... (am I politicaly correct ;-?)

Alexander Nosenko wrote:
> A hundred of us rabbits (lurking in the corners) wouldn't make one elephant
> in anything but squeeking... (am I politicaly correct ;-?)

Don't do yourself down.  All it takes to move into centre-stage is a
little effort...

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk
-- He has the intelligence of a small mollusc and the practical experience of
   a split-pea.                               -- Jerry <jerr...@hotmail.com>

> wowba...@my-deja.com wrote:
>> 1. Tips must be approved before being registered.
>> 2. Tips are a formalised process. Once at the end of the process the
>>     document becomes fixed.
>> 3. The structure of the TIP is based around a technical improvement
>>    ie a patch to the code rather than a non technical discussion of
>>    if any changes should be made.
>> 4. Ammendments to the TIP (ie feedback) must be controlled by the TIP
>>    author.
>> 5. There is no visible evidence of anyone being interested in TIPS
>>    other than the TCT and the TIP author.
>>
>> All the above has nothing to to with my desire (among other things) to
>> see some direction come from the TCT as the stimulus for the continued
>> development of TCL.

OTOH, as the person who does the pre-registering vetting, I can assure
everyone here that:
  1. I approve if possible (hey, I check for well-formattedness, spelling,
     some grammar, and general relevance to the Tcl/Tk core.)
  2. Fixing the document at the end is not a bad thing from the PoV of
     people trying to work with it later on.  Working with a target that
     shifts daily is a fool's game...
  3. The web interface lets discussion happen during drafting, but that
     sort of thing is better done elsewhere.
  4. Amendments during drafting can be done by anyone (during the rest
     of the lifespan its at my discretion; I approve of anything reasonable,
     though I might sometimes force a major version change...)
  5. This varies from TIP to TIP.  Some attract loads of discussion, some
     don't.  Mandating that everything attract the same level of discussion
     is just plain daft.

Somehow, I suspect that you've not yet tried out actually using the TIP
system.  It has the advantage that not only do you have a web-publishing
engine to support the dissemination of your ideas, but also web-editing
(to allow feed-back,) CVS archiving of previous versions, and people to
help ensure that the ideas contained in the TIP are brought to the
attention of people likely to be interested.

By contrast, there's no mechanism at all to ensure that ideas on a Wiki
page or in this newsgroup get picked up and passed around people potentially
affected.

>> (development=evolution).

What an interesting assertion.  Good thing this isn't talk.religion.*  :^)

> I had hoped that the Wiki wishlist would be the most valuable way to
> contribute ideas and discuss them, but now people have accepted the TIP
> style.  I share your concern about the TIP process.
>
> The Wiki Tcl 9.0 Wishlist:
> http://mini.net/cgi-bin/wikit/883.html

That wishlist is reaching unworkable proportions with all the discussion
inside it (a common-enough problem with many Wiki pages.)  Perhaps I should
refactor...?

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk
-- He has the intelligence of a small mollusc and the practical experience of
   a split-pea.                               -- Jerry <jerr...@hotmail.com>

"Donal K. Fellows" <fell...@cs.man.ac.uk> wrote :

> Don't do yourself down.  All it takes to move into centre-stage is a
> little effort...

Umm... not so little, really. I've considered the cost of implementing the
level of ActiveX support I'd like to see in Tcl. It amounted to integrating
tcom and optcl with Active Scripting Engine things added, some patching of
the core and objects as a first-class sitizens (Featherish ?). With my level
of qualification it's 4+ months of work. The worst thing is that this
project can't be factored into smaller ones, at least not with classic
"bazaar" model.  Taking into account the fact I'm paid for Delphi
programming and our QC group uses VB for test scripts...

The serious Tcl enhancements (not just small add-ons, patches and testing)
at 8.0 and later require too high "entrance fee" in terms of qualification,
time and resources required.  That fee in many cases can't be paid by
individual developer without management's support. The management's support
of Tcl is... well... (sad smile)

Alexander
---
A big white elephants departed for greener pastures...

<flame>
What do you mean, at _that_ time?  Are you somehow implying that there
are not continuing Java instabilities, particularly in GUI development?
I've yet to find a Java application that I could a) get to work right,
and b) get to work right the first time...  my platform is SPARC Solaris 8,
and I would have thought that at least Sun would have some apps out
demonstrating the worth of using Java.  But perhaps I just haven't looked
in the right places.
</flame>

:would frequently here. "Shareware? That's ridiculous. Who's going to

:support field problems?" Customer, or potential customer, comments

<smile> Where did the shareware comment come from - Tcl and iTcl are
not shareware...  Of course, freeware / public domain / etc. get even
WORSE management reactions.</smile>

:Regardless of the popular opinion around the area and the cold reality

:that I would likely not be able to get a full-time job again doing tcl
:programming,

I assume you mean "would likely not ... programming with my current employer"?
Because I can't imagine you would have problems getting on elsewhere...

:But when I look in the 'help wanted' section in the newspaper, I don't

:see a single need for a Tcl programmer.

You're looking in the wrong places ...  if someone is looking for Tcl
work, I suspect there are those here on the newsgroup who can point people
off to work.  

:when I announced this in November. The encouragement and potential job

:offers were overwhelming. But alas, nothing really in my area.

Geographic area, or expertise area?

:here and finish some contractual obligations to existing customers. But

:my days to get paid for Tcl programming are unfortunately numbered.

Have you checked the various 'big' internet based job search services?
I checked a few months ago (when I was looking to fill a spot) and had
quite a number of hits come up nationwide ...

:Tcl to have the momentum of Java. Maybe it's just the Dallas area? I

:hope so, but I'm inclined to think not.

Interesting - just in the past 4 weeks I've seen several jobs locally
which listed Tcl as a desirable skill, along with C, perl, etc.

--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

What aspects of CPAN are desirable?

I can imagine one of the following being on the list:

Having a common place for people to download many pieces of tcl code?
Sounds like either Neosoft or SourceForge to me

Having behind the scenes mapping from a generic name to a specific archive site?
Currently we don't have multiple mirroring archive sites as far as I am
aware, so that seems less useful

Having a software interface that assists with downloading appropriate
pieces of software and builds it?  The CPAN software is only a tiny piece
of that and doesn't seem like it would be all that tough - what we need
is a flat file (XML anyone) description of each package and its requirement.
Voluminous - yes.  Rocket Science - unlikely.   Anyone going to step forward
and do this?  Unknown...

--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

:  ski...@my-deja.com wrote:
:> A simple search for tcl on www.dice.com produces 1200+ positions -
:>
:> Shawn
:
:It could be too simple.  How many perl positions?  c?  c++?
:Are these cases where they mention 5 other languages first and then say
:it would be nice if you also know tcl, just in case?  I know, its better
:than nothing.

So what is desired is positions where Tcl is the only language used?  Doesn't
seem very likely - the only type position around here like that was a few
Java only positions to get a project or two seeded.  In most cases, we
look for people with C and Unix experience, with perl/tcl/sql plus/etc. as
beneficial talents.

--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

>Having a software interface that assists with downloading appropriate
>pieces of software and builds it?  The CPAN software is only a tiny piece
>of that and doesn't seem like it would be all that tough - what we need
>is a flat file (XML anyone) description of each package and its requirement.
>Voluminous - yes.  Rocket Science - unlikely.   Anyone going to step forward
>and do this?  Unknown...

Cameron Laird <claird@NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html

:Alexander Nosenko wrote:
:[snip]
:> From my POW, some of advantages of 8.1+ over 8.0.5 were good enough reasons
:> to stop struggling and switch to VB and Delphi.

So you obviously are looking for a Windows only programming language, since
you won't be able to get VB or Delphi to run on most Unix platforms nor,
in general, MacOS, VMS, etc.

Some people are bothered by this next viewpoint, but I say "Good for you!"
It's great to move on to a better language for what you want.  I've
seen many people express the opinion that VB, Delphi, perhaps a few other
languages, were significantly farther along in their support of developing
Windows apps than Tcl/Tk .  Until more bodies come along to start coding
more support for Windows, the Tcl/Tk level of support will continue to
improve at its current rate.

--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

Alexander Nosenko wrote:
> > Don't do yourself down.  All it takes to move into centre-stage is a
> > little effort...
>
> Umm... not so little, really. I've considered the cost of implementing the
> level of ActiveX support I'd like to see in Tcl.

One of the problems with Open Source is this. If there's a feature worth $50
to 1000 people, but it costs $500 to implement it, it's unlikely to happen
with open source and much more likely to happen with commercial software.

--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.
"It says this wine has syphilis."
               "I think that's pronounced `sulphates'."

In article <3A76F63E...@san.rr.com>, Darren New  <dn...@san.rr.com> wrote:
>Alexander Nosenko wrote:
>> > Don't do yourself down.  All it takes to move into centre-stage is a
>> > little effort...
>>
>> Umm... not so little, really. I've considered the cost of implementing the
>> level of ActiveX support I'd like to see in Tcl.
>
>One of the problems with Open Source is this. If there's a feature worth $50
>to 1000 people, but it costs $500 to implement it, it's unlikely to happen
>with open source and much more likely to happen with commercial software.

> So you obviously are looking for a Windows only programming language,
since
> you won't be able to get VB or Delphi to run on most Unix platforms nor,
> in general, MacOS, VMS, etc.

Well, there are good chances to see Delphi on Unix soon and I never saw a
living soul who ever saw VMS :-)

Alexander.
--
Is application that works on 99% of existing computers portable?

Tcl was not well done on making it ubique available even if it is an open
source. For example, perl and its new version is distributed on RedHat's
and SuSe's latest Linux. Tcl that was distributed and installed on many
ISPs are just 7.6. And usually ISPs are refused to install Tcl. Perl
together
with Apache is default installation on a web server. On Windows and
Mac Tcl are far more less necessary. Tcl went to the corner.

But Tcl is not dead. When we can figure out why Tcl is going to the hell
we can change direction.

Chang LI
Neatware

Chad Smith wrote in message <3A75A9B3...@adc.com>...

>Once upon a time not too long ago I was an everyday tcl programmer -
>well actually I was an everyday [incr Tcl] programmer. I was hired in
>1996 at my current company to be "the Tcl expert". Upon being hired it
>was up to me to build the GUI of a hotshot new networking product based
>on ATM technology. What a cool position to be in! I naturally chose
>[incr Tcl] as my base language for all the reasons I'm sure everyone's
>heard: maintainability, scalability, flexibility, etc. etc, as opposed
>to using a function-oriented approach.
>
>I was happy as a lark for the next 2 years. But then things started
>changing a little. I started to get pressured on why I hadn't chosen

>Java. (My manager selected Tcl for the simple reason that Java was too

>would frequently here. "Shareware? That's ridiculous. Who's going to
>support field problems?" Customer, or potential customer, comments

>
>Regardless of the popular opinion around the area and the cold reality
>that I would likely not be able to get a full-time job again doing tcl

>
>But when I look in the 'help wanted' section in the newspaper, I don't

>when I announced this in November. The encouragement and potential job

>here and finish some contractual obligations to existing customers. But
>my days to get paid for Tcl programming are unfortunately numbered.
>

>Tcl to have the momentum of Java. Maybe it's just the Dallas area? I
>hope so, but I'm inclined to think not.
>

In my current job (Boeing Satellite Systems), Tcl/Tk is being used
extensively for development of internal test executives for Satellite
payload testing. I'm the local Tcl/Tk advocate, and certainly enjoy
the ease in which I can create powerful applications for our internal
customers. Yet I know my next position probably won't include Tcl/Tk.

For my self preservation, I'm trying to build my Java expertise (for
which there are A LOT of jobs posted). What better way to accomplish
this then by using Java in my Tcl/Tk applications (via Tclblend). I
get to use Tcl and learn Java at the same time.

Tcl/Tk will always have a special place in my heart, but unfortunately
it'll never have the general respect that C/C++/Java gets. Oh well.

Marty

On Mon, 29 Jan 2001 11:34:43 -0600, Chad Smith <chad_...@adc.com>
wrote:

>Alexander Nosenko wrote:
>>
>>  Different people could have different reasons for not developing Tcl
>> anymore, or even not using it anymore. Does Tcl community have clear
>> understanding of those reasons? What about a  "Why do you dropped TCL" poll
>> in this newsgroup (and others too)?

Chang LI wrote:
> For example, perl and its new version is distributed on RedHat's
> and SuSe's latest Linux. Tcl that was distributed and installed on many
> ISPs are just 7.6.

Actually, tcl 8.3 comes with redhat 7 and installed by default...

George

Petasis George wrote:
> Actually, tcl 8.3 comes with redhat 7 and installed by default...

It's a little unfortunate that redhat7 is a disaster area for other
reasons (distributing a development compiler and libc?  <shudder>)

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk

> Actually, tcl 8.3 comes with redhat 7 and installed by default...

wheras the binary rpm is compiled to a binary rpm by means of a perl
script...

Sven

--
end
The content of this message is for serious Newsreaders only...
(Hint: probably you are reading the signature only, not the message itself)

/me is giggls@ircnet, http://geggus.net/sven/ on the Web

> Petasis George <pet...@iit.demokritos.gr> wrote:
>
> > Actually, tcl 8.3 comes with redhat 7 and installed by default...
>
> wheras the binary rpm is compiled to a binary rpm by means of a perl
> script...

Could you please explain the sentence above? I am having some trouble
understanding...

>
> Sven
>

--
Jean-Luc Fontaine mailto:jfon...@winealley.com http://www.winealley.com

> I agree with much of what you've said. My sense is that Tcl/Tk is used
> a lot in industry, but very little in delivered products. And most of
> its use is in 'tool' development. So it's looked upon as a software
> tool to facilitate getting your job done. You don't see many
> advertisements for Tcl/Tk, just as you don't see ads for AWK
> programmers. It's a tool.
>
> In my current job (Boeing Satellite Systems), Tcl/Tk is being used
> extensively for development of internal test executives for Satellite
> payload testing. I'm the local Tcl/Tk advocate, and certainly enjoy
> the ease in which I can create powerful applications for our internal
> customers. Yet I know my next position probably won't include Tcl/Tk.

Testing is a very popular area for Tcl (demonstrating one of its
many strengths).  However, it's embedded in many delivered products -
most often where you never recognize it, or see it.  StoryServer is a
fairly obvious example, but it's in parts of most major CAD software,
routers have it embedded (older Tcl versions), and I've personally
worked on several products that used it in the deliverable.

> For my self preservation, I'm trying to build my Java expertise (for
> which there are A LOT of jobs posted). What better way to accomplish
> this then by using Java in my Tcl/Tk applications (via Tclblend). I
> get to use Tcl and learn Java at the same time.
>
> Tcl/Tk will always have a special place in my heart, but unfortunately
> it'll never have the general respect that C/C++/Java gets. Oh well.

I've come to the realization that there are so many more Java jobs
than Tcl jobs because it takes 10 Java programmers to do what I
can do in Tcl.  I'm only half-joking...

How's it supposed to get the respect of management if you've got
just one guy working on the project?  It's much more impressive to
have a battery of programmers slaving away.

Jeff

"Donal K. Fellows" wrote:
>
> Petasis George wrote:
> > Actually, tcl 8.3 comes with redhat 7 and installed by default...
>
> It's a little unfortunate that redhat7 is a disaster area for other
> reasons (distributing a development compiler and libc?  <shudder>)
>
> Donal.

Oh come on Donal. I know Red Hat bashing is the in thing
to do currently, but really do you have a better idea?
Perhaps folks should always just stick with the "stable"
and "well tested" release of packages. Like, shipping Tcl
7.6 for example. You just can't have it both ways.

Mo DeJong
Red Hat Inc

>I've come to the realization that there are so many more Java jobs
>than Tcl jobs because it takes 10 Java programmers to do what I
>can do in Tcl.  I'm only half-joking...
>
>How's it supposed to get the respect of management if you've got
>just one guy working on the project?  It's much more impressive to
>have a battery of programmers slaving away.

Jeff gets my nomination for QOTW.

--
Tom Poindexter
tpoi...@nyx.net
http://www.nyx.net/~tpoindex/

> Jeffrey Hobbs wrote:
> > I understand your problem with the canvas and lack of printing
> > support (everybody hates that), but I don't see what's wrong with
> > generic encoding handling.
>

>
> Have you heard anything about TkGS lately?  I'd like to work on the
> printing problems, but there's no payoff until we have a better
> abstraction for the device context.  Printing via PostScript in
> Windows is lame.

Frederic and Mo are working on it.  It's true that abstraction for
the device context will make printing easier on Windows (and Mac
I believe), but it really does require playing around with the
fundamental structure of how Tk was designed.

Jeff

Tom Poindexter wrote:
>
> In article <vxzog7l...@scriptics.com>,
> Jeffrey Hobbs  <ho...@scriptics.com> wrote:
>
> >I've come to the realization that there are so many more Java jobs
> >than Tcl jobs because it takes 10 Java programmers to do what I
> >can do in Tcl.  I'm only half-joking...
> >
> >How's it supposed to get the respect of management if you've got
> >just one guy working on the project?  It's much more impressive to
> >have a battery of programmers slaving away.
>
> Jeff gets my nomination for QOTW.
>

I second that.  :)

However many ISPs did not install Tcl in their systems and RedHat 7 has not
been widely accepted as a "worked" system. I have installed Tcl 8.3.2 and
made
it available on an ISP. It was last year. Now I forgot the procedure. Later
when
I need to use it I will write it on the paper. Is it possible to write a
file to make it
install by just typing a command? For example, type tcl832, it will prompt
which
directory you want to install and everything will be done.

Chang LI
Neatware

Petasis George wrote in message <3A77BFF9...@iit.demokritos.gr>...

>Marty Backe <mgb...@usa.net> writes:
>
>I've come to the realization that there are so many more Java jobs
>than Tcl jobs because it takes 10 Java programmers to do what I
>can do in Tcl.  I'm only half-joking...
>

It is not joking.

>How's it supposed to get the respect of management if you've got
>just one guy working on the project?  It's much more impressive to
>have a battery of programmers slaving away.
>

In the real world you can find many things that are anti-productivity.
If you finished a project quickly with a good tool manager may think
it is too simple. Even if a project can be finished by one person they
ask two or more persons. They think Ford's pipeline model is suitable
for software engineering. So where can they find dozen Tcl
programmers than Java programmers?

Chang

>Jeff

Well, I have not really done anything with TkGS lately except
reporting some bugs and make sure it builds and loads properly.
Frederic was doing all the coding, but he has been working
on a PhD so I don't know if he will be able to contribute
much in the near future. TkGS is a project that needs more
contributors.

Mo DeJong
Red Hat Inc

Sorry about that Mo, but Donal has a point :-)
RH 7 as shipped initially had many problems.
Including a thread bug in glibc that caused many
threaded apps (even xmms) to crash. Of course not an
unusable version, but had quite a few minor problems
that took me some time to fix them (like a tv-card,
or the presence of a cd-r that used all drives
from the scsi module). Its not about bashing redhat,
but 7 had (and still has) some problems...

George
If you don't like something, you don't use it.

Sven Geggus wrote:
>
> Petasis George <pet...@iit.demokritos.gr> wrote:
>
> > Actually, tcl 8.3 comes with redhat 7 and installed by default...
>
> wheras the binary rpm is compiled to a binary rpm by means of a perl
> script...
>

George

Jean-Luc Fontaine <jfon...@winealley.com> wrote:
>> wheras the binary rpm is compiled to a binary rpm by means of a perl
>> script...

> Could you please explain the sentence above? I am having some trouble
> understanding...

Shure, the first "binary" should have been replaced by "source". (one should
probably not post News in bed with a cold...)

Binary Redhat Packages (rpms) are build by means of original sources, a
description File (the spec file) and probably some patches. These components

The spec file usualy contains some bash script code as well.

In case of the RH7 tcl rpm this script code is mostly written in perl.

Sven

--
"I'm a bastard, and proud of it"
                          (Linus Torvalds, Wednesday Sep 6, 2000)

/me is giggls@ircnet, http://geggus.net/sven/ on the Web

> Jean-Luc Fontaine <jfon...@winealley.com> wrote:
> >> wheras the binary rpm is compiled to a binary rpm by means of a perl
> >> script...
>
> > Could you please explain the sentence above? I am having some trouble
> > understanding...
>
> Shure, the first "binary" should have been replaced by "source". (one
> should probably not post News in bed with a cold...)

There are indeed better things to do in a bed...

 
> Binary Redhat Packages (rpms) are build by means of original sources, a
> description File (the spec file) and probably some patches. These
> components
>
> The spec file usualy contains some bash script code as well.
>
> In case of the RH7 tcl rpm this script code is mostly written in perl.

True, as perl is now considered to be a standard feature...
But it is not needed, if you look at the following Tcl 8.3.2 spec file:
http://jfontain.free.fr/tcltk-8.3.2-3.spec

--
Jean-Luc Fontaine mailto:jfon...@winealley.com http://www.winealley.com

Is it possible to write a  file to make it install by just typing a command? For
example, type tcl832, it will prompt
| which | directory you want to install and everything will be done.
|
| Chang LI
| Neatware
|

Has anyone looked at freedelivery http://freewrap.sourceforge.net/freedelivery.html
for automated installation on Linux?

Tom Wilkason

Chang LI wrote:
> In the real world you can find many things that are anti-productivity.
> If you finished a project quickly with a good tool manager may think
> it is too simple. Even if a project can be finished by one person they
> ask two or more persons. They think Ford's pipeline model is suitable
> for software engineering. So where can they find dozen Tcl
> programmers than Java programmers?

I wish I was less cynical so I could disagree...

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk

:> not shareware...  Of course, freeware / public domain / etc. get even
:> WORSE management reactions.</smile>
:
:Not from my management. They know if I say "hey, I have a problem. I've
:put a call out on C.L.T. so I should have an answer by tomorrow", that
:when tomorrow comes, so does the solution.

Management at others sites have been know to say things like "but who will we
call on the phone when some catastrophe call"?  When given names of people
like CPU, Cygnus, etc.  the response is "but I've never heard of them" or
"they are not a major vendor/player"...  It is rumored that what many of
these cases REALLY mean is "who will we threaten to sue if something
goes wrong and it can't be fixed..."

--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

On  2 Feb, lvi...@cas.org wrote:
>
> :> <smile> Where did the shareware comment come from - Tcl and iTcl are
> :> not shareware...  Of course, freeware / public domain / etc. get even
> :> WORSE management reactions.</smile>
> :
> :Not from my management. They know if I say "hey, I have a problem. I've
> :put a call out on C.L.T. so I should have an answer by tomorrow", that
> :when tomorrow comes, so does the solution.
>
> Management at others sites have been know to say things like "but who will we
> call on the phone when some catastrophe call"?  When given names of people
> like CPU, Cygnus, etc.  the response is "but I've never heard of them" or
> "they are not a major vendor/player"...  It is rumored that what many of
> these cases REALLY mean is "who will we threaten to sue if something
> goes wrong and it can't be fixed..."

I don't think it's a rumour.

L

--
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK

Laurent Duperval                 "Montreal winters are an intelligence test,
                                         and we who are here have failed it."
mailto:laurent....@netergynet.com                          -Doug Camilli
Penguin Power!         ***Nothing I say reflects the views of my employer***

That's a sore point as well - the 'owner' of the language being 'absorbed'
shortly after renewing maintenance contracts for a product (TclPro).

--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

Certainly you are going to see more cases of Tcl skills as secondary than
primary.  However, just this week here on comp.lang.tcl someone was looking
for Tcl programmers to work from Vegas.

--
--
"See, he's not just anyone ... he's my son."  Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting

I totally agree with this strategy.  Also, you don't want to aim too
high.  tcl is a quantum leap over basic scripting languages such as ksh
for simple jobs such as tools.   At the same time, many thousands of
people are trained to use ksh and are out there using it to create
sluggish, inefficient tools.  In my experience, tcl scripts run 5X to
20X faster and can do many more things.  Still, you never see
comparisons between tcl and ksh which would suggest using tcl instead.
Tools may not be as exciting as high end apps, but the people who write
these tools buy books, take classes, and have jobs.  We need to keep up
the demand for books or the ones that exist now will not be updated and
new ones will not be written.

bob

Sent via Deja.com
http://www.deja.com/

Java doesn't work.

I posted to that effect on the java group, and I got answers that basically
amounted to:  no, it doesn't.  But no one summarized:  well, then, we've
agreed -- Java doesn't work.

There are four reasons why I say that Java doesn't work.

1.  The demo they ship with the distribution doesn't work on a reasonably
configured Windows 98 system.  A fellow on the newsgroup said it worked on
his 64Mb system.  On my 32 Mb system, the editor demo fails.  The system
freezes up.  This behavior is not unique to me; other people on the newgroup
got the same results.

2.  If you use Sun's distribution for Microsoft's system, you can watch your
keypresses echo.  Even in the 1.3 release, that they told me to wait for
because "client systems are handled better."

3.  If you use Microsoft's distribution, there is no Swing.  The rest of the
world is touting Swing.

4.  Sun and Microsoft don't agree on what is correct behavior.  Or, the
Microsoft version has some bugs.  One example is difference of treatment of
insets and menubars.

After spending a year messing with Java, we moved the project to Tcl/Tk.
Guess what?  It works.

        Rick

"Jeffrey Hobbs" <ho...@scriptics.com> wrote in message
news:vxzog7lbck.fsf@scriptics.com...

> Marty Backe <mgb...@usa.net> writes:
> > For my self preservation, I'm trying to build my Java expertise (for
> > which there are A LOT of jobs posted). What better way to accomplish
> > this then by using Java in my Tcl/Tk applications (via Tclblend). I
> > get to use Tcl and learn Java at the same time.

Rick Hedin wrote:
>
> Okay, I can't stand this anymore.  I know I'm the only person in the
> multiverse who feels this way, but I'm going to say it.
>
> Java doesn't work.

...

> After spending a year messing with Java, we moved the project to Tcl/Tk.
> Guess what?  It works.
>
>         Rick

I think if you changed that to "GUIs in Java don't work", you
would get a lot more folks to agree with you. Doing a GUI in
Java is torture, there is no other way to put it.

I would really like to write an article about your experiences
and why you switched to Tcl/Tk for your application. Would you
be interested in providing such info? There has been talk on
the tcl-pubs mailing list about the kinds of articles that
"should" be out there, your story sounds like one of them.

Mo DeJong
Red Hat Inc

Actually, I have the same feelings about java.
I my group (in a research institute) we mainly focus on natural
language processing (NLP) and machine learning. During research projects,
various needs arise. From my observations, only tcl has
fullfilled all of them :-)

I have written a NLP platform that is based only on Tcl. This
allows components that do linguistic processing to be dynamically
embeded into it (like ones written in tcl that can be sourced,
or ones written in C++ and loaded as tcl extensions).
The fact that tcl was used offered a large set of possibilities:
like interfacing with web through tclhttp, accessing databases
through tclodbc or even embeding our whole platform under
word with tclcontrol. My point here is that although tcl
is totally cross-platform (and in my opinion the only cross-platform
solution available today) there is a vast set of resources that allow
to do anything, even platform-depended stuff. Java does not seem to
be ready for all these. Its gui is difficult to develop and maintain
while does not behave the same under all platforms. Memory requirements
are enourmous. JNI is still not supported by all vendors. JDK's exist
for only a few platforms.

For example, for a research project, our tcl tools have to interface with
some databases (ms access and postgress). This was really trivial to do with
tcl. In a single day the scripts were ready and working. Now, these
databases
have to be interfaced by a java gui (actually a moc-up that took 2 months
to be developed with JBuilder :-)). After two weeks, we have not yet found a
way to make java ODBC bridge utilise the correct encoding for opening the
database
and read the greek data stored in there...

Of course I expect java to improove over time. But the same will also
happen to tcl. But the fact is that right now java is not ready for all
these.
For me tcl offers more things than java. And the fact that I have to compile
some things when changing platform is nothing in front of the time
I save writting tcl and the *working* solutions the tcl community
offers...

George

Petasis George wrote:
> Of course I expect java to improove over time. But the same will also
> happen to tcl. But the fact is that right now java is not ready for all
> these.
> For me tcl offers more things than java. And the fact that I have to compile
> some things when changing platform is nothing in front of the time
> I save writting tcl and the *working* solutions the tcl community
> offers...

By contrast we've had a lot of success using Java in our project.  But
there are a few points that should be noted: the thick client is in pure
Tcl/Tk, the server is 100% Java, no database or web resources were used,
and the connection between client and server is done with raw sockets
(incidentally, TCP networking is as easy in Java as in Tcl and vice
versa, in stark comparison with many other languages I could name but
won't...)

Donal.
--
Donal K. Fellows    http://www.cs.man.ac.uk/~fellowsd/    fell...@cs.man.ac.uk