SICP

Say, someone who has no prior experience with programming, and is at a rather 'young' age (Teen still) wants to get ahead of the game, and start up now, rather than later. Would one go about this by reading SICP? I've seen it linked so many times, I've only got to think it's a start.

>>26
Most of the things people enjoy complaining about when it comes to Python are non-issues.
For most things you can argue that, but you can run into the blub paradox if you are not careful. Take TCO for instance, if you've never used a language with proper TCO you can claim that "it's not a problem in practice", and it may not have been for you. Some of us like to write our programs in other ways, and find python wanting in certain aspects. One other issue, is that object fields are public. Again, maybe not a problem for you, but some of us know how useful proper encapsulation can be.
you have to face the fact that there are no languages that are actually good.
I agree with this statement.

<sub>--
1. I'm not talking about writing loops recursively. Anyone who writes a basic iteration recursively instead of using a higher order construct is a moron. TCO is especially useful in any case where you have a state-maching-like structures, and I've written imperative programs that have ended up kind of like that more times than I'd care to admit.</sub>

>>29
Take TCO for instance
The problem with TCO in FIOC, as I understand it, is that the most vocal proponents of it sound like "Give us implicit TCO we want recursive fibs also u don't understand `reduce` u suck derp haskal derp derp". Of course Guido perceives that as the way to say "I have read SICP today" (which it totally is) and disregards them in bulk.

And he is right, adding implicit TCO to Python is the dumbest idea ever, because suddenly all Python scripts in existence would start producing confusing stacktraces, pdb and the rest of advanced tools that expect orderly stacktraces would have to be patched in subtle ways and so on. Adding a switch to the interpreter or maybe a special import or something wouldn't help either because TCO is not an optimisation. So that is never gonna happen.

But even if someone managed to calmly explain that, dude, what we need is a new .tailcall bytecode like in .NET and a special "tailcall return" keyword, and present a set of real-world applications for the new functionality, even then I'm afraid it would be rejected.

Because if you need TCO for your FSM, writing a trampolining decorator takes five minutes and ten lines of code. Is some minute increase in speed by implementing it in the interpreter worth the effort? And it's not only CPython that would have to be patched, mind you. No, absolutely not.

object fields are public
Start private field names with an underscore. It will mangle the names, so no one would be able to accidentally access them, while deliberate access is not different from accessing them via reflection, which every language in existence that has reflection allows anyway.