Nice. Respect is likely due to Guillermo; this looks derived from his PackageDev project. The push/pop context action looks better than the begin/end region system, though maybe only a bit in convenience.
SO jumped the shark for me when its scope shifted hard from the original goals. I remember the original seedling goals that Spolsky posted; for example, a question is likely inappropriate for SO if its answer couldn't involve code. That got lost awful fast.
Oh, and remember how it was going to be all Wikipedia of programming, where really good answers would be zipped together so that SO became the defacto good-idea repository? And could evolve over time? Such a good idea. Never materialized.
Proper props for putting in the effort. Better than e-e. Usually, though definitely not always, better than isolated boards. But now we're in a good-enemy-of-best world where I still want some site or system addressing the original problems, but SO is so dominant I don't see how it could germinate.
SO has definitely out-stripped what came before. They were generation 1 and had gen-1 problems.
SO is generation 2, better than generation 1. But it's having gen-2 problems. I think a lot of it is because they are so proud of having fixed the gen-1 problems that they refuse to see their gen-2 problems.
His last note should have been his first; it's the Java environment that doesn't suck in any magnitude more than other environments, and has oodles of benefits for getting Serious Business done. You now have your choice of language with which you can enjoy the rock-steady JVM/JDK-library environment.
I still like the StarRotor[1] better. No reciprocating, no problems with seals (which are a big problem/weakness in Wankel-types; rather unadressed in TFA). Biggest problem for StarRotor is that all the manufacturing chains are already super-optimized for existing engine designs and don't much care to experiment.
Keyne's "15 hour workweek" projection cited within is an interesting thought experiment, but it ignores effects of necessary overhead.
For example, let's look at the cognitive overhead I face as a programmer. There's a certain amount of time I spend just spooling content into my brain's working store. I'm not contributing anything new; I'm just keeping the old in my brain and coordinating with the changes my coworkers are making. Let's pretend that forms a nice, round 10 hours of time a week. If I work another 5 hours, that time has a 2:1 overhead:production ratio. Since the productive time is what's being sold, it operates at a steep 300% cost inefficiency. The next 5 hours brings it down to 200%, the next 10 to 150%.
There's a lot that would change in our economies if we could eliminate transaction and overhead costs. But physical and temporal limitation utterly forbid that in practice. One should always take those highly abstracted economic projections and starting points of analysis: see what assumptions lead them to be skewed from reality. That post-analysis is, in my experience, often the truly enlightening part.
