Heh, not being able to bind to o by destructuring doesn't look like an intended behavior... Anyway, using `o' in order to mark optional arguments looked suspicious from the beginning. And now we know why.
At this moment Unicode is an implementation detail rather than a language feature.
I must say it: not supporting Unicode (or: explicitly planning not to support it) is a BAD thing. You will hardly notice it if you come from the US. It may get a bit tricky if you come from the UK, as you may want want to use the pound or euro symbol. If you come from a diacritics-rich language, then you may start feeling stupid. Prepare to serve yourself and your users communicates like:
"Sarra, thas cammanacata has baan adaptad ta tha fana pragrammang langaaga wa ara asang." ("Sorry, this communicate has been adapted to the fine programming language we are using."---it is not that hard guess after all, ain't it?)
No, PG, please don't be that guy.
Python's Unicode support sucked badly at the beginning, but they kept improving it. Right now it is kinda acceptable (though I regularly spend some time debugging Unicode errors---you'd imagine by now I would get used to it), in Py3k is hopefully gonna be made right. Ruby Unicode support still sucks, and that is basically why I don't use it (even though I like its semantics a lot, as it is more lispy than Python). Not being able to divide a word from your own language into three character substrings (Unicode characters use more than one byte) is plainly ridiculous... Even on the prototype level.
Of course, no one says it has to be done right now. But I'd like to know it is in the plans.
Ruby's unicode support is acceptable in 1.8, and good in 1.9. I'm not asking for the world, I just want string to be able to contain text in any encoding, and to be able to split a string into chars, given a encoding.
I would like to use numbers in various encoding like reversed (bigendian on little endian machines and vice versa). I also want the language to natively support all these number encondings and to be able to add two numbers, given their encodings.
Driving a Ferrari is rarely a collaborative endeavor :-)
Keeping `_' safe in fact increases the programmer's freedom. If I knew that by doing something I was going to fk up w/ other people's code and how they expect their code to behave, I would rather not* do it. OTOH, if there are namespaces, etc. then I know that I can enforce whatever coding conventions I want, in the privacy of my personal sandbox.
Programming is not only about communicating w/ computers; it is also about communicating w/ other people, i.e. your coworkers and so on. Nothing that makes it harder can be a Good Thing. (Of course, unless you are the Lone Wolf coding in your cave---but then you are probably using your Own Better Language and don't care about Arc anyway ;-).)
Freedom is an interesting philosophical topic. How can a restriction make you more free? Well if you drink the FSF GPL Richard Stallman branded Kool Aid, you might "get it", but I sure don't.
I don't want the freedom from doing things, I want to the freedom to do things.
That said, strictness and protection and safety of some language features is something some people would like to rely on.
I think operator overloading in C++ was a huge freaking mistake for instance. You can look at two piece of code without going through some contextual learning to find out what the hell "+" was just redefined to do, and I think that's crappy.
Other languages get by some how without operator overloading. And often without a loss of expressiveness.
That said, judicious use, and education about how subsystems in software work is a necessity even in the presence and absence of things people might consider to be abominations, like operator overloading :-)
