The first half of the cited quote seems to suggest that LOC is a bad measuring unit, so I think it contradicts the premise of the article. It's also worth noting that optimizing for LOC usually comes at the expense of readability, maintainability, and testability. In practice, these are far more valuable than brevity.
There is an argument to be made for performing operations in the database when they are the sort of operations that the database is designed to do. As that is a performance optimization, it can be difficult to know when it is worth doing. So your best bet is to do the things that make it easier to work with your program for as long as possible. Moving your logic into the database to save LOC is not one of those things.
Great article, thanks! Blender has been on my radar forever. You've given me another reason to check it out!
The Greater Hartford Python Group would love to have you as a guest speaker (or member)! If you're interested, you can contact me at myfirstname.mylastname at gmail.
The first half of the cited quote seems to suggest that LOC is a bad measuring unit, so I think it contradicts the premise of the article. It's also worth noting that optimizing for LOC usually comes at the expense of readability, maintainability, and testability. In practice, these are far more valuable than brevity.
There is an argument to be made for performing operations in the database when they are the sort of operations that the database is designed to do. As that is a performance optimization, it can be difficult to know when it is worth doing. So your best bet is to do the things that make it easier to work with your program for as long as possible. Moving your logic into the database to save LOC is not one of those things.