HN user

12ren

23 karma
Posts0
Comments15
View on HN
No posts found.

In the aftermath of a wave of criticism, his company collapsed.

One breast cancer charity that parted ways with Mr. Pallotta began producing its own fund-raising walks, but the net sum raised by those walks for breast cancer research plummeted from $71 million to $11 million.

But because his company collapsed, the true comparison figure that Mr. Pallotta raised became $0 million. As a business, it didn't succeed. And he's blaming the world. People often give to charities to feel charitable, and having a profit-motive undermines that - even if the result is that less money is raised. This is because people making donations are often fulfilling a need to give and help people - not by what is best for those being helped. The latter requires a kind of ruthless saint, quite different from the human motivation of brotherly love.

In contrast, ordinary businesses helps people, or else no one would give them money. A fantastic example of this is Grameen Bank "microcredit": http://www.grameen-info.org/index.php?option=com_content&... Usury (interest for credit) has got to be pretty much the opposite of charity, yet it seems to do tremendous good.

Crows "finding" money is problematic, as it might not be "lost"... intelligence (evolution, flow of water, etc) has a way of finding the shortest path. It seems tricky to specify the goal clearly, so the crows are trained to find only "lost" money. Perhaps only reward them for coins that were on the ground? As opposed to in someone's pocket, purse, on a shop counter, in a cash register, in a bank... hmm, this experiment could end badly.

Crows more intelligent than monkeys, he claims in the following (1 min) video. Could that be true? http://www.npr.org/blogs/bryantpark/2008/03/taking_over_the_...

We try to kill off adaptive pests like roaches, rats and crows, but we're breeding them to be parasites ... a better goal ... is to seek an interspecies harmony.

Lovely idea! Reminds me of how parasites became symbiotes, then integrated, as has been argued for some cellular machinery (eg mitochondria and chloroplasts) by Lynn Margulis: http://www.amazon.co.uk/review/R3IIWSOA7G9YKL . It also reminds me of "The Evolution of Cooperation" Axelrod http://en.wikipedia.org/wiki/The_Evolution_of_Cooperation

An editor is more like a "toy" than a "game" (http://news.ycombinator.com/item?id=407816), because it lacks goals.

This “toy” should be the core mechanic of the game minus any goals or decisions. There is no win or lose state, just a fun thing to play with.

I liked ken's comment about Mirror's Edge not unlocking abilities, but you can't use them til you encounter the appropriate geometry in the environment (or I think, maybe you could use them before, but you didn't need to, as there were simpler more obvious ways to complete the task using abilities that you already knew about).

For example: movement in an editor. The cursor keys will allow you to do anything; but the word-movement keys can often do what you need more efficiently. Then, in vim (using it as an example because I know it), you can search to the right using "f<somechar>", and there's also F, t, T, ; and ,.

Interestingly, I've only really started to use the latter ones after years, because I'm having a touch of RSI, and I have a need for fewer keystrokes.

One could convert vim (for example) from a toy into a game by adding goals. These goals would have progressively greater difficulty such that they need the more sophisticated controls to accomplish them.

Having a need for something gives you a motivation for learning it; but it also makes it cognitively easier to learn. When you have a gap or lack in your mind crying out for a solution, acquiring the solution that fits that gap makes you feel "ah, that's better!". This makes it more memorable; and creates a strong link from the problem to the solution, making the solution accessible to you the next time you need it - making it useful to you, in practice.

True, especially for the many people who make one attempt, fail, and stop.

Though if you look at people who make several attempts, and who learn something from each, I think the probability of success fast approaches 1. I think that in practice, if you persevere and are reasonably capable, success is inevitable.

Interesting. It also happens with people newly infatuated with OO, esp design patterns.

I think this is a natural phase of learning - when you first grasp a new concept, you use it everywhere; later, you use it where appropriate. Maybe the first phase is exploratory practice, to grasp its limitations. I'm sure there is a pithy expression for these two phases.

Anyone know it?

