Ted Blackman (one of the Urbit developers) recently posted a puzzle on Twitter, asking people to describe what a piece of code (written in this phonetic representation) does. [1]
I was delighted to find that I still remembered the phonetic names after first reading of them back in 2013, though I got the exact result wrong.
Quite sincerely, they should just look into running WebKit server-side.
That said, in my experience if Apple has secretly decided they don't like you, they tend to move the goalposts on you in subsequent reviews, so migrating their systems to WebKit may not be time well spent.
It also seems like they were trying to abuse/repurpose OS level functionality (the power button). I imagine that was difficult on Android, and the article completely fails to acknowledge that this is actually impossible on iOS.
We ran some casual benchmarks on this at work once, and it's important to note that the performance of AutoLayout dramatically improves based on the degree of nesting you employ.
If you have sixteen views on a cell and their locations all depend upon each other, it's going to take a long time to solve those constraints. But if you can break up the cell, say into four subviews with four elements inside them, it's likely to be faster (no guarantees, though)
A long time ago I put my Snapper Card (NZ equivalent) in a cup of acetone to get the chip out. I then stuck the chip in the back of my Nokia bar phone.
> It’s no secret that I really like Clojure and as a lisp, it was the easiest language for me to start the prototype with, but there’s no reason this couldn’t be done for any language with a dynamic runtime. The rest is mostly simple analysis of an AST and some clever inference.
I have looked into this. It is kind of criminal that for most real world languages (Ruby[1], C[2] etc), it's not possible to just define a grammar and throw it at a standard parser generator for them - they generally have one or two quirks which make this infeasible.
In my ideal alternate universe it would be considered unthinkable to publish a language without also publishing a grammar in a standard format for said language, which can then be plugged into your favourite text/semantic/tree editor. Our tools should dictate our languages, not the other way around.
"Design hubris" is such a common problem for mobile/front end developers and the source of so much wasted time I'm surprised it's not talked about more commonly. Shit's expensive, man!
I am thankful that these days I get to work with talented designers who know what a UITableView is and understand the limitations of the medium.
As I remember, an early CSS proposal included the Cassowary constraints solver engine, but they decided not to go with it because either a fast implementation didn't exist at the time, or they were worried users wouldn't find the system intuitive?
You must have read about Urbit, right? Their VM's underlying language/bytecode/thing, Nock, is based on nested pairs of natural numbers, which is perhaps only slightly less unwieldy than operating on single bits.
PS, if you're as enthusiastic about this idea as I am, we should talk, can I email you?
I was delighted to find that I still remembered the phonetic names after first reading of them back in 2013, though I got the exact result wrong.
[1] https://twitter.com/rovnys/status/1199958608483684352