Sayonara Tcl/Tk

Can't fit to any of above? Send here.

Sayonara Tcl/Tk

Postby Googie » Fri Apr 05, 2013 5:42 pm

Long story short: SQLiteStudio moves from Tcl/Tk to C++/Qt, because Tcl/Tk wasn't good enough. More details on new version are here.

Now, if anybody's interested in details of why Tcl/Tk is not good enough, I will elaborate on this.

I was struggling with various problems in Tcl. I used to be a strong Tcl fun. I've been programming in it for about 10 years.
I believed in its simplicity and great possibilities. Well, at least the former one is true. I have had enough. I decided to move to C++ with Qt.
Tcl is broken at design level and it also lacks base set of ready to use solutions. I still think it's excellent tool for simplifying daily tasks.
I use it and probably will use it for that purpose. It turns out that its name fits it perfectly (Tcl - Tool Command Language).

Here are few examples of what made me change my mind:

1. Multi-threading model.
In most modern languages you have your application in memory and you can start serveral threads to work with it, taking care of proper synchronization.
Most programmers are familiar with that. Tcl on the other hand provides slightly simplified model. Here every thread has its own memory segment
(its own Tcl interpreter). Every thread can work only with its own data, therefore there's no need for any synchronization (well, almost...
but we'll talk about it later). Threads talk to each other by messages - one thread tells another to do something and the other one will do it
as soon as it's idle. It's impossible to cause dead-lock or memory corruption. As great as it might seem it introduces huge disadventages:
a) You cannot simply share Tcl procedures across threads. You have to create the same procedure in every thread you want to use it in.
b) You also cannot share big chunks of data. You have to send it in message to another thread, in other words - copy it.
c) Object-oriented frameworks won't work across threads and this is even worse than with procedures. If you want to use any class instance in two threads,
you have to load class definition in both threads, then you have to serialize object (to plain Tcl variable) in one thread and deserialize it in another.
d) Any extension your application uses have to be loaded in every thread that will use it. That includes OO frameworks, so to actually use an object
in other thread, you have to load OO framework in the other thread, then load class definition and then serialize-send-deserialize the object.
e) As I mentioned at the begining, you don't have to synchronize anything. That's not entirely true. There are still other resources that can be
shared between threads, like files. There are synchronization primitives available in Tcl for that purpose, so yes, Tcl does require some
multi-threading synchronization after all, just not for memory.

I thought that this model is a result of how it was done long time ago and it isn't easy to change it. I asked about it few times on comp.lang.tcl
and I learned that this is not the reason. It turns out it's better to forbid shared memory in order to avoid synchronization issues,
because most programmers cannot write proper multithreading applications! Who would have thought, right?

Another argument is that this way Tcl is more scalable. Yeah, right. It really scales "well" when you load 500KB of procedure definitions
into each thread, or need to copy 100MB of data, or serialize/deserialize 100 objects. Tcl's threading model simply sucks!

Here are some comp.lang.tcl threads about this subject: ... _sCRmQZHYJ ... 2lMyDk9vMJ ... rDatRZTaQJ ... cDyXToBEsJ

2. Tk
Despite the very easy GUI development with Tk, it's broken in many ways. For example it's not guaranteed that Tk will tell you the true geometry
of the window, unless you force to process all events in the event loop first. This includes events like one which closes that window, so developer
will actually ask for geometry of a window that no longer exists...

Tk is outdated. I know there's Ttk (Themed Tk) and it's great, but there still so much old stuff, like menus on Unix, or color dialog on Unix.
You won't find a nice MDI widget for Tk. There are some MDIs available, but they're very simple. There's also no real tabbed interface available.
There are tabs in Ttk, but they are very limited in features. Tabs in other packages look like they were from early nineties.

Keyboard layouts are broken. For example ctrl+c/ctrl+v won't work on Russian keyboard layout.
It's not something you can workaround in Tcl code, unless it's fixed in the Tk itself.

3. The [expr]
Everybody I tried to introduce to Tcl hated the [expr]. Apparently it's cool to add {*} operator to Tcl syntax (in 8.5), but it's a crime
to do anything about math expression operator. The {*} operator brings Tcl syntax closer to "write-only" dogma, than $() for math expression would ever do.

There was an argument that introducing $() operator would break backward compatibility. So what?! When you release major
version you're pretty justified to break minor backward compatibility in the name of language enchancing, just mention it in release notes.
Otherwise you will be stack with same old shit, which everybody complains about.
Site Admin
Posts: 689
Joined: Wed Jul 27, 2011 8:04 pm

Re: Sayonara Tcl/Tk

Postby Artur » Sat Apr 06, 2013 9:26 am

Through I cannot exactly understand* what things you are writing about, I can see you are having some problems with TCL and how you want your program to be. If C++ works out for you, that's great then :).

I knew someone who wrote a game with python. Even if in the end it worked fine, it does used a lot more resources than it should use. For such a simple game having 2 GB of ram used was a lot more than I could have expected and I told that to him. Sadly he dropped it later, because it were to much work to rewrite it for something like C++.

Googie wrote:There was an argument that introducing $() operator would break backward compatibility. So what?! When you release majorversion you're pretty justified to break minor backward compatibility in the name of language enchancing, just mention it in release notes.Otherwise you will be stack with same old shit, which everybody complains about.

That reminds me of php and the split and explode functions. Both existed for some time and they dropped it in php5.3 if I'm right. Where there complains why it was dropped and such, but why do you need two functions which do the same, if one is sufficient. They also dropped sqlite2 in php5.4, which I do hate because I need to rewrite everything I had before, but there is sqlite3. Clearing and replacing old stuff can help keeping things clean and simpler.
Let's go the easy way and choose SQLite!
User avatar
Posts: 116
Joined: Thu Jul 28, 2011 12:10 am
Location: Bavaria, Germany

Return to Chat

Who is online

Users browsing this forum: No registered users and 1 guest