208 karma · joined November 1, 2012
You can find many examples of things in nature that are "hard to solve" yet "easy to verify".
I think once someone proves it, it will be obvious in hindsight as a lot of people are just ignoring the isomorphisms in nature.
Also, I can't imagine the answer to something as fundamental as this coming out of a hacky solution. There's probably a more elegant, natural way to prove it. And by natural I mean maybe they should start looking outside Turing's theory.
You could borrow one of those nice DSLR cameras from a friend and shoot something, buy/get some background music online and then get help to edit a short video. It's not that hard and definitely worth it!
A very serious cultural problem I see here in Brazil.
Huumm... Except the fact that, arguably, I don't normally conjecture outside HN [1].
[1] I actually want to see what pg has got to essay about this. Just wait until the Arcstar is ready...
Please hold your downvotes I kid, I kid. Most of this (rather funny) criticism is geared towards SV culture in general, I guess, as HN is just a reflection of that plus common nerd/hacker/engineer/smart-kid-outcast behavior. Apart from the idiosyncrasies of large communities that HN is not invulnerable to, I actually have found great content here. And yes, I'm a white college kid in his early twenties with big ambitions, pg is my hero and I don't feel like getting a job at IBM -- that doesn't mean I'm going to chase a $1B exit with Instagram for Squirrels+social+toilets alongside my other rich friends, replacing cancer research with tweets and fucking up the economy while at it. I'm broke and from another country like many people here, and despite the stupid media frenzy, snarky HN comments, bubble or not and so on, I still want to be part of all this. Why? Because I'm young, stupid and want to see what it's like.
I guess this is what the world's greatest engine of innovation looks like: a bunch of young and stupid nerds from another country.
I recommend (re)reading "Great Hackers" by pg and (re)watching "Hammock Driven Development" by Rich Hickey.
Hmmm I see, I'll make sure to change the commands' instructions.
Defaults would be cool, but not fixed right? What if you could click somewhere and the x,y gets pasted in the command box?
Joints come from Box2D (a famous physics engine), they should have fixed length but it's not 100% accurate. Ok cool, when I add the other joint types I'll improve the description!
I was analyzing the psychological reasons behind this by introspection, and I think there's something to do with your brain trying to repel every little thing that is different from you somehow. It's there for a reason, so I guess that was probably useful 50,000 years ago.
I've realized that whenever you're trying to convince someone or trying to make them understand you, the way to do it is by showing them that deep deep down, you're not so different after all. I really wish more people would realize this. For instance, when you think about a thief, your mind says "Man, I really hate that guy. I would never do such a thing". But maybe he was just trying to feed his family. And that is something you would do.
Yes, yes! I definitely agree but what I meant is "principles of functional programming outside functional languages". When you understand the trade-offs that these principles bring to the table, you can apply them in OO languages -- in some cases. But here he's banning it for good with that statement!
- Comments are fails
Sometimes you rewrite code for performance, making it fast but awful to understand. Comments are very useful in this case.
- Minimize the number of arguments
- Avoid output arguments
Basically, you're arguing against some principles of functional programming, advocating the use of state. There's no good or wrong with state, I think, there's only a trade-off. Heavy use of state = easier/faster to code, harder to debug/read.
IMHO these kinds of generalizations are pretty dangerous. We should always try to understand the problems lying underneath in order to correctly assess the trade-offs. A quote from Elon Musk that goes something like "don't rely on analogies, try to understand the problem" popped up on HN some other day, but I'm too lazy to go look for it now. :-)
You'll learn about the several "weapons of influence" many people have used and still use on you (and you use on people) sometimes without even knowing. It also gives you great insight into sales.
I highly recommend it for a technical person.
This man has probably overseen the early days of more successful startups than anyone else in the world. That huge amount of heuristics (pratical experience) loaded in a single head is the reason I listen to what he says. He's wise.
But wise does not mean "he who gets it right every damn time". I guess there's likely a psychological explanation as to why we love opportunities to pick on the flaws of successful people. "Hey look, pg made a mistake! Ha, I knew he wasn't god!"
I'm not a "documentation expert" or anything, but IMHO I'd say there is too much information on your "landing page" and not a clear "call to action":
- How about some installation instructions?
- Basic usage? (addressing the main features, those which most users will probably use most of the time) If I were you I'd put the details about plugins somewhere in the Wiki.
I don't have a lot of spare time to check out your thing, so the project becomes increasingly unattractive as I have to waste more and more time to figure out how to use it / how to get it up and running for a basic test.
Again, IMHO, I believe this applies to most hackers, and to open source documentation in general. Very often I see great hackers who can code 1000x better than I do, but fail to write 'attractive' documentation for their projects.
That's an unfortunate simplification. Without a technical background, you wouldn't know how long it takes to make a basic CRUD app. "3 weeks? Ok I guess. Oh, 3 months actually? Ok I guess." And what about performance, scalability, costs, etc? You'd have no clue.