Arch-TK
So is it now their official policy that to have a bank account with them you must own a phone that can run their app?
I really don't get how your excuse worked, but I am guessing this is a made up policy and the fact it's a charity made them think twice about being assholes about this.
The average banking app is not about convenience, it is about restricting how a user can access their account, compliance box ticking and an endless march towards minimising liability at all cost. Meanwhile people are getting mugged and moving money at knifepoint because the device they normally carry around everywhere with them is now a gateway to their bank account.
I only run apps that are open source, or that I can audit and that don't abuse Android's silly features to restrict me, and only when the app isn't a requirement to access or interact with something. For example I refuse to buy any hardware which requires a proprietary app to use a feature.
I think the HSBC app qualifies as malware but I'm morbidly curious how bad South Korea's version is...
I use GrapheneOS, but if you as a bank want to gate access to my money via some kind of technology, you better be including it as part of the account.
For example, HSBC continues to let me manage my bank account via the web browser, and continues to offer a battery powered hardware token as the means of authentication.
I let you hold my money, for whatever reason. Why do you expect me to be your distributed infrastructure provider? I am not going to let you require that I run your proprietary malware in order to access my own money.
The idea where you are effectively _expected_ to constantly provide free compute for companies to run their complete garbage on hardware _you own_ just for the privilege of giving them money is one of the most absurd trend in recent times.
I'd say that JS webapps are the same but at least there you run things on your terms in a sandbox that you can inspect and look at the requests, and there's no effective enclave carved out of your hardware (except for EME but that's another topic for another day and I'd be complaining if banks started to use it too).
Yeah, unfortunately the UK isn't a country, it is actually a circus, so you can't apply any regular logic, you must apply circus logic.
It's incredibly disappointing to see people constantly complain about the actually _reasonable_ implementations (that don't rely on a loss of privacy for adults _or_ children).
Sending a mangled `text/plain` part in a `multipart/alternative` (when you could simply omit it) is the email equivalent of having a store that advertises that it sells Amish-compliant items, but the only compliant items on sale are hand-painted wooden boards that say, "Sorry, we don't sell Amish-compliant items."
Don't want to go out of your way to cater to the Amish? No problem. That's not what the post asks of you; the post simply asks you to stop claiming to do so.
There are also some devices which advertise ZigBee compatibility but the manufacturers don't seem to test them against coordinators other than their own (and ConBee 2 seems to have the most problems in this regard).
The protocol is complex, they all are, implementing it correctly isn't a given, but I think the issues people have are more often a factor of how long a protocol has been in use than any fundamental aspect of it.
As soon as cheap hardware manufacturers get on board you get this problem.
Quality hardware works fine with ZigBee. It's by no means perfect technology, if you want that, use copper wires, but it doesn't work as badly as you claim if you are not unlucky with coordinators and devices.
* Title
* Brief
* Table showing the issue
* Notes about CSS/JS disparity
* An idea for why it happens.
* The idea/code for a solution.
This could just be:
Chromium allows websites to figure out your OS using math functions
Chromium's implementation of Math.tanh and CSS trigonometry functions since version 148 uses the host libc implementation. This is a problem because libc implementations vary between operating systems and can produce slightly different results on different platforms (and potentially even different versions of the same platform). This can be used to accurately distinguish between Linux, MacOS and Windows.
Here's a table showing the issue with Math.tanh:
...
For javascript, so far it's only Math.tanh that uses the system libc, the rest of the functions are implemented in V8. But for CSS it's worse, all functions use the libc versions.
Since math should be deterministic, it would be an improvement to privacy as well as platform uniformity to have V8 implement tanh and have the CSS use those implementations too. <side>Notably there are also some quirks in Web Audio. ...</side>
Here's some code which when compiled with `-ffp-contract=off` will produce the same MacOS result on all the other platforms Chromium supports. One option is to just unify the results, another is to make them match the claimed platform.
...
---
It took me 10 minutes to draft the above. With the effort it probably took to prompt that blog post, you could probably get it proofread, generate the table if you have access to the right boxes but don't have it already. And produce the right code with a test harness, verify it.
It's a lot shorter, but that's because the post doesn't really have that much content. There's huge quantities of fluff, the entire "Four Traps" section is so incoherent that I still don't get what it's trying to say after trying to read it 4 times on two different occasions.
It's an important topic, and I am glad you wrote about it, but even half a page of notes would have been enough to convey this. It would save me literally skim reading headings just to get past all the fluff.
> I claim nothing about "bare bones", so, again, you must clarify what you mean by it before I can do anything with it.
I shouldn't need to spell this out, but I am not insinuating anything negative or positive about your approach by calling the description you gave initially as "bare bones". I am simply using "bare bones" as a shorthand to refer to your definition of ORM.
You are claiming that implementing an ORM doesn't require query building, I am claiming that it does. I am calling your proposed ORM that doesn't require query building "bare bones", just as a shorthand to avoid saying "ORM that doesn't do any query building". I hope this makes things clear for you.
> That's up to the implementation to figure out. ORM isn't a specific algorithm. Is that the source of your confusion?
We are talking about _an_ ORM. As I clearly stated in my original comment, and as is being described in TFA. _An_ ORM is a tool which presents a "relational" database's (e.g. PostgreSQL, SQLite, MariaDB, ...) contents as an object graph. With the _external_ relationships (as in the relational model) modelled as _internal_ relationships (as in object graphs).
I am not talking about abstract "object <-> relational mapping" in a vacuum, I am talking about the specific thing that people mean when in 2026 they say "I am using an ORM".
> Whereas SQL does not.
SQL centres around bags of tuples, so you are indeed right that it's not quite truly relational, as was Codd, as I acknowledged. But that doesn't make any impact on what people mean when they say "ORM" in modern day programming parlance. So please stop appealing to an irrelevant definition.
> Relational databases are natively relational, not just able to represent relations.
What do you think this even means? The fact that SQL has bags of tuples just means that if you want it to follow a relational model, you must merely ensure that you enforce these bags to be sets. At this point the remaining complaints by Codd don't have an impact on the fact that, insofar as you don't hit those specific niche limitations, you are faithfully representing a relational model at least in your data.
Relationships in the relational model are not internal, they are external. This is one of the reasons for the OR mismatch. It's counterintuitive that object graphs represent relations internally, and relational models do so externally, at least when phrased like that, but it's inherently true.
The fact that graphs represent relationships also doesn't make graph databases or object databases relational. I would have assumed this was clear from what I wrote so far, but as I already established, I suspect you're not actually reading half of what I am writing, so it maybe isn't so surprising that you think I am ignorant of these things.
If I only read select paragraphs of what Codd wrote, I might also think that he was ignorant of his own model, but instead I kept reading what he wrote until I was confident in my understanding of it. I suggest you do the same if you wish to have a productive conversation on any topic online.
I am asking _you_ what _you_ are trying to claim here.
If you have a class such as:
@dataclass(frozen=True)
class User
name: str
friends: set[User]
"user" (user_name) subset:
("Fred")
("Jeff")
("Bob")
("Fred", "Jeff")
("Fred", "Bob")
fred = User("Fred", { User("Jeff", set()), User("Bob", set()) })
This breaks down further when you add more to the users tuple set, e.g. let's add a required "surname" field.
("Fred", "Robinson")
fred = User("Fred", "Robinson", { User("Jeff", ???, set()), User("Bob", ???, set()) })
I am asking how _your_ idea of an ORM which doesn't handle querying (or if you want to use relational terminology, evaluating relational algebra expressions) works. Presumably you will claim that it will only map data which is mappable, which is wonderfully useless. But then you're just describing the concept of mapping, and not "an ORM" which is a tool which handles this concept for you.
> No. SQL is not for relational databases. This is most obviously observed by the fact that SQL is centred around tables instead of relations.
This is a weird argument. Relational data doesn't centre around relations, it centres around sets of tuples, the relations are an external concept which makes interpreting the dataset useful.
> Codd, inventor of the relational model, spent a lot of time writing about why SQL isn't relational if you want a more in-depth technical explanation
E. F. Codd complained that SQL databases aren't a faithful representation of the relational model, and that's accurate. His complaints were with the following (cited verbatim):
"
* Flaw No. 1: it permits duplicate rows in relations;
* Flaw No. 2: it supports an inadequately defined kind of nesting of a query within a query;
* Flaw No. 3: it does not adequately support three-valued logic, let alone four.
"
Regardless, their use of "tables" has nothing to do with whether they're relational or not. Codd's complaints are to do with the fact SQL databases use bags instead of sets, that SQL doesn't perfectly represent certain relational semantics because the language was rushed and half-assed, and that they handle MAYBE (NULL) half-assedly and lack support for "inapplicable" values.
The thing to note here is that these flaws, if fixed, would have no impact on the OR impedance mismatch, or the ORM problem.
> but suffice to say that ORMs and SQL are not directly compatible.
You are making an appeal to definition here, specifically the definition of the words "Object", "Relational", and "Mapper". "ORM" is itself a marketing term which was coined at some point in the 90s. This was to describe an approach people were taking to trying to map objects in languages such as C++ to _tables_ in "relational databases" of the time.
The relational databases which were being mapped had tables because that's what the papers of the time[^1] talk about.
The earliest paper I can find that talks about "mapping" describes it in terms of query generation and proxy objects[^2]. Although it does describe a "Light Object Mapping" approach which distinctly doesn't model relationships or use query generation, and uses "basic objects" (which do not actually represent an object model, and are instead just data transfer objects (DTOs)). But what "Light Object Mapping" means here is specifically: "just write your own SQL and map it to DTOs by ahnd" rather than describing any automated approach for the problem, which is precisely how it's the only option that gets away with not having a query generator.
It's kind of funny seeing how far back the "impedance mismatch is imaginary" mindset reaches, because it's present in this paper too. A paper which then goes on to explain the significant complexity of this problem and brushes over many of the even harder parts.
[^1]: http://infolab.stanford.edu/pub/keller/1993/sigmod-93-persis... [^2]: https://www.freeengineeringbooks.com/Ebooks/objectRelational...
No, I am asking about your hypothetical "bare bones" "ORM" which explicitly _doens't_ have anything beyond "object mapping".
> When your code merely does that, what do you call it?
Certainly not _object_ mapping. It's something between regular "data mapping" and "completely worthless." If the thing you get out of it is not something representing an object from your object model.
> ORM alone is not sufficient for these patterns.
You are talking about a definition of ORM which is at odds with any definition of ORM that I am personally aware of.
Classical ORMs focus almost entirely on providing proxy objects which represent your object model and which back accesses with additional queries.
> Unlikely. SQL is mentioned in the headline for a reason. Nobody uses relational databases in the real world.
SQL is a query language for relational databases. Unless you have another definition for "SQL" or "relational database" which is at odds with common parlance.
> I understand why you might think a relational database is necessary given that ORM stands for Object Relational Mapping, but as ORM operates on data, not databases, the data can be relational even if the backing database isn't. It simply becomes another mapping step to see them become compatible.
While certainly an ORM maps between an object model and a relational model, the fact that this could be done with something other than a relational database seems completely irrelevant to anything in this discussion.
You seem to be taking the term "Object Relational Mapping" splitting it into its constituent parts, looking at the definitions of those terms, and then assuming that the definition for the whole term is just a simple combination of the individual terms.
This is akin to me claiming that OOP doesn't require a programming language or computers, and can merely involve me buying or otherwise procuring a bunch of things (objects) and then setting them up (programming) in the form of a Rube Goldberg machine in order to perform calculations.
My earlier statements regarding the example code existed to point out that the mere act of taking some relational data and somehow converting it to objects in your object model is not "mapping" in any meaningful sense because the resulting objects would be incomplete, and in some cases would not even be able to be constructed from arbitrary relational data.
The mere act of instantiating a partial object graph from relational data is _not_ "ORM", in the same sense that writing and calling functions is not functional programming.
User {
name
friends: List<Friend>
posts: List<Post>
}
I now do:
user = get_mapped_user()
for post in user.friends[0].friends[0].posts {
...
}
What happens when I access `.friends`?
Does it give me an empty list, because I didn't ask for it?
I am not aware of anything that calls itself an ORM which merely does:
user: User = map_from_relational_to_user(query_user())
ORMs, at their core, try to abstract away something like `user.friends[0].friends[0].posts` more or less into some underlying queries against a relational database. The main distinction between them being in the availability and first-class nature of the escape hatches when this operation inevitably becomes slow.
Relational databases can represent graphs, and graphs naturally have relations, but in your OO language you can make choices about how to traverse an object graph based on external state, and such traversal is incremental and dynamic. Relational databases can have recursive queries, and these can be used to traverse graphs, but the shape of the query has to be known up front. Recursive queries can be dynamic over database state, but not over arbitrary external state. Even assuming some incredibly deeply integrated super-ORM, it's easy to imagine how programs that operate on graphs _and_ can be automatically mapped to an efficient set of relational queries are a limited subset.
This is the fundamental object-relational mismatch. You can use escape hatches, or you can contort your code, but every time you do this, you have to accept that you're no longer "mapping" in the transparent sense that ORMs were supposed to provide.
I think probably the easiest way to get an intuitive sense for the problem is to consider a simple object graph model:
User {
name
friends: List<User>
posts: List<Post>
}
user.friends[0].friends[0].posts
Now, how do you create an object that is backed by a relational database while still transparently letting you perform object-graph traversals such as the one above? It's easy to see how `User` would need to be an object with a `name` field. Since the data is recursive, you probably don't want to eagerly load all friends and posts, so you'd have proxy objects that make additional queries when you access them.
It's easy to see how this leads to the classic N+1 style issue. You have your user, you load their friends. Maybe your proxy object is smart enough to only load only their first friend. You end up making a bunch of additional queries after the first one to load the user. Especially when your database is on a disk and large, or accessed over the network, you can see how this quickly gets out of hand.
In the object/graph model, the relationships are _internalised_. They're represented _within_ the object. But in the relational model, relationships are external. To "map" from one to the other efficiently, you can't just represent things as objects with some glue, because you keep running into these "look ahead" issues. When you access user.friends or even user.friends[0], your mapper has no way to know what you're going to ask for next.
Of course, one way to solve this would be with deeper integration or a DSL. Let's say you had a query language which can represent the above query, and then you analyse this query to try to map it efficiently to a relational query. Sounds like we've solved the problem? Well kind of, yes. Except we're no longer mapping the object model to the relational model. A given query leaves you with dead objects, you've just delayed the problem while leaking abstractions. You can add proxies to those but you're now back to square one except you've maybe improved performance a little bit.
ORMs build queries for you, but a query builder does not need to be an ORM.
It's not a matter of "fractional speed difference" unless your database has very few entries. OR mismatch problems often like to appear shortly after your database starts to see any real use.
The only performant way to use an ORM is to use escape hatches everywhere. Alternatively, you can use an "ORM", something which calls itself an ORM while only doing superficial data mapping into dynamic or generated native (to your language) data structures. There are a _lot_ of these, most normal people call them query generators.
I have a strong feeling that this person just likes this as a style and enforces it by hand…
I am not currently looking for employment, nor am I currently particularly worried about future prospects if I was suddenly in the position of looking for employment.
But if I ended up in a position with nothing to lean on but scattering my CV everywhere, well…
A lot of my major contributions are littered across the internet, private, or even just verbal/consultancy. They're things I did for free, in my spare time.
I also avoid GitHub. If you just look at my GitHub page for extra context, you would likely miss that delivering that very GitHub page likely involved a few bits of code I wrote.
Now, I could do a better job of trying to document this stuff, so it could be easier to find… But also I can't quite imagine how that would work.