I don't disagree, but I think there is the otherside of that same coin... What if we could do other stuff while remaining productive.
Rather than the example of missing first steps, what if we had, "Ok Claude, prepare a few slides for my presentation, I'm going to watch my childs mid-day recital..." maybe you get a success/failure ping and maybe even need to step out for part of the event, but in another world you couldn't have gone at all.
Short of jail, nowhere in adulthood are you required to stay somewhere by law.
On top of that, I don’t think the kid quietly using their phone and ignoring class is the main issue here… it’s causing issues with the other kids and making the experience worse for a lot of kids.
I tend to agree, however, I typically tell people that if you see longer function names, you should watch out for complexity. In fact, if I have to write some overly complex code that I can’t isolate for some reason, I will usually try to show it in the names being extra long.
Computers were invented to speed up calculations, and yet the primary thing we use them for today is to read the news and send each other messages and memes…
I think it’s totally reasonable, to expect developers to find the real use
If you don’t fix it… and the code is working… what is the problem?
I leave notes like that sometime as indicators of intention… or invitation to the next reader… but if it never changes and is not causing issues… that’s fine, leave it as is.
I can empathize with the author here that types can be very challenging to get right, especially with high amounts of dynamism.
However, I think that saying it is "terrible for library developers" is a bit far. I think its terrible for developers who want to make use of advance types... which ultimately doesn't depend if you're a library dev at all.
It boils down to: "Typescript learning curve gets really steep after the basics"
The author mentions they help maintain redux-saga. I don't want to dig on them, but from my personal experience, that library takes you down quite an opinionated application path with complexity inherit to it. Heck, just making types for redux was a pain, let alone adding async and additional composability.
My take is that the author has chosen complex tech to work with, and that influences the complexity in their types.
I've been using Workflowy for years now. I really love it.
They been working lots of interesting features in but stick to the basics that everything starts as a list. You would be surprised what is possible w/ just a list!
MDN docs are the best... they should monetize via high level articles and example implementations for systems.
For example, the webRTC docs are great and explain a lot about how it works... however, there is very little information about good patterns for including it in your application. I bet people would be happy to pay for guides like that, I would.
I think these questions come from the idea baked into charitable giving. When you purchase a good, the thing you're getting is obvious, it is what you're purchasing.
However, when you're giving to charity, what are you getting? You probably want to know.
If charities are smart, I bet they could take advantage of this by creating classic ladders which encourage more contributions if people get a say of where a "portion of their donation" goes.
I've thought about hooking into messages w/ a running mac before... Do you have a high level description of your approach? I looked in the iMessage GraphQL Server server repo for docs but didn't see anything obvious...
On a quick investigation I noticed you are reading the sqlite db... but it wasn't super clear how you send/receive messages?
Rather than the example of missing first steps, what if we had, "Ok Claude, prepare a few slides for my presentation, I'm going to watch my childs mid-day recital..." maybe you get a success/failure ping and maybe even need to step out for part of the event, but in another world you couldn't have gone at all.