I notice a couple of the talks are repeats from the European meeting that I attended in June :-) http://www.eurotcl.eu/program.html
383 karma · joined September 8, 2015
This avoids the Global Interpreter Lock problem that plagues Python. How does Guile handle that?
But people who are willing to take a less conventional approach may find that it opens up cleaner and more elegant ways of doing things. For example, upvar is not just a workaround - it can support meta-programming techniques which are not even possible in e.g. Python.
The "Tcl way" is to have a minimal core which just supports running commands and connecting them together. Everything else is implemented as commands, including the control constructs, and any command can be redefined. This flexibility does of course allow things to go wrong in ways that could not happen in a more restrictive language. But it also provides an adaptability that is hard to give up once you get used to it.
A new terminal/shell is a very hard sell, as I know from my own experience. Six years ago I wrote my own terminal/shell combination ( http://wiki.tcl.tk/23446 ). It works well enough that I've been using it myself full-time at work ever since, but although a few other people have tried it, no-one else ever adopted it. My own attempt is implemented in Tcl/Tk, an older but much lighter-weight framework (it has no problem with cat-ing a 50MB file).
I combined the functions of shell and terminal because I found the shell/terminal split made some of the functionality I wanted difficult or impossible. One example is that I colour text written to stderr in red - standard shells mix stderr and stdout together before the terminal even sees them.
I decided early on that I would not support terminal escape sequences. I set the TERM environment variable to "dumb" which tells well-behaved programs not to use escape sequences. So you can't run vi/vim in one of my windows, but I always use gvim so I don't find this a problem.
Similarly after some experimentation I decided not to use ptys as they created as many problems as they solved. So programs which change behaviour based on whether they are connected to a terminal behave as if running from a script. Eg. running "man command" lists the whole man page rather than trying to page it - but this is what I want since one can page up/down in the shell anyway.
However it seems that people who use a terminal get very attached to its idiosyncracies and will reject anything even slightly different. Since it's very difficult to make any real improvements without introducing incompatibilies, attempts at improving the terminal/shell user experience rarely catch on. In contrast, a few other tools I have implemented using the same technology have been adopted by a worthwhile user community at work. I think the difference is that they are used for more specialised tasks and don't require the user to change their everyday workflow.
Anyway, good luck with your endeavour!