Updated 2018-01-03 17:53:57 by CapoCapisimo ▲

Contributors to comp.lang.tcl frequently express concern that a decision to use Tcl is risky, because the language might ... well, something might happen.

It's hard to answer unspecified fears rationally. The well-defined ones all turn out to be mistakes. Will Java be better-supported? Well, IBM and Sun have been supporting Java for all its worth, and its portability in particular, and Tcl remains available for a wider span of platforms. Is Tcl vulnerable because its creator might not support it? In fact, John Ousterhout has been away from technical leadership of the implementation since 1999 or so, and new versions continue to appear. Won't GNOME themes, or .NET, or Ruby, or object-orientation, or ..., leave Tcl behind? Sure; in three to five years, each of these will catch up with features Tcl already enjoys. If that means, "leave Tcl behind" to you, then Tcl is probably not a language that will leave you comfortable.

Maybe Tcl will decline in any of several objective senses. The evidence usually presented in support of such a prediction, though, is demonstrably ... inconclusive.

LV: I would add to the above that when people say "Tcl doesn't have ..." followed by some function, what they seem to mean is "I want to do ..., but I don't want to code it myself, don't want to pay someone to code it, and don't want to have to download and build something other than the tcl.tar.gz or tcl.zip file."

That is a rather unfortunate attitude to take towards open source.

VK: That's not always true. Sometimes TCL does not have some feature due to the fact that it does not go smoothly into the TCL ideology, but it is actually really used in programming world. Closures - http://wiki.tcl.tk/3330 is an example (there are attempts to simulate them but all you get is poor substitutes). Proper object destruction is another example. Anonymous subroutines, the possibility of writing one-line command line scripts - you can neither download this as .tar.gz nor even implement it actually.

Duoas: Wait a second-- are you saying that just because you can find things like monads in functional languages or direct port access in assembly languages or feature X in language Y that Tcl should include it in its core? Perhaps all imperative languages are evil and should be turned into functional languages? There will always be differences in design philosophies between languages. Tcl's strength lies in the fact that it is easily adaptable to so many different (and usually incompatible) philosophies.

LV: VK, you make a valid point. I will grant you that there are various features which Tcl does not have, and which are anywhere from difficult to impossible to implement. But, if you think about it, there are few languages in existence which have every feature that anyone might think of during the many years after its creation. So that is just a simple statement of fact and not a criticism of every language created.

Duoas: I don't think his point is valid at all.

LV began by saying that people complain that Tcl doesn't have feature X because it would mean having to code it themselves. This is an attack on the mentality of lazy programmers, in defense against their gripes about Tcl: they could still code feature X themselves, or find another, perfectly valid Tcl way to do it.

VK, at least as I read him and in context, disagrees, giving the argument that people in the real programming world (an attack on Tcl advocates) use feature X, which Tcl does not have "due to the fact that it does not go smoothly into the TCL ideology" (an attack on Tcl). He attempted to lend weight to his argument by mentioning closures, object destruction, lambdas, and one liners, concluding that all are only available in Tcl as cruft or impossible. This endeavors to equate laziness with its opposites: propriety and knowledge of how to use the tool at hand.

I responded that this reasoning is nonsense. Just because you can find some language feature X does not mean that Tcl is useless, or that doing something one way in language Y means that it needs to be done the same way (or at all) in Tcl. You can read here [1] what Stroustrup said about similar attacks on C++ (scroll down to "C++ is useless...").

Show me all the programming languages that don't work or are obsolete because they don't have closures, and why they trump all the programming languages used for the past 30 years that have worked just fine without them. Show me all the critical programs that were subverted because the language didn't have lambdas! Show me all the one-liners critical to general computing and why this obsoletes Tcl!

LV is correct: no language has everything. If you want closures, either go use Scheme or Smalltalk, or fix Tcl yourself! It seemed to me that the point of this page was that bloating Tcl with nonsense like this is a real fear. Is Tcl Different!

SYStems: regarding closures, I believe their main value is encapsulation, they are a simple nice and clean data encapsulation mechanism. TclOO will provide encapsulation which what closures are all about. While I agree closures might be a lot simple and straightforward for many cases. But the OO approach is not such a terrible compromise.

DKF: Closures and OO do different types of encapsulation, and aren't interchangeable. The main problem with closures is how to introspect them; introspectability is a key feature of Tcl.

