[VTK ARB] TCL/TK: is it needed anymore in VTK?

[Steve Pieper]

Hi Guys -

As one of the olde timey tcl guys, I'd agree with Andrew's assessment that
supporting tcl in the future is not required and should be considered for
the chopping block for VTK 6.

FWIW, the current development version of slicer (version 4, to be released
this year) relies only on the vtk python wrappings.  For most purposes, the
differences between python and tcl are pretty minimal - but the big thing
python has is numpy and the ability to get at image/poly data as numpy
arrays.  Now with SimplyITK's python bindings it is becoming possible to
move bulk data around between packages in very nice ways.

For those who are interested, the last vestiges of tcl in slicer are
supported by an adapter layer which uses tkinter and a custom package called
tpycl (python inside tcl - meant to be pronounced, with a sigh and a roll of
the eyes as "typical!").  With typcl, big chunks of slicer code written for
tcl wrapped vtk can be run unchanged against a python wrapped vtk.  This is
used to delay the task of porting/debugging legacy the Editor and the
EMSegmenter.

http://viewvc.slicer.org/viewvc.cgi/Slicer4/trunk/Base/Python/tpycl/

This layer is for backwards compatibility only - nobody is using it for new
development.

-Steve

On Wed, Jul 27, 2011 at 11:40 PM, Andrew Maclean
<andrew.amaclean at gmail.com>wrote:

> Hi Will,
>
> I have just now had a look at slicer and see what you mean.
>
> Regards
>    Andrew
>
>
> On Thu, Jul 28, 2011 at 1:36 PM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> Andrew-
>>
>> I see your point and agree, I'm thinking that applications like
>> Slicer, which at one time had large dependencies on Tcl, would not be
>> happy (although this is fast changing). So if this were to occur it
>> would have to be staged over a very long time, probably after some of
>> us older guys bite the big one :-)
>>
>> W
>>
>> On Wed, Jul 27, 2011 at 10:10 PM, Andrew Maclean
>> <andrew.amaclean at gmail.com> wrote:
>> > Hi All,
>> > This is just for discussion and it was prompted by a throw-away comment
>> by
>> > someone in the last VTK ARB Meeting regarding TCL.
>> > So:
>> > In the beginning ... when VTK was just a baby (and a lot of you at
>> Kitware
>> > were still in primary school!), TCL was really essential and useful
>> because
>> > at that time there were no other rapid development/prototyping languages
>> > that were cross-platform and easy to use. So at that time (late 90's
>> early
>> > 2000's) TCL was really great in that you could rapidly prototype
>> something
>> > and then code in C++. Yes I know that Python was around at that time but
>> TCL
>> > usage was more widespread.
>> > Now... we have Python and using Python is really convenient because the
>> > transition to C++ and or Java is relatively simple.
>> > I know that there are still tests and examples that use TCL in the VTK
>> tree
>> > but lots of these have moved to C++.
>> > Also if you look in wikiexamples, there are 6 tcl examples vs around 59
>> > python examples, 11 java and lots and lots of C++ examples. So to me
>> this is
>> > saying that TCL is fading into obscurity. You could argue on
>> > these figures that Java is not doing so well either but good Java
>> > programmers can easily convert C++ to Java so I suspect Java programmers
>> > just use the C++ examples.
>> > From my own experience I have found it is far simpler to prototype in
>> Python
>> > and then develop in C++. I used to use TCL (because nothing else was
>> around
>> > in the old days), but switched to Python because I found that students
>> and
>> > coders were more able to use Python than TCL mainly because of syntax
>> > issues. The main point is that the syntax of Python is modern but TCL is
>> > not.
>> > Is there a really strong reason for supporting TCL in the future?
>> >
>> > I have no issues with Java and Python and our efforts should go to
>> > supporting these two languages. I acknowledge that there is
>> an Achilles heel
>> > in Python in that Python 3+ is different from 2.x but you can work
>> around
>> > these issues and I am seeing some development now moving off 2.x to
>> version
>> > 3.x. However the Python 3.x api seems to be closer to C++ than the 2.x
>> > versions so in the future more programmers will move to it.
>> > Regards
>> >   Andrew
>> > --
>> > ___________________________________________
>> > Andrew J. P. Maclean
>> > Australian Centre for Field Robotics (ACFR)
>> > The Rose Street Building J04
>> > The University of Sydney  2006  NSW
>> > AUSTRALIA
>> > Ph: +61 2 9351 3283
>> > Fax: +61 2 9351 7474
>> > URL: http://www.acfr.usyd.edu.au/
>> > ___________________________________________
>> >
>> > _______________________________________________
>> > Arb mailing list
>> > Arb at vtk.org
>> > http://public.kitware.com/cgi-bin/mailman/listinfo/arb
>> >
>> >
>>
>>
>>
>> --
>> William J. Schroeder, PhD
>> Kitware, Inc.
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> will.schroeder at kitware.com
>> http://www.kitware.com
>> (518) 881-4902
>>
>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
> Australian Centre for Field Robotics (ACFR)
> The Rose Street Building J04
> The University of Sydney  2006  NSW
> AUSTRALIA
> Ph: +61 2 9351 3283
> Fax: +61 2 9351 7474
> URL: http://www.acfr.usyd.edu.au/
> ___________________________________________
>
> _______________________________________________
> Arb mailing list
> Arb at vtk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/arb
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/arb/attachments/20110728/d6fd35c1/attachment.html>