But a dict is a list of paired elements? I do like the fact that you can convert freely between string/list/dict. It removes a lot of boilerplate type conversion. Want to serialize a dict? In most languages that's boring code. In Tcl it's so easy you do it all the time.

> But a dict is a list of paired elements?

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?

Tcl dicts are ordered, so you have a defined order for this. http://www.tcl.tk/man/tcl/TclCmd/dict.htm#M27

Depends on the language, but I prefer the Python approach here. Python is a dynamically (but strongly) typed language. If you want a list from a dict, get a new list via casting ie. list(the_dict), or get a list from either side via the_dict.keys() or the_dict.values(). Weakly typed languages that will do implicit type conversion for you such as TCL and Perl seems prone to mistakes and confusion from this stuff as code complexity of the project grows. I don't think Python gets it right here either though really, as in the end explicit types save so much headache and stupid bugs by finding problems for you at lint or compile time.

With all the discussion about the syntax, some of Tcl greatest features are overlooked. The article could do with an update. I would like to see the current state of Tcl compared to node.js Possibly the tcl core beats node.js on many points.

200 mbps is plenty. Problem is that real speeds are mostly lower. Note that most office networks still operate at 100Mbps and are doing just fine. Arguably so though.

No, 50 Mbps will be sufficient for this with the right codecs and gear. Now if you want it all as raw data - that makes a difference.

50Mbps is barely sufficient for high quality current HD.

1 + 1 = 2 Is fairly unambiguous until you introduce operator overloading (and why i despise overloading).

> 1 + 1 = 2 Is fairly unambiguous until you introduce operator overloading (and why i despise overloading).

It is only unambiguous if you specify the numbering system you are using ;)

</pedantic>

Is there actually a notation and + operator for which 1 + 1 = 2 is ambiguous? Only being semi-rhetorical, I'd be interested to know if there is one. (Modular arithmetic is not considered ambiguous, at least not in the math neck of the woods.)

Not really answering your question, but more to the point of the discussion in my opinion, a() + b() could be ambiguous if a() and b() are functions with side effects and the evaluation order of the +-operator is not specified.

1 + 1 = 10b is what he's saying.

Yes, that's what I meant - even "1 + 1 = 2" can be ambiguous if no context is provided.

> 1 + 1 = 2 Is fairly unambiguous until you introduce operator overloading (and why i despise overloading).

What is it specifying—or, perhaps a better question, what would an implementation look like? It might be more precise to say "I have yet to encounter an implemented spec that was not in some way ambiguous."

1 + 1 != 2 if the 1s are magnitudes of vectors - if the directions are opposite, then they can be 0. In fact, 0 <= 1 + 1 <= 2 in that system.

That's not how addition works. You're either adding the vectors or you're adding the magnitudes. You don't get to sleight of hand by writing one and adding the other.

Overloading is a feature of natural language though, and therefore completely unavoidable in writing a spec.

I have a gut feeling that there is some merit to the idea that exception handling isn't all that great. Just so much code out there does not really handle the exceptions, it just exit(1)s. C will teach you to check return values (usually easy enough: if (result==NULL) {fatalerror(1,"result not OK");}) . If you don't, the program will continue to run (derailed). Most 'high-level' programmers will consider an abortion of execution just fine, while C programmers will put more thought into handling an error situation. Few C programs will automatically abort with a core dump on the first occasion of 'record not found'.

Agreed. Game programming will teach you a lot of programming skills, and staying with game programming can elevate you to great heights as a programmer, and it's great fun. The only negative is that games are relatively closed systems, whereas most of the rest of the software world includes a lot of interaction with other systems (databases, security, operating systems, payment etc etc) which you may never get to practice while programming games (unless you do multiplayer online games i guess). Oh, and do not expect to earn money programming games.