6 ms·

My immediate reactions to this was (A) that's a lot of money and (B) why are people still using TCL for embedded-scripting now that we have Lua?

by pawadu 10y ago

pmarin 10y ago
why are people still using Lua for embedded-scripting now that we have Javascript? we can play this game all day. Tcl was one the the popular scripting languages when Flightaware started using it.
- pawadu 10y ago
  Point taken :) But remember that Lua was specifically designed for embedded scripting and has minimal footprint. A javascript engine is a huge beast in comparison.
  - codezero 10y ago
    Off topic: It's refreshing to see this back and forth on HN without it being a sht slinging competition.
  - dkfellows 10y ago
    If someone wants to use, say, LuaJIT to work on the $100k bounty for a 10x speedup of the Tcl language, they should go right ahead; prove that you can do it and claim the cash. (I guess I'll be rather involved in setting the test of the performance up; I've relevant experience.) However, that scale of acceleration is not trivial, not at all.
  - mayoff 10y ago
    But remember that Tcl was specifically designed for embedded scripting: > In the fall of 1987, while on sabbatical at DEC's Western Research Laboratory, I got the idea of building an embeddable command language. The idea was to spend extra effort to create a good interpreted language, and furthermore to build it as a library package that could be reused in many different applications. http://web.stanford.edu/~ouster/cgi-bin/tclHistory.php http://web.stanford.edu/~ouster/cgi-bin/tclHistory.php
  - dkfellows 10y ago
    Tcl has a bigger footprint than Lua, but provides more services.
- deleted 10y ago
  [deleted]
dded 10y ago
Commercial EDA tools almost all use Tcl. (Cadence's Skill is a notable exception.)
deleted 10y ago
[deleted]
ArkyBeagle 10y ago
Tcl's quite mature. Scotty seemed like a superpower the first time I saw it. Then it slowly vanished. If you pay yourself $50 an hour, fixing all those two things will be well more than 20 hours. It's not that much money. Lua seems pretty good. So ... many ... languages...
blacksqr 10y ago
Flightaware uses Tcl for far more than embedded scripting. It's one of the most data-intensive and heavily trafficked sites on the web, and makes virtuoso use of Tcl for a variety of tasks from serving active web pages to database querying to processing high volume external data streams. It's probably the best current demo of Tcl's unique power. I'll venture a guess that if any other tool could do the job better, they would use it.
to3m 10y ago
I used Tcl a few years ago. I quickly came to the conclusion that its assumption that everything can be converted to a string and (losslessly) back is insane, and I haven't used it since. However I found it much more pleasant to use than Lua - which I've used a fair bit - for a few reasons: - shell-like command syntax a bit friendlier for interactive use (the default lack of brackets alone goes a long way!) - straightforward, easy-to-read internal code (Lua's code is fine but a bit inscrutable - this is obviously subjective but I know I'm not the only one to feel this way) - GC by reference counting (more predictable object destruction) - very straightforward extension API You may disagree that they are excellent reasons, but I claim they at least reach the level of "reasonable" ;)
- dkfellows 10y ago
  The string interconvertibility (more formally, strings are the supertype of all other value types) only really applies to values that you can regard as being immutable. Mutable state instead goes into a named entity (even if it is an automatically-generated name); after all, if you can mutate the state, you need to care about the actual identity of the thing that holds that mutable entity. It also means that there's very little of the old spooky action-at-a-distance problems with Tcl; it's always clear where you are dealing with something that can confuse you, as you've explicitly got a name/handle. Tcl did solve the problem of handling double-precision floating point number precision loss well. A numerical analyst fixed the code so that the automatic conversion generates the shortest string representation that will reparse to the same bit representation. It also avoids quite a few bugs in the C library in the process (on the grounds that different platforms have different bugs to each other).
  - to3m 10y ago
    As far as I can remember, this being 3.5 years (and several projects) ago, I had a lot of problems putting things in lists, because some list functions seemed to be cavalier about turning things into strings, and I'd end up with my carefully-constructed list of Tcl objects turning into a list of strings that were all "" :( The obvious thing to do is just turn an object into a parseable string. So if you have a Texture object, which is a struct Texture at address 0x12345678, you might let this become a string, "(Texture * )0x12345678" (or similar). And then if you're expecting a Texture object you can check for not just a TclObj struct of the appropriate type, but also a string of the right format. I'm sure I found this unworkable, though, my recollection being that Tcl would call the free callback on the original object after turning it into a string, and so you'd quite possibly end up with a string representation of a dead object... but now that I say that out loud, it sounds super insane. So maybe I'm recalling rightly. And then Tcl is still insane, and I stand by everything I said. It happens. Or maybe I'm wrong... and that's good! Because I otherwise really did prefer it to Lua. I know exactly why Lua's C API is the way it is, but that doesn't make it any less horrid. And Tcl's shell-style syntax is way better for interactive use.

