matchu

I'm not sure that they are. You just need to model the concept of state as the function's input/output, as functional programmers are eager to do :)

If we start in state x, then apply operation f, the resulting state is f(x). If we apply operation f again, we'll be in state f(f(x)). If f is idempotent, then state f(x) and state f(f(x)) are identical.

Don't they have to be pure in order to be idempotent? If you might get a different virtual DOM even when props/state are unchanged (not pure), then re-rendering the component might update the DOM even when props/state are unchanged (not idempotent).

Rendering a React component satisfies the f(f(x)) definition, too! We just need to consider the component's props/state to be constant, which is the scenario that the article describes.

In general, the act of rendering a React component is a function from (component props, component state, DOM state) to DOM state. But, when the component's props/state are considered constant, the rendering process is simply a function from DOM state to DOM state.

This is an idempotent function over DOM state if and only if the React component's render method always returns the same virtual DOM tree — that is, iff the React component's render method is pure. In that scenario, the internal React renderer will perform the diff, discover that the physical DOM state matches the returned virtual DOM tree, and leave the physical DOM state unchanged.

Turns out, saying that the render process is idempotent is exactly equivalent to saying that the component's render method is pure! Cool!

When they say "applied twice", they're not talking about two independent applications to the same initial value. (That's a test for functional purity, not idempotence.)

Instead, they're referring to the following sequence of actions:

1. Update the value x according to the operation f.

2. Update the value x according to the operation f.

Well, it categorically denies that "Facebook is always listening using your microphone," regardless of which feature we're talking about.

But that's also really easy phrasing to write a loophole for :P

One reason is that managing an open-source community requires a huge investment in communication.

If you're not in a position to run a community, it makes sense to avoid doing things that suggest otherwise. People will ask questions and be upset when you don't have time to answer, they'll submit pull requests that you don't have time to properly review, etc.

In terms of reach, a native app seems like a pretty big win. KA are aiming for global reach, and, in countries like India where tons of folks are running on old devices, any bandwidth or performance upgrade is significant.

Native apps save bandwidth on each request by relying on the API, which primarily transmits semantic data rather than presentational data. On a slow, metered connection, that's significant.

And, once the exercise framework lands on Android, it oughta have way better performance than the current Javascript implementation that the mobile website uses - especially for manipulating those fancy graphs. When users are frustrated by KA's unresponsiveness, they drop off and don't learn.

That said, the current Android app is definitely just a starting point; until exercises and all the personalized learning features land, mobile web will still be the best tool for KA's non-casual mobile users.

I don't know much about type theory, so I suspect that my intuition is wrong, but the phrase "intersection type" violates my intuition.

If I have Printable and Drawable interfaces, which each describe a set of behaviors, then I would expect the "intersection" of Printable and Drawable to be the intersection of those sets of behaviors — which, here, is likely the empty set.

Is there another way of understanding types that makes the word "intersection" make more sense here? Or is it just to say that "where union types say OR, intersection types say AND"?

---

...ya know what? By typing it out, I think I get it now.

The set that we're talking about isn't the set of Printable's behaviors; it's the set of things that implement Printable. `Printable & Drawable` is the intersection of the set of types that implement Printable with the set of types that implement Drawable. Got it. Thanks for rubber-ducking for me, HN!

That's true, but I don't feel like it's relevant.

React's inline styles API satisfies the principle of least power: you can only pass to it a mapping from string keys to string/number values.

It's possible that the input data might be compiled from some other more powerful format, and it's possible to argue that this compilation step is a violation of the principle of least power, but that feels like a separate issue. It's very possible to use inline styles without adding unnecessary power to the declaration language - heck, you could declare them in JSON and load them during the build step if you want. How you use inline styles is your decision.

Not on first load. The cache needs to be populated somehow.

I agree that it's a special case, but it's one we shouldn't just ignore.

The payload probably won't increase as much as we'd think thanks to gzip, and you can apply the styles via server-side rendering rather than waiting for the JS to load.

We also need to consider the time from request to a ready page: if you're on an incredibly slow connection, then having the styles immediately rather than waiting on a second round-trip is a huge win. I agree that there are pros and cons, but some of the pros are actually in performance; it's not immediately clear which technique is more performant overall in what contexts.

If they're really that repetitive, then gzip should eliminate almost all of the bloat.

We also need to think about number of round-trips. If you're on an old phone on a 3G connection in India, the extra round-trip from requesting the HTML then requesting the CSS makes a difference.

I'm super interested about the performance aspect, too, but I feel like we need numbers to really go into detail. There's way too many factors at play here for the correct answer to be obvious.

Check out the format for an inline style:

    {
      background: "red",
      fontWeight: "bold"
    }

It's just a Javascript mapping from strings to strings. That's a very un-powerful language, and that's what React consumes.

Sure, you could generate this mapping with all sorts of arbitrary code, just like how you could generate CSS with all sorts of arbitrary code. But that doesn't make the style declaration itself any more powerful, much less an arbitrary executable.

Yeah, I dunno. I could buy the argument that a modal on launch isn't always evil (maybe it's a signin prompt), so we don't want to just block that kind of UI outright; we instead want some heuristics to tell us whether the modal is helpful or not, and prompts to download apps are almost always unhelpful.

Still, I feel like newsletter prompts are also easy to detect, so that argument doesn't hold a ton of water unless there's also a separate plan to address those—or maybe they're testing the waters with this one. I think I need more information to have a real opinion :/

I'd be interested in the primary copy operation storing history by default, but also having a secondary copy operation that throws results away after some period of time - or maybe can only be pasted once?