The first phase is like "To the man with a hammer, everything looks like a nail". It's also similar to Fred Brooks' "Second System Effect" http://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_Seco... , where you try to learn from all the mistakes you made in the First System.

Children learning language will apparently learn and use plurals correctly - until they discover the abstraction that you can add "s" to make a plural. They then apply it everywhere, including the irregular plurals: mans, foots, tooths, mouses etc. (that last one may be legit these days, mouse having acquired a technical referent). Or even like that developmental stage of babies, where they try chewing everything they find.

Adam Savage is a very funny guy, and a true geek. That didn't come across for me on mythbusters.

"You can only clean up a messy room by picking up one thing at a time, you can't think about the totality."

It's the planned spontaneity that makes the "Anyway." slide work. His setup and delivery of this line is so enthusiastic, natural, sincere that it couldn't be planned... yet there's the slide. Cute theatrical technique.

Here's an idea: treat the slides like a ventriloquist's dummy, so that they counter your argument, mock you, undermine you. You could have a conversation. You'd need theatrical skills to pull this off.

Please reply to this comment if you try this out!

There's an issue of need satiation. Once a need is met, further improvements can't be absorbed. Like water when you aren't thirsty, it doesn't matter.

Hardware helps performance - but this only matters when more performance is needed. For example, if features or usability are needed, extra performance doesn't help. This is obvious, but it's surprisingly easy to get caught up in improvements that are better, but that don't matter.

For productivity of programmers, faster hardware only helps when performance is a problem. The article says: If [it] makes them merely 5% more productive... - that's an "if". Will a faster PC make you more productive? These days, compilation is too quick for me to squeeze in a swordfight. For other hardware (eg large screens) there is also a limit beyond which extra real estate isn't useful (Joel on Software talked about several of his coders that don't use their second monitor). It depends on the task, of course.

Faster is always cool and impressive. But like a 300 miles per hour station wagon, will it help you?

Examples of successful Strong DSL (ie. standalone) are James Gosling's project for satellite control (I think it was), which he did so that users could make their own changes without bothering him (I doubt details are online - he mentioned it in an interview as a virtual machine that was a precursor to Java).

Our own pg also had a DSL for the Yahoo Store (was viaweb), so users could customize it. From the docs, it looks like it is implemented as Lisp with isomorphic friendlier syntactic sugar.

On weak DSLs (ie within a host language), I still think it's a virtue to try to make it as self-contained as possible. Mini-languages are surprisingly common: regular expressions; printf format syntax; XPath within XSLT. I saw a great comment recently [1] suggesting having DS error messages. I think this is an oft-overlooked aspect of the abstraction (it's not just syntax!), and to make the abstraction as non-leaky as possible helps everyone (programmer and non-programmer alike).

[1] http://debasishg.blogspot.com/2008/04/external-dsls-made-eas...

I got exactly the same impression from my compilers class, especially for parsing - it's a bunch of techniques, which vary in their applicability. I still have that opinion, after years of research and commercial work using parsing.

Although there's some mathematical theory in the background (regular expressions, context free grammars), the techniques don't fully correspond to them, and aren't really implementations of the theory, but a convenient, useful, doable subset. The adoption of the techniques seems to be dictated by what works to solve specific practical problems. The techniques themselves are pretty ad hoc; but they have been studied, and there is a body of knowledge about where each technique is applicable. Although certain correspondences have been proven, it's not neat and beautiful like physics; but truth and beauty aren't what ye need to know here.

It's really "Compiler Engineering".

Abstracting (too much), it's violated expectations - like broken promises, people really don't like it.

Taking a tangential step, computer automation is similar when it purports to be able to help you, but doesn't understand you well enough to do so; like MS's "clippy".

In contrast, Google's "I'm feeling lucky" button is automation that fulfills its promise (though the name emphases that luck is involved). Google can predict so well what I want, that this button is (very often) right. An awesome achievement. I added a simple command-line google lookup, to go directly to the page, and it's freaking me out how well it works:

    > cat ~/bin/g
    firefox google.com/search?q="$*"\&btnI= &