Hacker News new | ask | show | jobs
by narrator 1949 days ago
TCL had some bad features that kind of killed it. For example, "upvar" was a really bad idea. Bad features tend to kill languages over time. Everyone used to use Perl in the late 90s. It had too many bad features though, and nobody wanted to maintain those programs.
4 comments

I've always been surprised that nobody has tried to take a "The Good Parts" subset of a big language (C++, Perl, etc.), codified/formalized it as its own language, and then attempted to popularize the new reduced language as a distinct effort/project/community to that of the original language.

One could release this "language" as a distribution of the inner language's compiler together with a wrapper (like C++ originally was to C), that, rather than adding features and compiling down, just analyzes the source file and errors out on use of forbidden syntax; or, if no forbidden syntax is used, just passes your code straight through to the inner compiler. A bit like a pre-commit-hook style checker, but a pre-compile-hook style checker.

For c++ there is orthodox c++ which is a subset of the larger language. Although as far as I know there is no linter/compiler. https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
I just liked what is in Little, it's enough like C that it is trivial for me to jump into it (tcl always took a half a day, I really dislike the tcl syntax), it's got enough of the shortcuts from perl that it is pretty terse, and credit where credit is due, syntax aside, tcl has a bunch of useful stuff, check out Little's switch(), that's tcl's switch.
I have not tried to codify it yet, I think mainly because I'm still figuring it out, but I've been doing this with Perl and PHP, writing in a lowest-common-denominator style which is almost identical between the two...
Someone should do this with Nim.
I always thought upvar was kind of a cool feature, and allowed laser-specific targeting in places where you'd use a global otherwise in C. Is there any specific way that it's caused problems?
I like it too because it's DIY pass by reference.
We obviously liked it because upvar is how Little passes by reference. I don't know why someone thought upvar was bad, it is useful.
Hmm, I would disagree with this (quite strongly). Not that tcl doesn't have misfeatures (of course it does), but that `upvar` or `uplevel` are one of them.

Those commands effectively make any tcl function be able to operate as an f-expr (in old lisp parlance). Effectively (this is a simplification), an fexpr is a runtime macro, as opposed to the more traditional lispy compiletime macro.

Its what makes tcl feel more like a lisp-for-strings. Much of the truly horrible tcl code out there in the wild is from folks who try to use tcl as just another c-style scripting language.

Treat it more as a lisp, and it some of its inherent elegance shines through.

My $0.02 anyway ...

Fexprs are misfeature, which is why we have to digging into sixty-year-old Lisp literature to learn about them.

Lisp people had bad ideas along the way. They recognized that this is the case and got rid of those ideas, in some cases documenting some of those choices.

I sort of agree with this. I'm not a lisp fan, I don't think lisp is bad, it's just not how my brain works so I struggle. But I understand lisp enough to agree with you and I think that is what John was trying to do.
What's upvar?
http://www.tcl.tk/man/tcl8.5/TclCmd/upvar.htm

That man page isn't the most clear. upvar gives you a way to modify a variable in the calling context (and I think it can go up more than one stack frame).

It's a way to pass by reference rather than the default pass by value (how tcl passes is more complicated than that for performance but the default semantics are pass by value).

upvar means that you have access to the variables of the calling function. You can ask, what is the value of local variable foo in the scope that is calling here?

It's a facepalm-stupid thing to put into a programming language. Programs that use it will not be efficently compilable; the compiled code will have to provide upvar access similarly in order to make them work.

When compiling a function, you don't know which callee might ask for an upvar, so you can't optimize away variables or keep them in registers across calls.

Not much, what's up with you?