andymatuschak

An unannounced project. Certainly this thread would be more interesting if I could point you to an app or even a codebase!

What are you finding weak? There are certainly quirks, but I'm enjoying it relative to the alternatives!

I can't suggest anything, I'm afraid—I haven't worked with Windows and Linux targets using React Native. But it appears that there are React Native rendering targets for Windows and Linux (https://github.com/Microsoft/react-native-windows and https://github.com/status-im/react-native-desktop). I'd probably start by looking there.

And of course, because React Native can build to web, one could ship Electron apps for platforms with lower priority for your business.

You can already use React Native to deploy to macOS, via Catalyst. I'm doing it now.

There's a lot of discussion in the comments here about Electron vs. native apps. But last year's Catalyst project, which allows you to ship iOS-based projects on the Mac, opens an important new path. I've been surprised not to see many people discuss it!

In particular, this means that you can use React Native to build native macOS apps. You still get live reloading, hot code push, pleasant abstractions, etc. Most importantly, though, these apps can use straight-up AppKit controls on macOS and straight-up UIKit controls on iOS. Better still, you can use react-native-web to ship such projects on the web too.

You will+should, of course, have many platform-specific branches. But I find that the vast majority of my code is shared, and there's a _world_ of difference in being able to use the same development tools to ship polished software on desktop, mobile, and web.

My most recent project builds to macOS, iOS, Android, and web out of the same Typescript project. There was certainly some toolchain chicanery involved in this, but now that it's set up, it's delightful.

Many of the companies shipping Electron apps on desktop are shipping React Native apps on mobile. I would very much like to see React Native-based desktop apps replace Electron apps.

FWIW: I'm one of the co-authors of the article, and I worked at Apple during the early App Store years, but I saw no evidence of this. Based on my experiences, I believe the current situation is more a function of neglect and distraction than anything intentionally orchestrated.

Hi there. I'm one of the article co-authors, and I was definitely one of the Photoshop-anchored designers agitating for Adobe to add UI-centric design features. I think you're right that it was enormous mistake to leave this market open. Unpacking how this comment relates to the claim in the article:

That section's claim is that these mediums are often common goods, so it's hard to build moats around one's investments. Extending your comment to more explicitly attack the central claim, I think you're suggesting that if Adobe _had_ paid attention to this market, they'd be able to defend their position, and Sketch/Figma never would have been relevant. Maybe they would have been able to more quickly create a "spinoff" app because they could adapt existing code, or maybe they could take advantage of their existing network effects (e.g. through educational channels). And, more broadly, that the general claim is weaker than it appears: media inventors can often find ways to defend their turf through mechanisms like this.

That might be true! It's hard to adjudicate counterfactuals like this. I'd be curious if you have any lenses that might help us think about that. Given that we're on Hacker News, I'll offer: one reason why startups often outcompete incumbents is that line extensions like this are counterintuitively often _harder_ for the well-resourced incumbents because of inertia, culture, etc.

Indeed, that's a nice way to frame my thesis. Or maybe even more directly: what if books were shaped such that "reading a book" meant "doing SQ3R to a book"?

Yep, I think we're aligned on all this! One lens on my aspirations is to create a "stable" of "moves" like "including figures" which can be applied contextually to better align with the way readers think and learn.

Gotcha. Yep, I'm sympathetic to this view.

Research stemming from Piaget suggests the need to introduce information not authoritatively but rather in response to "disequilibria"—authentic intellectual needs in the listener/reader. Of course, good authors can also work to create these disequilibria.

Do you think that the presence/lack of this intellectual need is the highest-order bit? That is: if you really have questions you want answers to, you're not going to have any trouble absorbing what you need, no matter the medium's shape? I guess I see it as a both-and situation!

(Author here) You're right that the piece would have been better if I'd done this. But if it helps, my co-author and I did it here: https://quantum.country.

