bct

25 ms·

211.
by bct 15y ago
The difference between assembly and (for example) C is vast. The difference between JS and CS is much smaller. Whether the difference in usability and maintainability is worth the extra layer of complexity is an important question.
212.
by bct 15y ago
This is what I actually believe.
213.
by bct 15y ago
Your expectations are odd. Large, loosely-knit communities don't (and can't) decide things in the way that you're suggesting. Regardless of what "should" happen, we're just going to continue muddling around. It's worked out OK so far.
214.
by bct 15y ago
Linux users are not a monolithic group that all simultaneously want mainstream success and exclusivity. There's plenty of room for both approaches.
215.
by bct 15y ago
Most of that difference in life expectancy is due to lowered infant mortality, they weren't copyrighting anything anyhow.
216.
by bct 15y ago
Hmmm, interesting. Here's a concrete example: I've got an 'Organization' model and a 'Person' model. I want to use them interchangeably in some templates, so I need to be able to get their names in a consistent way. An Organization just has
217.
by bct 15y ago
I'll try to think of examples and come back to it tomorrow. For now: One thing that I'm still not clear on is when to wrap .get/.set. Should I always write my own getters/setters and only use .get/.set internally? Right now I'm only wrappin
218.
by bct 15y ago
"Lack of guidance" is the way I'd describe it. The documentation is great, but it didn't help to steer me away from making architectural decisions that don't work well with Backbone when I was doing my first experiments.
219.
by bct 15y ago
Those are some pretty wild assumptions you've got there.
220.
by bct 15y ago
Men's issues are feminist issues, and are best advanced by working with and as feminists.
221.
by bct 15y ago
> It implies that just by being a men one is in a more powerful and advantageous position. All other things being equal, yes, a man is in a more powerful and advantageous position. Obviously there are lots of individual women who are mo
222.
by bct 15y ago
> down-vote the heretic > "forbidden thought" > I don't care about "thought crimes". Bad news: you're not the brave thinker that you seem to think you are (in fact your "forbidden thought" is probably more common than the altern
223.
by bct 15y ago
Please note my parenthetical.
224.
by bct 15y ago
keymone said: "overdramafication because of overbitchiness? boring.." Quoted for posterity.
225.
by bct 15y ago
The difference is the societal context. Women are judged by and valued for their appearance (to the exclusion of other attributes) to an extent that men are not.
226.
by bct 15y ago
"Do women also find the fact that only women actors are used in cleaning commercials "fucking gross"?" It's not gross in the same way, but yeah, that is a great example of sexism!
227.
by bct 15y ago
"They're paid for it, there is nothing illegal about it" Ah, Hacker News, where all ethical questions boil down to "were they paid?" and "is it illegal?".
228.
by bct 15y ago
> (E.g. I can't see a client going "oh!, there's a new business function I haven't seen yet, let me invoke that!".) Of course not, nobody thinks that. That notion does not exist. > With the rels/links, you're just moving the couplin
229.
by bct 15y ago
The trick is to build ugly systems that are able to grow into beautiful ones.
230.
by bct 15y ago
I don't understand the distinction you're making between "trivially" and "non-trivially". Looking at pretty much any commercial CMS you can see that publishing documents can involve all kinds of business logic.
231.
by bct 15y ago
http://www.ietf.org/rfc/rfc5023.txt
232.
by bct 15y ago
Of course we have to be pragmatic about these things - if you have a business that will live or die based on the success or failure of its API then you have to make your decision based on that - but there are times that it makes sense to pu
233.
by bct 15y ago
You examine the situation and determine what makes the most sense. Do you want the client to repeat the request if it's not sure whether it succeeded or not? If so, use PUT; otherwise use POST. This isn't complicated stuff.
234.
by bct 15y ago
I don't think there's anything particularly unRESTful about using non-URL ids in that case. The critical thing is that the client isn't using out-of-band knowledge (i.e. what the developer read in the API documentation and hardcoded into th
235.
by bct 15y ago
What's often left out is the reason that that's a useful rule to have: if PUTs are always idempotent, then you can always safely repeat a PUT if you're not sure whether it succeeded or not. This makes it easier to build robust systems.
236.
by bct 15y ago
> commonly held up as exemplary REST Not by people who know what they're talking about. > This makes so much more sense because then you can use ?command= and have any command you want and not have people confused about what it mean
237.
by bct 15y ago
No. It is incorrect to use tables used for layout, and this widespread practice has made it impossible for user agents to treat tables specially. A div exists to have no meaning. Using it for layout doesn't hurt anything except page size (u
238.
by bct 15y ago
I had the same problem, for some reason get '/:short_code' do end got inserted at the end of the textarea.
239.
by bct 15y ago
> Then I will. It's a conspiracy theory, worthy of all the mocking typically associated with such a thing. When we're talking about a company what's the difference between a "conspiracy" and a "plan" or "strategy"? (Serious question.)
240.
by bct 15y ago
Maybe we don't need stuff like Avatar.

More ›