callenish

Have you never had to indicate how many bytes you are sending over a stream, say in the Content-Length of an HTTP response? Have you never put strings into a byte buffer?

But that doesn't matter. Let's say you are correct: when working with strings, you more often want the rune length. It still wouldn't be the right decision, given the other design decisions of Go, because it would have needlessly complicated things with only arguable benefits. Let me show you what I mean.

The len() function works with a whole lot of things: strings, arrays, slices, maps and channels. For the first three, len() returns the number of bytes involved. This is because all three are backed by an array, and so sensibly have similar semantics. It would have violated the principal of least surprise for anyone who knew the language to have an array-backed storage not return a byte count. Both the language developers and the users of it would have to special-case strings, in code and in their brains.

Now, they could have decided to do it anyway, but then another surprise awaits. What happens when you take a slice of a string? Oh no, more special casing and more complication for everyone.

The Go developers do special-case where doing so would clearly be a win for their users. Consider range, which iterates by runes over a string, potentially moving the index on the underlying array forward by more than 1 on each pass. That is clearly going to be the most common usecase the user is going to want and so was worth doing. It also eliminates many of the usecases where getting the length of a string in runes would matter to you. Not all, but a lot.

In Go:

    len("нєℓℓσ") // 12, because there are 12 bytes
    utf8.RuneCountInString("нєℓℓσ") // 5, plz kill me i am an abomination

Shouldn't UTF8-specific things live in the utf8 namespace? Some programs won't need any string handling, after all, and it would be a waste to include code they never used.

Assuming you can allow the utf8 namespace as sensible, would you feel better if there was a RuneLen() function aliased to RuneCountInString()?

If you are that upset about it, then my suggestion is to explain your rationale and submit a patch[1] to provide the alias. It's not like it would be hard to code. Perhaps you might convince people and get it in the next release.

[1] http://golang.org/doc/contribute.html

I think this calls for a meme.

http://qkme.me/3uxsx0

I think this is an impressive first step, and I love the flow-through that future owners will be equally bound by the terms. Essentially, it gives a permanent free license to use the patents in any open source projects, which can only be an incentive for businesses to make their code open if they can.

I've often wondered, though, why there isn't a consortium to which all the companies with "defensive" software patents can assign them, on condition that if the company get sued for ANY software patent, the consortium will terminate the license to the plaintiff for ALL the patents it holds. The consortium could make that explicit in the license for software patents they offer (for free) to everyone. Sue someone for a software patent and you lose all rights to these others.

That would kill software patents dead in their tracks, I think. There are many elements of that solution in this one announced by Google, but it would be far more effective if every company who hated software patents but held them anyway collaborated.

You are right that it is a better term, and I should have used it. I disagree that there is no link between being risk tolerant and risk seeking, though. It would be an interesting study to see if entrepreneurs engaged in high risk sports such as sky diving more frequently than others.

I know there is a temptation to look back on events with hindsight and pound your chest shouting, "Mea culpa, mea culpa!" But it is a misplaced notion in your case.

You describe your first attempt at a startup as a failure. It should be seen as a learning experience. Entrepreneurs tend to be risk seekers, which is why they take the chance on a startup to begin with. I would guess from your description of your actions with FlightCaster that you were far more risk averse the second time around, from which I conclude that likely you learned that you took too many heedless risks the first time.

Would there have been an exit with FlightCaster if you had taken more risks? Possibly not. Perhaps the level of risk you took on was exactly what was needed. The nature of life is such that you will never know.

It is good that you keep in mind how lucky you are, though. Many good people lose out while making all the right decisions. After all, even with a 95% likelihood of success for a particular action, 5% of people will still lose. And there are an awful lot of bets you need to win in order to get a startup off the ground.

So make sure you learn the lessons you can from the past, but keep it in perspective. Otherwise you will put too much emphasis on things. I wouldn't trust a person to run a company who didn't fear that it might fail, but fear is self-fulfilling if you let it. Striking a balance between the two is the key, and each experience you have helps you find it.

When the blogger used the phrase "Fibonacci mysticism" it becomes clear he has far too much bias to pay attention to what the kid was actually doing.

He points out that voltage in solar cells is essentially boolean. Ok. That means that the kid has shown a way to orient the cells so they get sunlight for a longer period of time. If evolution is anything to go by, his approach likely reveals a local minima for maximizing the time that sunlight is collected.

Is that worthless? No, it is not. It may well explain why trees orient their leaves the way they do, and there could well be practical applications. If your solar array produces more than the peak power you need but the cost and energy loss of storing the power are significant, you may well want to use a pattern like this that mimics what trees do.

What impresses me is that the kid noticed something in nature he hadn't noticed before, read up on it to see what was known about this pattern, and then went out and measured to see whether what he had read was accurate. Once he had verified what he read, he then figured out how that knowledge might be applied. In doing so, he discovered something that, while obvious in hindsight, is not something that would necessarily have occurred to someone trying to figure out how to maximize the time for solar panels to deliver energy. I think the kudos are appropriate, even if the stories are misleading.

An important point here is that in any news story about something that you know a lot about, there are always errors. Always. We should all keep that in mind when we read or watch or listen to the news.

Perhaps you should let some of the open data citizen groups know about this so they can add more data. Also, if you haven't already then take a look at CKAN[1] for datasets to add.

[1] http://ckan.net/