This. In my experience of many decades using software program flaws, be them bugs or UI issues are longer lived in open source software than in commercial software. In commercial software either you fix it or your competition will.

In open source software the standard answer is: "the source code is there, fix it yourself!" which is as realistic as telling passengers on a falling plane that they are welcome to try to fix the problem.

Dude, we all know (even the GP) that straight out projections of exponential functions are wrong. However the fact that in just 20 years either one gets us there (as opposed to say 200 years for both combined) means that the error of tracking the exponential curve is much smaller than one would have expected from a straight out mindless exponential projection.

Solar is on a Moore's law curve and has the same principles behind it, so we could well see a 100x increase in PV production over the next 10 years.

Huh? for most of the last 100 years we pretty much had a single temperature choice: yellow incandescent. A bit more recently we had halogen (relatively successful) and CFLs (not really). What is this huge temperature market you talk about?

Yes and possibly my kids where kidnapped by aliens while they were asleep and hypnotized into believing that LED lights are better. Care to discuss other "realistic" alternatives?

At any rate the kids part was anecdata, and only one piece in a wider argument which is "the preference for present incandescent yellow has a large historical component" and that part will go away with time.

The conclusion that your childens' stated preference is based on color alone is non-sequitur, at best. At worst, it's a blatant red herring.

Except for the minor fact that they said so themselves. Here's the quote again for your benefit "they describe it as artificially yellow".

I also gave evidence that this has happened before, when we transitioned from gas light to incandescent light. Lastly even today people prefer the somewhat whiter hue of halogen over regular incandescent yellow, indicating that the present yellow isn't really all that is made to be.

Now, and here's something you don't seem to be aware of, constructing an argument is different than a logical proof. E.g. "he had a gun, motive and opportunity. He was at the scene of the crime and was seen running away after shoots were fired". It does not logically follow that the person did the crime and it would be a logical fallacy to state as much, yet it is the reasonable and logical conclusion nonetheless.

In my house there are three consecutive rooms: one with an incandescent bulb, the second with a compact fluorescent and the third one with a LED light. I asked my kids which one they prefer and to my surprise, they both chose the LED light. Then I bought a somewhat "warmer" LED and put it in the corridor next to the white LED room. As an old timer, I prefer the warmer LED. Not my kids. They describe it as artificially yellow and again to my surprise they choose the whiter LED.

The only reason we prefer the ugly yellow hue from indandescents is because we are used to i. It isn't "warm", its sucky. Same with thing happened when gas lighting was first replaced by incandescents: people pined for the soft orange glow of gas lights but within a few years people realized how bad that hue was.

My kids, young and unencumbered by tradition prefer the LED lights. So will everyone else rather soon, as we slowly transition to whiter more sunlight-like hues that are now possible with LEDs.

I'm pretty sure they have said as much themselves.

First of all, I was giving some reasons why it didn't take off. Second Scheme/Lisp still doesn't have easy to use pointers to implement a threaded binary tree which is point (2). Third, point number (3) is not a matter of taste. This is like saying that not liking a shit sandwich "is a matter of taste".

Lastly, the person who needs to wake up and smell the coffee is you: Lisp hasn't taken off. So clearly there must be powerful reasons why this is so. I listed some, and the way you deal with them is plain old denial. I've learned Lisp thirty years ago, and heard arguments like yours back then. With your attitude I can guarantee you that we will be having this same conversation in another thirty years.

I refuse to crucify one of mine for a minor transgression when yours walk away with treason time and time again.Simple as that.

She should be as harshly punished as Bush Jr was for lying about WMD or as Cheney for illegally releasing the name of a CIA agent.

Sorry, but the original Lisp got quite a few things wrong itself and by the time it got around to fixing it had missed the boat. Here's a sample

1. the only data structure available is the list. Scheme includes arrays and so much better for it
2. it doesn't have pointers, which means it is hell to build a complicated but very efficient data structure like threaded trees
3. (it(has(too(many(parenthesis) ) ) ) ). In part because it attempts to operate under the illusion that a function call like (ADD 1 2) is the same as the list (ADD 1 2) which it isn't and hence the setq and ' rigamarole. In fact back when Lisp was first introduced its creators thought that not long from there a version 2.0 would be introduced using more standard notation, like ADD(1,2) or even, _gasp_ 1+2.
4. The main flow control structure is recursion. Recursion can be very nice and elegant, but there are times where one needs a for loop or a while loop, and one can either shoe horn it under recursion, or simply make the language richer and include those control structures (see again Scheme) for things are best understood as a for or a while loop.
5. variables were a bit of a kludge which lead to juggling of partial results into function parameters

If modern Scheme had been introduced in 1965 instead of 1975 we might be today programming in some modern dialect of Lisp.

Now some fanboi will come and explain why these things aren't a bug but a feature in 3, 2, 1

I was a manager and never missed a deadline. It really isn't that hard. Most people fail because they do it the wrong way. First give no estimates until you have developed a good picture of the global architecture and have some bare bones functionality running. This takes about 1-3 months of your team, but well worth the effort. Then keep an eye from the very beginning on who's falling behind, and move resources around to support the people who ended up with more than their fair share. Assign a medium size portion of the project to your senior developer(s) so that they are available near the end to go and help in those areas that turned out to be gorier than predicted. You cannot bring people from outside since it takes them too long to ramp up as obseved by Fred Brooks. This is why you use your senior people: they know the whole system and can jump in in any part***. Stand firm in your refusal to add features and lastly, near the end, drop any minor feature which gets postponed to version X.1.

Most costumers are happier with a version in time with 95% of the features than a complete version three months late.

Also be realistic with what means to be in time. If you take three years to develop a system and you are five days late, you were off by 0.5%. Any one who tells you in this case that you were late is just mathematically innumerate. I was never more than a week late, but I'd dare say that even an error of 5% (which for a three year project is seven weeks) should not be considered late. Forecasting is an imprecise science afterall.

Oh and one last thing, there is one estimate you tell the team and there is another one in your head. So the goal is "we run as hard as we can to finish by May 10th, so that when sh*t happens (which always does) we make the real June 1st deadline (which you always keep secret so programmers don't budget for it.... you know, work expands to fill allotted time).

*** Stu Feldman, a Unix principal was used this way, according to Ritchie. Stu didn't fully own a single component of Unix but his code is everywhere, doing central things that had fallen behind and were passed on to him.

...and the one use of GOTO that could be often justified got incorporated into modern languages as the break/continue pair.

So all in all a good outcome: stop using GOTO as the main control structure while preserving its good uses.

Which is why C's choice of assignment operator is so asinine and bug inducing, yet one that few of its descendants has been willing to break. In fact I can only think of Go as a modern language which eschewed it.

The private part yes, the keep it part is the one that fails. They can simply delete it, and no amount of encryption will protect you from that.