On the issue of a central leader figure, I have seen projects fail precisely because someone was staking a career on it. In that scenario, the customers you truly serve are your boss and your boss's boss. Users? Damn them and their expensive 'requirements'. Support? Someone else's problem. Maintainability? How is that going to get me promoted? All of those things cost time and money, and therefore are risks to be avoided. Better to spend your time burying bad news and selling your failure as 'success' to those who really matter.
All of the self-managing teams I've ever worked on have been much more user-focused and success-oriented (in the true sense) than any project where someone was afraid of losing their head. Self-managing teams just seem to be immune to certain kinds of office politics.
This has been my experience as well. That's why I mentioned malformed meritocracy: when you lead a technical project based on non-technical values, projects have a higher chance of failing precisely on the technical side. Which, despite the wet dreams MBAs were brainwashed into believing, is usually a single point of failure, unless you're a company like Oracle, whose licensing practices and negotiation gap allow them to shove any piece of crap along with their DBMS (which is otherwise worth its money).
Keeping good programmers without rewarding technical merit (while, worse, holding non-technical values in a disproportionally high esteem) is, in my experience, next to impossible. It quickly leads to a depletion of valuable team resources. This doesn't necessarily mean poor economic performance -- you can still achieve that through non-technical means, from aggressive licensing to patent trolling. But at that point, what PM methodology you use for your cargo cult software development process isn't really relevant anymore.
In my experience, most of the projects that were led by primarily ladder-ambitious people have been utter failures if taken at their overal impact. Many of them have actually reached their economic goals, but alienated exceptional developers, blocked promotion for more value-oriented professionals and had outrageous maintenance costs. Good if you look only at a handful of trees, bad if you look at the forest.
Although the lambda papers talk about Scheme, that's not what they're really about. They're really about... lambda. The takeaway is that many common features of languages can be thought of as disguised uses of the lambda operator. So lambda is actually the unifying abstraction behind many languages, even if they don't know it.
The original 'Lambda the Ultimate X' papers are very short, so no reason not to give them a try.
Zero-click info for error messages would be a great resource. There are already some sites that do this for specific kinds of error (e.g. ora-code.com for Oracle errors) but a general "put in this error and I´ll tell you what it means" site would be fantastic.
If I were to add up all the searches I do in a day, then searches for programming advice (e.g. how do I fix X, what's the syntax for Y) would outnumber all my other searches put together, so I definitely think there's a bit opportunity here.
That's only the start of it. How many people who use the web know what http means, or why it appears in their address bar? And how many people at all know what :// is for?
Several Lisp applications have config files that are just Lisp files run at start-up. Emacs is an example. You can (and people do) put absolutely any code in there. There's no need to restrict it to just setting variables.
So what's the difference between a config file and code? Config files aren't compiled (so no need to rebuild when you change them) and they are intended to be modified by the user, while other code isn't.
There is a world of difference between the ad hominem fallacy and an insult. The ad hominem fallacy is bad reasoning. But insults are the spice of life and cathartic for the soul.
Lady Nancy Astor: If I were your wife I would put poison in your coffee!
Winston Churchill: And if I were your husband I would drink it!
HN has civility standards in part to limit the attention advantage that can come from inflammatory rhetoric. Scientific Journals operate the same way, and for the same reason. If you even out the language, the arguments have to speak for themselves.
If object-orientation means X then why don't people just call it X?
If object-orientation is polymorphism then how come many polymorphic languages aren't object-oriented?
At the very most, object-orientation is a particular mechanism for achieving a particular kind of polymorphism (namely ad-hoc object-based polymorphism). At most. Given the vagueness of the term, it could not even be that.
After reading the above article, one could argue that if the definition of object oriented programming is flexible enough, clojure fits it. But we hit a philosophical problem. If clojure is object oriented because it can do all the stuff that oo languages can do, then oop becomes a meaningless metaphor, just a name for a set of common sense ideas. Oop NEEDS to be defined in terms of traditional object systems(with classes and methods and stuff like that) in order to make sense as a paradigm. If you define oop as "a general metaphor in which everything is an object and objects interact with each other via message passing" you can implement it in a variety of ways, all of which would be object oriented.
Simply put, if you don't have the concrete mechanics, the name you had for the result doesn't make sense anymore. Wow, i knew oop was a vaguely defined term, but i didn't know just how fragile its definition was until i started writing this comment.
All of the self-managing teams I've ever worked on have been much more user-focused and success-oriented (in the true sense) than any project where someone was afraid of losing their head. Self-managing teams just seem to be immune to certain kinds of office politics.