jwmerrill

I don't think this would be a very compelling argument for Occam's razor if you didn't already believe it. This argument says you can't assign high probability to all "complex" theories, but it doesn't seem to say that the high probability theories must be simple. You could use any criterion at all to single out a high probability subset.

From the first entry:

> Implementing these features is easy because this is the second time for me.

Marijn Haverbeke has been writing some great material about his experiences creating ProseMirror [1]. I wonder how the two systems compare.

[1] http://prosemirror.net/

[2] http://marijnhaverbeke.nl/blog/collaborative-editing.html

The problem with this way of thinking is that there are invariably things that you initially believe will be of no concern to the parent that later become concerns of the parent. It's tempting at that point to graft on some event system so the parent can watch the things that it now cares about, and then maybe you add some hooks to allow the parent to preempt or change certain behaviors. This evolution requires careful thinking every time, and it's easy to make mistakes.

The great thing about the elm architecture is that from the very beginning, it gives the parent all the hooks it will ever need to observe and modify the behavior of children. In the beginning, when the parent doesn't care, it just passes the actions up and passes the model back down without having to look at them. That might feel a little bit boilerplate-y at the beginning when you don't need it, but it's the same everywhere, so it isn't difficult at all. And once you've done this, evolution of the components requires much less thinking about architecture, and leaves much less room for mistakes.

    julia> bisect_root((x) -> rand() - 1/2, 1.0, 2.0)
    (1.1980511149266218,1.198051114926622)

    julia> bisect_root((x) -> rand() - 1/2, 1.0, 2.0)
    (1.595600613503659,1.5956006135036591)

I don't think it's right that publishers seem to view me showing up at their front door as carte blanche to abuse my network and system resources to the full extent that JavaScript allows. And I think it's wrong to characterize user pushback as theft. Other kinds of "theft" are criminal behavior. Pick better terms.

Response 2: a few sites are already popping up messages asking you to turn off your ad blocker, which is at least a partial existence proof.

Response 3: if you want to know whether I got your ads, use cookies or make the request url unique to me, and then check that your ad servers served the appropriate requests before allowing your content servers to serve me content.

But seriously, I shouldn't be required to solve all these problems for you as a user in order to not be called a thief. If you want a more explicit contract, then require a log in. If that adds too much friction, invent a better a better solution.

*Edited to remove the inflammatory suggestion to go out of business if you refuse to negotiate.

Suppose you want to schedule a phone call for two weeks from now with your colleague in Melbourne. That's currently kind of challenging. It's fairly easy to accidentally agree to an inconsistent time. What if that two weeks straddles a DST change in one country, but not the other?

In UTC world, you agree to a single time, and there's no confusion. To pick an appropriate time, just look up the range of business hours in Melbohrne, and intersect those hours with the business hours wherever you are.

I don't really see how your google or clock app examples are compelling. Just google "business hours in Melbourne", and then save those in an app or wherever if you think you'll want that information again soon.

Here's a different POV. Using an ad blocker is not theft: it's a negotiation.

When I click on a link to your site from a site like HN, I have not implicitly agreed to whatever terms you would like to impose on me. I can't even really know them ahead of time.

Instead, I'm sending my User Agent to negotiate fetching some resources. If I decline to fetch your ads, you can feel free to decline to serve me your content. Or you can give the content to me anyway. Your choice.

Star ratings have problems with compression of scales at the top and bottom. You'll never know which item is someone's favorite (or least favorite) with star ratings, because typically there will be several items with the maximum or minimum number of stars.

Pair-wise comparisons are also more fun and easier for users. When I'm doing star ratings, I often find myself trying to remember what star ratings I've given to similar things that I liked a little more or a little less so that I can try to be consistent.

Pair-wise comparisons probably make more sense for items in similar categories, though. It makes a lot more sense to pick a preference between two novels than it does to pick a preference between an ice cube tray and a camp chair.

In analogy with scientific modeling, there's a risk of over-fitting your tests against the exact circumstances of your product as it exists today. You want tests to capture the important aspects of your product, while having a little bit of flexibility for the "noise" related to differences between platforms, and changes to mostly but not entirely unrelated parts of the product.

