5 ms·

Keep in mind that this example was (presumably intentionally) cherry-picked to show off the worst of Tcl's syntax. It's not really representative of how express

by nilkn 11y ago

Keep in mind that this example was (presumably intentionally) cherry-picked to show off the worst of Tcl's syntax. It's not really representative of how expressive the language can be in the right context, and it doesn't show the benefits that you can get from having a very simple, regularized syntax with little added sugar. On the topic of expr, though, it can be avoided if desired in favor of Lisp-style prefix operators: http://www.tcl.tk/man/tcl8.5/TclCmd/mathop.htm http://www.tcl.tk/man/tcl8.5/TclCmd/mathop.htm

tyingq 11y ago
There are things to like about tcl, but lists aren't really one of them. Not cherry picked, an "official" page describing lindex: http://wiki.tcl.tk/1481 http://wiki.tcl.tk/1481 Objectively compare that with most any other language's docs for lists/arrays/whatever. "Everything is a string" does have some downfalls.
- nilkn 11y ago
  I think you might have misinterpreted my point. When I said it was cherry-picked, I did not mean that it wasn't a legitimate example or that lindex is not a real, standard Tcl function. It's a completely fair example and is something that is liable to happen in practice. All I meant is that it was clear from the context that an example was chosen showing a weakness of the language (relative to standard C-like syntax) and that it's not quite fair to judge the whole language based on that one example. Tcl's incredibly simple syntax and lack of syntactic sugar are what lead to situations like that example. But those same things are also responsible for making the language Lisp-like and fairly homoiconic. You can do incredible things in Tcl thanks to its simple syntax which is amenable to macros and code generation.
luckydude 11y ago
That example was contrived but it wasn't designed to show off the worst of Tcl's syntax. There is worse out there. Little wasn't a slam on Tcl, if you think that then you miss the point. Little is trying to bring people to Tcl. The Tcl ecosystem has a boatload of good stuff, people should check it out. But many people are put off by Tcl's syntax, it's fine for glue, which is what Ousterhout intended, but it sucks for 300,000 lines of code. If you want to write big programs then perhaps some type checking could help you. And perhaps some familiar syntax might help. Little is for people that have to maintain a pile of code.
- ArkyBeagle 11y ago
  Tcl is fine for big projects. Use OO as does Tk. Use namespaces. And type checking isn't exactly difficult in the language. Some combo of catch {} and scan usually does it for me.
  - googie 11y ago
    SQLiteStudio developer here. I think it's a project which could be considered big. Version 2.x.x was written entirely in Tcl and the main problem was memory sharing with threads. There's none. Threads can communicate only by messages. Worse than that - each thread has to load very same packages and same procedure definitions (into separate memory segment) for each thread that wants to use them. Threads in Tcl are like processes that can communicate through pipe. It's a major pitfall of this language in context of more complex projects. Besides that it is a very nice language to use and read. Gives quick results with little effort. I still use it almost every day, just not for complex projects. I'm aware of tsv package (shared variable), but this is just sharing scalar variables or arrays. You cannot share objects, procedures, namespaces, resources, etc - and that is the major reason for sharing memory across threads.
    - eggy 11y ago
      Message passing without memory sharing. Isn't that what Erlang processes are? Is it because having to load the packages into the thread makes it too large? Just curious.
      - googie 11y ago
        I'm not familiar with Erlang. Nevertheless there are two main issues with this threading model: 1) Application memory consumption grows more than it should, because same extensions have to be loaded several times in the same application, but in separate threads; 2) Resources such as images (or any other kinds), or OO objects, cannot be transferred between threads efficiently, the only way is to serialize them to scalar representation, which then can be passed through either tsv (mentioned above) variables, or through a message to another thread - then deserialize them there. Apart from precious time which it costs, you also make a full copy of resource/object, growing memory consumption even more.

by nilkn 11y ago

tyingq 11y ago

There are things to like about tcl, but lists aren't really one of them. Not cherry picked, an "official" page describing lindex: http://wiki.tcl.tk/1481 http://wiki.tcl.tk/1481 Objectively compare that with most any other language's docs for lists/arrays/whatever. "Everything is a string" does have some downfalls.

nilkn 11y ago
I think you might have misinterpreted my point. When I said it was cherry-picked, I did not mean that it wasn't a legitimate example or that lindex is not a real, standard Tcl function. It's a completely fair example and is something that is liable to happen in practice. All I meant is that it was clear from the context that an example was chosen showing a weakness of the language (relative to standard C-like syntax) and that it's not quite fair to judge the whole language based on that one example. Tcl's incredibly simple syntax and lack of syntactic sugar are what lead to situations like that example. But those same things are also responsible for making the language Lisp-like and fairly homoiconic. You can do incredible things in Tcl thanks to its simple syntax which is amenable to macros and code generation.

luckydude 11y ago

That example was contrived but it wasn't designed to show off the worst of Tcl's syntax. There is worse out there. Little wasn't a slam on Tcl, if you think that then you miss the point. Little is trying to bring people to Tcl. The Tcl ecosystem has a boatload of good stuff, people should check it out. But many people are put off by Tcl's syntax, it's fine for glue, which is what Ousterhout intended, but it sucks for 300,000 lines of code. If you want to write big programs then perhaps some type checking could help you. And perhaps some familiar syntax might help. Little is for people that have to maintain a pile of code.

ArkyBeagle 11y ago
Tcl is fine for big projects. Use OO as does Tk. Use namespaces. And type checking isn't exactly difficult in the language. Some combo of catch {} and scan usually does it for me.
- googie 11y ago
  SQLiteStudio developer here. I think it's a project which could be considered big. Version 2.x.x was written entirely in Tcl and the main problem was memory sharing with threads. There's none. Threads can communicate only by messages. Worse than that - each thread has to load very same packages and same procedure definitions (into separate memory segment) for each thread that wants to use them. Threads in Tcl are like processes that can communicate through pipe. It's a major pitfall of this language in context of more complex projects. Besides that it is a very nice language to use and read. Gives quick results with little effort. I still use it almost every day, just not for complex projects. I'm aware of tsv package (shared variable), but this is just sharing scalar variables or arrays. You cannot share objects, procedures, namespaces, resources, etc - and that is the major reason for sharing memory across threads.
  - eggy 11y ago
    Message passing without memory sharing. Isn't that what Erlang processes are? Is it because having to load the packages into the thread makes it too large? Just curious.
    - googie 11y ago
      I'm not familiar with Erlang. Nevertheless there are two main issues with this threading model: 1) Application memory consumption grows more than it should, because same extensions have to be loaded several times in the same application, but in separate threads; 2) Resources such as images (or any other kinds), or OO objects, cannot be transferred between threads efficiently, the only way is to serialize them to scalar representation, which then can be passed through either tsv (mentioned above) variables, or through a message to another thread - then deserialize them there. Apart from precious time which it costs, you also make a full copy of resource/object, growing memory consumption even more.