HackerLangs
TopNewTrendsCommentsPastAskShowJobs

Arch-TK

3,066 karmajoined há 10 anos
Any sufficiently advanced type system is indistinguishable from an esolang.

---

C++ can remain irrational longer than you can remain sane.

---

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

- C. A. R. Hoare (RIP)

comments

Arch-TK
·há 17 horas·discuss
Look, it's pretty clear to me that you're either not reading half of what I write, or choosing to ignore it. I am not particularly interested in speaking to a wall.

> 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.
Arch-TK
·há 3 dias·discuss
> Are you imagining that there is some way to partially map relations and objects but somehow not go all the way? I admittedly cannot picture what that would look like. What would the purpose be?

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]
I am trying to figure out how your described model maps it from partial information such as:

"user" (user_name) subset:

    ("Fred")
    ("Jeff")
    ("Bob")
"friend" (user_name, friend_name) subset:

    ("Fred", "Jeff")
    ("Fred", "Bob")
Because to "map" this to the object model, your relational mapper would presumably need to do this:

    fred = User("Fred", { User("Jeff", set()), User("Bob", set()) })
But from the above partial information, you don't know if Jeff or Bob have friends.

This breaks down further when you add more to the users tuple set, e.g. let's add a required "surname" field.

    ("Fred", "Robinson")
Now mapping the above would result in:

    fred = User("Fred", "Robinson", { User("Jeff", ???, set()), User("Bob", ???, set()) })
Unlike with the empty "friends" set case, there's _nothing_ you can put in the names which is correct unless you force those fields to be nullable. This is basically unmappable.

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...
Arch-TK
·há 5 dias·discuss
> That depends on the rest of your code.

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.
Arch-TK
·há 5 dias·discuss
Okay, so I have an object like:

    User {
        name
        friends: List<Friend>
        posts: List<Post>
    }
Let's say we have a "MappedUser" which is derived from this type by this ORM.

I now do:

    user = get_mapped_user()
    for post in user.friends[0].friends[0].posts {
        ...
    }
Ignoring "get_mapped_user()" how does our user object work?

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())
Not only is it difficult to conceptualise how this operation would ever meaningfully work for any non-trivial query, it's also difficult to see how it would even work for trivial queries.

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.
Arch-TK
·há 6 dias·discuss
First, it's useful to define terms. When I talk about an ORM I talk about an ideal ORM which transparently maps ordinary object graph access patterns to relational database queries. These do exist, and they exhibit the OR mismatch problem I describe below. Some ORMs instead expose the OR mismatch and try to make the leaky abstraction a first class citizen. I would prefer not to call these ORMs, but it doesn't matter. Lastly, there are "ORMs" which are just query builders + DTOs, these are just not ORMs, but I think they're a great choice when interacting with SQL. You can accuse me of committing a no-true-Scotsman fallacy, and I can accuse you of moving the "ORM" goalposts.

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>
    }
This is a mostly natural way of structuring this data. One natural (albeit contrived) operation might be:

    user.friends[0].friends[0].posts
If you had a reason to do this operation, most people wouldn't think twice about it. There's overhead from the indirection, but nobody would think of this as an excruciatingly slow operation if working with native objects.

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.
Arch-TK
·há 9 dias·discuss
> inconsistent

I have a strong feeling that this person just likes this as a style and enforces it by hand…
Arch-TK
·há 11 dias·discuss
It's okay, completely wrong thread for this statement, but I wouldn't voluntarily use current MacOS (no idea if the older variants weren't terrible) over anything but ssh. Worse than Windows 11.
Arch-TK
·há 12 dias·discuss
The list of "bonus" criteria and how they come about makes me feel sick.

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.
Arch-TK
·há 15 dias·discuss
When I tried implementing something like this at some point, I found it impossible to actually implement reliably because DNS resolution changes all the time.

Unless you dynamically add rules as you resolve DNS requests and before responding to them, which seems painful to pull off.

Or do you point DNS records for the relevant domains at a proxy server, and have that server inspect SNI, look up the actual DNS records, and then tunnel the traffic? But this would rely on SNI which isn't a requirement (although it's probably always there...).
Arch-TK
·há 21 dias·discuss
If you have a thermoblock espresso machine, the brewing part can be over and done with in all of 1 minute.

But either way, the time consuming parts are preparation and cleanup.
Arch-TK
·há 26 dias·discuss
I don't really care about a ban like this, but I do strongly care about exactly how they plan to enforce it. There are technical solutions which are both inexpensive, would be just as effective, and which would fully respect the privacy of all individuals.

But, regardless of whether the push is well meaning or not, the UK government has a historical track record of trying its best to eradicate the concept of an individual having any right to privacy from the government. A significant chunk of the population seems to even believe that wanting privacy from the government is a signal that you are doing something illegal.

People have been making comparisons to 1984 for years, but the current state of the UK should genuinely be raising alarms. It's like they're trying to compete with China for control over their population.
Arch-TK
·mês passado·discuss
Not yet, but for a long time nobody spent years in court because they were particularly rude to nobody in particular on the internet, and then it happened, and the law was there all along.
Arch-TK
·mês passado·discuss
It's gaming communities too. There is a massive mindset overlap between gamers and average UK residents.

They both think that all the dystopia is for the greater good, is never abused, and if you fall victim to it, you must have been doing something dodgy to deserve it.
Arch-TK
·mês passado·discuss
No, just the UK.

I actually think it might be worse.

You need to be able to hand over encryption keys too.

Claiming to not know them is also not allowed, whether you actually know them or not.

I am reasonably convinced that if you wipe the key slots on an encrypted drive but leave encrypted blocks around, they might be able to argue that you are obligates to store all the block keys for such an occasion. So using any kind of multi-tier encryption in the UK might be a massive liability unless you permanently store all the material required to derive any key that is used to encrypt anything.

This also probably has impact on TLS now that I think about it.

Now, real world criminal cases are likely to proceed differently than how they proceed in the mind of a programmer interpreting the law as a program. But, I am not too convinced such a farcical thing wouldn't happen, the UK government and police have engaged in much dumber things.

Now that I think about it, storing randomness on a disk could probably be used to incriminate you in case that disk was seized. Since the police wouldn't be able to tell if it wasn't encrypted data.
Arch-TK
·mês passado·discuss
The rule is that at all times enough return vessels must be docked to the ISS for everyone on board.

These are usually the same vessels they used to get up to the station.

This has the consequence that if they need to re-dock one of the vessels (for whatever reason) all the astronauts that would normally use that vessel must board it for that menuvre. Just in case it fails to dock again.

And they don't normally have spares.

IIRC, this is a good video on the topic: https://m.youtube.com/watch?v=82YHM12n2JI
Arch-TK
·mês passado·discuss
I mean, yes, the lace quality is important too. But strictly speaking, not tying a granny knot will improve your results regardless of choice of lace.
Arch-TK
·mês passado·discuss
This seems equivalent to some arguments I hear for practicing a religion.
Arch-TK
·mês passado·discuss
Google has been optimized for sentence like questions so much that for a good 6+ years now it has been completely useless as keyword search.

To clarify: sentence search got slightly better at the cost of keyword search. So the result is unusable garbage.
Arch-TK
·há 2 meses·discuss
"to tweak" is probably quite far away even if "get a semi-decent CAD drawing" was remotely reliable which it isn't.
Arch-TK
·há 2 meses·discuss
Are you implying that we shouldn't be annoyed at Flock and forced GPS tracking in cars because my ignorant neighbours have a cloud connected doorbell?

Because I am instead annoyed at all three.

Not necessarily my neighbours, but the companies selling this spyware.