kenbellows's comments

kenbellows | 6 years ago | on: Microsoft Edge preview builds for macOS

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.

kenbellows | 7 years ago | on: JavaScript Equality Minesweeper

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

    > true == 1
    -> true
    > false == 0
    -> true
Do you get something different? Or is the game claiming something different?

kenbellows | 7 years ago | on: JavaScript Equality Minesweeper

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

    if (Number(myNum) === 2) {}
For me this also extends to using `Boolean(val)` instead of `!!val`, etc.; though I understand the appeal of those nifty one-liners, I think they cause confusion in many places and don't communicate intent nearly as well.

kenbellows | 7 years ago | on: A file that’s both an acceptable HTML page and a JPEG (2012)

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.

kenbellows | 7 years ago | on: The Ethics of Consciousness Hunting

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?"

kenbellows | 7 years ago | on: Show HN: Rb – Turns Ruby into a command line utility

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?

kenbellows | 7 years ago | on: 1/0 = 0

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.

kenbellows | 7 years ago | on: 1/0 = 0

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.

kenbellows | 7 years ago | on: Understanding JavaScript Objects

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!

kenbellows | 7 years ago | on: Understanding JavaScript Objects

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
The critical distinction here is between `constructor.prototype` and `object.__proto__`. For exactly this reason, it bothers me a bit that the article uses `Prototype`, with a capital "P", to mean "the thing that `object.__proto__` points to". This is completely different from the `prototype` (small "p") property of a constructor, which is essentially just a holding place for the `__proto__` property of any objects created by calling this constructor with the `new` keyword.

Hopefully that all made sense!

kenbellows | 7 years ago | on: Understanding JavaScript Objects

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'
When you access `sparky.hasSpine`, the JS engine first checks whether `sparky` has an "own property" called `hasSpine`. It doesn't, so it checks `sparky.__proto__.hasSpine`, which is the same as `dog.hasSpine`. No luck, so it checks `sparky.__proto__.__proto__.hasSpine` (i.e. `mammal.hasSpine`), and finally `sparky.__proto__.__proto__.__proto__.hasSpine` (i.e. `vertebrate.hasSpine`), which resolves to `true`.

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

kenbellows | 8 years ago | on: HTML 5.2 Recommendation

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.)

kenbellows | 8 years ago | on: Lindy effect

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

kenbellows | 8 years ago | on: It is easy to expose users' secret web habits, say researchers

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.

kenbellows | 8 years ago | on: Google Has Dropped Google Instant Search

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.
page 1