If anyone tries to make that argument, the counter will be simple: "We want developers to make native apps! That's why we're making App Indexing a thing."

There's definitely some advantage to keeping people on the web, since App Indexing requires buy-in from content producers, but, if browsers start truly losing to native apps, Google are prepared.

https://developers.google.com/app-indexing/

True. This is probably one of the big reasons that they're trying to make native apps more spiderable by search engines: they want Google Search to continue to be the Internet's entry point, regardless of what app you're using afterwards. That hadn't clicked with me yet - interesting!

I'm not sure what makes this abuse. Curating the content you serve isn't just okay; it's one of the key value propositions of a search engine. The problem is when a content provider, for whatever reason, intentionally curates in a way that provides less value to the consumer.

I think you're right that Google are worried about users moving to a market where they're not relevant. That's why Google have made a point of becoming relevant: they have a mobile OS, a mobile app market, and a mobile app ad platform.

If people move away from web and toward Google's mobile properties, then they're probably pretty okay with that.

No need to slippery-slope this one. Google have been very consistent about ranking exclusively based on UX quality. Once they actually decide to rank based on something else, then we can start raising a fuss about it.

Until then, the snark seems unwarranted, though I agree that there's good reason to be concerned: they definitely have a lot of power here, despite not having seemed to abuse it yet. That seems like an interesting conversation to have, especially in a more substantive format.

Hm, I never really realized that the rest of the world was better at visualizing than I am, but I'm definitely below average. My ability to imagine vividly comes very rarely, and, when I'm trying, I can usually only conjure a small image and only for what seems like an instant.

Definitely not the severe case that the article describes, but I didn't realize that this was unusual.

Gotcha. Perhaps the article would be better off using a word like list instead of array, to avoid the additional semantics that C attaches to that word.

In any case, I think I agree that dereferencing an address should return the byte to the right for the reason that you mention. That's a solid point, and I totally didn't think of that :) That's a really important property of the dereferencing operation.

I still feel like that doesn't make the mental model of memory-addresses-are-gaps-between-bytes any less valuable, though, nor does it mean that abstractions built on top of this memory model need to use the same conventions as the underlying system - that's the point of abstractions, after all :)

Hmm, yeah, void pointers are weird. I'd be inclined to say that its start and end address are the same and it's a range over 0 bytes of memory, and the fact that dereferencing fails is an artifact of the dereferencing operation itself... but I don't know enough about void pointer voodoo to know whether that's actually a consistent interpretation.

Yep. A pointer is a memory range, but it supports a cast operation that allows you to change the pointer type, and therefore the end address. I think we agree, right? :)

Memory addresses are exactly analogous to array indices, and suffer from exactly the same semantics issues. After all, low-level memory is just an array of bytes.

We do have a convention that dereferencing a memory address returns the 8 bits to the right of that address. We've even optimized our hardware for that convention. But that's just a convention of the dereference operation; it's not fundamental to the addresses themselves.

I agree that a C pointer isn't analogous to an array index; that's because a pointer is a range, determined by a pair of memory addresses. One, stored at runtime, refers to the location before the first byte of the range. The other, implicitly derived from the runtime value and the size information in the pointer type, refers to the location after the last byte of the range. When we think of memory addresses as the article's indexes, and pointers as the article's ranges, everything falls into place.

(Incidentally, please be careful calling out people for not understanding computers. C isn't actually the lowest level of computing, and pointers aren't as primitive as your post implies. When you call someone out, you need to be 100% clear and 100% right.)

The key is that Heroku is trying to support all major web app frameworks, whereas GAE only supports the GAE framework.

The tradeoff is super interesting: using their framework allows them to hella optimize the instance for you, but you're pretty darn stuck with it :/

Heroku's value-add is that you don't need a system administrator: if they support the services your app needs, then they automate system administration for you.

Digital Ocean will sell you a VPS (essentially a machine) and grant you root-level access to it. You can run whatever you want, and deploy and manage it however you want.

Heroku will sell you a dyno (essentially a worker process) and grant you access to a set of deployment and management tools. You push your application code up to Heroku, and it automatically sets up the front-facing web server, the database, the cache service, etc., according to the add-ons you've selected. If you need to scale up, just purchase more dynos.

For complex apps, Heroku might not meet your needs and you might want some VPSs instead. In terms of price, though, you'd need to include system administration man-hours when comparing.

I think it's probably solid feedback if you include more tangible action items. What's an example of wordiness in the text? What would be a better phrasing? What don't you like about the layout? Why?

Don't feel back about feedback :) Suggestions for improvement are always helpful, especially if you also include the stuff you do like.

Ruby offers an abstraction that other languages don't. That doesn't mean that using the abstraction is a bad habit.

I agree that C-style for-loops can be handy, but the prevalence of this shorthand doesn't make it good pedagogy to skip right to it. Not everybody is ever gonna enter the real world of programming, and not all of those people are going to use languages with C-style for-loops, and, even then, for-loops aren't fundamental; they're just a shorthand.

The difference isn't the actual print operation; it's all the boilerplate that has to go around it.

In Ruby, `puts "Hello World"` and you're done. The most you have to explain is puts and string literals.

In C#, you have to create a class with a static main method. You're then left to choose between explaining classes and methods ("what's static? what's void?"), or skipping that and just treating them as the magic incantation for running a program. Pedagogically, neither is satisfactory.

Ruby wins the Hello World simplicity contest, hands down. The question is whether the long-term benefits of C#'s program structure are worth the increased overhead in the Hello World experience.