I was generating functions procedurally, and I was having a scoping problem with one of the inner variables. Naturally, the suggested solution was to do a string replace on your newly created function. Seems obvious in retrospect. :)
It's kind of a moot point though. Javascript is unstoppable in the extension language space now.
I think this would be a chance to rehabilitate the much-maligned GOTO keyword. But "tailcall" is probably just as good.
Perl has used "goto &foo" for that exact purpose for ages. It just became yet another random feature that experts know about, regular programmers ignore, and critics use to show how terrible the language is.
http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...
1 - With TCO, there would be no more "recursiveFunction recursiveFunction recursiveFunction" x 1000 stack traces. Which apparently is bad. Might force someone to use a debugger, you know.
2 - Non-standard Python implementers won't be competent enough to code it, so it's best he doesn't force them to.
3 - He doesn't believe in recursion. He doesn't like it. I mean, the look of it. It's too nerdy.
4 - He made a bad choice in basing his language in dynamic binding. He recognises it, says it's horrible style, un-pythonic, but won't make it go away because users, users, yadda yadda. All this from someone whose job description is BDFL ;)
Yeah, I'm bitter about some minor quirk no one cares about, but... you know, I might have preferred a "I can't be arsed to do it" answer. Those arguments are pretty laughable.
I would dare to claim that there's some trend to do things more side-effectlessly not only in programming, but also in general, people in IT are finally realizing* that the more isolated, light-weight and modular things are (think of increased interest in functional programming (pure functions), dominance of cloud-based/inspired solutions (spinning up small instances of VMs)) the better. Somehow this particular mindset helps at all levels.
Hah, there's actually a term for what I'm trying to describe: Shared nothing architecture[2]. Allowing side-effects on any level implies "sharing" to me.
[*]: of course you could say "this has always been the case", but somehow some years ago Java and the friends seemed like the only "enterprise level" solution to most businesses and the general fat-stack+vertical-scaling seemed somewhat reasonable.
[1]: http://neopythonic.blogspot.nl/2009/04/tail-recursion-elimin... [2]: http://en.wikipedia.org/wiki/Shared_nothing_architecture
Messy C? Most people who've worked on it seem to think it's rather clean. (Not the bytecode compiler though -- that is indeed a mess. But most of the implementation is solid, readable code.)
is there a paper that describes the underlying implementation (with the new stackless stuff)?
1. http://wiki.tcl.tk/37253#pagetocbefb5a57
2. http://www.tcl.tk/cgi-bin/tct/tip/328
3. http://www.tcl.tk/cgi-bin/tct/tip/327
Update: more details on the NRE implementation are available here [5] at the contributing author's site; anonymous login required.
Some might ask how TclOO compares to iTcl's. For one the performance is in another league.[2](Version 0.3)
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.
Also, shared-nothing "architecture" goes back to the 60s with the first investigations into concurrency. In fact, if I were being pedantic, I would say it predates computing itself: logic is all side-effect free.
And I am not really claiming that software development changed much in 3 years, but I think people's mindsets are changing faster than that, especially of those who are actively involved in thinking about these things.
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.
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.
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.
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?