Reading the code of others is no substitute for writing code yourself.
It's very easy when looking at the solution to a problem to say "I would've thought of that" and maybe you're right. But maybe not.
Having real experience of the consequences of your decisions, keeping skin in the game, is also important. Maybe not for every single decision, but a representative sample.
you mean value types rather than primitives right? (Strings are objects)
It would be saner if everything was non null by default. There'd be no need for a ! then and no ambiguity for beginners around whether something is nullable or not. No downside for non-beginners either unless they're in the habit of using more nullable parameters/vars than non-nullable, which doesn't seem like a particularly good idea...
I was there for a few days at the beginning of July and they had those warnings then too (plus a body heat scanner, which was a little bit disconcerting because I was very warm at that point!!)
with 1) it seems like what you're saying is that given a closed system, you cannot accurately observe and record the whole state of that system within the system itself.
This feels right on the surface, but is it actually true?
A quine contains a complete record of itself. That's an extreme case to be sure, but it does seem to provide at least one counterexample . . . (of a system that contains itself, not necessarily a system that actually observes and records itself)
A recording of a system does not need to contain everything in order for that recording to by played back, as long as the replay system is deterministic -- you just need to record the random inputs. E.g. see the way they do it in video games [http://www.gamedev.net/topic/439336-replay-system/]
I'm not saying that it is possible, just it shouldn't be dismissed out of hand just because it feels like it should be impossible.
why would you need to re-read every line if you are looking at methods that have a single responsibility and that responsibility is clearly communicated through the name? (and parameter types/name, return types/names, in languages where some of those things are available)
The only reason I've ever had for knowing who wrote code is if the code+comments+tests do not adequately explain what's going on and I need to know.
On most of those occasions the person who wrote the original code had already left the organisation.
sdees requires a file server, specifically it prompts the user for one and saves it to ~/.config/sdees/config.json, therefore it is not serverless.