RS: Open source software lives as long at least one developer has the sources and can compile them. Tcl sure isn't a fashionable language, but you also often hear how people are surprised and ultimately converted. Yes, we are a minority - but we've got The Cool Language! I'm not worried as long as everything is a string.

LES 2006-11: I am not really an expert, but I do read and try a lot of stuff, and after 3 years using Tcl, I am still firmly convinced that Tcl is, sadly, an excessively well kept secret. If more developers took the time to shake off all prejudice and examine Tcl a little more, they would have nothing but the insecurity of working with an unpopular language to deal with. Tcl Tcl has all and a few other traits that many languages pursue and haven't managed to deliver to-date. Sadly, Tk is a different story. Tk is obsolete, no question about it.

peterc 2008-01-13: This where the modern widget extensions like Tile are so important to Tcl's future as it stops people making snap judgements that Tcl's dated just on the basis of what classic Tk looks like. (Much as I think Tcl can continue as a lower profile language on a technical level, I'd really like to see more jobs on the boards with Tcl skills sought after.)

Tcl has many years in front of it

Nothing to worry about. No need to have a million programmers for a programming language to live and prosper. As the saying goes: too many cooks spoil the broth. I think Tcl-TK has the right ingredients, the right wiki, the right chat, and ultimately the right people to live for a long long time. It improves slowly but steadily and this is what counts. I am sure it will still be strong and healthy when yours truly will become food for (gourmet I hope) worms 6 feet under the ground :-) and way beyond...

Besides, good programming languages take a long time to die. We still hear about Cobol and Fortran which have been around for 50 years.

But those who really want to ensure Tcl's longevity, those who really want to make a concrete gesture towards getting TCL known, should do what

and a few others have done: write software for the general public. Everyone who, like me, will be able to open magically a new program with just a click of the mouse without any installation, will be curious about the language and will try to learn more. Will, Jean-Claude, Mark, Brian and the discrete programmer have given Tcl/Tk its visit cards and its credentials.

But don't worry anyway about programming for programmers. There is a whole section of French literature which is called: literature for writers (le Nouveau Roman). They write experimental novels if you will (novels without a character, without a start, a turning point and an end). They don't sell a million copies of their books but still, a few thousand people are interested and this is what counts.

Finally, a last point. Judging by the vitality of this site, Tcl will be around for a long long time.

All in all I believe TCL's main strengths are this wiki, the chat, programmers mentioned above who write software for the general public, people like Mike Griffiths who make it a point of answering questions on the Ask and it shall be given pages and each and everyone who contributes to anything related to Tcl/Tk by bringing in their two cents worth.

No. Really. There is nothing to worry about.

I do worry about climate changes however. But that is another story for another day...

RFox: I have only two things to say about this: AOLserver & CISCO.

[LTG30]: If the reader is concerned about TCL's future, read the third paragraph of this link. http://www.tcl.tk/about/audience.html

[BV]: F5 (http://www.f5.com/) has added a new feature called "irules" to their latest load balancing products. They made extensive use of TCL. These irules are very powerful. You can read more about this by searching for "irules" at http://devcentral.f5.com/ .

SYStems: I too would worry if Tcl was the only programming language I know, but why should it be? I agree that for any individual there are so many languages he can learn. And even when you do know more than one language, most developers seem to prefer to use just one most of the time if not all of the time. Even more I know that it's hard for Tcl to be that one language. I think the core team of Tcl should focus more on making Tcl different than redundant. This way Tcl will have a better of making the short list of the programming languages most programmers feel the need to learn. My pick list would be

  • Java
  • C, C++ (systems development)
  • Vb.Net or C# (anything first class in .net)
  • A scripting language: Perl, Ruby, Python, Tcl. Python just got a huge push by being the default for the OLPC
  • Sql, PL/Sql, T-Sql, MDX

As you can see Java is in a category of its own (in my opinion), Tcl isn't!

LV: Of the the more apparently unusual aspects of Tcl is that there isn't a core team who has a goal of moving Tcl forward. The TCT is tcl's core team and their goal is to facilitate new features as the community makes suggestions and then the community develops them. Granted, there are those on the TCT who do in fact work on the core language, submitting wonderful improvements. But they do so wearing the hat of a community member, not as a part of the job of TCT member. I'm not involved in other communities like Tcl, so perhaps this is a different development model from most. Most of the software I follow, in fact, is lead by its creator or someone who picks up the reigns after some change in leadership. Thank goodness we have the TCT to manage releases, to help discuss the technical merits of new ideas, etc.

DKF: Well, there are two groups. There's the TCT who are very much about management oversight and strategic stuff, and whose membership is restricted (though our discussions are public). But for day-to-day work, there's the [Tcl Maintainers] and [Tk Maintainers], who are the people with commit access to our CVS repository. Anyone's free to be a maintainer; the main requirement is an ability to submit patches for bugs that don't break things. New features have to have their genesis in the community as a whole though (formally, we want a patch and a TIP before the feature goes in, so that we capture not just what was done but why); the biggest advantage I have is not that I'm on the TCT, but rather that I'm an active maintainer and so I've got a lot of experience with the code, and that's something that's open to anyone who knows C (or Tcl or nroff or autoconf) or who is willing to learn.

LV] Thanks for the additional explanation. As a side note, do most of the enhancements to the code you maintain come from any sort of direction given to you (or set by you) or do they mostly come from community contributions via TIP or some other means?