My immediate reactions to this was (A) that's a lot of money and (B) why are people still using TCL for embedded-scripting now that we have Lua?

by pawadu 10y ago

My immediate reactions to this was (A) that's a lot of money and (B) why are people still using TCL for embedded-scripting now that we have Lua?

pmarin 10y ago

why are people still using Lua for embedded-scripting now that we have Javascript? we can play this game all day. Tcl was one the the popular scripting languages when Flightaware started using it.

pawadu 10y ago
Point taken :) But remember that Lua was specifically designed for embedded scripting and has minimal footprint. A javascript engine is a huge beast in comparison.
- codezero 10y ago
  Off topic: It's refreshing to see this back and forth on HN without it being a sht slinging competition.
- dkfellows 10y ago
  If someone wants to use, say, LuaJIT to work on the $100k bounty for a 10x speedup of the Tcl language, they should go right ahead; prove that you can do it and claim the cash. (I guess I'll be rather involved in setting the test of the performance up; I've relevant experience.) However, that scale of acceleration is not trivial, not at all.
- mayoff 10y ago
  But remember that Tcl was specifically designed for embedded scripting: > In the fall of 1987, while on sabbatical at DEC's Western Research Laboratory, I got the idea of building an embeddable command language. The idea was to spend extra effort to create a good interpreted language, and furthermore to build it as a library package that could be reused in many different applications. http://web.stanford.edu/~ouster/cgi-bin/tclHistory.php http://web.stanford.edu/~ouster/cgi-bin/tclHistory.php
- dkfellows 10y ago
  Tcl has a bigger footprint than Lua, but provides more services.
deleted 10y ago
[deleted]

dded 10y ago

Commercial EDA tools almost all use Tcl. (Cadence's Skill is a notable exception.)

deleted 10y ago

[deleted]

ArkyBeagle 10y ago

Tcl's quite mature. Scotty seemed like a superpower the first time I saw it. Then it slowly vanished. If you pay yourself $50 an hour, fixing all those two things will be well more than 20 hours. It's not that much money. Lua seems pretty good. So ... many ... languages...

blacksqr 10y ago

Flightaware uses Tcl for far more than embedded scripting. It's one of the most data-intensive and heavily trafficked sites on the web, and makes virtuoso use of Tcl for a variety of tasks from serving active web pages to database querying to processing high volume external data streams. It's probably the best current demo of Tcl's unique power. I'll venture a guess that if any other tool could do the job better, they would use it.

to3m 10y ago

I used Tcl a few years ago. I quickly came to the conclusion that its assumption that everything can be converted to a string and (losslessly) back is insane, and I haven't used it since. However I found it much more pleasant to use than Lua - which I've used a fair bit - for a few reasons: - shell-like command syntax a bit friendlier for interactive use (the default lack of brackets alone goes a long way!) - straightforward, easy-to-read internal code (Lua's code is fine but a bit inscrutable - this is obviously subjective but I know I'm not the only one to feel this way) - GC by reference counting (more predictable object destruction) - very straightforward extension API You may disagree that they are excellent reasons, but I claim they at least reach the level of "reasonable" ;)

dkfellows 10y ago
The string interconvertibility (more formally, strings are the supertype of all other value types) only really applies to values that you can regard as being immutable. Mutable state instead goes into a named entity (even if it is an automatically-generated name); after all, if you can mutate the state, you need to care about the actual identity of the thing that holds that mutable entity. It also means that there's very little of the old spooky action-at-a-distance problems with Tcl; it's always clear where you are dealing with something that can confuse you, as you've explicitly got a name/handle. Tcl did solve the problem of handling double-precision floating point number precision loss well. A numerical analyst fixed the code so that the automatic conversion generates the shortest string representation that will reparse to the same bit representation. It also avoids quite a few bugs in the C library in the process (on the grounds that different platforms have different bugs to each other).
- to3m 10y ago
  As far as I can remember, this being 3.5 years (and several projects) ago, I had a lot of problems putting things in lists, because some list functions seemed to be cavalier about turning things into strings, and I'd end up with my carefully-constructed list of Tcl objects turning into a list of strings that were all "" :( The obvious thing to do is just turn an object into a parseable string. So if you have a Texture object, which is a struct Texture at address 0x12345678, you might let this become a string, "(Texture * )0x12345678" (or similar). And then if you're expecting a Texture object you can check for not just a TclObj struct of the appropriate type, but also a string of the right format. I'm sure I found this unworkable, though, my recollection being that Tcl would call the free callback on the original object after turning it into a string, and so you'd quite possibly end up with a string representation of a dead object... but now that I say that out loud, it sounds super insane. So maybe I'm recalling rightly. And then Tcl is still insane, and I stand by everything I said. It happens. Or maybe I'm wrong... and that's good! Because I otherwise really did prefer it to Lua. I know exactly why Lua's C API is the way it is, but that doesn't make it any less horrid. And Tcl's shell-style syntax is way better for interactive use.