nercury

I hope the wages of sales people are lower than that of a calculator.

Extremely small island that stretches from New York to Atlanta..

If someone spent their time learning their tools, they will make better choices when writing the code without any additional time cost.

There are two variants of very similar code. Both do the same thing, both are readable and maintainable. The difference is not primarily in performance, it's in quality of craft.

Anything you say or do will be used against you by any future government. What's legal now, might not be legal tomorrow, and you will be jugged by your AI "friend". Welcome to dystopia.

The real threat is AI arguing/competing with itself and wasting 90% of world's power.

This is more of a preference for bridge to be visible in application. Also the bridge may seem simple at first, but it also may gain associated data, like created_at, order, etc.

Yes, I would not put it just anywhere. But I have few rules about ORMs:

- Proper DB design first. You should be able to remove the ORM and DB should still function as intended. This means application-side cascade operations or application-side inheritance is banned.

- No entities with magical collections pointing to each other. In other words, no n to n relations handled by ORM layer. Create in-between table, for gods sake. Otherwise it becomes incredibly confusing and barely maintainable.

- Prefer fetching data in a way that does not populate collections. In other words, fetch the most fine-grained entity and join related data. Best if you craft special record entities to fetch data into (easy with EF or Doctrine).

- Most ORMs allow you to inspect what kind of queries you create. Use it as query building tool. Inspect queries often, don't do insane join chains and other silly stuff.

I would use ORM in one kind of app: where I would work with data that shares records that might need to be either inserted or updated, and there is several nesting levels of this kind of fun. You know, you need to either insert or update entity, if it exists, you should update, and then assign related entities to it, if it does not, then you should insert, and assign related entities to the newly created id. The ORM can easily deal with that, and on top of that it can do efficient batched queries, which would be really annoying and error-prone to hand-craft.

If the app does not require this kind of database with these kind of relations, I would not use ORM.

Yeah, in a web app, one context per request. In desktop app... I have never used EF there.

Pardon me for the tangent (just a general comment not directed to OP).

What I have learned over the years is that the only way to properly use ORM is as a fancy query tool. Build the query, fetch/update data, MOVE THE DATA to separate business objects. Don't leave ORM entities shared across the sea of objects!

Phew, thanks, I got that off my chest.

struct Node<'a, 'b, 'c> { data1: &'a Data data2: &'b Data data3: &'c Data }

Wow. It's like teaching C++ and starting from SFINAE. Or C# and starting from type parameter constraints.

Please think of a real-world examples when teaching stuff. I am very eager to see the program a beginner would need to write that requires: 1) references in a struct; 2) 3 separate lifetime parameters for the same struct.

It's like destroying a factory when the chips it produces do not sell.

Corporate prioritization is the ultimate cookie cutter, doomed to produce the most generic thing possible.

If AMD did not come up with 64-bit extension, we would be saying goodbye to x86 architecture.

This sounds like "You aren't having fun properly".