Bounty program for improvements to Tcl and certain Tcl packages(github.com)
github.com
Bounty program for improvements to Tcl and certain Tcl packages
https://github.com/flightaware/Tcl-bounties
21 comments
Yes, that's at least technically possible. On the other hand, there's enough work that I believe it very unlikely that anything would be rejected like that provided it works well with the rest of the language, and is reasonably documented and tested. I also know the people involved; we're more of the "You're doing the work? Let us hold your coat for you." persuasion.
The bounties are not large enough to pay someone to solve them. The ones that are fairly low value are likely to get picked off rapidly by the existing community by just focusing their attention slightly differently. The high value ones are in the class where you'd need a team of expert programmers to take them on, and would expect to be supporting them for an extended period of time; that can burn through $100k in pretty short order. (Yes, I'm working on that particular bounty, but I was doing so before the bounty was announced. I know how exactly difficult it is.)
IOW, these are all rewards for success, not pay for doing.
The bounties are not large enough to pay someone to solve them. The ones that are fairly low value are likely to get picked off rapidly by the existing community by just focusing their attention slightly differently. The high value ones are in the class where you'd need a team of expert programmers to take them on, and would expect to be supporting them for an extended period of time; that can burn through $100k in pretty short order. (Yes, I'm working on that particular bounty, but I was doing so before the bounty was announced. I know how exactly difficult it is.)
IOW, these are all rewards for success, not pay for doing.
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?
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.
I'll venture a guess that if any other tool could do the job better, they would use it.
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" ;)
- 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" ;)
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).
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).
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.
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.
The usual problem is to do with managing list construction, and the usual answer is the [list] command, which Does The Right Thing for sane code. We also made sure that such lists go through the script evaluation engine cleanly (except for the first word, which will be forced to be interpreted as a command name, obviously). I think we (well, mostly me in this case) sorted this out properly in 8.5.
Still, we don't recommend tying objects with important lifetimes to values; Tcl really assumes that it can clone and release them as it sees fit (and effectively that it can interconvert through the serialization without problems). It's a pretty different design decision to what most programming languages go with, and has a lot of consequences, some really good and some quite irksome at times.
There's quite a few extension packages that do the sort of thing you're talking about without trouble. In particular, the packages for handling talking to DOM trees, DCOM interfaces, and JVMs all take this approach without becoming disaster zones. Another approach is to put the magical value in a variable and refer to that variable by name (which is a bit more easily done when it is an array element). I'm sure something could be worked out.
Still, we don't recommend tying objects with important lifetimes to values; Tcl really assumes that it can clone and release them as it sees fit (and effectively that it can interconvert through the serialization without problems). It's a pretty different design decision to what most programming languages go with, and has a lot of consequences, some really good and some quite irksome at times.
There's quite a few extension packages that do the sort of thing you're talking about without trouble. In particular, the packages for handling talking to DOM trees, DCOM interfaces, and JVMs all take this approach without becoming disaster zones. Another approach is to put the magical value in a variable and refer to that variable by name (which is a bit more easily done when it is an array element). I'm sure something could be worked out.
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...
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...
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.
Tcl was one the the popular scripting languages when Flightaware started using it.
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.
But remember that Lua was specifically designed for embedded scripting and has minimal footprint. A javascript engine is a huge beast in comparison.
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
> 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
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.
Off topic: It's refreshing to see this back and forth on HN without it being a sht slinging competition.
Tcl has a bigger footprint than Lua, but provides more services.
[deleted]
Commercial EDA tools almost all use Tcl. (Cadence's Skill is a notable exception.)
[deleted]
I can vouch for Karl Lehenbauer - he's one of the head dudes at flightaware.com and they definitely use a bunch of Tcl.
Just hire a programmer to do the work and pay them in accord with a contract.