Back in the days when "system" was a reasonable font choice, fixing a bug after shipping would take weeks, months, or years, and could cost $10^4 to $10^8. You might have had to pull actual boxes off actual shelves somewhere!

In this story as it actually happened, the bug was fixed and the fix was deployed in a single day, at the cost of a few laughs.

I'm sure they tested on Windows when they added Segoe to the list, so the problem is that they didn't test again after fiddling with other fonts that they (incorrectly) thought would be irrelevant to Windows. And remember, nothing was broken in a way that a machine would notice, so automated acceptance tests wouldn't have caught this regression.

I think it's worth considering the possibility that this is a story of Medium acting more or less in their economic interest (maybe even in the economic interest of their users?) rather than a story of a bunch of hipsters with a hilariously broken QC policy.

Double your money in only 2300 years with the miracle of compounding interest.

I've had good success with Jison as a JS parser generator that is performant enough to feel good about using in production.

http://www.freelists.org/post/luajit/Turning-Lua-into-C-was-...

tup is the only new build system I'm aware of that successfully innovates on build correctness. It snoops file system calls while running your build commands, so it can tell if your declared dependency structure doesn't match your actual dependency structure. It also notices when you change your build commands, and will delete old build objects that would no longer be produced by the new commands.

We used it to replace gulp in a medium size node/javascript project, and it absolutely destroys gulp in terms of efficiency and correctness. The only downside is the lack of more community resources describing how to configure tup for non C projects.

http://webcache.googleusercontent.com/search?q=cache:7SWRaHW...

(x(t), y(t))

or implicit form:

f(x, y) = 0

Parametric form is naturally associated with one point of view of what a plane curve is: the set of points traced out as a parameter is swept over its domain. Implicit form is naturally associated with a different point of view: the set of points that satisfy a certain relation.

Functions of the form

y = f(x)

can be easily re-expressed in parametric form:

(t, f(t))

or implicit form

y - f(x) = 0

so both the parametric viewpoint and the implicit viewpoint are equally valid and useful ways of understanding the graph of a function. You could rephrase the author's insight as saying that he had always understood graphs of functions parametrically, but later learned to also understand them implicitly.

Depending on the application, it may be more convenient to have a parametric representation of a curve, or an implicit representation of a curve. For example, it's easy to find a point on a parametric curve, but hard to test if a point is on a parametric curve; on the contrary, it is hard to find a point on an implicit curve, and easy to test if a point is on an implicit curve. If your curve is the graph of a function, it is easy to convert back and forth between these forms, but in general, converting from one form to the other may be quite hard.

For me, the relationship between implicit and parametric representations is a piece of math that I didn't really learn until long after I thought I had already learned math.

https://html.spec.whatwg.org/multipage/workers.html#communic...

Here's a jsbin experiment that shows that the main thread is blocked while parsing JSON using the author's technique (tested in Chrome 44 and Firefox 41):

http://jsbin.com/yutahe/8/edit?js,output

http://www.nytimes.com/2010/11/17/dining/17curious.html?_r=0

His conclusion was that most oils taste the same after you heat them to frying temperatures.

http://www.dnd.utwente.nl/~tim/colorforth/Leo-Brodie/thinkin...

But neurons totally do work by encoding information with discrete signals.

https://en.wikipedia.org/wiki/Action_potential#Process_in_a_...

Action potentials are discrete events, and just like hi or lo in a silicon computer actually correspond to a range of voltages, the exact voltage-vs-time curve of an action potential likely has considerable flexibility.

This is a really valuable observation.

"Smart" compilers seem great for letting you write code without thinking too hard when performance requirements are loose, but they make it difficult to achieve peak performance in two ways:

1. The fact that details of the machine are abstracted away from you means that you may never learn them well.

2. It ends up being insufficient just to know the details of the machine, because you also need to know how to coax the compiler into producing the low level result that you want, and then you need to be vigilant that later changes to the compiler don't break your assumptions.