7 ms·

Tcl Rule 1: Everything is a string. Tcl Rule 2: See rule 1. Tcl Rule 3: Not joking.

jeffh 14y ago
While the EIAS philosophy is true in Tcl, at the real guts level, the actuality is "Everything must be representable as a string". EMBRAAS it! There is an object system underneath which handles native or user defined types.
- sreque 14y ago
  It's worse than that, unfortunately. Everything is implicitly convertible to a string, and every string is implicitly convertible to any other type. So, if you pass a dictionary into your function that expects a list, it will happily convert between types for you. I do not like this sort of behavior in my dynamic type system.
  - jjr 14y ago
    But a dict is a list of paired elements? I do like the fact that you can convert freely between string/list/dict. It removes a lot of boilerplate type conversion. Want to serialize a dict? In most languages that's boring code. In Tcl it's so easy you do it all the time.
    - keypusher 14y ago
      Depends on the language, but I prefer the Python approach here. Python is a dynamically (but strongly) typed language. If you want a list from a dict, get a new list via casting ie. list(the_dict), or get a list from either side via the_dict.keys() or the_dict.values(). Weakly typed languages that will do implicit type conversion for you such as TCL and Perl seems prone to mistakes and confusion from this stuff as code complexity of the project grows. I don't think Python gets it right here either though really, as in the end explicit types save so much headache and stupid bugs by finding problems for you at lint or compile time.
      - deleted 14y ago
        [deleted]
    - skoob 14y ago
      > But a dict is a list of paired elements? Not really. A dict is an unordered set of keys where each key has a value associated with it. If you try to access a dict as a list, you might expect to get a list of key-value pairs or a list of values or possibly a list of keys. And in what order will the elements in the list be?
      - schlenk 14y ago
        Tcl dicts are ordered, so you have a defined order for this. http://www.tcl.tk/man/tcl/TclCmd/dict.htm#M27 http://www.tcl.tk/man/tcl/TclCmd/dict.htm#M27
  - marshray 14y ago
    (Apologies in advance, I'm just thinking out loud here, not meaning to troll.) So you like strong typing. I do too, but I like it even more at compile time. If you're doing without the compile time error checking, why not go all the way and do without type errors at runtime as well? Sounds like a choice between: 1. type errors at compile time, 2. data-dependent type errors at runtime, or 3. data-dependent corruption and/or non-type errors at runtime.
  - luser001 14y ago
    > I do not like this sort of behavior in my dynamic type system. Why? [Other than for performance reasons] I keep repeating this point in every Tcl thread. Tcl was meant to be used to enable command line shells for programs written in C. Btw, being able to treat a list as a dict has been useful to me. I (developer) write a routine to be used by a non-developer, who may not be a great programmer. The list notation is easy in Tcl. I can just tell them to make a list with keys and values alternating. And for a one-time conversion cost, I get to use it as a dict. Also works the other way around: I can return a dict. And if a Blub user is processing it, he's free to ignore my documentation that it's a dict and process it as a list (again for a one-time cost). YMMV.
    - masklinn 14y ago
      > Why? [Other than for performance reasons] Because it becomes very hard to reason with what you have at hand, and in my experience the "helpful" conversions, rather than actually help, mostly hides errors and bugs in the code and delays there effect, making them much harder to diagnose than a stricter handling.
  - RHSeeger 14y ago
    Tcl's EIAS can be annoying at times, but it also allows for an amazingly easy to use language that provides for some amazingly powerful abilities. For example, the ability to build arbitrary control structures with little effort. Most other languages, dynamic or not, can't come close to it's flexibility and some of the things you can do with it.
iso-8859-1 14y ago
It's not a problem in Bash, why is it a problem here? Right tool for the job...
- cageface 14y ago
  Because most people have enough sense to keep bash scripts to a few hundred lines at most and switch to a saner language for anything more complex. In a language like TCL intended for larger-scale development it's just a bugfest waiting to happen. It's kind of a moot point though. Javascript is unstoppable in the extension language space now.
  - oddthink 14y ago
    Really? I've never seen it used as an actual extension language. I've seen Lua, I've seen Scheme, at work we do everything in Python (but that's more extending than embedding), but I've never seen JavaScript as a "extend this C or C++ application" language. I'm not counting node, because it only exists to run JavaScript. Nor am I counting web browsers, for similar reasons. Can you give some examples? PDF is the only one I can think of. Most of the existing JavaScript engines seem too heavy-weight to be used as extensions. Since I'm not in the web-developer bubble, I just don't see JavaScript all that often.
    - wreckimnaked 14y ago
      Embedding Javascript is fairly easy with Qt[1], so I assume that many applications built on top of it may use it. 1: http://doc.qt.digia.com/qt/qdeclarativejavascript.html http://doc.qt.digia.com/qt/qdeclarativejavascript.html
      - oddthink 14y ago
        Thanks for the link; I'd forgotten about Qt and JavaScript, which is funny, since I was just thinking about learning it.
