: http://www.interwoven.com/news/press/2000/1020ampr.html
Uh oh.. I can't see that leading to anything good for the Tcl community
now (and at a critical stage when the Tcl community is being separated
from Ajuba). I can't see Interwoven having any real interest in working
on Tcl.
Note:
"The Ajuba team represents a concentration of XML, Java and eBusiness
integration talent"
It's Java they're talking about.
--
- ---------- = = ---------//--+
| / Kristoffer Lawson | www.fishpool.fi|.com
+-> | se...@fishpool.com | - - --+------
|-- Fishpool Creations Ltd - / |
+-------- = - - - = --------- /~setok/
> I'd be *very* interested to hear
> the Tcl Guys' comments on this development:
>
> http://www.interwoven.com/news/press/2000/1020ampr.html
Indeed. There is no mention of Tcl in the above announcement.
--
Jean-Luc Fontaine mailto:jfon...@winealley.com http://www.winealley.com
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
I remember the sinking feeling I had when I hit the Scriptics
site late one Sunday evening and found Ajuba instead.
I was *wondering* why dev.scriptics was down this Sunday and
why TclURL hadn't been updated lately.
Just a guess, but the lawyers and beancounters have no
idea what Tcl is, and they might just end up throwing it
back to Berkely, which is fine with me. What we need is
smart CS students with resources and time behind them
to help out!
Just don't let the sharks know there's anything worth eating
in the water!
Cheers,
Ralph Hempel - P.Eng
------------------------------------------------------
The train stops at the train station,
The bus stops at the bus station,
So why am I sitting at a work station?
------------------------------------------------------
Sent via Deja.com http://www.deja.com/
Before you buy.
well, that provides a nice exit for both the investors in ajuba as
well as some of the key people. that should leave (after some
transition period) a group of people less interested in b2b and
more interested in continuing work on tcl, who don't stay at
interwoven. potentially with some cash in their hands, and fresh
from the cynicism of vc-funded startup life, that may provide the
seeds of some very exciting new opportunities for tcl.
mark
--
Mark Roseman <ros...@teamwave.com>
http://www.teamwave.com
TeamWave Software Ltd.
-John-
Roy Terry wrote:
>
> I'd be *very* interested to hear
> the Tcl Guys' comments on this development:
>
> http://www.interwoven.com/news/press/2000/1020ampr.html
________________________________________________________________________
John Ousterhout 650-210-0102 tel
Chairman and Chief Technology Officer 650-230-4070 fax
Ajuba Solutions ous...@ajubasolutions.com
http://www.ajubasolutions.com
I'm sorry, but this seems rather far fetched.
Volker Hetzer wrote:
>
> Roy Terry wrote:
> >
> > I'd be *very* interested to hear
> > the Tcl Guys' comments on this development:
> >
> > http://www.interwoven.com/news/press/2000/1020ampr.html
> Maybe they can get interwoven to hand tcl back to berkeley?
>
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Not that I really understand how an Ajuba statement could make much
difference on how things end up. It's difficult to see how this could
be good for Tcl. Strategically it's rather bizarre:
- Tcl is only now slowly becoming a community product instead of
a Scriptics one. This has not taken place yet and wont for a while,
especially in the mindset of potential developers and users.
- I'm pretty sure it will be more difficult to convince the Interwoven
people that having a strong focus on Tcl and developing is a good idea.
They just want some XML expertise and, based on their own statement, Java.
I find it very difficult indeed to believe Tcl will have the same status
with Interwoven that it has had with Ajuba.
- You have just rebranded yourselves and you have just completed
refocusing yourselves. How can this be a good time to sell off the company?
Unless the whole purpose of rebranding was to find someone to buy up
Scriptics.
I'm sure the Ajuba folk made some good money out of it, but it's hard to see
how this will benefit Tcl -- or even Ajuba -- in the mid- to long-term.
Iiiiiinnnnnnnteresssssstinggggggg.....
Interwoven is a big competitor to Vignette. Vignette uses Tcl as a core
component of its flagship product. I can't wait to hear how this one turns
out. Thank goodness Tcl is open source! I'm amazed I haven't heard anything
about this internally. Maybe nobody knew. Or maybe it's a no-op for us and
the tcl community, since the press release sounds like Interwoven isn't
interested in the tcl part of the aquisition.
I hope John, Jeffrey, Brent, et. al. made a bundle on the deal! In my mind
this certainly legitimizes what the Ajuba team has been able to accomplish
with tcl as a tool for managing XML. To bad the press release didn't mention
Tcl. That should have been a condition of the sale...
--
Bryan Oakley Vignette, Corp
boa...@vignette.com http://www.vignette.com
http://purl.oclc.org/net/oakley
Huh?
I guess I fail to see the logic there. So Ajuba
is no more. There was already some writing on
the wall when they changed the company name from
Scriptics to Ajuba.
I guess I don't see what folks are so worked up
about. It is not as if Tcl is totally dependent
on Ajuba or anything. In case you have not been
following the news lately, there is now a
governing body in place to manage the
future of Tcl. It is made up of a number of
people who have an interest in what is best
for Tcl.
Tcl was around long before Scriptics/Ajuba
ever existed, and it will be around
long after.
Mo DeJong
Red Hat Inc
We have finally updated our www.ajubasolutions.com website
with what we can say about the acquisition.
http://www.ajubasolutions.com/company/whatsnew.html
This is of course a good news/bad news scenario. The good news
is that several interesting bits of our technology will begin to
appear in open source. The bad news is that Ajuba/Interwoven won't
be funding Tcl development as before. More good news is that the
Tcl Core Team is now a group of 14 folks from a variety of
companies who's job is to help *you* help Tcl.
The Tcl web site, http://dev.scriptics.com/, er, uh,
http://dev.ajubasolutions.com (both work) will continue during
a transition period while we set up "tcltk.org", as will our
FTP repository.
One more bit. Ajuba employees (including, Jeff and myself)
only found out about this less than two weeks ago, and the
"definitive agreement" was signed only last Thursday.
So, I apologize that we couldn't say more sooner, but it's
best to proceed carefully during deals like this.
Brent Welch
we...@ajubasolutions.com
That's what I used to tell my girlfriends when they acted all sad and
concerned as they were dumping me. :-)
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***
Thanks for the update, Brent.
FWIW, I vote for open source TclPro. It is a nice set of tools, even if
Interwoven isn't interested in them as a product. Perhaps someone could
explain to "management" that open-sourcing TclPro could actually help
reduce Ajuba/Interwoven's "existing support obligations."
Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html
>Mark Roseman <ros...@teamwave.com> wrote:
>: well, that provides a nice exit for both the investors in ajuba as
>: well as some of the key people. that should leave (after some
>: transition period) a group of people less interested in b2b and
>: more interested in continuing work on tcl, who don't stay at
>: interwoven. potentially with some cash in their hands, and fresh
>: from the cynicism of vc-funded startup life, that may provide the
>: seeds of some very exciting new opportunities for tcl.
>
>I'm sorry, but this seems rather far fetched.
Doesn't seem so far fetched to me.
--
David Gravereaux <davy...@ajubasolutions.com> Yet Another Tcl Guy
Sustaining Engineer (Tech Support) Ajuba Solutions
http://dev.ajubasolutions.com/doc/integration.html#Tcl (650) 230-4079
Well, this development has made my job that much harder.
Actually, it has made hard again what had become much easier.
What I'm talking about is convincing management to take a
chance on Tcl/Tk. At least, I didn't read in the various
press statements anything concrete regarding the continuance
of any Tcl support contracts.
An issue that is always brought up by management is technical
support. Granted, management is happy with the tools and
applications I develop. When it comes time to make a tool
a deliverable to the customer, the same questions arise. It
is pointed out to me that I may not be available to provide
support if (shudder) Tcl/Tk should break. Who will step up to
provide support (or take the blame) then? With Scriptics/Ajuba
in existence, and their Tcl/Tk support contracts, it became
much easier to pitch Tcl convincingly where management was
concerned.
Now, I strongly believe that for any Open Source package to
gain acceptance in an organization, someone has to be a
champion for that package. I have become that champion for
Tcl/Tk where I work. Still, having that additional "support
contract" backup made it much easier for management to buy
into Tcl/Tk versus more popular and visible packages like
Perl and Java. Note that I didn't say better packages, but
management isn't always concerned with what is technologically
the "best". Rather what interests them is what technology
won't end up "biting them in the butt" in the future.
My perception is that it has been a constant uphill battle
trying to increase the mindshare of "the best kept secret in
programming": Tcl/Tk. After all of the efforts that have
been put forth on the behalf of Tcl/Tk, I still don't see many
articles published on Tcl/Tk (maybe I just don't subscribe to
the right trade journals). I do see plenty of articles on
Perl, Java, Javascript, and (to a lesser extent) Python and
PHP.
The Tcl Consortium has come and gone. Now, the flagship Tcl
company is dropping Tcl/Tk via its assimilation by Interwoven.
A disturbing trend continues. Perhaps true OpenSource
development via the TCT on SourceForge is the best thing for
Tcl/Tk. Obviously, grass root advocacy of Tcl/Tk has become
more important than ever!
Disgruntled in Dallas,
Mac A. Cody
>Now, I strongly believe that for any Open Source package to
>gain acceptance in an organization, someone has to be a
>champion for that package.
Looks like this leaves a market place for a new business opportunity for
someone...
Honestly, we didn't sell many incident based or gold support packages.
The dev site was down because of a random glitch. The AOLserver
there seems to need to restart itself (it runs out of inittab ...)
and occasionally fails to bind to its port upon startup. This has
happened two or three times since we started using it in February.
To be fair, we are not using the final 3.0 release of AOLserver
on that site. (Our www.ajubasolutions.com site runs TclHttpd.)
The maintainer of our TclURL repository has simply been on vacation.
So far, my limited contact with the Interwoven folks has been positive.
> Just a guess, but the lawyers and beancounters have no
> idea what Tcl is, and they might just end up throwing it
> back to Berkely, which is fine with me. What we need is
> smart CS students with resources and time behind them
> to help out!
"Throwing back to Berkeley" doesn't make much since seeing as
how John Ousterhout left there in 1994. John has worked hard
to set up the Tcl Core Team as a cooperative group of folks
that are charged with watching over Tcl's future development.
Our goals is to foster all those smart grad students, engineers,
and "old hands" so we can continue to maintain Tcl as an
excellent platform.
> Just don't let the sharks know there's anything worth eating
> in the water!
True - their bean counters don't value Tcl the way you and I do!
The Interwoven engineering team broke into spontaneous applause
when they heard John O. was joining their organization. They
have a top-notch team, and most of us (I speak only for myself,
of course) are looking forward to working with them on some cool
new stuff. Frankly, I have a very limited view of what I'll
be doing there, if I'll be using Tcl or, gasp, Java, or, gack,
Perl. But, Tcl is first in my heart and I'll do what I can to
help it along in the future.
Brent
Define "product", and please read
http://dev.scriptics.com/advocacy/tclHistory.html
Tcl has been a freely-available "product" since John made
his first releases in 1988. I urge the paranoid folks out there
to relax and let Tcl go forward based on the fundamentally
awsome properties that it has. It has had a tremendous slingshot
since the Sun days when as many as 10 engineers helped port it
to Windows, Macintosh, and the Java platform, and more recently
as Scriptics/Ajuba created great tools and pushed the envelope
for using Tcl has a robust product platform.
> - I'm pretty sure it will be more difficult to convince the Interwoven
> people that having a strong focus on Tcl and developing is a good
idea.
> They just want some XML expertise and, based on their own statement,
Java.
> I find it very difficult indeed to believe Tcl will have the same
status
> with Interwoven that it has had with Ajuba.
I don't think it matters as much as you think. Tcl is
way beyond the stage of being made or broken by the whims
of a single company. Really.
> - You have just rebranded yourselves and you have just completed
> refocusing yourselves. How can this be a good time to sell off the
company?
Have you seen the Tech stock market lately? Tried to raise
money to fund your own startup? Happily we've been bought
by a company who's stock is going up in this down market. (IWOV)
> Unless the whole purpose of rebranding was to find someone to buy up
> Scriptics.
No, the goal was to refocus the company on the B2B market.
Acquisition was definitely not a goal at that time.
And, just to clarify, I'm not on the Ajuba executive committee
so I've not been privy to boardroom negotiations. I was
as weirded out as the rest of you by the Scriptics->Ajuba
name change. But hey, the logo's cool, eh? :-)
> I'm sure the Ajuba folk made some good money out of it, but it's hard
to see
> how this will benefit Tcl -- or even Ajuba -- in the mid- to long-
term.
Well, we would have made more going public (probably), and we
might well have gone completely out of business and been left
with monopoly money. It's a risky world out there.
-- Scott
Neil Madden wrote:
>
> I see from their site, that interwoven are a M******** partner
> (http://www.interwoven.com/partners/profiles/microsoft/). I hope this
> doesn't reflect their attitudes to open-source offerings (such as
> Tcl)...
>
> Volker Hetzer wrote:
> >
> > Roy Terry wrote:
> > >
> > > I'd be *very* interested to hear
> > > the Tcl Guys' comments on this development:
> > >
> > > http://www.interwoven.com/news/press/2000/1020ampr.html
> > Maybe they can get interwoven to hand tcl back to berkeley?
> >
They earn money, they have a sucessful product and they
uses TCL from their beginning days
mfg
aotto
In my opinion, the setting up of the new development group means that
whatever happens to Ajuba should not effect tcl.
And to hear that the great bunch of people there who have done so much
for us have now got a share in 31 million, well the only thing I can say
is, at the next conference, the beers are on you, guys ;0). Bloody good
luck to you.
Gordon
Having just read the press release at
www.scriptics.com/cpmpany/whatsnew.html
it would seem that plans have been in motion for some time to
assure the continued development of Tcl :-)
An we might get TclPro as OpenSouce as well :-)
John , are you going to join Interwoven or have you made
enough out of the deal to retire to the country ? :-)
Peter.
From a personal side, however, I hope that TCL/TK development still goes on.
I use it for cross platform for a variety of applications. Apart from
producing code workable code quickly, it means my stress levels are so much
lower!
"Roy Terry" <royt...@earthlink.net> wrote in message
news:39F441CB...@earthlink.net...
> "Throwing back to Berkeley" doesn't make much since seeing as
> how John Ousterhout left there in 1994. John has worked hard
> to set up the Tcl Core Team as a cooperative group of folks
> that are charged with watching over Tcl's future development.
> Our goals is to foster all those smart grad students, engineers,
> and "old hands" so we can continue to maintain Tcl as an
> excellent platform.
>
> > Just don't let the sharks know there's anything worth eating
> > in the water!
>
> True - their bean counters don't value Tcl the way you and I do!
> The Interwoven engineering team broke into spontaneous applause
> when they heard John O. was joining their organization. They
> have a top-notch team, and most of us (I speak only for myself,
> of course) are looking forward to working with them on some cool
> new stuff. Frankly, I have a very limited view of what I'll
> be doing there, if I'll be using Tcl or, gasp, Java, or, gack,
> Perl. But, Tcl is first in my heart and I'll do what I can to
> help it along in the future.
Brent, Thanks for a reasoned and sincere reply. Reading the news
bulletin caught me a bit off-guard, and based on John O's post
so was Ajuba.
In today's fickle world, I could only imagine the worst-case
scenario for the Ajuba staff. I apologize for jumping to
conclusions.
I look forward to whatever the core team can do and will continue
to use and promote Tcl as much as possible. Of course, the
release of TclPro for free would help the development of Tcl
as a "real" scripting language by giving us more tools to help
test and find bugs in our scripts! :-)
Cheers, Ralph Hempel
: I guess I don't see what folks are so worked up
: about. It is not as if Tcl is totally dependent
: on Ajuba or anything. In case you have not been
: following the news lately, there is now a
: governing body in place to manage the
: future of Tcl. It is made up of a number of
: people who have an interest in what is best
: for Tcl.
Yes, and that's great. But I believe the point is that this is all
very sudden and takes place only very soon after the new governing
body was set up. Tcl is still linked heavily to Scriptics/Ajuba so
the timing of this news could've been better.
There are a few bright spots. *Dr. Dobbs
Journal* should have at least two Tcl
pieces this winter. ZDnet has committed
to a monthly piece on Tcl <URL:http://
starbase.neosoft.com/~claird/comp.lang.tcl/Tcl_Counselor.html>.
*Server/Workstation Expert* will have at
least one Tcl feature this winter.
I recognize that what would be really
cool would be to have a piece in *Petro-
chemical Engineering* on real-time
databases and Tcl, and one in *Telecom-
munications Magazine* on central-office
hardware testing with Tcl, and one in
*Enterprise Computing* on ditching Oracle
development tools in favor of Tcl, and
... Well, it's going to be a while
before we achieve that, if ever. I know
you want it. I've got plenty of ideas
for people who seriously want to pursue
publication opportunities.
.
.
: Define "product", and please read
: http://dev.scriptics.com/advocacy/tclHistory.html
: Tcl has been a freely-available "product" since John made
: his first releases in 1988. I urge the paranoid folks out there
Yes, I know. Tcl wont die with this. I didn't mean to imply it would.
But I'll repeat a point I've made before -- Tcl did lose quite a bit of m
omentum after it was separated from Sun and with the mess involved. I suspect
it will lose some now aswell, especially as the governing body hasn't really
taken off yet. But I don't see how this could be anything but a bad
thing for Tcl.
I understand that business decisions must be made and names must be
changed so that companies can be sold off, but equally it's not
silly to be concerned about how things are to continue.
: I don't think it matters as much as you think. Tcl is
: way beyond the stage of being made or broken by the whims
: of a single company. Really.
It wont be broken, but Ajuba is very closely tied to Tcl (like it or
not) and until the community effort takes off properly, things like
this will have an impact.
: No, the goal was to refocus the company on the B2B market.
: Acquisition was definitely not a goal at that time.
: And, just to clarify, I'm not on the Ajuba executive committee
: so I've not been privy to boardroom negotiations. I was
: as weirded out as the rest of you by the Scriptics->Ajuba
: name change. But hey, the logo's cool, eh? :-)
To be honest, I think a selloff was something that must have been on
people's minds at the time. It just feels too bizarre, from a business
point of view, to totally refocus and rebrand the company and then
immediately sell it, unless the latter was the intention all along.
The more I think about this, the more difficult it is to feel positive
about it as a Tcl developer.
I'll have to remember that one :-)
Yeah - ignore my somewhat kneejerk remarks. I'm getting quite good at
spouting rubbish before I discover all the facts. I think I should start
sleeping more and drinking less.
That sounds more positive. Their website does seem to show that they
have a Java-orientation, but they bought Ajuba for your XML skills, and
AFAIK the Ajuba XML skills are built on top of Tcl, so it would make
sense to use the existing products and skills in that area. If not,
there's always Jacl and Tcl-Blend....
Is there is space for a new TCL company ??
This is the output after ~3 hours single-brain brain-storming
Business Plan:
Integrate
Source Navigator + TclPro + "Compiler"
to provide a real professional Software-Development environment
this will be a 5 head stuff company
2 head's from TclPro, they will continue to improve TCL (...)
1 head from Source Navigator ( ... )
1 head from "Compiler" ( aotto )
1 additional support
Find strong Partners to Help for the first Month's
1) Vignette, as one of the key TCL user's
2) Red Hed, as owner of Source-Navigator and major player
in the open-source community
3) some additional people or company's
Help doesn't mean money, Help mean to "help" to come into
business with other companies. We need people with connection's
not with money
This will help:
1) Vignette, to put TCL people and development away from
"Interwoven"
2) RedHat, to find a new way to sell their business tools
3) To become a major player in the tool business
The back of all the activity will be "Compiler" and the
ability to compile every language ( Tcl, Java, Perl, Phyton , ... )
This will expand our business to support all these languages
on one single code-platform
"Compiler" + Source-Navigator + ( TclPro )
Additional we will integrate this environment into other
software-products ( SAP, Vignette, ... ).
Many software-products have a very complex customizing environment,
and they will happy to get a IDE-Framework which support
their local configuration language in a cross platform
environment.
mfg
aotto
look at http.//home.t-online.de/home/aotto/comp-main_E.html
for information about "Compiler"
Well looking at the team we have some great personalities for heading
tcl into the future. John O isn't about to let tcl fall into obscurity,
nor Jeff or Brent. The hours all those guys have put in for the love of
it, middle of the night, holidays etc. this won't sway them from making
tcl great.
And with Mike McLennan ( Mr "have a t-shirt" tcl charisma man ) in there
as well, pushing tcl, well, I think we've never had it better. I feel
not only is tcl's future bright, but we now have a shining example of
what can be achieved on the back of tcl.
This is a tcl success story, not an obituary.
Gordon
Is there space in the market for a new TCL company ??
That may be, but possibly not bigger than 3-5 persons. And don't forget
about the many companies already using Tcl and providing service,
starting from one man shows like you or Mr. Haschek (TIDE) up to
companies like Cygnus (Red Hat) or Vignette.
It is not good for Tcl, that it looses full time developers. But on the
other hand, other languages do prosper without such support. There may
be some place for a new Tcl company, but if this could earn enough money
with support to hire full time developers to work on the core is at
least questionable.
> Integrate
> Source Navigator + TclPro + "Compiler"
> to provide a real professional Software-Development environment
The Source Navigator is great for C and C++, but absolutely useless for
tcl/itcl.
The parser for tcl/itcl is not good, even that used in ASED is much
better. The ASED parser gives you namespaces, classes, methods and the
like, the parser in SN gives you nothing.
If TclPro (which is at the moment very questionable) would be available
as open source, who would need you "Compiler"?
And don't forget, the market for the all singing and all dancing IDE is
not unlimited. On the one hand you have the great PC platform with MS
and Borland tools. Absolutely useless to compete with. And on the other
hand you have an emerging Linux platform with open source tools.
KDevelop and SNavigator for C++/C/Java/Tcl and others (like ASED) Tcl
only. The small market share left is taken with less known tools like
TIDE.
> The back of all the activity will be "Compiler" and the
> ability to compile every language ( Tcl, Java, Perl, Phyton , ... )
>
Even if you make your compiler work for every day use, who should be
interested in such a multilanguage beast ? Perhaps I'm too narrow
minded, but one scripting language and 1 1/2 compiled language is enough
for me. And at least this will be no open source tool, therefore nobody
will be interested helping you.
> This will expand our business to support all these languages
> on one single code-platform
>
> "Compiler" + Source-Navigator + ( TclPro )
>
If you'd be listening to the problems updating the source of SN to a
recent tcl/itcl version ...
Bye, Carsten
PS: Next European Tcl/Tk Conference takes place 7/8 june 2000 :-)
--
Dipl. Ing. Carsten Zerbst | Express your needs for the
| 2. European Tcl Conference 2001 !
zer...@tu-harburg.de |
http://www.tu-harburg.de/~skfcz | http://www.tu-harburg.de/skf/tcltk
The Parser-Problem is not as big. ( I Know What I Say )
Source-Navigator is very powerful in features.
"Compiler" can be easy integrated into it
> The parser for tcl/itcl is not good, even that used in ASED is much
> better. The ASED parser gives you namespaces, classes, methods and the
> like, the parser in SN gives you nothing.
>
> If TclPro (which is at the moment very questionable) would be
available
> as open source, who would need you "Compiler"?
TclPro is not an compiler.
"Compiler" and the power of compiler stands for it own
>
> And don't forget, the market for the all singing and all dancing IDE
is
> not unlimited.
but special in the Open-Source Market ( Tcl, Perl, Phyton ... )
nothing exists...
On the one hand you have the great PC platform with MS
> and Borland tools. Absolutely useless to compete with. And on the
other
Does Borland or MS sell TCL, Perl, Phyton, ... Compiler ??
You see no competition
( I make it a littel bit stronger -> they don't have the knowlege
to write Compiler for this languages )
> hand you have an emerging Linux platform with open source tools.
> KDevelop and SNavigator for C++/C/Java/Tcl and others (like ASED) Tcl
> only. The small market share left is taken with less known tools like
> TIDE.
>
> > The back of all the activity will be "Compiler" and the
> > ability to compile every language ( Tcl, Java, Perl, Phyton , ...
)
> >
>
> Even if you make your compiler work for every day use, who should be
> interested in such a multilanguage beast ? Perhaps I'm too narrow
beast is an awful word .. every language get his own "Compiler"
> minded, but one scripting language and 1 1/2 compiled language is
enough
> for me. And at least this will be no open source tool, therefore
nobody
> will be interested helping you.
The story of Scriptics failed because their ist not enought
"meat" in the TCL language to feed a company.
but TCL is for me only a starting point and all the custom
power of the other languages will help to get it working
>
> > This will expand our business to support all these languages
> > on one single code-platform
> >
> > "Compiler" + Source-Navigator + ( TclPro )
> >
>
> If you'd be listening to the problems updating the source of SN to a
> recent tcl/itcl version ...
SN works and i used it !!! ( This is very important for me )
Does you ever compile SN with "Compiler" and ITCL support ??
( this is a not public edition )
This will give you all the bad code you are looking for.
>
> Bye, Carsten
>
> PS: Next European Tcl/Tk Conference takes place 7/8 june 2000 :-)
>
> --
> Dipl. Ing. Carsten Zerbst | Express your needs for the
> | 2. European Tcl Conference 2001
!
> zer...@tu-harburg.de |
> http://www.tu-harburg.de/~skfcz |
http://www.tu-harburg.de/skf/tcltk
>
Ah, the first rumor about end of Tcl brings up your business plan again
? Do promotion for "Compiler", business is not going very well, isn't it
?
And why do you use a new email Mr. Otto, got anything to hide ?
--
Gerhard Hintermayer
http://www.inode.at/g.hintermayer
This is no Hide ..
I sitting at Dresdner Kleinwort Benson FFT
and setup the XETRA. EUREX, NEWEX and EEX Stock-Exchange
applications.
This is my main business and the money maker :)
I introduced "moodss" as Sys-Management Tool, and i put
Source-Navigator at a starting-point into business.
Step by step i have to compete again Java, Perl ...
I have to to put the message into their head
"If something have to work, They have to use TCL"
You see nothing bad
mfg
aotto
> --
> Gerhard Hintermayer
> http://www.inode.at/g.hintermayer
>
I believe that Tcl will go out of the commercial market.
Chang
Me thinks the "obvious head of the Tcl project" is John O.
The TCT is in place. John has stated that if "the team" runs
into a bottleneck, then *he* will break it and make a decision.
And, in that vein, what company serves as the "obvious head
for the Perl project" ? There isn't one, is there?!
What Tcl needs is more press. Perl bastardized Tcl's Tk. Python
makes one actually run a Tcl/Tk app so *it's Tk* can send messages
to it to actually do the GUI stuff. But, because of "the press"
they are looked upon as better by many. Kinda like Windoze over
Linux, or VHS over Beta. The best doesn't always win. It depends
so much on "the press".
Tcl "in the press" is a key area that we are lacking. Tcl has some
cool features that other scripting languages have yet to match.
Perl and Python are just starting to look at Unicode support.
The thread support in Tcl is far better than what Perl has,
but I am not sure about Python threads. Tcl and the Tk toolkit
were so good, that Python just used it directly instead of trying
to copy it (aka Tkinter). This is the sort of stuff that would
make a good article, but someone needs to write it. One thing
that the Python came has taught us, it that getting press brings
in new developers. It does not matter how good your tech is
if nobody knows about it!
Mo DeJong
Red Hat Inc
I don't necessarily see problems with other languages sharing
Tk. I would like to see the perl/tk and python/tkinter groups
get more involved with tk at the C level. Most other languages
that bind to Tk, use a layer of language specific bindings over
the Tk-C layer, similar to the layer of tcl/tk over the Tk c layer,
and as far as I can tell that is where most of the time/effort
is spent. It would be nice if time/effort was also spent fixing
bugs, adding new widgets, etc. so that all communities would
benefit from the effort, not just the tcl community.
Along the same lines as what you were saying, Perl has
roles' for each release.
I noticed there is a specific person who is in charge of
PR for Perl 6. (on the perl 6 project page)
It would be nice if tcl had similar positions. A logical
nominee would be someone like Cameron Laird who has written
a lot of articles for different publications, and is very
knowledgeable about tcl, perl, python, etc. Of course, who
knows whether he has interest and time to do something like
that.
--Dan
What an interesting development. Its completely consistent, in my mind,
with the distilled content of the clt newsgroup, which I have been
following for the past couple of years. I am now convinced that the
flavour of the newsgroup is an accurate reflection of the state of
Tcl/Tk in the marketplace.
What I have noticed over my time of near daily reading of the
comp.lang.tcl news group are the following flavours of conversation:
1) The Tcl/Tk language has evolved to the state that it is robust,
extensive, reliable and globally useful for the wide variety of
applications evident in its market niche.
2) The workload ascribed to maintenance of the Tcl/Tk software suite in
the face of the rapidly changing platform environments for which it is
supported has reached the level where all available support resources
are fully consumed.
3) There are no broadly held ideas, although also not paucity of
suggestions and personnaly championed proposals, as to the strategic
direction that Tcl/Tk should take in the future.
4) There appears to be no consensus about the actual needs of the
marketplace that are not met by Tcl/Tk in its current state.
and most recently,
5) There is not much market support for Tcl/Tk, in the sense that the
only business organization to mentor it has disappeared. This latest
event appears to reflect a decline in market interest dating back to
probably prior to the split of Scriptics from Sunlabs.
So, Tcl/Tk appears to be a mature product that nobody, in the relative
sense, wants. Aside from the recognition that it is a solid, adaptable
and useful tool, nobody appears to know, or rather be able to sell, a
concept for the future evolution of Tcl/Tk that has obvious market
relevance and immediate popular appeal. Focussed maintenance resources
are declining while environmentally imposed maintenance requirements are
increasing.
On the other hand, there are dependencies on Tk embedded into other
scripting languages that appear to enjoy expanding market penetration.
The python GUI is, after all, Tk, while the perl/Tk add on is tied to a
scripting language that is firmly (?) entrenched as the web server side
scripting language.
Managers of organizations that depend on Tcl/Tk either for operations
or to make their products work will all have to review the merits of
continuing to base activities on a piece of software that must now
appear to be on the verge of stagnation and possible disappearance, if
only because of the maintenance problems argued above. In the final
analysis, a business must base its own future on a supported software
base, and if you can't buy support, then you have to pay for it
yourself.
The crucial questions as to the future of Tcl/Tk as a broadly accepted
and used vehicle are:
1) What is, and will be, the ratio of realistic cost, in terms of
resources needed to maintain current the software on a wide platform
base, to a realistic assessment of the potential, manageable and
commited support resources?
2) Presupposing the emergence within the community of a winning
strategic direction for the future development of Tcl/Tk, what is the
ratio between the development investment needed to attain the strategic
goal and the probable quantity of available committed, manageable
development resources?
Passionate rhetoric aside, the Tcl/Tk community should, I believe,
seriously review these two issues with a view to developing community
based mechanisms that can address the support and development needs of
the Tcl/Tk software and application base. It is clear to me that Sun,
and Scriptics/Ajuba management teams have already, through their market
based business decisions, rendered judgement on these issues. Is their
really another conclusion to be reached?
Ideally, a visionary leader would emerge from a focussed discussion of
the market needs, the intrinsic advantages and limitations of Tcl/Tk and
the identifiable pool of qualified resources, who, through charismatic
appeal, dedication, and the expression of high levels of energy, would
provide the community leadership to make the future of Tcl/Tk an assured
success. Failing that, discussion will be required that is supported by
a framework that will result in the establishment of a common community
vision that drives forward Tcl/Tk towards broader market acceptance and
assured stability.
Tcl/Tk is in no immediate danger, as the depth of its penetration in
the marketplace, the relationship it has as a building block for other
software suites, and its Open Source nature will provide the momentum to
carry it forward at its current level of development for 2 to 5 years.
After that, unless something happens to break down the current strategic
concept impasse, the drift into the hiatus of a historical achievement
in the world of computer science is likely to accelerate sharply.
--
Iain B. Findleton
http://pages.infinit.net/cclients
custom...@videotron.ca
(514)457-0744
I make my living as a Tcl/Tk consultant, and I can assure you that
Tcl/Tk is
thriving out there.
I can also tell you about the contracts I didn't get because Tcl wasn't
percieved as a serious platform for the development. "Go Java", they
say, "We can get approval for a Java contract." (And then I tell them
how
much more it will cost to go Java, and the project gets dropped.)
I think that Tcl needs both a corporate and a non-corporate sponsor.
We (the community) need a non-corporate place where development can
take place that isn't held hostage to a corporations need to make a
quarterly
profit, or a percieved change in the markets.
I believe that John, Brent, Jeff and the rest have taken an excellent
step in
that direction with the Tcl Core group.
I think that the Tcl Consortium was also a good thing. I'd love to see
it revived,
if only as a web site with up to date links for consultants, users,
actively maintained
packages, etc. Just being able to tell my clients that there is a
professional looking
page where they can find more support options helps sell Tcl/Tk to the
corporations.
This is a perception thing, a good looking website speaks of many stable
language
supporters, while no website, or just a spot on SourceForge speaks of a
grad-student
project that could be dropped after graduation. (Before anyone jumps on
me, these
are not my opinions, they are the opinions I fight against to promote
what I consider
the best tool for many projects.)
I think we need a corporate sponsor to provide the appearance of
stability. Corporate
IT Departments need to know there is somplace where they can buy a
long term support contract, even if most Tcl/Tk users don't buy them.
The corporate IT shops need to be assured that the *COULD* buy the
contract,
whether they need it or not. It's the perception that they can get help
if they need it,
rather than having help right now that's important.
Regarding Mac's comments on articles - Cameron has been writing Tcl/Tk
articles
for a several years now, and I've been writing a regular column for
;login: magazine
for the past 2 years.
One of the problems I've found in writing for the non-computer magazines
is that
they want articles about a specific project, and most of my clients
prefer I not discuss
the details about how they out-compete their competetion.
I encourage anyone using Tcl for a project that isn't corporate
confidential to
write it up for your trade magazine. Those magazines are hungry for
decent articles
that explain how to make something in their field work better.
--
........................... Clif Flynt ..........................
... Tcl/Tk for Real Programmers - Academic Press Professional ...
.... http://www.cflynt.com ............ cl...@cflynt.com ....
. In theory there is no difference between theory and practice .
........................ In practice, there is. .................
Well, I'm on the Ajuba Executive Committee and was privy to all
the boardroom negotiations, so I can tell you quite definitely: we
wouldn't have spent the time and money to re-brand the company if
we were planning to sell it. Perhaps this doesn't make any sense
to you, but it's the truth...
________________________________________________________________________
John Ousterhout 650-210-0102 tel
Chairman and Chief Technology Officer 650-230-4070 fax
Ajuba Solutions ous...@ajubasolutions.com
http://www.ajubasolutions.com
I am joining Interwoven; I'm afraid this deal didn't yield
retirement money for any of us.
But did you actually buy a support contract? Unfortunately it's
hard to build a business around a backup strategy that no one
actually pays for.
> Tcl/Tk is in no immediate danger, as the depth of its penetration in
> the marketplace, the relationship it has as a building block for other
> software suites, and its Open Source nature will provide the momentum to
> carry it forward at its current level of development for 2 to 5 years.
> After that, unless something happens to break down the current strategic
> concept impasse, the drift into the hiatus of a historical achievement
> in the world of computer science is likely to accelerate sharply.
I don't mean to be rude, but what is your point? What feature could
be added to Tcl to overcome this "strategic concept impasse" of which
you speak? If we were playing buzzword bingo on the current
features that one could access in Tcl, I think you would have a
lot of red dots on your page.
One could say the same things about C or C++. You are basically stuck
with VC++ on windows, and if you are running on anything else you
are most likely going to be using gcc. Where is the innovation there?
Or we could look at other scripting languages. Where are you going
to buy "enterprise support" for Python and Perl? Has the lack of
a "strategic concept impasse" caused people to stop using Perl?
Last Perl users meeting I went to, they were talking about this
cool new concept that was appearing in the next version, UTF-8.
What exactly is this "winning strategic direction for the future
development of Tcl/Tk" that you speak of? Frankly, I don't see
why Tcl needs a "winning strategic direction". It is a tool,
use it to make cool things. If people like the things you
make, they will use your tool.
This all reminds me of the guy who wrote in to the Source-Navigator
mailing list asking us to port the entire GUI to a C++ based widget
set. His argument was basically, "look this new GUI thing is really
neat, and the code would be better and faster if it was not written
in this Tcl thing." We invited him to do the port and check back
with us in a year when it was done. We would rather be spending
my time improving our product than chasing down pointers and
wasting time with an untested GUI toolkit.
> In article <39F5A63E...@inode.at>,
> Gerhard Hintermayer <g.hint...@inode.at> wrote:
> > aot...@my-deja.com wrote:
> > >
> > > ... lots of his "Compiler" promotion stuff
> >
> > Ah, the first rumor about end of Tcl brings up your business plan
> again
> > ? Do promotion for "Compiler", business is not going very well, isn't
> it
> > ?
> > And why do you use a new email Mr. Otto, got anything to hide ?
> >
>
> This is no Hide ..
>
> I sitting at Dresdner Kleinwort Benson FFT
> and setup the XETRA. EUREX, NEWEX and EEX Stock-Exchange
> applications.
>
> This is my main business and the money maker :)
>
> I introduced "moodss" as Sys-Management Tool, and i put
What do you mean exactly by that? I would really appreciate being informed
about any use of the moodss software.
Thank you very much in advance.
> Source-Navigator at a starting-point into business.
> Step by step i have to compete again Java, Perl ...
> I have to to put the message into their head
>
> "If something have to work, They have to use TCL"
>
> You see nothing bad
>
> mfg
>
> aotto
>
> > --
> > Gerhard Hintermayer
> > http://www.inode.at/g.hintermayer
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
Jean-Luc Fontaine mailto:jfon...@winealley.com http://www.winealley.com
I was under the impression that the TCT was voted into office
something like 3 months ago. It does not seem "very sudden"
to me. In fact, I would say that getting the TCT going has
taken longer that it should have. Perhaps we just needed a
good kick in the butt.
"John Ousterhout" <ous...@scriptics.com> schrieb im Newsbeitrag
news:39F45F24...@scriptics.com...
> We'll have an "official" statement on this later today or tomorrow.
> The press release wasn't supposed to go out until late today; somebody
> at Interwoven jumped the gun and caught us unprepared. Sorry for
> the confusion...
>
> -John-
>
> Roy Terry wrote:
> >
> > I'd be *very* interested to hear
> > the Tcl Guys' comments on this development:
> >
> > http://www.interwoven.com/news/press/2000/1020ampr.html
<aot...@my-deja.com> schrieb im Newsbeitrag
news:8t3to3$trb$1...@nnrp1.deja.com...
>
>
> Is there is space for a new TCL company ??
>
> This is the output after ~3 hours single-brain brain-storming
>
> Business Plan:
>
> Integrate
> Source Navigator + TclPro + "Compiler"
> to provide a real professional Software-Development environment
> this will be a 5 head stuff company
> 2 head's from TclPro, they will continue to improve TCL (...)
> 1 head from Source Navigator ( ... )
> 1 head from "Compiler" ( aotto )
> 1 additional support
>
>
> Find strong Partners to Help for the first Month's
> 1) Vignette, as one of the key TCL user's
> 2) Red Hed, as owner of Source-Navigator and major player
> in the open-source community
> 3) some additional people or company's
>
>
> Help doesn't mean money, Help mean to "help" to come into
> business with other companies. We need people with connection's
> not with money
>
>
> This will help:
> 1) Vignette, to put TCL people and development away from
> "Interwoven"
> 2) RedHat, to find a new way to sell their business tools
> 3) To become a major player in the tool business
>
>
> The back of all the activity will be "Compiler" and the
> ability to compile every language ( Tcl, Java, Perl, Phyton , ... )
>
> This will expand our business to support all these languages
> on one single code-platform
>
> "Compiler" + Source-Navigator + ( TclPro )
>
> Additional we will integrate this environment into other
> software-products ( SAP, Vignette, ... ).
> Many software-products have a very complex customizing environment,
> and they will happy to get a IDE-Framework which support
> their local configuration language in a cross platform
> environment.
>
>
>
> mfg
>
> aotto
>
>
>
> look at http.//home.t-online.de/home/aotto/comp-main_E.html
> for information about "Compiler"
>
>
Well said. I'd paraphrase that as:
"Tcl Rocks!"
> 2) The workload ascribed to maintenance of the Tcl/Tk software
suite in
> the face of the rapidly changing platform environments for which it is
> supported has reached the level where all available support resources
> are fully consumed.
This is rather far off-base. Perhaps Jeff can comment on
the effort required to port Tcl/Tk to the new 64-bit architecture
from Intel. I know we were up and running (mostly) quite quickly,
ahead of the Perl efforts if I recall correctly. That turns out
to be more complex than you think because there was all of the
Windows, AIX-like-thing, and Linux Operating Systems/Compiler
platforms to work with. I also know that Tcl runs on MacOS X
(well, that was easy - its a UNIX derivative with gcc support)
OS 390, and a wide variety of platforms.
The support effort comes from adding features, not maintaining
the current feature set.
> 3) There are no broadly held ideas, although also not paucity of
> suggestions and personnaly championed proposals, as to the strategic
> direction that Tcl/Tk should take in the future.
Hmm - "strategic direction" - I thought that cross-platform,
secure, robust, easy to use, was a pretty good strategy.
Works for me.
> 4) There appears to be no consensus about the actual needs of
the
> marketplace that are not met by Tcl/Tk in its current state.
>
> and most recently,
If it isn't spelled "j-a-v-a" then the market place doesn't understand
it. Happily, there are 3 ways to integrate Tcl/Tk and Java:
Jacl: a Tcl interpreter written in Java
TclBlend: dynamically load the JVM into a process running Tcl, and
Rave: a remote connection to a JVM from Tcl - no, you haven't
heard about that before, but you'll be hearing more.
> 5) There is not much market support for Tcl/Tk, in the sense
that the
> only business organization to mentor it has disappeared. This latest
> event appears to reflect a decline in market interest dating back to
> probably prior to the split of Scriptics from Sunlabs.
Right-O: java, java, java...
> So, Tcl/Tk appears to be a mature product that nobody, in the
relative
> sense, wants. Aside from the recognition that it is a solid, adaptable
> and useful tool, nobody appears to know, or rather be able to sell, a
> concept for the future evolution of Tcl/Tk that has obvious market
> relevance and immediate popular appeal. Focussed maintenance resources
> are declining while environmentally imposed maintenance requirements
are
> increasing.
Ohh, such reasoned gloom and doom! Loads of companies world-wide
use Tcl for mission critical needs, and they are not going to stop.
> On the other hand, there are dependencies on Tk embedded into
other
> scripting languages that appear to enjoy expanding market penetration.
> The python GUI is, after all, Tk, while the perl/Tk add on is tied to
a
> scripting language that is firmly (?) entrenched as the web server
side
> scripting language.
Uh, actually PHP is rather successful on the server side, too.
> Managers of organizations that depend on Tcl/Tk either for
operations
> or to make their products work will all have to review the merits of
> continuing to base activities on a piece of software that must now
> appear to be on the verge of stagnation and possible disappearance, if
> only because of the maintenance problems argued above. In the final
> analysis, a business must base its own future on a supported software
> base, and if you can't buy support, then you have to pay for it
> yourself.
The whole maintenence argument is, again, off-base.
Note that is it's Perl that may have to be re-written from
scratch, mostly, because its code base is so crufty.
Java has its own issues, where each JVM from each vendor on
each platform has different behavior. Remember, Java coined
the phrase "write once, debug everywhere".
Tcl is clean, well built, has a good OS-dependent abstraction
layer, etc. etc.
> The crucial questions as to the future of Tcl/Tk as a broadly
accepted
> and used vehicle are:
>
> 1) What is, and will be, the ratio of realistic cost, in terms
of
> resources needed to maintain current the software on a wide platform
> base, to a realistic assessment of the potential, manageable and
> commited support resources?
I think Mo said it well. Cygnus felt that the code base was so
clean that they could deal with whatever bugs came their way. No
support burdon there.
> 2) Presupposing the emergence within the community of a winning
> strategic direction for the future development of Tcl/Tk, what is the
> ratio between the development investment needed to attain the
strategic
> goal and the probable quantity of available committed, manageable
> development resources?
I think we need to take a bigger view. Customers want solutions.
Some care how they are implemented, some don't. If you build stuff
that works and solves their problems, they are happy.
> Passionate rhetoric aside, the Tcl/Tk community should, I
believe,
> seriously review these two issues with a view to developing community
> based mechanisms that can address the support and development needs of
> the Tcl/Tk software and application base. It is clear to me that Sun,
> and Scriptics/Ajuba management teams have already, through their
market
> based business decisions, rendered judgement on these issues. Is their
> really another conclusion to be reached?
Off base again. Scriptics/Ajuba is a VC-funded startup, which
brings its own set of pressures for big-big payoffs. A Tcl tools
company is probably viable for a small group, order 5, but certainly
not viable for 60 people. But, I think it is more likely that
companies that solve problems (Telecom control, system test,
application integration) will simply continue to use Tcl because
it works well. I am looking to those users to work together
to shoulder the relatively straight-forward efforts to maintain
Tcl on new hardware and add new features in a clean way.
> Ideally, a visionary leader would emerge from a focussed
discussion of
> the market needs, the intrinsic advantages and limitations of Tcl/Tk
and
> the identifiable pool of qualified resources, who, through charismatic
> appeal, dedication, and the expression of high levels of energy, would
> provide the community leadership to make the future of Tcl/Tk an
assured
> success. Failing that, discussion will be required that is supported
by
> a framework that will result in the establishment of a common
community
> vision that drives forward Tcl/Tk towards broader market acceptance
and
> assured stability.
I'm looking for broad community support at this point.
> Tcl/Tk is in no immediate danger, as the depth of its
penetration in
> the marketplace, the relationship it has as a building block for other
> software suites, and its Open Source nature will provide the momentum
to
> carry it forward at its current level of development for 2 to 5 years.
> After that, unless something happens to break down the current
strategic
> concept impasse, the drift into the hiatus of a historical achievement
> in the world of computer science is likely to accelerate sharply.
Urk - I have a hard time with "strategic concept impasse".
Tcl is a vehicle for your good ideas - it is not an end unto itself.
Brent Welch
> > On the other hand, there are dependencies on Tk embedded into
> > other scripting languages that appear to enjoy expanding market
> > penetration. The python GUI is, after all, Tk, while the perl/Tk
> > add on is tied to a scripting language that is firmly (?)
> > entrenched as the web server side scripting language.
> Uh, actually PHP is rather successful on the server side, too.
Yep, there are a lot of PHP users out there who have never even heard
of Tcl:-/
--
David N. Welton, Responsabile Progetti Open Source, Linuxcare Italia spa
tel +39.049.8043411 fax +39.049.8043412 cel +39.348.2879508
dav...@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
That sound very interesting for all of us.
Could you wrote an article about it? This is absolutely good stuff
for an article in the specialized press, especially Tcl vs
Java/Perl/Python.
JoÄ—l Saunier
> The Source Navigator is great for C and C++, but absolutely useless
> for tcl/itcl.
> The parser for tcl/itcl is not good, even that used in ASED is much
> better. The ASED parser gives you namespaces, classes, methods and the
> like, the parser in SN gives you nothing.
Carsten, would you be interested in helping to test and debug a new
Source-Navigator parser for Tcl and Itcl? There has been lots of
talk about one on the Source-Navigator mailing list, but we need
more Tcl experts that are willing to lend a hand.
We use it know to observe our application software,
process + channel
I wrote 6 Pluging which inform the people
( just a bell ) if something goes wrong.
In fact there is a real compition between TIVOLI and moodss.
Right now i can say that TIVOLI is a useful tool but mostly
introduced buy people which are not closed enough to the
real world problem. This lead's to a situation that right now
"moodss" is the application which really make the money
and TIVOLI is the application they spend money for.
> Thank you very much in advance.
>
> > Source-Navigator at a starting-point into business.
>
> > Step by step i have to compete again Java, Perl ...
> > I have to to put the message into their head
> >
> > "If something have to work, They have to use TCL"
> >
> > You see nothing bad
> >
> > mfg
> >
> > aotto
> >
> > > --
> > > Gerhard Hintermayer
> > > http://www.inode.at/g.hintermayer
> > >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --
> Jean-Luc Fontaine mailto:jfon...@winealley.com
http://www.winealley.com
>
>
This is no Problem ...
i write a german paper
( my english is not as good as it should be )
and send it to the newsgroup,
==> everyone can pic it up for publishing
>
> JoÄ—l Saunier
I miss the Consortium. The problem with
the Consortium, as best I could understand
it, was that we couldn't convince the
people whom Tcl most benefits (Cisco, Sie-
mens, various financial houses, Oracle,
..., each of which have scores of Tcl pro-
grammers) to chip in enough of a
contribution to keep the thing going. The
world welcomes fresh ideas on that score.
.
.
.
>One of the problems I've found in writing for the non-computer magazines
>is that
>they want articles about a specific project, and most of my clients
>prefer I not discuss
>the details about how they out-compete their competetion.
Soooo true. This seems to work against
Tcl even more than other languages. I've
also encountered several cases where or-
ganizations don't want it published that
they're using Tcl instead of Java (...),
because shareholders, upper management,
... might find out. If it's just getting
a job done quickly and reliably, of course,
then Tcl is OK for that; just don't let
the public know about it.
>
>I encourage anyone using Tcl for a project that isn't corporate
>confidential to
>write it up for your trade magazine. Those magazines are hungry for
>decent articles
>that explain how to make something in their field work better.
Absolutely. Also, if someone has some of
the elements
* good article idea
* magazine where it can be placed
* organizational permission
* skill in composition
* time to write
but not others, please get help. Clif and
I and others should be able to find a way
to pull together enough pieces to make some
sort of good result happen.
.
.
.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Still, it tickles me.
... but they're not the OS-level threads that users expect.
They're different from Tcl's thread support, and there cer-
tainly are instances when developers need what Tcl has.
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
Tcl has comparable technical credits: AOLserver
is based on Tcl! StoryServer is based on Tcl!
Source Navigator is based on Tk! Tcl does awesome
XML! Comanche is based on Tk! ... Why does the
marketplace take Tcl for granted? I'm still puz-
zled.
George
I think I could bring another interesting Tcl-article into the iX
(europes biggest unix mag)
The next one planed there is one for the upcomming tcl8.4 in Q1 2001.
Bye, Carsten
--
Dipl. Ing. Carsten Zerbst | Express your needs for the
| 2. European Tcl Conference 2001 !
zer...@tu-harburg.de |
http://www.tu-harburg.de/~skfcz | http://www.tu-harburg.de/skf/tcltk
I'll be blunt. Python's attachment to Tk has always been
quite provisional. *Plenty* of Pythoneers want to ditch
Tkinter for an alternate toolkit binding, and the current
Ajuba Solutions (mis)publicity has unsheathed the knives
again. We'll see how that turns out.
One way or another, though, plenty of people with no inter-
est in Tcl will be using Tk. The good news is that, more
than any time in the past (if you believe me), everybody is
ready to pull together. I've tossed together a page of pointers
<URL:http://starbase.neosoft.com/~claird/comp.lang.misc/core_enhancement.html>
to help the insiders orient to their peers, and it's been
well-received so far. In principle, leading Perl, Tcl,
Ruby, Python, ... people are open to helping each other.
I'll be glad to do more introductions. What's the next
step, Dan? To me, what Tk most needs is help with TkGS,
and hard discussions among the "foreigners" about what
eases their interface burdens.
Incidentally, Perl people might help with MacOS and BeOS.
Wouldn't that be a great trade?
Also incidentally, folks should know that Dan's been doing
quite a bit to help out in comp.lang.python and
comp.lang.perl.tk with Tk-related questions. It makes a
difference.
Who knows, indeed? Cameron certainly isn't
reliable on questions about whether he has
time for any more activities.
I thought about that, and rejected it, perhaps unjustly. The
thing I can't figure out is how people come to any conclusions
about Anaconda other than through using it. It certainly isn't
documented in any place *I*'ve noticed
<URL:http://forums.itworld.com/webx?2...@85.NO6JarnFdXj^0@.ee6d080>.
Also, if Anaconda makes an impression, why doesn't Comanche?
The one that might have made an impression on the Linux crowd is
Mailman <URL:http://www.fsf.org/gnulist/production/mailman.html>.
It's far more obvious this is a Python application.
I'm curious how this looks to others. I have an unusual relation
to the Linux mainstream, and there's a lot I miss.
What's Tcl's counter? The hurricane tracker?
Hmmm...Somehow I had the idea that the Ajuba crew would not be doing
support for Tcl/Tk in future. That would leave people like me, in my
spare time, adding features and porting it to new architectures. I am
predicting that such a scenario would inevitably cause an increasingly
large lag between the main stream of activity and Tcl/Tk releases.
I have read about all of Tcl/Tk and it is indeed well done. That is most
likely the result of the years of effort by a cohesive, competent,
experienced and well managed team. My point is who replaces them as
effectively ?
>
>
> Hmm - "strategic direction" - I thought that cross-platform,
> secure, robust, easy to use, was a pretty good strategy.
> Works for me.
>
This is where Tcl/Tk is at today. A strategic direction is the framework
within wich future developers take decisions relating to new features
and capabilities that would allow the the product to survive and prosper
in the marketplace, expand its market penetration, and increase market
share.
Tcl/Tk does its thing well today. Can it do it better? Can it do more?
Should it do more? These are strategic concerns.
>
> If it isn't spelled "j-a-v-a" then the market place doesn't understand
> it. Happily, there are 3 ways to integrate Tcl/Tk and Java:
> Jacl: a Tcl interpreter written in Java
> TclBlend: dynamically load the JVM into a process running Tcl, and
> Rave: a remote connection to a JVM from Tcl - no, you haven't
> heard about that before, but you'll be hearing more.
There is a market driven statement of needs. Let me ask, however,
whether this is a comforting one or a disquieting one.
Having thought over my initial observations on the departure of
Scriptics/Ajuba, it occurres to me that, beyond the fundamental utility
of Tcl as a tool for rapid solution to application integration problems,
the unique advantage that Tcl/Tk offers is the Tk GUI building
capabilites. Other languages like python and perl don't have their own
GUI interface, but java, javascript and VB do. This last point is a
potential killer.
What is the selling point of a Tcl/java marriage? It can't be Tk,
because my java programmers already have a GUI environment. It then has
to be the Tcl features. If i am already a Tcl site, I am interested
because I have a transition tool that will tide me over until I can redo
my application integration stuff. If I am not a Tcl site.....
>
>
> Ohh, such reasoned gloom and doom! Loads of companies world-wide
> use Tcl for mission critical needs, and they are not going to stop.
However feeble, my observations are aimed at stimulating discussions
about a direction for preserving the fabulous work that Tcl/Tk
represents. "Gloom and doom" has nothing to do with the ebb and flow of
ideas in the marketplace. UNIX is, in my opinion, far superior to
anything that Microsoft has yet produced, yet its market share is,
according to many measures, on the decline. If you go into business
today, you go NT/ME/2K, and not because UNIX is no good, more costly,
less reliable, or feature poor.
> The whole maintenence argument is, again, off-base.
> Note that is it's Perl that may have to be re-written from
> scratch, mostly, because its code base is so crufty.
> Java has its own issues, where each JVM from each vendor on
> each platform has different behavior. Remember, Java coined
> the phrase "write once, debug everywhere".
> Tcl is clean, well built, has a good OS-dependent abstraction
> layer, etc. etc.
This is a vacuous observation. Even if maintenance is trivial, somebody
has to be assigned to do it, and that person has to maintain sufficient
knowledge of platforms and the code base to be able to take appropriate
action. I used to know the names of these people. Will I know them this
time next year?
There are hordes of crappy codes out there that have strong market
presence. Take a look at some of the original C standard library stuff
that ran the UNIX world from 1978 to the arrival of Linux on the scene.
>
> I think we need to take a bigger view. ...
Err...I thought that was my point.
>
> Off base again. Scriptics/Ajuba is a VC-funded startup, which
> brings its own set of pressures for big-big payoffs. A Tcl tools
> company is probably viable for a small group, order 5, but certainly
> not viable for 60 people. But, I think it is more likely that
> companies that solve problems (Telecom control, system test,
> application integration) will simply continue to use Tcl because
> it works well. I am looking to those users to work together
> to shoulder the relatively straight-forward efforts to maintain
> Tcl on new hardware and add new features in a clean way.
Ah. A "Tcl Consortium" type of structure. That could be viable. Industry
based and funded. A self help organization that could provide a
"permanent" home for Tcl and assure the continued functionality and
reliability of Tcl for the members. That sounds like a strategy to me.
>
>
> Urk - I have a hard time with "strategic concept impasse".
> Tcl is a vehicle for your good ideas - it is not an end unto itself.
>
Indeed it is not. Perhaps we have no need of an "enhanced" Tcl at all. I
have not seen anybody say that as yet, and I suspect that if someone did
say it the reaction would be somewhat animated. The thing is, having
watched months of discussion about things like the "OOP framework in
8.4", and "RFC for the overhall of _____", most of which enjoy fleeting
glory, it is my sense that there is a feeling that Tcl needs to be
something more than it is, but also that consensus as to what that
missing something should be is not forthcoming.
A strategy that states that Tcl is to be frozen into a standard
scripting language as defined by its (more or less) current structure,
features and interface specifications might, in my opinion, be as
effective in preserving the language as would be a fruitful result of a
search for a new evolution path. After all, we all still use MS batch
scripts 20 odd years later, and that is the result of a conscious
decision by Microsoft to NOT improve the language in any way.
--
Iain B. Findleton
http://pages.infinit.net/cclients
custom...@videotron.ca
(514)457-0744
Yep, that's the only reason I use Python. At one point, I was even
considering porting it to itcl.
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***
John Ousterhout wrote:
>
> Mac Cody wrote:
> >
> > .... Still, having that additional "support
> > contract" backup made it much easier for management to buy
> > into Tcl/Tk versus more popular and visible packages like
> > Perl and Java....
>
> But did you actually buy a support contract? Unfortunately it's
> hard to build a business around a backup strategy that no one
> actually pays for.
>
We'll, as I said, it made pitching Tcl/Tk to management much
easier. It didn't make it fool-proof, though. There is a lot
of inertia towards "everything Java", even in my own department;
where I've been advocating Tcl/Tk since 1995 (when Java was an
obscure language called Oak, IIRC). It has been a constant
struggle advocating Tcl/Tk with a few victories and setbacks. I
pushed for Tcl Consortium membership (when it was around) and
buying a Tcl/Tk support contract here at Raytheon without success.
Sorry. At least I tried.
Mac
--
_________________________________________________________________
| | |
| Mac A. Cody | Principal Physics Engineer |
| Raytheon Systems Co., C3I | email: Mac_A...@raytheon.com |
| mail stop HA-36110 | phone: (972) 205-6452 |
| P.O. Box 660023 | or 1-800-752-6163 x6452 |
| Dallas, TX 75266 | fax : (972) 205-7180 |
|_______________________________|_________________________________|
And at least one Tcl user who hasn't heard of "PHP"? (Here around
Albany, NY, we have "CDPHP": the Capital District Physicians Health
Plan, but I bet that's unrelated.)
Chris
--
Christopher Nelson, Sr. Software Engineer Pinebush Technologies,
Inc.
Author: Tcl/Tk Programmer's Reference
http://www.purl.org/net/TclTkProgRef
Tcl has the vision problem for long term. At the beginning Tcl was promted
as a platform, then it became a tool to promote the use of the XML.
Could you convince manager to use Tcl rather than Java?
It is difficult. Because Java has a long term support. I think Tcl, Perl,
and
Python may fall in the corporation market in the future.
[snip]
>
>This is a perception thing, a good looking website speaks of many stable
>language supporters, while no website, or just a spot on SourceForge speaks
of a
>grad-student project that could be dropped after graduation. (Before
anyone jumps on
>me, these are not my opinions, they are the opinions I fight against to
promote
>what I consider the best tool for many projects.)
>
I agree. SourceForge is not enough. Only coders will read it.
A web site is very importan to promote Tcl's existance.
>I think we need a corporate sponsor to provide the appearance of
>stability. Corporate IT Departments need to know there is somplace where
>they can buy a long term support contract, even if most Tcl/Tk users don't
buy them.
>The corporate IT shops need to be assured that the *COULD* buy the
>contract, whether they need it or not. It's the perception that they can
get help
>if they need it, rather than having help right now that's important.
>
Right.
Chang LI
>........................... Clif Flynt ..........................
>... Tcl/Tk for Real Programmers - Academic Press Professional ...
>.... http://www.cflynt.com ............ cl...@cflynt.com ....
>. In theory there is no difference between theory and practice .
>........................ In practice, there is. .................
>
>
>
>
>
Hi,
one sentence about Phyton ...
I have contact to a lot of different company's,
bank's or consultatnt agency's and i never saw one
line of Phyton code in business
I would say
"Phyton is the most unused language"
mfg
aotto
> Tcl has comparable technical credits: AOLserver
> is based on Tcl! StoryServer is based on Tcl!
> Source Navigator is based on Tk! Tcl does awesome
> XML! Comanche is based on Tk! ... Why does the
> marketplace take Tcl for granted? I'm still puz-
> zled.
> --
>
> Cameron Laird <cla...@NeoSoft.com>
> Business: http://www.Phaseit.net
> Personal: http://starbase.neosoft.com/~claird/home.html
>
> I don't mean to be rude, but what is your point? What feature could
> be added to Tcl to overcome this "strategic concept impasse" of which
> you speak?
I only comment on the angst I observe in the news group. Personally, I
think that Tcl is just great as it is. I think that, aside from the
occaisional bobble, its pretty well reached the limits of where it can
go without a major overhall of its language structure. Since I use it
mainly as a glue and configuration tool, which, as I understand it, was
what it was designed for, I really see little need for further
development of the language.
>
> One could say the same things about C or C++. You are basically stuck
> with VC++ on windows, and if you are running on anything else you
> are most likely going to be using gcc. Where is the innovation there?
Indeed. Gcc, however, being as it is a truly wonderful compiler, just
does not come in at the same level as VC in terms of end user useability
and feature richness, does it. I presume your point is really that
VBScript is destined to obliterate Tcl in the Windows marketplace?
>
> Or we could look at other scripting languages. Where are you going
> to buy "enterprise support" for Python and Perl? Has the lack of
> a "strategic concept impasse" caused people to stop using Perl?
> Last Perl users meeting I went to, they were talking about this
> cool new concept that was appearing in the next version, UTF-8.
>
> What exactly is this "winning strategic direction for the future
> development of Tcl/Tk" that you speak of? Frankly, I don't see
> why Tcl needs a "winning strategic direction". It is a tool,
> use it to make cool things. If people like the things you
> make, they will use your tool.
>
Well, I do realize from previous exchanges that I grate on your nerves,
and for that I do appologize. I am a big fan of Tcl and I don't
personally think that much more than an improved packaging of the Tcl
idea is needed, or rather might be useful. Perl, I think, got main
stream when people said "Perl is THE premier tool for CGI applications",
this at the time the web started to expload. Python I don't really know
about all that much, but I wonder if its popularity has outdistanced it
ability to deliver results.
People said about Tcl that "Its a glue language" and what do you know?
It has become popular as a glue language! But, you know, its a great
language for many other things. Unfortunately, people pigeon hole
everything, so you have to be very careful what you say when you launch
a new thing. Your first label will stick, and come back to haunt you.
So, I ask, what, exactly, should we all say when someone asks "What
exactly is Tcl and what is its main use?"
Saying "Gee, its just great, you can use it for everything!" is probably
not going to do it. I am presuming that there are good answers out there
in the community, and I am suggesting that they be aired, distilled, and
the best ones propagated.
Well, if you look to the latest statistics and count
LINUX to UNIX the world look different. In fact there
is a strong movement into LINUX
> Python I don't really know about all that much, but I wonder if its
> popularity has outdistanced it ability to deliver results.
I'm ok with both Python and Tcl, and use them both. I probably have
more of a vested interest in seeing Tcl succeed. I don't consider
myself too much of a bigot, but I will say what I think Python has
going for it:
1) It feels very clean. Things make sense, and work in more or less
the same way throughout the language. It doesn't have too many
'special cases', or wierd idiosyncracies.
2) It has a huge standard library that is documented well.
3) It feels pretty general purpose to me. By this I mean that I could
use it for a lot of things, and it would work ok. Maybe it
wouldn't be as fast as C, or have quite as nice a C API as Tcl, or
muAnge text as well as Perl, but it will do all of these pretty
well. I also wouldn't feel uncomfortable seeing it used for a
large program, it seems to scale pretty well.
I suspect that many other people get the same impressions from it.
Ciao,
--
David N. Welton, Responsabile Progetti Open Source, Linuxcare Italia spa
tel +39.049.8043411 fax +39.049.8043412 cel +39.348.2879508
dav...@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
I am not really the right person to necessarily lead the
effort. This is really something that needs to be
championed by one of the tcl core team members.
The decision has already been made to split tcl and tk
into two seperate projects: tcl and tktoolkit -- when
they are moved over to sourceforge. This is a first step.
o Tk needs to be made fully thread safe, so that the event
loop etc. will work correctly in a multi-threaded world.
o Tk needs to be made into a proper package (there has
been a lot of talk about this, and I think some patches
have been submitted to do this.
o Tk needs some more widgets (at the Tk-C level) to be
more comparable to other toolkits. As Cameron knows,
Tk is losing ground to wxPython and PyGtk, etc. in the
python world. There is a good start to this for Tk 8.4
(Jeff wrote a spinbox and Eric wrote a panedwindow) but
there are still several more widgets (see the 8.4 roadmap)
that are needed in the near term. Eric has mentioned that
he might be willing to write an experience paper on how to
make a new widget for Tk (using the C API etc.)
o Native Drag and Drop (tkDND will meet this need-- George
Petasis is working on this).
o TkGS (I know that Mo Dejong and Frederic Bonnet are working
on this with
o Mac OS X Tk (Jim Ingham is working on this).
o Work at the Tk C-level to make writing of megawidgets easier.
(as discussed by Eric Melski earlier this week)
I could see potential collaboration on many of the projects
listed above. Each of the other language communities have
Tk advocates (some of whom have books about using Tk with
their respective languages), that could help work on Tk.
One additional item that isn't listed in the projects above,
would be to move the tcl bindings that lie over the Tk C layer
into a tcl specific directory, and allow other languages to
have directories at the same level for their tk integration
pieces. I don't see this as being popular with the Tcl/Tk
community, but I think it is probably the *right* thing to
do if the communities are to really start working on Tk as
a multi-lingual widget toolkit.
Really the biggest hurdle is getting past the mindset that
people will flee tcl for other languages if they have access
to Tk. Other languages *do* have access to Tk. Some people
do choose to write perl/tk or python/tkinter, and yet others
continue to use tcl/tk. I don't have any personal desire
to write perl/tk or python/tkinter, but I think that it is
strategically important to get more people contributing if
Tk is going to remain the powerful toolkit it is today. As
I listed above there is plenty of work to be done, and it
will benefit tcl/tk programmers as well as the other language
communities. Alternatively, with no help from other
communities there might not be enough contributions
to finish all the above listed tasks in a timely fashion,
which would hurt tcl/tk programmers.
Well I have a day of meetings ahead of me, so I probably won't
be able to write much more untill tonight.
I will reiterate that I think it is important to get someone
from the TCT to champion this, as I am not really very
involved in core development-- and the new model is built
around the TCT championing projects they believe in.
--Dan
>In article <39F66BFD...@scriptics.com>,
>John Ousterhout <ous...@scriptics.com> wrote:
> .
> .
> .
>>Unfortunately it's hard to build a business
>>around a backup strategy that no one actually
>>pays for.
> .
> .
> .
>QOTW. There's some hilarious comeback to this 'bout how
>other language inventors are given to wild public pro-
>nouncements, but *our* founding father has an unrivaled
>ability to speak soberly; I'm apparently not a funny
>enough guy to figure it out, though.
Actually, the funny point really is that Ajuba can no longer
afford to support Tcl--because Tcl is so stable and easy-to-use
that Tcl users don't need the support.
Will
--------------------------------------------------------------------------
Will Duquette, JPL | William.H...@jpl.nasa.gov
But I speak only | http://eis.jpl.nasa.gov/~will (JPL Use Only)
for myself. | It's amazing what you can do with the right tools.
I don't question that Java has a long and prosperous
future.
This reminds me tho.... I have been picking on a ScottFree Tickle
counterpart for sometime now.... I need to dig it up and finsh it!
scott
>
> Cameron Laird <cla...@NeoSoft.com>
> Business: http://www.Phaseit.net
> Personal: http://starbase.neosoft.com/~claird/home.html
>
Like www.tcltk.com for example?
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- US citizens? Remember, I rule the world in this scenario. They aren't
citizens of the US, unless that stands for United Stevenland.
-- Steven Odhner <ta...@primenet.com>
Perl 5.6, Python 1.6, and Python 2.0 all comes with
Unicode support.
</F>
I've been reading this thread from the beginning, and the discussions
seem to be interesting(taking twists and turns). But I've found no one
ever mention the use of Tcl in EDA industry. Most of the inhouse
CAD tools use PERL, but TCL is being the chosen API for commercial
CAD tools, most notable ones are those from Synopsys(their flagship
product design compiler(without which none of the microprocessors, be it
a Pentium or K6 would have been made possible) uses Tcl API. Also
Avant! does have a Tcl API for all its products. Tcl has become the
language of choice in the EDA industry. Many of the not well known
EDA tools(eg. Sente now part of frequency technology), has been built
mostly on Tcl and has Tcl API. I've been using for the tcl/tk/expect
successfully for the past few years.
EDA industry is one of the few commercial markets, where Tcl really
shines and outshines even the most widely used PERL.
Regards
Raman
Perl 5.6's Unicode has warts; for example, it can't
do convenient reads from Unicode-encoded files. See
the perlunicode document which is part of the 5.6
manual set.
Still, what 5.6 has is quite a wonderful step forward
for the people who need it.
Effbot himself implemented Python's Unicode string
type (when he wasn't working at his startup, main-
taining Tkinter, writing daily summaries of Python
news, or checking in on comp.lang.tcl to ensure we're
telling the straight story), and it works quite well,
from all I know.
--
Perhaps someone who knows these toolsets could provide a list of
widgets they have that tk doesn't have. A similar list of Perl/Tk
widgets that Tcl/Tk is missing would be useful as well...
--
<URL: https://secure.paypal.com/refer/pal=lvirden%40yahoo.com>
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
We recently developed a big CMS application with Eiffel and a TCL/TK
binding. Writing an article about this is not the problem but which
magazin wants to print this ? They told me its to exotic.
So i must keep my secret of success for myself :-)
That is true. Exactly the web site should be a Tcl portal.
Chang
Microsoft dropped Java because it got nothing as a software
company.
Sun and IBM will push Java because they are hardware
companies. They do not expect make money from the
platform software. They just want attract users to their
hardware platforms (servers).
Chang
>I don't question that Java has a long and prosperous
>future.
I can accept that. Well, there is one other thing;
besides attracting customers (in IBM's case, at least
as likely to be in services as hardware, much as I
admire some of the IBM hardware), it's cheap brand-
ing. At least part of Sun's justification for Java
promotions has no particular technical component;
it's simply a way for Sun to establish itself as a
happ'ning place. I'm serious--that's part of the
public relations dance.
>
>o Tk needs some more widgets (at the Tk-C level) to be
> more comparable to other toolkits. As Cameron knows,
> Tk is losing ground to wxPython and PyGtk, etc. in the
> python world. There is a good start to this for Tk 8.4
> (Jeff wrote a spinbox and Eric wrote a panedwindow) but
> there are still several more widgets (see the 8.4 roadmap)
> that are needed in the near term. Eric has mentioned that
> he might be willing to write an experience paper on how to
> make a new widget for Tk (using the C API etc.)
>
A big program of Tk is that its look and feel is not professional in native
platform. A fundamental rule of GUI design is the consistency. On Windows
Tk's widgets looked weird vs. any native windows applications. Tk on
Unix may be better.
Chang
>--Dan