bll 2017-9-8 Google Trends. I don't know how accurate this is, but it doesn't look good.https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F07fw2 (Tcl programming language)Not totally dead, this is a good sign...https://trends.google.com/trends/explore?date=today%205-y&q=Tkinter (tkinter)Another source (stackoverflow, tcl and tkinter tags):https://insights.stackoverflow.com/trends?tags=tcl%2CtkinterYou will find that there are a large group of people who have no interest in changing the wiki. They spout phrases like "spirit of the wiki", which if I translate correctly means "do it my way". It would actually be easier to start a new wiki, but you will need to collect a group of people who are willing to contribute to it -- this is difficult, as many people don't want to keep two different wiki's up to date. Fragmentation isn't good, but fighting these these high-inertia people seems worse in this case.A repository of Tcl packages would be great, but first I think a more standardized way of installing would be useful. e.g. Python (which I know nothing about) has a set of directories that are searched for modules, and their 'easyinstall' and 'pip' programs install into these directories. If the Tcl modules could be installed in this manner, this would be much easier. I think, right now, if I installed a few Tcl modules to use on Linux, I would probably have to add several different paths to ::auto_path. This is not portable nor very manageable.Once this module/package tree/system is in place, then the major modules can be repackaged to install into the standard directories, and a repository/installation system can be built.I also have a server available that can be used for wiki/forum/repository, whatever Tcl/Tk related.
EMJ 2017-09-12 bll, you said "I think, right now, if I installed a few Tcl modules to use on Linux, I would probably have to add several different paths to ::auto_path." Could you perhaps provide an example of this.bll 2017-9-12 Can't find any. Looks like the maintainers are choosing good paths and tclsh and wish have those paths. But my locally installed tclsh doesn't have these paths in ::auto_path (nor does a tclkit, but that could be argued). I don't think /usr/lib should be in the search path.If have have my own tclsh installed into $HOME/local/, I would still like it to search the standard paths.I would still want a way to install packages from a repository (into $HOME/.tcltk(?)) using some tool so I can fetch an up-to-date version of a package and have it work.
- Google Trends - Try adding Perl for comparison, its way higher than Tcl, but declining a lot faster. Try adding Python and it doesn't seem to know it's a language, so the snakes and Monty are obviously mucking up the figures. On the whole, I don't think it's clear enough how the figures are worked out.
- Stack Overflow - I think this says more about the type of people who use it and how it is run. Too many wrong but "accepted" answers (and no way to fix them), and too many incomplete answers.
- The Wiki - is not the primary web page, that is www.tcl.tk . As for "do it my way", I think it has mostly been "this is why I don't like your way", the result of which should be (but sadly often isn't) a reasonable discussion.
- Repository - yes, but what we have seen with ActiveState is both the risk of changing commercial focus and the result of the loss of specific people. Providing a physical resource to run a repositry is less than half the battle.
- Package/Module Installation standards - They exist actually - install Tcllib or tdom as they instruct and you don't need to change auto_path. However there are several reasons why people don't set their packages up for this.
- EMJ Bad idea - begins to sound like making the use of git the default. There are people who do not want to use git (including me). How could we get Github to give a list of the things that constitute our repo? ...
LostOne 2017-09-09 It's a sad truth but i've felt this since I tried doing full stack development with Tcl. While you can do almost anything with Tcl which is great there are some issues. It might not look like an issue and some will see this as a "feature" you actually have multiple ways to do anything. I think this is where the concept of feature creep kicks in.Let's take a look at Web Development using Tcl.. Overwhelmingly.. You have Naviserver/AolServer, Rivet, Wub, TclHttp, and Tanzer.. you might want to look at this page for more info http://wiki.tcl.tk/16686 I've personally tried to use Websh (2006-2008) and NaviServer(2014-2016) (built some frameworks around them) but gave up because managing & sysadmining took way too much time.. no precompiled packages, manual compilation.. etc Also because there are very few people who use them and so you have to reinvent everything session management, authentication, and basic stuff that you can find easily in PHP/Python/Ruby frameworks.. I know OpenACS has it all but there are downsides to using it. I've also tried other things but none of them suited my needs.Recently playing with Nginx + Tanzer prooved to be a better way to be able to develop web apps that can replace Tk by using the browser. Distribution of tanzer + starkit is easier. However, again, you need to reinvent the wheel for almost everything to create a web app, imagine doing a webshop..Let's take a look at the cool trend started by StarKit(s). It's now grown to distinct ways of doing starpacks like wize, cookit, kitgen, dqkit, kbskit.. Each one has a different way of working with packages.. again, 100 different ways of doing it, no unification.This wiki contains a treasure of info, however it's hidden and you need to search a great amount of time before you can find anything since the search function is not always the best way to search.Tcl Marketing & Graphical Design needs manpower.. Manpower requires volunteers and funding. The only way this would succeed IMHO is if a new community would arise on another domain.Maybe cloning the wiki & enhancing it would be the first step. However curating it is also a big requirement. Then maybe a new repository which would be open in a way that anyone could host mirrors that would be authenticated against a central server. Security wise nowadays this might prove a little tricky. There are multiple packages and pages on the wiki that talk about different types of repositories, heck, even starkits have something that can help you build a repository:). Maybe using something like the teaparty & enhancing it? http://teaparty.rkeene.org/fossil/homeTo sum it up: The biggest problem I've encountered is that there are many great tools & apps but when it comes to a userbase with examples, support & development most of them stop evolving after some time which leaves newbies scratching & banging their heads. You've got 100 ways to do something but no one left maintaining & supporting them..Unification and collaboration is the keyword here.Maybe a set of more advanced Tcl tool usage & tutorials could help with the collaboration & unification process. Just saying.Taking a look at Python as an example. 10-20 years ago you might have had university classes in Java, now they're almost all replaced by Python. It's not hard to understand why, since for Information Security and Ethical Hacking most of the neat tools out there are written in Python or have python interfacing. hping3 was the only tool (Information security wise) i've found that still supports Tcl at a scripting.The discussion and examples can go on for hours.. creating a well known, reputable, growing and usable language also means creating certain tools that fill in a niche.Anyways, since there is no big company backing up Tcl I see it as vanishing into obscurity each day.I'm open to debates & helping out. Anyone else ready for some Unification & Collaboration?
WJG (13/09/17) I don’t think that it's terribly helpful pushing out negative memes such as “Tcl is dead”. A lot of work is being done on the sources and a bunch of other useful tools and packages proving that Tcl/Tk is alive. Popularity based upon downloads and bookshop sales figures is not the measure of the suitability of a programming language for any task. Superficially, what is the most obvious difference Tcl and the ascending star of Python? --Vowels. The similarities? The name Tcl is born of an outmoded way of naming computerish kit, both hardware and software, whereas Python is named after outmoded way of British comedy. Its time to move on. I have a few points of my own to make about the comments which initiated this page. There seems to a trend to homogenize the use of computer languages, and academia does appear to be looking for a "Birmingham Spanner", single tool fit for all jobs, an approach to teaching a common programming language to new incumbents who require basic familiarity with machine processing of some sort. Familiarity with Python might "transferable skill", as academics say, but I would suggest that this approach has much is to do with what is in vogue and the need to get students up and running with something simple to grasp along with the availability of cheap textbooks. I have used Tickle since the 1990s in pursuit of various computational linguistics projects and have no need to seek out alternatives. Nowadays I’m working on some bleeding-edge work in the lemmatization of Sanskrit compounds and use relatively simple Tickle scripts for the job with success whilst others are struggling with the internals of Python and R. The Wiki? I regularly consult the WIKI as the portal to all that is Tickle and still remember the anticipation of reading about Richard Suchenwirth’s latest “weekend-project”. However, the Wikis past charm is perhaps its draw-back. In its present form using the Tcler’s wiki is like accessing the InternetArchive’s “WayBack Machine”. Nowadays my first port of call for new ideas or solutions is either Stack Overflow or RosettaCode. Why? Solutions to questions, with no drawn out side chat. If the meme “Tcl is dead” is correct, I don’t know what the solution might be. Certainly, the imagination of potential users needs to be sparked. Imagine youngsters hacking their Raspberry Pis at school and their teacher asks which programming language should they use? When they put their hands up they will need something easy to say like "Python", the acronym “Tcl" rolls freely from no ones lips.chw (2017-09-13) sorry, couldn't resist. "Python" especially the "Monty" form sounds like the early seventies of the last century/millenium. And Tcl is an outdated TLA, too. Having enjoyed the movie "Valerian" recently, let us rename it to "Mül Converter" before the Phythonistas take this name over :-) The German version chose "Mül Transmutator" which IMO sounds even more technical.
LAM - 2017-09-13 21:22:41I vote for change the name to TZL (The Zombie Language): 1) Zombies are trending and 2) they are almost/dead but they keep going ahead (·_-)stevel That's hardly a constructive attitude. Do you actually want to get involved? There's a lot happening and if you want to help drop me an email and give you something to do. Mention what your areas of interest are.bll 2017-9-15 A publicly available to-do list would be nice. An itemized list with project, lead developer, other developers, status, last update date, a way to contact these people.
clemp 2017-09-14 I have recently "discovered" TCL in the last month while looking for a platform on which to base internal engineering tools. So, I can tell you the impressions of a newcomer who is unburdened by the bias of history. :-)
- TCL does not appear to be dead but it appears to be losing supporters as fast as it is gaining new ones. Seems to in a sort of equilibrium.
- There are an amazing number of useful packages and available code in the TCL ecosystem but... First, it is hard to find them and second, it is hard to sort them out from the many packages that have not been updated for years and which do not work with the later versions of TCL.
- TCL has many traits and features that make it very useful as a support tool for other tasks but has not gotten widespread traction. As a potential new user, I was asking myself "Is there some technical reason for that?" The fact that it is still heavily used for testing and EDA convinced me that it is just a marketing problem.
- Part of the marketing problem is that I had to keep digging past the first impression to understand that TCL is still alive and being updated. The main page http://www.tcl.tk/ has links and logos for ActiveState but when I went to their site, I hit references to TCL products they no longer offer and circular links. That raised questions from the start.
- Next I ran into this wiki which has the look and feel of the old days of the web... but contains a lot of great information. Digging through it, I hit many dead links or links to pages that say "X is no longer being supported.". More questions.
- I next found TCLKits and Starkits. What a great idea! Perfect for checking out what TCL can do. I tried downloading and running them. Some work. Some don't. More questions.
- As far as the name goes, TCL is certainly more business friendly than Tickle. I can just imagine all the are-you-serious looks I'd get if I started telling potential clients that I can support their systems using a language they have never heard of and that language is called Tickle. No, TCL works much better for that.
HE 2017-09-16 I can't imagine what is the problem. 20 years ago I searched for a easy to use, platform independent, programming language which I could also easily install on win32 systems. For my working environment I found three options: Perl, Java and Tcl. Today Python would be an option, too.I gave all three a try. Java failed the job for me. Because it doesn't hold all the promises of the marketing. I saw to many Java programs from professionals with memory leaks or problems to handle Oracle connections. Comparing Perl and Tcl at that time Tcl had some advantages for me. 1st its syntax matches the way how I think so solve a problem. 2nd I don't need to bother with object orientation. But, when I need it I could simply load an package for this. 3rd it has these nice console feature (and much better in win32 the wish console). All other things like how to get the right extension came later.Today, if you are looking for a programming language it would be similar. As long as the programing language is not dictated by your environment, you would choose first which language fits from its handling, syntax, etc. best for you.As with any other programming language you have to spend more effort if you have some special needs. If you need the newest release, or to be independent from what is installed by your system/administrator, or you want embed Tcl into a program as scripting layer, or ... , you often need to to your own installation. But, I can tell you, you can do all this with Tcl.On Linux systems you have all three (four) languages available. And Tcl is a bit outdated in some of the big distributions like RedHat (and with this Centos). On the other hand you can easily compile your own Tcl/Tk distribution for Linux (and with msys and mingw also for win32/64) with all the extensions/packages you want.
osch 2017-10-08 I don't think Tcl/Tk is dead, but the language is no longer in the focus of interest. Other languages such as Java dominate software development. It would be nice if Tcl/Tk would be taken into account again, but this is a typical chicken-and-egg dilemma: Tcl/Tk is no longer taught at universities (because there is no demand by companies), so there are no beginners familiar with this programming language. On the other hand, companies no longer use Tcl/Tk, partly because there are no young professionals.To achieve a relaunch of the language, I spontaneously think of the following aspects that need to be done:
- Become independent of ActiveTcl.
- A common Tcl/Tk homepage as startpage.
- Documentation and manuals in the most important languages, not just English.
- Clean up the wiki and delete outdated posts.
- Tcl/Tk including all packages (e. g. Sqlite3, TKTable) as installable binary for Windows, OS X, Linux, Android and iOS.
- A program such as Freewrap, so that you can distribute your program in a binary form.
- A development team that reports regularly and in detail on the further development of the language and regularly prioritizes the wish list of the users.
- Generate attention in the public media (journals, internet forums and so on) to bring Tcl/Tk back into public's awareness.
- Reintroduction into university (and school) curricula.
- Central coordination of relaunch activities.
bll 2017-10-08osch wrote: Documentation and manuals in the most important languages, not just English.That would be German and French initially.Clean up the wiki and delete outdated posts. A development team that reports regularly and in detail on the further development of the language and regularly prioritizes the wish list of the users.There are people actively fighting any change to the wiki and any change to the language. They seem to be determined to make sure it stays stagnant.Some of it is due to lack of manpower. People are interested in their own projects and do not give other people's projects the support and attention which would introduce change.But there are also people (a vocal minority) that fight against anything that introduces change.Something that doesn't change does not grow and is essentially dead.You are right -- there needs to be a small development team that is willing to do what's good for the language, ignore the vocal minority and move the language forward. Sometimes the changes won't be ideal, but that's part of the growth process.
EMJ 2017-10-08I thought of a lot of responses, but I seem to have said most of them already.So, to pick on a couple of things:
- Would it have been a better use of osch's time to translate documentation rather than write a book? (I suspect not, but...)
- Who is fighting what changes? Language changes and wiki changes are two very different things. The language has changed and is still changing, and tension between backward compatibility and clever new ideas is universal.
- What does "Clean up the wiki" mean? How do we decide what pages are outdated? Even pages outdated in a technical sense may contain something of value. The trouble is, the wiki is a bazaar and some people seem to want a cathedral. They can't be combined and the bazaar is valuable.
- Old is not necessarily bad. New is not necessarily good.
- The language is great, but it's hard to deploy. There's no defacto install (even ActiveTcl hasn't really been that in a long time, and Teapot/Teacup, while a nice idea, didn't really work all that well). Also, even though they've been around as the gold standard for sharing Tcl projects as a single file for years now, the ability to read starpacks isn't even built into the Tcl core, so not all copies of Tcl can even read them off the bat.
- I think the issue with the Wiki that people have mentioned is that it's not really new-user-friendly; it's not so much community-maintained collaborativee documentation or project/extension reference, it's a sprawling mass of discussion with some documentation and notes thrown in, but all pretty much at random, and often not up to date (with info that's no longer accurate or links that have been dead for years). And while this wiki certainly has its uses, it's not something that people thinking of taking up the language look at and think "Great, this'll be handy". Tcl could really use a) a decent, dedicated, and -filled- package management system, and b) a site built around that for finding and researching packages/extensions, possibly also with a section for working projects.
bll 2017-10-8EMJ wrote: Who is fighting what changes? Language changes and wiki changes are two very different things. The language has changed and is still changing, and tension between backward compatibility and clever new ideas is universal.(a) Named parameters. (b) string insert. Neither of these causes any backwards compatibility problems and both enhance the language. I know my own code would greatly benefit from named parameters. I have many procedures where I am using an argument parser. sebres also has a laundry list of changes.Backwards compatibility is a must.
EMJ 2017-10-09(a) TIP 457(b) TIP 475 [string insert]sebres?
TV Tcl has never been the typical language certain informatics people might thing it should have been, it's still going strong in the EE world.