(Author here) You might be amused to learn that I actually have looked into prospects for technologies around learning in one's sleep. Unfortunately, things don't look great. But you might enjoy this paper, on learning smell–sound associations during sleep: https://www.nature.com/articles/nn.3193

To your central point: you're right that effortful engagement is a hugely important ingredient for learning, so we shouldn't aspire to simply remove effort. But do you think that there's nothing that can be done in an explanatory artifact to support the knowledge construction process you're describing? To make it any easier, at all?

Just as an intuition pump, imagine comparing 1. Euclid's Elements, with no figures; 2. Euclid's Elements with figures. Does the latter addition ease knowledge construction? If so, why wouldn't we expect it to be possible to take more steps of the same kind?

> There might be a fundamentally novel and strictly superior way of learning, but it's hard for me to see which cognitive bases aren't covered by combining these two methods.

(Author here) I agree that methods like the ones you've described are indeed quite effective when executed successfully. I argued in the piece that this kind of process is often blocked on metacognition. That is: the reader has to regulate and monitor the processes you're describing while simultaneously grappling with new concepts. It's a lot to ask. And of course, the medium doesn't even explicitly ask it of the reader: when people do these kinds of methods, they're instigating that independently.

Even if we limit ourselves to just these methods, can't we imagine a medium which is somewhat more involved in the methods we claim are essential to understanding?

And if we accept that, one more provocation: wouldn't we want authorial intent to carry into the use of these methods? Given that the author is already carefully sculpting so much of the rest of the reading experience, why wouldn't we benefit from them extending their authorial direction to the metacognition around the book?

Thank you for that kind synthesis, Ivan. Speaking of learning APIs: I'm a fan of your use of concept maps in your books!

Author here; this is a great point and I’m grateful for it. Maybe we shouldn’t expect to absorb such knowledge!

That said, if the theory is that books’ knowledge is absorbed through concrete use, why is the book so uninvolved with facilitating or interleaving with that concrete use? I’d suggest the impetus and regulation of the concrete use (and its relationship to the book) is all on the reader. Does that align with your thinking?

You’re right that I don’t treat motivation seriously enough in this piece. It’s very true that you will absorb nothing from a book which you do not read.

The framing which drove me was: isn’t it odd that even readers who are quite motivated to read a book still often absorb fairly little?

It’s true! I tried to evoke that paradox with the Sagan quote. On a relative basis, it’s remarkable what they’ve achieved. On an absolute basis, thought, it’s surprising how unreliable the medium is (and hence all the more spectacular that they’ve achieved the results we enjoy!). If the medium achieved these results while as unreliable as it appears to be, how much more could readily be achieved?

This Shopenhauer quote is quite apt; thank you for the thoughtful response. One wondering: to what extent is information a prerequisite for insight?

That’s very kind; thank you.

This is helpful feedback; thank you!

Very glad you're enjoying that! While we've explored some of the possibilities in this space in the essays here, it does feel early to standardize: lots we're still excited to explore in purpose-built contexts first. :)

One of the authors here. While the study schedule is regulated by algorithm, the questions themselves were hand written. We have found it’s quite difficult to write good questions, needs lots of revision and thought. Glad you enjoyed!

> Or a free app that is just done as a thank you to the community that has supported them over the years? What would be wrong with this?

That would be a very expensive thank you for a tiny business! Given Panic's level of polish and concomitant development timelines, I expect this app took several months of a designer's time and at least six months of an engineer's time—probably more like nine. Then QA, support, etc. I'd guess we're looking at a >$150k price tag here, plus ongoing maintenance.

As to paying for itself via bringing new users into their customer base: given the average sale price of their desktop software, this iOS app would have to generate several thousand net-new sales. That doesn't seem wildly outlandish to me, but I'd guess one order of magnitude fewer is more likely.

Khan Academy | Mountain View | Full-time

