kenbellows

Nowadays many applications, and especially most big-name business application suites (G Suite, Microsoft Office online, etc), are converting all their web applications to Progressive Web Apps, adding Service Workers and such so that they work just fine when you're offline and sync to backup document changes and such whenever you reconnect later. Give it a couple years and it won't be a problem anymore.

"Walled garden" in what sense?

To be precise, similes are a type of analogy

Which is ironic, given that English developed as basically French + German (or some old versions of those languages).

Not sure what you mean, can you explain more? When I open my console, I get:

    > true == 1
    -> true
    > false == 0
    -> true

In that sort of case I like to use explicit type casting, e.g.

    if (Number(myNum) === 2) {}

Assuming you can include JS in the file, I imagine it would only run if the file was being parsed as HTML at the moment, not when parsed as a JPEG. That's the main point here: this file can be interpreted in two ways, but the data in it is treated very differently and has different effects depending on the way it's currently interpreted.

This won't answer the question directly, but these sorts of discussions always bring to my mind the famous quote from Jeremy Bentham: "The question is not, Can they reason?, nor Can they talk? but, Can they suffer?"

Nah, I doubt it's actually a forgotten feature, it's probably got some known use cases. I bet it will stick around

I mean, if you think about it, any time you run any installer, whether via brew install, apt-get install, or an .exe or .msi, you're effectively running someone else's unknown code on your system, often as a superuser (e.g. with sudo apt-get install). Is there a significant difference here? At least in this case you could potentially download the shell file and read it before you run it, unlike with a binary executable.

Am I way off base here?

1/x as x -> 0 is a famously tricky expression because your statement that it "obviously increases exponentially as x approaches zero" is only true half the time, because it's only true if you approach zero from the positive side, with x being set to smaller and smaller positive values. If, on the other hand, you set x to negative values of smaller and smaller size, 1/x actually decreases toward -Infinity. This is one of the several reasons that 1/x is typically considered undefined for the Reals.

The OP didn't invent the definition of fields as defined by additional and multiplication, with division defined as the Inverse of multiplication. Even the Wikipedia article on fields (https://en.wikipedia.org/wiki/Field_%28mathematics%29#Defini...) defines them this way. (Not that Wikipedia is an authority on truth, but I find that it's a pretty good indicator of what positions are common/widespread regarding a subject.) It's a bit silly to claim that division is defined as axiomatic "in mathematics" given how fundamental fields, defined as the OP defined them, are to modern number theory and mathematics in general.

Very good points. And thanks for the note about Object.getPrototypeOf(obj) and Object.setPrototypeOf(obj, newPrototype), I don't think I had ever actually looked that up!

Ah, I see. The special thing here is the `new` keyword. When an object is created using `new myconstructor()`, the following steps occur (among others):

  1. create a new empty object; call it `newObj`
  2. call the constructor using `newObj` as its `this` context, so that `this.a = 1` is effectively `newObj.a = 1`
  3. if the constructor has a `prototype` property defined, invoke `newObj.__proto__ = myconstructor.prototype` to establish the prototype chain on the new object

Hopefully that all made sense!

Can you rephrase? The "prototype chain" refers to the whole sequence of objects that link to each other by the `__proto__` property, e.g.:

    let vertebrate = {hasSpine: true},
        mammal = {hasHair: true},
        dog = {sound: 'bark'};
        sparky = {name: 'Sparky'},
        jumbo = {name: 'Jumbo'};
    
    mammal.__proto__ = vertebrate;
    dog.__proto__ = mammal;
    sparky.__proto__ = dog;
    jumbo.__proto__ = dog;
    
    console.log(sparky.hasSpine); // true
    console.log(jumbo.hasHair);   // true
    console.log(sparky.sound);    // 'bark'
    console.log(jumbo.name);      // 'Jumbo'

This entire structure of objects linked through their `__proto__` property is what we call the "prototype chain". Does that answer your question?

I love the idea of an x-height axis as demonstrated in Dunbar. Different x-heights can be used for really interesting effects in different design contexts.