DKF: It's a mixed bag. A number of things that I know about are really just me (or one of the other main folks that form the loose cabal that corresponds to other projects' "core team" notion) scratching long-standing itches, especially with the things that go deeper. But other stuff is often a feature that's pushed for by the wider community foremost (more often these are things that are less about fundamental semantics and more about nice shortcuts for great usability). But these are general impressions, not rules.

The best way to become a maintainer is to try to fix bugs for a bit. Then maybe design and write a new feature. At that point you'll probably have enough experience to be able to do real maintenance.

[DM] 2010-07-01 07:31:54:

The portability problem of Tcl/Tk applications through Tcl versions and platforms is often the portability problem of some critical extension. We have seen that with IncrTcl, long time ago, and we are seeing that today with BLT. I understand that the adoption of a well defined architecture for extensions should help, however, for the sake of Tcl future, it'd be advisable to keep an eye on such key extensions, not just on the core package.

LVwikignoming 2010-07-01 11:37:46:

The remarks about portability across Tcl versions actually applies to portability across platforms as well. So it really behooves a developer to make each use of an extension an intentional decision, and to include in the application test plans testing against the platforms and versions that will be supported.

SeS 2010-07-06:

I would like to add my 2 cents into this discussion, simply because I have 5+ years of experience in digital IC layout design and I am witness that over the years, also before I started this profession, that it seems that tcl has & is being used on a frequent base by both tool suppliers/developers as well as IC designers in the semiconductors industry. For some reason, the PR of tcl/tk is kept quit (in relative terms). Sorry, if I am repeating things, but I think a programming language becomes more attractive as soon as SDE kits & tools become more mature & available and provide enough features to let the designer express their needs & idea's in a quick & consistent manner. With tcl/tk, I see a vacuum compared with other languages, especially in terms of a mature and up-to-date IDE, although "mature" is a relative term since the requirements of such an IDE is different for each software developer...

bch: What would be the IDE that's a Python IDE, or Perl or Ruby or PHP? That's the space that immediately jumps to mind that Tcl competes in. I happen to use XEmacs and it's inferior-tcl mode for a REPL, among other Emacs features. I don't know how typical that is, or what others might want. Compared to other languages, perhaps you could enumerate Tcl's IDE weaknesses?

SeS: To answer that, I would have to pick an IDE written in/for tcl/tk and do a compare of these to a reference. My reference would be Visual Basic, since I used it in the past frequently, but, maybe that is the problem or the reason for my comment. Let me put it in another way, IS there a IDE written in & for tcl/tk which simply let the user move around any widget on a form/toplevel from pixel to pixel? In other words, using the "place" geo manager instead of pack & grid which (I believe) the majority of tcl/tk IDE's do? There is no need for pixel-based placement? Well, maybe, maybe not, it depends on one's requirements and one's imagination, having the option would be nice. I am not saying there is none, it is just that I have not read or seen one yet...and since I am relative new to tcl/tk, maybe you can enlighten me and show me the link to such an IDE? I would sure like to see it to compare it to my initiative, tG². And there is more what makes an IDE a good IDE, but this would require a book to be honest, with my limited time I am restricting myself to this feature only as an answer to you bch.

[CapoCapisimo] - 2018-01-03 17:53:57

Tcl is great!, is powerfull and simply RAD language with Tk library, not contrived characteristic.

Category AdvocacyCategory Discussion