At Khan Academy, we’re building an early product development team which will explore and propose solutions to big open problems in education. We’re looking for a couple new prototyping-and-invention oriented colleagues to join us, and we naturally thought of you all. Our approach is multidisciplinary, but we’re seeking depth in interaction design (https://boards.greenhouse.io/khanacademy/jobs/825531) and scrappy prototype engineering (https://boards.greenhouse.io/khanacademy/jobs/825502).

For an idea of our work: we’re currently exploring how we might support students in developing rich understanding through open-ended, free-response-style activities (rather than the typical fill-in-the-blank or multiple-choice). We hope to help millions build critical thinking, historical reasoning, and literary analysis skills.

Here are a few reports on more conceptual exploratory projects from some of the folks involved: https://www.khanacademy.org/research/reports/cantor and https://www.khanacademy.org/research/reports/early-math

Please let us know if you’re at all interested in chatting more about the roles (andy@khanacademy.org). Thank you!

Khan Academy | Mountain View | Full-time

At Khan Academy, we’re building an early product development team which will explore and propose solutions to big open problems in education. We’re looking for a couple new prototyping-and-invention oriented colleagues to join us, and we naturally thought of you all. Our approach is multidisciplinary, but we’re seeking depth in interaction design (https://boards.greenhouse.io/khanacademy/jobs/825531) and scrappy prototype engineering (https://boards.greenhouse.io/khanacademy/jobs/825502).

For an idea of our work: we’re currently exploring how we might support students in developing rich understanding through open-ended, free-response-style activities (rather than the typical fill-in-the-blank or multiple-choice). We hope to help millions build critical thinking, historical reasoning, and literary analysis skills.

Here are a few reports on more conceptual exploratory projects from some of the folks involved: https://www.khanacademy.org/research/reports/cantor and https://www.khanacademy.org/research/reports/early-math

Please let us know if you’re at all interested in chatting more about the roles (andy@khanacademy.org). Thank you!

These are both wonderful pieces of news! Thanks for sharing.

One other big contributor to app size we've noticed at Khan Academy: extensive use of value types, particularly ones whose fields require more than a couple words of storage.

The big picture observation is that for value types with storage larger than a few words, several instructions must be emitted per call and per storage word because they cannot be passed-by-value in registers. And Swift often emits more calls than you can see (e.g. thunks, protocol witnesses, weak sentinels, etc). This is not new to Swift—the same requirement exists when passing large C values around—but we use value types a lot more in Swift for various reasons, so the issue becomes more salient.

In terms of remediation, I audited our app for all structs larger than a few words. I just did this manually; there were something like 120 structs to look at. For each, I converted it to a class then evaluated the impact on generated code size. Only four structs had meaningful impact on generated code size (to the tune of ~13MB), and happily, they were fully immutable, so they retained their value semantics even when converted to classes. If they had not already been fully immutable, I would have had to spend some time either adapting the classes to achieve value semantics, or adapting their clients to tolerate reference semantics.

Then I audited our app for all enums larger than a few words. These can be made pass-by-reference by using Swift’s `indirect` feature, which implicitly boxes associated storage. We had one enum for which this made a substantial difference, to the tune of several MB.

Then I had to make sure runtime performance hadn’t been too badly damaged by all the new dynamic allocations and indirections. In the end, I observed nothing noticeable. We don’t have formal repeatable performance tests, though—it would have been interesting to see the impact on those.

C++ has this issue, too; it largely handles it by using reference arguments when consuming large stack values. In the future, it’s possible for Swift to optimize many cases (especially intramodule) where this occurs by allowing deeper stack frames to reference values types stored in parent stack frames when it can prove it’s safe. Rust has a lot of fanciness here you might find interesting!

Historically, one of the key dangers with using unprefixed names has been that future system updates add new classes which collide. Testing at dev-time won't future-proof you very well.

The non-interactive content should mostly work in the iPad app. iPhone is trickier.

This is a tough area for us in general, unfortunately.

We've been pretty insistent on colocation for internships in particular, just because we think synchronous and serendipitous interactions are really important in these kind of apprenticeships.

But I'd love to be wrong and discover a way to achieve the same quality of results remotely and asynchronously.