Arc Forumnew | comments | leaders | submitlogin
2 points by akkartik 601 days ago | link | parent

"It's not about finding some holy grail of PL. It's about finding a language that is powerful and will pretty much let me do whatever I want."

I don't see the distinction. Isn't "let me do whatever I want" the holy grail of PL? :)

My point is that it's equally important to keep learning new things _to_ want. No single language will consistently do that.

"The tclers wiki contains a massive amount of information on the language, programming in general, and many other topics, the likes of which I've never seen concentrated as well in another programming community."

That is high praise! Feel free to submit your favorite links as new threads.

"..everything is a string, but.. so what? ..if you pass "5" to a command that needs to use it as an int, a conversion will take place.."

Automatic conversion is utterly evil: http://stackoverflow.com/questions/9032856/what-is-the-expla...

Here's another way to think about this. Types are useful but they're also speed-bumps. Dynamic languages push types to runtime so that you can run partially correct programs and gradually make them right. The drawback is that you can never be sure that your program doesn't have a type error; there can always be some code path that you haven't tested that causes everything to come crashing down. Passing just strings around makes this drawback exponentially worse: now you can't be sure your program is right even if you cover all possible code paths and your tests have perfect coverage, because type safety is a function of the lines executed and the data they rely on.

On a hunch I also took a look at Tcl's scope design (http://wiki.tcl.tk/12245) because that's something non-lisps (ahem, Python) mess up in subtle ways. And sure enough, Tcl is brain-damaged in this area. (I have sympathy for this mistake, because I too have spent time trying to "design hybrid approaches that strikes a great balance in maximizing the advantages of both lexical and dynamic scoping while minimizing the disadvantages of each": http://arclanguage.org/item?id=15137. Everyone should play with these things, but there's no known improvement on Lisp's dynamic scope and Scheme's lexical scope -- exactly as they're implemented there. Everyone should play with scope strategies so they can understand why.)



2 points by mpr 601 days ago | link

It looks to me like the confusion in that SO post is because Javascript does something sneaky in order to support several syntaxes that mean the same thing. Tcl has no syntax. Braces aren't used to delimit blocks and denote dictionaries. They're just used as an escaping mechanism, period. Once you know the language, it is always clear how the interpreter will treat your data.

-----

1 point by akkartik 601 days ago | link

The brace ambiguity only covers some of the issues they discuss. And there are many more elsewhere on the internet..

-----

2 points by mpr 601 days ago | link

What do you find brain damaged about tcl scoping?

About the holy grail quote... I should say it's not about __finding__ such a language, more like it's about __searching__ for such a language. Which involves constantly looking at different ones.

-----

2 points by akkartik 601 days ago | link

upvars is a terrible idea. You don't want capturing variables from the lexical environment to be something you have to explicitly ask for everytime. If you don't tend to use lexical scope all the time you end up with all sorts of action-at-a-distance bugs.

Newlisp is another language that uses dynamic scope by default. All it does is save a little bit of implementation effort. In every other way it's bad for users.

Interestingly, Mu plays this game as well. In Mu you have to explicitly specify what level variable you mean. But Mu explicitly isn't a high-level language. It's a language for building Lisp compilers in. And all Lisp compilers implement lexical scope under the hood using these tricks.

So what I'm saying is that Tcl is trying to avoid some work related to automatically managing lexical scope, and trying to pass this off as good for programmers.

But these comments of mine aren't as concrete as I usually strive for. I doubt you'll be persuaded by them. Just keep them in mind as you continue your search.

"..it's not about __finding__ such a language, more like it's about __searching__ for such a language. Which involves constantly looking at different ones."

Yeah, we're completely in agreement there.

-----