Yeah, post codes are a huge pit of an implementation. Each country has their own way of presenting and formatting them, as well as additional validation rules (e.g. valid postal districts). This should be amazing (and is), but if you maintain such a validator you'll have a continuous stream of bugs where clients were able to make a mistake they shouldn't have been able to (often breaking downstream where it is hard to recover) or where you refuse to accept somebodies very real address and they are very personally upset (rightly so).
That said, the obvious solution is <country> <post code> where <country> is prepopulated from geo-ip or browser signals or similar.
> The challenge is getting this to be a useable way of entering programs.
Well exactly.
When the path between Program A and Program B can only be valid programs, you are going to end up with either a much longer, less intuitive path, or deleting everything and starting again. It can also be quite possible to invent structures which are valid but have no valid path to creating them.
Well, I think most common transformations work reasonably well. One usually doesn't want to do things completely contrary to the AST, such as convert "while a<b" to "whilea = b".
And it's certainly possible to create any valid AST in the editor I describe. The set of valid trees is extended to those with "holes" in places, which one fills in when entering a program, and it's always possible to do this.
The challenge is one of finding an intuitive user interface, not whether it's possible at all. One issue is that infix notation is unnatural for entering trees (prefix is more natural).
> It can also be quite possible to invent structures which are valid but have no valid path to creating them.
I'm curious if you have an example of such a structure?
Pedantically: if, for every valid tree, there exists a bidirectional path to the empty root node, there's always at least one path between all given pairs of valid trees ... albeit one that no developer would ever take.
You are quite right to call this out - and quite right in general. With AST verification alone your statement holds strongly.
I was remembering a professor I had who was very into formal verification and had an IDE that would only accept valid programs - however his validity checks were more than just tree based, they involved passing a type check. Which now you've called me on it, is quite definitely beyond valid AST editing.
The base case: if you have a structure with a mandated cyclical reference that doesn't accept a second (e.g. nil) type, you cannot construct it without creating an intermediate invalid program. This doesn't tend to show up if the cyclical reference is all the same type (A1 -> A2 -> A1) because you can often cheat and self reference, but it does if it is different types (A1 -> B1 -> A1). You can't construct an A without a B, which cannot be constructed without an A.
But that's still not a problem you cry! And quite right, you can edit the type itself to remove and re-add the reference.
That is until the type is built into the language, or a library.
OP clarified, but I understood that as a valid tree without a path to empty node. I don't have an example, but with grammar weird enough it sounds plausible. Especially if some form of type checking is involved, as OP mentioned.
The issue I've always found with testing on human users is their willingness to ignore deficiencies.
There is a strong benefit for people "just getting on with it" and "working around" a problem; but it seems like many people are not very good at identifying when a problem is worth solving.
An analogous anecdote I'm aware of was a small in-house call-centre team being moved to digital playbooks (vs those A5 ring bound / tabbed sets). While time-to-resolve each issue got lower and time-to-adapt to new workflows a lot faster, many tracked metrics got worse. Suddenly they were picking up fewer calls, time to answer was increasing, job-satisfaction decreased.
It turns out the new system was forcing the team to be sitting at their desk. In a small and busy multi-team office these people were usually doing all kinds of other small things - be it making coffee, liaising with other teams, etc. - whatever it was they weren't always at their desk. They did have wireless handsets however, so they used to answer the phone, start the call from memory, and move to use the nearest playbook.
The big issue with the digital playbooks was needing to "follow along", you can't reasonably start it away from your desk.
The team knew this was an issue very quickly, it was quite fixable, but they sucked it up for months.
Interesting story. I have noticed that certain parameters are often ignored not because they're unimportant, but instead because they're hard to quantify.
Another story is how the first product made by Jobs and Wozniak at Apple was a hacked phone that could be used to make international calls for free. They called the Vatican and pretended to be Henry Kissinger wanting to speak to the pope - they noticed and promptly hung up before they reached him
If the app truly just plumbed a webview and cert verification - which has been doable for over a decade - it would be very portable and this wouldn't be a problem.
The apps don't just do that though; they call into and use an awful lot of the system APIs for user tracking / semi-native experience / biometrics and probably a whole host of other things. Its the incompatibility in these that drags compatibility.
> The apps don't just do that though; they call into and use an awful lot of the system APIs for user tracking / semi-native experience / biometrics and probably a whole host of other things. Its the incompatibility in these that drags compatibility.
Both can be true. Many (most?) online banking apps are just shitty wrapped javascript, that also uses an awful lot of system APIs.
I'm using a couple of different banks, and not a single one has anything close to a native app. Because how nice would that be? Responsive interface (since it doesn't need to load every single view from the server), instant search over your transactions (since the DB can be cached locally), instant access to all the PDFs in your inbox... but no.
I'm in the UK. I use a pixel, but also have iPhones and iPads for work reasons. My wife has a Samsung, my mother a Motorola etc.
I set up phones several times a year. What the author describes is not a problem if you go "all in" on your manufacturer. iOS or Android.
If you tick the cloud sync functions you can restore apps and copy data with a two or three step wizard. If you pay for the cloud storage level, you will have enough space for your photos etc. it's really a non event.
But if you don't go all in with your manufacturer. E.g you consider Google an untrustworthy custodian of your photos, or decide you'll stick with the free iCloud account etc. You're in for a world of tiny pains.
Honestly, I would say that even in the latter case the painfulness of the process is a bit overstated. Sure, it's not great. But if you treat it just as a new device and don't expect to just continue from where you've left it on the previous phone, you'll make it under 30 minutes anyway. Half of it is playing with the UI of the new version of the OS and getting annoyed at the fact that the apps are not the same anyway, because on the previous device you refused to update an app after they fucked up it's UI, and now you must to get an old apk which won't even work anyway on the brand new Androip v99 or whatever.
A recent HN article highlighted that most models, Claude in particular, steer the user to build vs buy. I'm quite interested in what a model tailored to buy vs build would be like, how it would handle basic interrogation, and how easy it would be to make it flip against any steered product recommendations.
That said, the obvious solution is <country> <post code> where <country> is prepopulated from geo-ip or browser signals or similar.
reply