> the lack of parentheses for function calls plus currying means that to read a function call, you need to already know how many arguments the function takes
While I agree with the general sentiment of what you are saying, note that the syntax has nothing to do with it, it is purely about Haskell using currying excessively. The syntactic translation between Haskell and JS is straight-forward and 1-1:
f x y z -> f(x)(y)(z)
f x (y,z) w -> f(x)(y,z)(w)
I agree that excessive currying is not great, and generally push for non-curried arguments unless a curried form realy is used in practice. But for this to really be comfortable, and to still enjoy all the hgiher-order programming that's nice with Haskell, we would need good records (strucural, anonymous, extensible), which it doesn't really have right now, so we are stuck with currying.
Yes, you could write the same thing, but defaults and language conventions matter. Writing curried functions in JavaScript is awkward enough that nobody does it by default. If you did, people would ask why in a review.
I agree, I also renewed my passport recently and the website and process is quite smooth. It's the more complex cases, first requests from abroad, etc., that lack automation.
> although I don’t really see why it was relevant anyway, my son’s Britishness is derived from my Britishness, her nationality and the nationality of her parents is essentially irrelevant
This is essentially happened to me, the "75% of the initial doc requests turned out to be irrelevant" was referring to this sort of thing.
If you don't have a legal father then you can't claim British citizenship through your father. That's all pretty straightforward. (Although there's a fun case where you can claim citizenship by double descent because your ancestor wasn't able to claim citizenship because of sexist historical laws).
Weirdly this never came up for me (and I'm in a similar situation). I suspect what documents are ask for varies a lot by who is assessing the application.
> Tonight we were wondering why nobody had identified the flight which caused the UK air traffic control crash so we worked it out. It was FBU (French Bee) 731 from LAX/KLAX to ORY/LFPO.
> It passed two waypoints called DVL on its expanded flight plan: Devil's Lake, Wisconsin, US, and Deauville, Normandy, FR (an intermediate on airway UN859).
> Bearing in mind this is likely decades old C code that can't be rewritten or replaced because the entirety of the UK's aviation runs on it.
It's new code, from 2018 :)
Quote from the report:
> An FPRSA sub-system has existed in NATS for many years and in 2018 the previous FPRSA sub- system was replaced with new hardware and software manufactured by Frequentis AG, one of the leading global ATC System providers.
That's true, but then, why did engineers try to restart the system several times if they had no clue what was happening, and restarting it could have been dangerous?
That's super interesting (and a little terrifying). It's funny how different industries have developped different "cultures" for seemingly random reasons.
It was terrifying enough for me in the gig I worked on that dealt with reservations and check-in, where a catastrophic failure would be someone boarding a flight when they shouldn't have. To avoid that sort of failure, the system mostly just gave up and issued the passenger what's called an "Airport Service Document": effectively a record that shows the passenger as having a seat on the flight, but unable to check-in. This allows the passenger to go to the airport and talk to an agent at the check-in desk. At that point, yes, a person gets involved, and a good agent can usually work out the problem and get the passenger on their flight, but of course that takes time.
If you've ever been a the airline desk waiting to check-in and an agent spends 10 minutes working with a passenger (passengers), it's because they got an ASD and the agent has to screw around directly in the the user-hostile SABRE interface to fix the reservation.
It's better to say SABRE replicated, in digital form, that card file. And even today the legacy of that card form defines SABRE and all the wrappers and gateways to it.
While I agree with the general sentiment of what you are saying, note that the syntax has nothing to do with it, it is purely about Haskell using currying excessively. The syntactic translation between Haskell and JS is straight-forward and 1-1:
I agree that excessive currying is not great, and generally push for non-curried arguments unless a curried form realy is used in practice. But for this to really be comfortable, and to still enjoy all the hgiher-order programming that's nice with Haskell, we would need good records (strucural, anonymous, extensible), which it doesn't really have right now, so we are stuck with currying.