- rikthevik 14y ago

jeffh 14y ago

While the EIAS philosophy is true in Tcl, at the real guts level, the actuality is "Everything must be representable as a string". EMBRAAS it! There is an object system underneath which handles native or user defined types.

sreque 14y ago
It's worse than that, unfortunately. Everything is implicitly convertible to a string, and every string is implicitly convertible to any other type. So, if you pass a dictionary into your function that expects a list, it will happily convert between types for you. I do not like this sort of behavior in my dynamic type system.
- jjr 14y ago
  But a dict is a list of paired elements? I do like the fact that you can convert freely between string/list/dict. It removes a lot of boilerplate type conversion. Want to serialize a dict? In most languages that's boring code. In Tcl it's so easy you do it all the time.
  - keypusher 14y ago
    Depends on the language, but I prefer the Python approach here. Python is a dynamically (but strongly) typed language. If you want a list from a dict, get a new list via casting ie. list(the_dict), or get a list from either side via the_dict.keys() or the_dict.values(). Weakly typed languages that will do implicit type conversion for you such as TCL and Perl seems prone to mistakes and confusion from this stuff as code complexity of the project grows. I don't think Python gets it right here either though really, as in the end explicit types save so much headache and stupid bugs by finding problems for you at lint or compile time.
    - deleted 14y ago
      [deleted]
  - skoob 14y ago
    > But a dict is a list of paired elements? Not really. A dict is an unordered set of keys where each key has a value associated with it. If you try to access a dict as a list, you might expect to get a list of key-value pairs or a list of values or possibly a list of keys. And in what order will the elements in the list be?
    - schlenk 14y ago
      Tcl dicts are ordered, so you have a defined order for this. http://www.tcl.tk/man/tcl/TclCmd/dict.htm#M27 http://www.tcl.tk/man/tcl/TclCmd/dict.htm#M27
- marshray 14y ago
  (Apologies in advance, I'm just thinking out loud here, not meaning to troll.) So you like strong typing. I do too, but I like it even more at compile time. If you're doing without the compile time error checking, why not go all the way and do without type errors at runtime as well? Sounds like a choice between: 1. type errors at compile time, 2. data-dependent type errors at runtime, or 3. data-dependent corruption and/or non-type errors at runtime.
- luser001 14y ago
  > I do not like this sort of behavior in my dynamic type system. Why? [Other than for performance reasons] I keep repeating this point in every Tcl thread. Tcl was meant to be used to enable command line shells for programs written in C. Btw, being able to treat a list as a dict has been useful to me. I (developer) write a routine to be used by a non-developer, who may not be a great programmer. The list notation is easy in Tcl. I can just tell them to make a list with keys and values alternating. And for a one-time conversion cost, I get to use it as a dict. Also works the other way around: I can return a dict. And if a Blub user is processing it, he's free to ignore my documentation that it's a dict and process it as a list (again for a one-time cost). YMMV.
  - masklinn 14y ago
    > Why? [Other than for performance reasons] Because it becomes very hard to reason with what you have at hand, and in my experience the "helpful" conversions, rather than actually help, mostly hides errors and bugs in the code and delays there effect, making them much harder to diagnose than a stricter handling.
- RHSeeger 14y ago
  Tcl's EIAS can be annoying at times, but it also allows for an amazingly easy to use language that provides for some amazingly powerful abilities. For example, the ability to build arbitrary control structures with little effort. Most other languages, dynamic or not, can't come close to it's flexibility and some of the things you can do with it.

iso-8859-1 14y ago

It's not a problem in Bash, why is it a problem here? Right tool for the job...

cageface 14y ago
Because most people have enough sense to keep bash scripts to a few hundred lines at most and switch to a saner language for anything more complex. In a language like TCL intended for larger-scale development it's just a bugfest waiting to happen. It's kind of a moot point though. Javascript is unstoppable in the extension language space now.
- oddthink 14y ago
  Really? I've never seen it used as an actual extension language. I've seen Lua, I've seen Scheme, at work we do everything in Python (but that's more extending than embedding), but I've never seen JavaScript as a "extend this C or C++ application" language. I'm not counting node, because it only exists to run JavaScript. Nor am I counting web browsers, for similar reasons. Can you give some examples? PDF is the only one I can think of. Most of the existing JavaScript engines seem too heavy-weight to be used as extensions. Since I'm not in the web-developer bubble, I just don't see JavaScript all that often.
  - wreckimnaked 14y ago
    Embedding Javascript is fairly easy with Qt[1], so I assume that many applications built on top of it may use it. 1: http://doc.qt.digia.com/qt/qdeclarativejavascript.html http://doc.qt.digia.com/qt/qdeclarativejavascript.html
    - oddthink 14y ago
      Thanks for the link; I'd forgotten about Qt and JavaScript, which is funny, since I was just thinking about learning it.
rikthevik 14y ago