Slightly tweaked, a leaderboard of em dash containing comments after ChatGPT release, limited to users who used them in fewer than 1% of comments before ChatGPT release, and who posted at least 200 comments before and after ChatGPT release. Data is recent (August 28th).
Of course this doesn't mean they're using ChatGPT either, they could've switched devices or started using them because they felt like it.
WITH by_user AS (
SELECT
`by` AS user,
COUNTIF(text LIKE '%—%') AS match_count,
COUNT(*) AS total_count,
(timestamp >= '2022-11-30') AS after_chatgpt
FROM `bigquery-public-data.hacker_news.full`
WHERE type = 'comment'
GROUP BY user, after_chatgpt
),
combined AS (
SELECT
user,
MAX(IF(NOT after_chatgpt, match_count, 0)) AS match_before_chatgpt,
MAX(IF(NOT after_chatgpt, total_count, 0)) AS total_before_chatgpt,
MAX(IF(after_chatgpt, match_count, 0)) AS match_after_chatgpt,
MAX(IF(after_chatgpt, total_count, 0)) AS total_after_chatgpt,
FROM by_user
GROUP BY user
HAVING total_before_chatgpt >= 200 AND total_after_chatgpt >= 200
),
with_fractions AS (
SELECT
*,
SAFE_DIVIDE(match_before_chatgpt, total_before_chatgpt) AS fraction_before_chatgpt,
SAFE_DIVIDE(match_after_chatgpt, total_after_chatgpt) AS fraction_after_chatgpt
FROM combined
)
SELECT
user,
FORMAT('%d/%d (%.0f %%)', match_before_chatgpt, total_before_chatgpt, ROUND(fraction_before_chatgpt*100)) AS before_chatgpt,
FORMAT('%d/%d (%.0f %%)', match_after_chatgpt, total_after_chatgpt, ROUND(fraction_after_chatgpt*100)) AS after_chatgpt
FROM with_fractions
WHERE fraction_before_chatgpt < 0.01
ORDER BY fraction_after_chatgpt DESC
LIMIT 15
Since it's mention-undocumented-endpoints day, https://news.ycombinator.com/latest?id=$ID does that, where $ID can either be a story (in which case you get the entire thread sorted reverse-chronologically) or a comment (in which case you get the comments in that subthread).
Ruby has method aliases. Python does not allow a string to capitalize itself.
Ruby uses Ruby methods within Ruby classes to extend Ruby. Python has decorators so you can write functions that return functions that return functions to create a new function.
Ruby has strict object-oriented encapsulation. Python is laid-back about objects, because you probably know what's going on inside them anyway.
Ruby lets you leave off parentheses so you don't miss objects having attributes too much. Python will let you mix tabs and spaces for indentation, but passive-aggressively mess up your scoping as punishment.
Ruby has seven kinds of closures. Python has one, in the unlikely case a list comprehension won't do.
Ruby's C implementation is a mess of support for language-level flexibility. Python's C implementation is so clean you get the unsettling thought that you could probably write Python using C macros.
Ruby supports metaprogramming for cases when programmers find it more descriptive. Python supports metaprogramming for cases when programmers find it necessary.
Ruby is expressive. Python is direct.
Ruby is English. Python is Esperanto.
Ruby is verse. Python is prose.
Ruby is beautiful. Python is useful.
I like Python, but coming to it after using Ruby for seven years, well, I think it's like dog people and cat people. You can like having one species around, but you're always thinking -- why they can't be more like the other?
I find these “shorter work weeks are just as effective” articles to be nonsense, at least for knowledge workers with some tactical discretion. I can imagine productivity at an assembly line job having a peak such that overworking grinds someone down to the point that they become a liability, but people that claim working nine hours in a day instead of eight gives no (or negative) additional benefit are either being disingenuous or just have terrible work habits. Even in menial jobs, it is sort of insulting – “Hey you, working three jobs to feed your family! Half of the time you are working is actually of negative value so you don’t deserve to be paid for it!”
If you only have seven good hours a day in you, does that mean the rest of the day that you spend with your family, reading, exercising at the gym, or whatever other virtuous activity you would be spending your time on, are all done poorly? No, it just means that focusing on a single thing for an extended period of time is challenging.
Whatever the grand strategy for success is, it gets broken down into lots of smaller tasks. When you hit a wall on one task, you could say “that’s it, I’m done for the day” and head home, or you could switch over to something else that has a different rhythm and get more accomplished. Even when you are clearly not at your peak, there is always plenty to do that doesn’t require your best, and it would actually be a waste to spend your best time on it. You can also “go to the gym” for your work by studying, exploring, and experimenting, spending more hours in service to the goal.
I think most people excited by these articles are confusing not being aligned with their job’s goals with questions of effectiveness. If you don’t want to work, and don’t really care about your work, less hours for the same pay sounds great! If you personally care about what you are doing, you don’t stop at 40 hours a week because you think it is optimal for the work, but rather because you are balancing it against something else that you find equally important. Which is fine.
Given two equally talented people, the one that pursues a goal obsessively, for well over 40 hours a week, is going to achieve more. They might be less happy and healthy, but I’m not even sure about that. Obsession can be rather fulfilling, although probably not across an entire lifetime.
This particular article does touch on a goal that isn’t usually explicitly stated: it would make the world “less unequal” if everyone was prevented from working longer hours. Yes, it would, but I am deeply appalled at the thought of trading away individual freedom of action and additional value in the world for that goal.
The idea that SQLite shouldn't be use for web applications is about a decade out-of-date at this point.
But... actual guidance as to how to use it there is still pretty thin on the ground!
Short version: use WAL mode (which is not the default). Only send writes from a single process (maybe via a queue). Run your own load tests before you go live. Don't use it if you're going to want to horizontally scale to handle more than 1,000 requests/second or so (though vertically scaling will probably work really well).
I'd love to see more useful written material about this. I hope to provide more myself at some point.
Of course this doesn't mean they're using ChatGPT either, they could've switched devices or started using them because they felt like it.
Query [2]: [1] https://news.ycombinator.com/item?id=45072937[2] https://console.cloud.google.com/marketplace/product/y-combi...