To summarize in two words: Its ugly.
Tcl syntax is ugly, tk GUI's are ugly and look old.
Also, Python is the winner for me because it's syntax resembles C but is a lot easier to write.
Tcl syntax is ugly, tk GUI's are ugly and look old.
Also, Python is the winner for me because it's syntax resembles C but is a lot easier to write.
> > Lately, there has been a lot of work to update the Tk look and feel, and it has finally started to bear fruit. However, in terms of marketing, the damage has already been done: the image of "old, crufty Tk" has been firmly planted in countless developers' minds, and no amount of facts are going to displace it in the near future.
> Also, Python is the winner for me because it's syntax resembles C but is a lot easier to write.
Yes, I covered that aspect too:
> > The syntax, for your average programmer who doesn't want to go too far out of their comfort zone, is perhaps a little bit further afield from the C family of languages than they would prefer. Still though, a "human" problem, rather than a technical one. Perhaps, sadly, the message is that you'd better not "scare" people when introducing a new language, by showing people something that doesn't look at least a little bit familiar.
You are apparently one of the many who is a bit scared/confused/whatever by a seed that has fallen a bit farther from the C tree.
As far as the syntax, Tcl is quite elegant, in reality, once you take the time to understand it (which is not much time, as it's also very simple).
http://www.tcl.tk/man/tcl/tutorial/tcltutorial.html
Most of the actual material is Clif Flynt's though. It's not perfect, but at least it's a starting point that's widely visible to people getting going with the language.
And, of course, it's Tcl, whereas you're asking about Tk. Definitely something that would have been useful.
Also behind the clean Python look (that almost seems pseudo code in simple programs) the Python semantic is really complex compared to the one of Ruby for instance.
Wrong. The opposite is true. See their respective grammar dependency graphs.
Ruby: http://farm1.static.flickr.com/93/280661836_e477a01932_o.jpg
Python: http://farm1.static.flickr.com/80/281055485_cc5069b990_o.jpg
Python is specifically built around the concept of "One and only one way to do it". (Source: http://www.python.org/dev/peps/pep-0020/)
Ruby is specifically built around the perl motto of "There's more than one way to do it". (Source: http://www.artima.com/intv/ruby3.html)
Claiming that python semantics were more complex than ruby semantics just makes no sense to me when the difference is even clearly stated in their respective design goals.
Not that the three sligthly different types of callable objects/blocks/watchamaycallits in ruby are a shining example of elegant design. I don't know if ruby or python is simpler (I don't care, scala is even more baroque around the corners than both and I still prefer it), it is just that your syntax diagramms add nothing to a discussion about semantics.
They both point to the parameter definition, but lambda sits under "test" and refers back to "test" while the normal function definition sits under "compound_stmt" and also points to "suite."
Those are rather big differences, and reflect rather well that while perhaps semantically they are similar, syntactically speaking they are very different.
Well, I'd say they do provide a strong indication at least.
arbitrary and subtle differences between things that should be the same
It seems Python would need quite a truckload of such subtleties to make up for the complexity difference reflected in the graphs alone. And since one of its core design-goals is to avoid subtleties like that I think the graphs were a valid vehicle to illustrate my point.
Lambda is ofcourse a well-known wart in Python, but honestly, if we start wart-counting here then I think the comparison would end even worse for Ruby.
For the record: I'm obviously a python guy but have also used rails and sinatra before. I'm by no means a ruby-hater. It's just that I couldn't let the statement "Python more complex than ruby" pass without speaking up. Because, as I tried to illustrate, I can not imagine a metric by which that would be true.
e.g. it's easy to add your own control structures to the language
>e.g. it's easy to add your own control structures to the language
Huh? You obviously don't know Lisp. Between PLT Scheme and Common Lisp you have several metric tons of libraries. And Common Lisp is certainly used for serious production work.
And finally, Lisp like freaking invented adding your own control structures to the language.
But to say that things have moved past Lisp, that's laughable really. I mean, I don't even have garbage collection on my iPhone (and I really dig Objective-C).
For better or worse, if you want to replace C, you have to dig deep.
The real killer for TCL initially was having to build extensions into the binary. If a lib needed BLT you had to rebuild TCL with BLT, then another library need a conflicting add-in you ended up with multiple TCL installs and a dll-hell of trying to get the right libs to play nicely. Don't know if thats fixed.
It is Tcl, by the way, not TCL.