Tuesday, June 26th
This excellent read was sent to me recently by a friend. There’s a lot of amazing quotes throughout. Here’s just a few that caught my eye.
It is probably not an accident that the agglutinative languages all seem to have been instigated by committees, and the crystallization languages by a single person.
Philosophically, Smalltalk’s objects have much in common with the monads of Leibniz and the notions of 20th century physics and biology. Its way of making objects is quite Platonic in that some of them act as idealisations of concepts–Ideas–from which manifestations can be created. That the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is a-kind-of Manifestation-Idea–which is a-kind-of itself, so that the system is completely self-describing– would have been appreciated by Plato as an extremely practical joke [Plato].
In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole–like data structures, procedures, and functions which are the usual paraphernalia of programming languages–each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computer all hooked together by a very fast network.
…my emotional involvement has always been centered on personal computing as an amplifier for human reach–rather than programming system design–and we haven’t got there yet.
I have a lot of strange nostalgia for the early days of computing and the internet. It's especially strange considering that I wasn't alive for most of it. Either way, I appreciate the idealism and, in some ways, naïveté regarding how computers would eventually be used and misused.
Thursday, June 21st
Before React Native can render for the first time, you must initialize its runtime. Unfortunately, this takes several seconds for an app of our size, even on a high-end device.
A common misconception is that React Native allows you to move away from writing native code entirely. However, that is not the current state of the world. The native foundation of React Native still rears its head at times. For example, text is rendered slightly differently on each platform, keyboards are handled differently, and Activities are recreated on rotation by default on Android. A high-quality React Native experience requires a careful balance of both worlds. This, paired with the difficulty of having balanced expertise on all three platforms makes shipping a consistently high-quality experience difficult.
Although I don't have any real experience with React Native, both of these points seem like dealbreakers to me.
I'm always hesitant to recommend a framework like React Native that is not officially supported by Apple. Especially when Apple can operate mysteriously and suddenly. It's quite possible (however unlikely) they could ban all apps from the App Store made from frameworks such as React Native.
Furthermore, I think there's a lot of cases where branded apps across platforms should behave and meet the interface guidelines of each platform. Sharing model and data code is nice (in which case, C/C++ is pretty cross platform…), but I have a hard time believing that views and UI should be identical. To me, that would just be the lowest common denominator of experience across all supported platforms.
In addition, personally, I'd rather write Swift than JS.
More: mjtsai.com, hackernews, medium/airbnb
Friday, June 15th
It’s very difficult to recommend much from the current crop of Macs to customers, and that’s deeply worrisome to us, as a Mac-based software company. For our own internal needs, we’ve wound up purchasing used hardware for testing, rather than opting to compromise heavily on a new machine. That isn’t good for Apple, nor is it what we want.
This is the most frustrating aspect to me: potential customers who have the means and will to buy new machines but because of stagnation in the hardware roadmap it would be absurd to spend a large portion of money on a computer with out-of-date hardware.
Their current failure to keep the Mac lineup fresh, even as they approach a trillion dollar market cap, is both baffling and frightening to anyone who depends on the platform for their livelihood.
Frightening indeed. I even dug up one of my old tweets from 2016 with an eerily similar "Do not buy" recommendation.
Wednesday, June 13th
At the end of the day, Dark Mode isn’t a brave new era for macOS, but it is a welcome addition to the system. It’s an option that I’m already enjoying on my test system, and I think I’ll move to it full-time this fall when macOS Mojave ships. It’s clear that Apple has put a lot of thought into the feature, and I think most Mac developers will be onboard with what it means for their applications.
Until all apps are recompiled against the 10.14 SDK, I suspect opening an older "stuck in light mode" app on 10.14 will be like someone turning on the lights in a dark room during a movie.
Wednesday, June 6th
While I’ve enjoyed many of the upsides of the Omni approach, I’ve also had the opportunity to really appreciate the many downsides. You might say it’s “a pretty sweet solution” for offering free trials.
I think it’s particularly important, in the face of all the celebration this week about Apple’s perceived changes to the App Store, to appreciate all the many ways in which this solution falls short of what many developers still hope for: bona fide support for real free trials in the App Store.
It would be nice to have better guidance from Apple on this, or even a StoreKit / iTunes Connect API for free trials. It feels a little odd and loose that their guidance is basically just as follows:
Non-subscription apps may offer a free time-based trial period before presenting a full unlock option by setting up a Non-Consumable IAP item at Price Tier 0 that follows the naming convention: “14-day Trial.”