With paper books I'm more concerned with having to have space to put it when I'm done. But, I find it more enjoyable to read a physical book, and am more likely to re-read it.
Another nice thing about paper books is that you can lend them out to your friends when you're finished reading them. This saves a bit of space, plus your friends can just pick them up and read them without worrying about a bunch of BS like whether it's compatible with their e-reader, if the DRM will work, if the publisher will revoke the rights for some reason, etc.
Or give them away, or leave them in a little free library for someone else to enjoy. In my old neighborhood somebody else had similar taste in scifi and (as far as I could tell) we traded Asimov books back and forth through the book box in the park!
I'd love to keep them all forever but (a) I think my house is about maxed out on shelves and (b) a book's potential is wasted on the shelf.
That has always been a pain point for me. I read a lot, so having physical copies can turn into a storage problem, especially since I keep a good backlog of books. I may not need a new book now, but I found one at the store that looks really good, so I buy it, place it on the shelf and it enters the queue. Although I did get myself used to using a kindle. Especially when I was in the Navy and needed enough to read for a 7 month deployment.
My current strategy is this. If its a book I know that will have re-read value that I really enjoy. I get a physical copy (such as LOTR). If its an interesting book that I want to read, but I don't see it as having high re-read value, I buy it on my kindle. May not be logical, but its a system that works for me so far.
Get the ebook for archival purpose and ditch the paper book when you’re done with your first read through.
If you later find out you want the paper book as home ornament, then spend a little extra to decorate your home.
The two major mistakes we make about books is:
1) we think we have to finish it. No, drop it if it’s boring.
2) we think we have to keep it around. No. Take a picture and write a few notes for your personal blog if you need to keep track. You don’t need it in your room or house.
In a good organization, there will be several layers of people owning failures of different types. The low level manager can claim ownership of failure to sufficiently manage expectations, their manager can claim ownership of failure to prioritize properly, and a yet higher level leader can own failure to provide funding.
It's about shielding the team from the consequences of failure. A good manager will say "If my team failed it's because I did not prepare them well enough/lead them well enough/manage expectations well enough". this is what ownership looks like. It is orthogonal to probability of failure.
I think a better way to phrase this is that judges should be punished in instances of gross negligence or malfeasance. An innocent person going to prison or early release in which a criminal commits another crime, on its own, does not necessarily imply this.
Smart developers both know SQL well, AND use ORM's.
Sure ORM's are not going to write the most optimized code by default, and they're not going to build indexes for you, etc. But they are a huge productivity enhancer and work well enough for a lot of the queries you're going to need. Most ORM's these days have advanced options too which enable the more fine-tuned use cases without having to drop into raw SQL.
Your second paragraph reads more like you are talking about query builders rather than anything in the domain of ORM. ORM happens after the query has executed and you have a relation already in hand. Everything that happens before the relation is made available is outside of the ORM purview.
Some ORM toolkits bundle query builders as a secondary feature, but they are still logically distinct features.
The only reason ORMs are relevant to this conversation at all is because they include query generation. The vast majority for popular ones do that - one that I know of that doesn’t (dapper) labels itself a “micro ORM” because of it.
ORM never includes query generation. Some libraries often include both ORM toolkits and query builders, but that's like calling sorting 'encryption' because libraries often include functionality for both. That would be quite silly, and confusing for the reader.
ORM is the act of mapping relations (sets of tuples) to objects (graph structures). How could query building be a part of that?
There are ORM toolkits that help produce the code to perform that mapping to save you from doing it by hand (although you can do it by hand, if you so wish!), but not even they could shove query building in the middle. Query execution has to happen before ORM can take place. You cannot perform ORM until you have the relation already in hand. (Mutation cases are in reverse, but I know you are capable of understanding that without it spelt out in detail)
What would it even mean for ORM to include query building?
If I'm reading you right, you seem to be saying that database helper libraries often include both query building and ORM toolkit features, usually along with other features like database migration management. Which is very much true. But why would you call one feature by the name of another? If you call query building ORM, is ORM best called database migration?
No...? The assertion about being able to understand the reverse case went out to anyone reading the comment. This is clearly a community forum, not some kind of private messaging system. Comments are not directed towards anyone in particular.
Stop and think. If you actually did somehow mistakenly believe it was a one-on-one with another person, why would you but your head into the conversation? That would be completely illogical. There is a curious contraction here.
You can rephrase it that way, sure: "After all this (being explicitly told that there is an inverse case), you still weren't capable of understanding what was written."
The first half of your comment does not logically precede that, though. There is no such implication.
You're the only person I've encountered that has expressed a strong opinion that the query building part of an ORM should be considered separate from the rest of the ORM.
Do you have any examples of open source ORM libraries that stick to the terminology you are advocating here? I've not seen one myself.
Maybe this is partly an ecosystem thing. What ecosystems do you mainly work in? I'm primarily Python with a bit of JavaScript, so I don't have much exposure to ORM terminology in Java or C#.
Irrespective of naming, can we at least agree that there are, at minimum, two completely different features being spoken about here?
1. A feature that prepares a query to send to the database engine.
2. A feature that transforms data structures from one representation to another.
And we agree that these are independent? You can prepare a query without data transformation, and you can perform data transformation without preparing a query? I think we can prove that, if you are still unconvinced.
Okay, so that just leaves naming. What should we call these distinct features?
Here are my suggestions:
1. Query building. Building a query is the operation being performed.
2. Object-relational mapping; ORM for short. Mapping objects to relations (and vice-versa) is the operation being performed.
These descriptive names seem well suited to the task in my opinion, but I am open to better ideas. What have you got?
Now, there is something else in the wild that we haven't really talked about yet, but may be that which that you are alluding to. Another abstraction, or pattern if you will, that rests above (to use my suggested terms, bear with me) both query building and objet-relational mapping to unify them into some kind of cohesive system that actively manages records. This is where it starts to become sensible to consider (again, using my suggested terms for lack of anything better) query building and ORM intertwined.
I would suggest we call that active record. In large part because that's what we already call it. In fact, what is probably the most popular and well known active record library is literally named ActiveRecord, so-named because it was designed after the active record pattern. But, again, open to better ideas.
> What ecosystems do you mainly work in?
Python, Javascript (well, Typescript, if you want to go there).
My mental model of what an ORM does is that it provides you with an object-oriented API that disguises some of the underlying mechanics of how the SQL queries work.
That's an object-oriented API that builds a query that looks something like this:
SELECT
"blog_entry"."id",
"blog_entry"."created",
"blog_entry"."slug",
"blog_entry"."metadata",
"blog_entry"."search_document",
"blog_entry"."import_ref",
"blog_entry"."card_image",
"blog_entry"."series_id",
"blog_entry"."title",
"blog_entry"."body",
"blog_entry"."tweet_html",
"blog_entry"."extra_head_html",
"blog_entry"."custom_template"
FROM
"blog_entry"
WHERE
(
"blog_entry"."created" >= "2021-01-01 00:00:00"
AND NOT (
EXISTS(
SELECT
1 AS "a"
FROM
"blog_entry_tags" U1
INNER JOIN "blog_tag" U2 ON (U1."tag_id" = U2."id")
WHERE
(
U2."tag" = 'python'
AND U1."entry_id" = ("blog_entry"."id")
)
LIMIT
1
)
)
)
ORDER BY
"blog_entry"."created" DESC
After executing the query it uses the returned data to populate multiple Entry objects (sometimes with clever tricks to fill in related objects so they don't have to be fetched separately, see select_related() and prefetch_related().
But the bit that builds the SQL SELECT query and the bit that populates the returned objects is pretty tightly coupled.
That is what was described originally by the active record paper. Traditionally it has been called the active record pattern, but if we'd rather call that ORM today, despite the misnomer, so be it. I couldn't care less.
But, I do care about being able to precisely communicate with other people. What are we going to call the other things?
> Smart developers both know SQL well, AND use ORM's.
> But they are a huge productivity enhancer and work well enough
I disagree with the implication that using an ORM is the default that 'smart developers' always choose.
Good developers choose the right tool for the job, so the tool selected depends on the job.
Also, what the term ORM means (and its effects on the design) vary based on language ecosystem and library. For instance, if the application doesn't need to dynamically navigate relations, and instead can get by with just treating the database as a set of structs, an ORM like Hibernate would probably introduce more complexity than it gives benefit. In such cases, a library like Jooq or JDBI could make the overall design simpler, perform better, and make it easier to reason about the behavior of the system. I would argue those are not ORMs, yet they can yield a better product, depending on the situation.
It's Pareto principle at play, in RL you usually need to highly optimize just a very small portion of the queries - let's call it 20% for the sake of tradition, though it's realistically <5% IME - to get almost all of the speed-ups worth the trouble. ORMs then help you to write the other 80% quickly and in a maintainable fashion.
ORM's allow you to make changes without having to refactor every single SQL statement you've written manually. They can also be typed, unlike raw SQL strings, which helps a lot during development. It's another abstraction, just like the one between your language of choice and assembly code.
Manually writing queries has a lot of overhead cost. Your entire application now has the UI directly tied to what the query returns. You can make intermediate classes to separate the two but eventually you'll end up making a worse ORM you need to test and maintain.
What an ORM gives you is a tunable level of abstraction. I know Ruby on Rails best so I'll use it as an example. ActiveRecord has a lot of tuning you can do, like partial selects and snippets of sql where you need it. If that isn't enough, there is find_by_sql as an escape hatch. If that is still not fast enough, you can call ActiveRecord::Base.connection and skip the ORM entirely.
This will keep complexity limited to places where it needs to be complex.
In my experience, every level of optimization you do comes with decreasing maintainability.
> Your entire application now has the UI directly tied to what the query returns.
Not really. Without ORM, your entire application is now tied to sets of tuples (i.e. relations) instead of rich graph structures (i.e. objects), but the relation need not be equal to the relation returned by the query. You could still have a transformation from one relation to another.
Not since the PHP days of embedding MySQL calls right in the middle of HTML have I seen anyone carry relations from end-to-end, though. The idea that anyone is not doing ORM these days seems like a straw man.
> Not really. Without ORM, your entire application is now tied to relations (i.e. sets of tuples) instead of rich graph structures (i.e. objects), but the relation need not be equal to the relation returned by the query.
And, in some edge-cases, the relation is more useful than the object graph.
It can be, but in real applications only a small percentage of queries are performance problems, and you're probably better off optimizing those than writing and maintaining hand written queries.
It's a higher level abstraction that that boosts dev speed and readability and is often good enough by default, esp. for CRUD work. More advanced ones have the ability to optimize things fairly well within the constraints of their API.
And it's not one or the other. There's always an SQL escape hatch when you need one for complex queries.
Yes. Every mature ORM that I'm aware of includes tools to trivialize fetching related records in an efficient manner. All people typically have to do is call the right method. In Django, for example, these methods are select_related and prefetch_related.
Also, they don't have to be slow. When benchmarking my hobby golang ORM, I found the performance cost vs hand writing optimal SQL to be in the microseconds per returned row. Small price to pay for everything it gives you: schema migrations, query builder, object mapping, validation, etc. And if you happen to have a particularly hot endpoint that needs to return tens of thousands of rows at once during a HTTP lifetime, you can always dip back down to the driver level.
It pains me that every time the topic of ORMs come up on HN that the comments are full of people warning not to use such a powerful category of tools. Maybe the tools they are using aren't very mature, maybe the underlying technologies are bit dated, maybe the documentation doesn't emphasize performance enough. I'm not really sure what's going on. Hopefully we can improve things so fewer people have issues and instead see performance improvements from using ORMs.
I haven’t seriously used an ORM for the simple reason that I find SQL simple enough to not need to learn an extra DSL to hide it. Furthermore, when I’m done figuring out the query I need in a Jupyter notebook (technically Google colab, should be same), I can just paste it to the C++/Go server or the dashboard config. Raw performance didn’t ever matter that much to me.
With all this: is there an ORM with documentation that’s good at explaining what would I gain over plain old SQL?
Have you ever used a rapid development framework like Django or Laravel? A good ORM is basically the core of any decent backend framework that interfaces with a RDBMS. You get to define a schema once which can then be used as a foundation for migrations, validation, queries, serialization, etc. Many ORMs may only help solve one or two of those things well, and in personal experience it is rare to see even okayish JavaScript ORMs, which may contribute to why people hate the category of tools.
Flask is okayish imo. People tend to use it with an ORM called sqlalchemy. There is also FastAPI as an alternative to Flask and Django in the Python web framework space. Just about anything can be used for small projects in a vacuum. I used to make websites with framework-less PHP files and mysqli.
Absolutely this - the attitude of “never use an ORM” is an immediate red flag for me in a developer, indicating that they don’t understand the capabilities of a wide variety of ORMs and the trade-offs involved.
I think “never use X” is probably a bit far. But personally I can’t really think of a situation where I would rather have an ORM.
I used to use them all the time. When I started doing pure FP I just realized I just didn’t really need my old ORM. When I came back to OOP languages (out of necessity, not pleasure), I realized I didn’t really need my old ORM there either.
It’s not a strong opinion and it’s not a religious thing, it’s just a different perspective whereby you see that something isn’t really necessary.
Benefits or not, you do pay quite a heavy price for the ORM, and I think most people don’t see this price because it has been normalized so much.
While my article reads like an anti-ORM manifesto, my warning is about relying on ORMs to do all the work. How am I supposed to understand advanced fine-tuning options if I do not understand how the low-level query works?
Copilot may be your little helper in writing code, but it is not going to consistently write the best code that YOU can write.
It already works with SMS, though. You can choose to use 3rd party apps like WhatsApp. I fail to see how users are meaningfully "locked-in" any more than an android
Teens get bullied if they show up as green bubbles in group chats. I've had people tell me they wouldn't want to show up as green bubbles to potential romantic partners. The iMessage lock-in effects are real.
This isn't about regulating what content American citizens are creating. It's about regulating the involvement of adversarial foreign governments to distribute that information. These are quite separate concerns.
>regulating the involvement of adversarial foreign governments to distribute that information
How is that any different than say Press TV, whose website and media are not banned and are freely viewable in the US because we have freedom of expression?
If TikTok is propaganda, they have to register as foreign agent, which they haven’t, so that will make them illegal.
However, I don’t see them being propaganda yet, but technically they can be overnight by download a new model from headquarter (and even without US user data leave US soil). The bill is trying to stop that possibility.
I don’t feel it morally sound to punish someone for sth they haven’t done yet. But what do I know? Reading many here and on Ars, most are actually thinking the two country are at war, so they can do anything to each other
I don’t think we are at war, but if enough people believe that way, does it matter?
Distributing propaganda in the US, even as a foreign country, is allowed by the 1st Amendment. Americans have a right to receive information. This bill is trying to stop something Americans have a right to
I think there's probably no way we can trust the data isn't going to China. This is China we're talking about.
But I don't even think the real problem is videos of high school girls doing choreographed dances going to China. The problem is psyops and disinformation. I think it's much more likely TikTok could be, and probably has been, used to sow political discord. It's not hard to imagine the Chinese government "suggesting" to TikTok that they alter their algorithm to promote content that, say, discourages people from voting, or promoting political violence, or eschewing vaccinations.
I think any challenges to this bill on Constitutional grounds would likely fail due to Congress' powers to regulate interstate commerce, to which SCOTUS has been pretty deferential.
The book "Kind of Blue: The Making of a Miles Davis Masterpiece" by Ashley Cole is great if you're into this album.
One of the most notable things about this album is that, while there were a few false starts, they used the first complete take for each track, which is astounding. I personally think it's the greatest achievement in the history of music.
It would have been quite expensive to try for a second or third take. You're paying for the room, for the tape, and for at least one engineer and probably another guy, and except for the tape, it's all per hour.
They had likely played together enough that they planned to just do one take unless there was a hiccup.
The thing about this album though was that it used a groundbreaking style of playing in a single mode, no chord changes. This was completely counter to anything ever heard in the jazz world before. Nor had they practiced these songs before. For them to sit down and record what they did, the first time, is pretty unbelievable.
reply