I can't speak for the spec authors, but IMHO, tags should be deprecated and eventually removed when they are deemed to be useless, especially when their functions and/or semantics are covered by another tag, and especially when their use is harmful (or rather, more harmful than beneficial).

In my (very personal) opinion, an HTML tag or attribute, and more generally a feature of any design/development framework, should be considered possibly harmful if it:

- presents possible security problems; for examples, consider some of the points listed here: https://html5sec.org/

- promotes poor usability or accessibility; e.g. interactive tooltips with links or controls in them, for example, are quite difficult to make accessible, and I wouldn't want an HTML <tooltip> tag without a lot of discussion about accessibility

- promotes anti-patterns; e.g., at this point I think <marquee>-style scrolling informational text is an anti-pattern in a web context, since it can the text much harder to read, especially on small screens

Of course, none of these concerns should lead to immediate removal of a thing as soon as they're pointed out, but they should be discussed and considered. It's a cost-benefit analysis: what does this feature actually buy us that isn't easily achievable with other features, what problems is it causing and how severe are they, and are the benefits worth the problems?

As for <menu>, my guess, though I haven't been able to find the actual discussion, is that it was removed because its semantics are somewhat in conflict with <nav>, and probably its most common use was custom context (aka "right-click") menus, which bring a lot of accessibility problems with them. I don't know that I agree with the decision to remove it altogether, since I think its use to semantically identify and group web application controls is very valuable and not covered by any other tags (though I'd love to be corrected), but I do think that context menus, which to me seems like the most common use for the <menu> tag, are a very problematic design element. Again, it's a balance; is it worth the problems it causes? I guess the authors decided it wasn't.

(Just to reiterate, I don't know why <menu> was removed, I'm just guessing. If anyone can find any of the discussions about <menu> and the problems with it, I'd love to read more.)

or, if you prefer, every point is a 'knee' in the curve with a huge speedup afterward

Hate to say it, but this is a rather naive perspective on human behavior and interaction. Like the GP said, the threat goes far beyond losing a job. For just one example, it is a very sad fact that transgender individuals face significantly higher rates of domestic violence, sexual violence, and stranger assault, especially trans individuals of color. More broadly, maybe it's true that fully outing all (or most, or many) closeted LGBTQ individuals would force faster societal change in the long term, but the short term effects may not be worth it, and anyway, I really don't think that decision should ever be in the hands of anyone other than the individuals themselves.

I really hope not; I can't count the number of times I've lost a bunch of data because I hit backspace when I thought I was focused on a text field. Alt+Left is plenty convenient, I don't run the risk of data loss, and I always know what it's going to do.

This is completely and totally true.

Depends on the use application. For observing especially large objects[1][2], I agree, it would be very hard to use for anything beyond a quick demo. But on the other hand, I think the phone is a perfect viewport for on-the-fly smaller applications, like an AR measuring tape[3], adding info about artwork in a museum, displaying a virtual prototype of a dish on a restaurant's menu[4], translating street signs on the fly[5], etc. The phone is perfect for applications where you don't want to plan ahead or be constantly carrying an extra piece of equipment around.

1: https://twitter.com/madewithARKit/status/880815805281300480 2: https://twitter.com/madewithARKit/status/880056901987254272 3: https://www.youtube.com/watch?v=z7DYC_zbZCM 4: https://twitter.com/madewithARKit/status/880744158423658497 5: http://newatlas.com/google-translate-update/35605/

I don't agree with that description of what the brain does when you catch a ball, or with the principle it's proposing. I don't think the brain does any kind of calculations to figure out how to catch the ball; I think it's effectively muscle memory. If you've never caught anything before, your brain will have no clue what to do. As you practice running to catch things, I think a better description of your subconscious process is something like: "The ball (or whatever) looks like it's growing bigger in my visual field at a certain rate. A previous time when it grew bigger at a rate kind of like that, I applied about x force in the legs, and I didn't get there in time. Another time when it was growing at about this rate, I put applied a larger amount of force y, and the ball landed behind me. This time I'll try to apply a little more than x force, but less than y force, and see how that works."

This is a substantial oversimplification of course (there are many more factors involved than how fast the ball is growing in the visual field), but I think the point is clear enough. I doubt there's any trigonometry happening in the brain's circuitry; it seems much more plausible to me that the brain is really good at remembering how it felt in previous circumstances, recognizing how those remembered circumstances relate to the current one, and trying to adjust.

As I understand it, this is actually a significant debate in cognitive science, philosophy of mind, and related fields. One prominent proponent of a view like the one I've expressed here, that the brain doesn't require or use heavy math to do things like catch flying objects but rather acquires the ability over time through experience, is John Searle. He is known for using the example of his dog's ability to catch a ball that's bounced off a wall when discussing and arguing against theories of mind that propose that all unconscious processes must be following algorithms or rules (like running through computations to figure out how to catch a ball). Here's a quote of his from the BBC program Horizons (quote found in "New Technologies in Language Learning and Teaching", issue 532, on page 37 [1]):

  If my dog can catch a ball that's bounced off the wall, that may be
  just a skill he's acquired. The alternative view (the pro-AI view)
  would say: "Look, if the dog can catch the ball it can only be 
  because he knows the rule: go to the point where the angle of
  incidence equals equals the angle of reflection in a plane where the
  flatness of the trajectory is a function of the impact velocity
  divided by the coefficient of friction" - or something like that.
  Now, it seems to me unreasonable to think that my dog really *knows*
  that. It seems to me more reasonable to suppose he just learns how
  to look for where the ball is going and jumps *there*. And a lot of
  our behavior is like that as well. We've acquired a lot of skills,
  but we don't have to suppose that, in order to acquire these skills,
  the skills have got to be based on our mastery of some complex
  intellectual structure. For an awful lot of things, we just *do* it.

I think the article is arguing that while age may not be necessary for quality, it is sufficient. A young(er) programmer may or may not have these qualities, but in order to survive in the programming industry beyond a certain point, you have to develop these qualities. (Not sure whether I agree, but I think it's a point worth considering.)

As some guy once said

In case anyone's curious, it was Bo Burnham in a Conan interview: https://www.youtube.com/watch?v=q-JgG0ECp2U

I would think that whitespace becomes significant inside string-delimiting square brackets for the same reason that whitespace is significant inside string-delimiting quotes: whitespace characters are characters like any other. I would expect `[ abcd ]` to be different from `[abcd]` in the same way that `" abcd"` is different from `"abcd"` in languages that use quotes.

Is there something I'm missing that mitigates this intuition? Does this language (or, for that matter, the demo language you wrote for your class) ignore leading or trailing whitespace inside square brackets? What about excess whitespace between words (that is, whitespace beyond a single space or tab)? If so, if indeed leading/trailing/excess whitespace is collapsed inside of square bracket delimited strings, how would I create a string with leading or trailing whitespace or extra space between words if I wanted to?

Honest questions; don't mean to criticize, just eager to learn.

Indexing into 2D containers is often an exception to the "x, then y" rule; indexes are very often specified with "row, then column"[1]. It's true that this is different to Cartesian coordinates, but grid cells aren't points or locations on a Cartesian plane, they're members of a 2D container: the grid.

1: https://en.wikipedia.org/wiki/Index_notation#Two-dimensional...

But... why? If you wanted to express their equation in terms of tau (that is, 2pi), you could just set the first term of the right hand side to 10/phi instead of 5/phi. In fact, throughout their derivation there are points where a tau-based version would be a bit cleaner (though of course there are other points where tau might be a bit messier).

He was referencing this statement from the GP: "Looped around a waist and​ the same person can get up to about 1.0-1.5x with cleats on turf." Point is, if tug-of-war players have been known to lose hands because the rope was wrapped around them, do you really want to see what happens when you wrap it around your waist? Maybe it's safer because your body is much thicker than your wrist, but is that really an experiment you want to run?

Not sure the process, but it's possible on YouTube to allow community members to add captions for your videos (after approval by the channel owner); who knows, maybe a few generous folks with some spare time would do the work for you