Mobile UI builders can barely generalize over their own domain even when they are just targeting a specific platform.
That's not very high praise, to me. Look at all the code you still have to write just creating a table view on iOS. If I avoid writing code, then I'm stuck with stringly-typed identifiers hidden in sidebar menus which is even harder to debug.
The bottom line is that client development is hard. So hard that our tools for more focused platforms than web (like mobile) aren't even better, they just have different trade-offs.
There's nothing you can do to guarantee they are successful.
What you can do is expose your kid to a lot of things and help them find something they're passionate about. Ideally something they can use to pay their bills too when their business fails. I don't see why some programming/tech exposure can't be one of those things.
I work fewer hours and have more lateral mobility than pretty much all my friends that make as much money as I do. Software engineering is a good field. Nobody is saying you have to force it down anyone's throat, and that's not what a Minecraft scripting API is doing.
What a great creative opportunity though for kids out there to dabble in programming due to a game they love. That doesn't preclude them from being financially savvy in the future. They're kids.
Doesn't that simply depend on how often you have to leverage human enforcement? Whether you have to do it <1% of the time vs 100% of the time would drastically change the answer to your question.
It's like chargebacks. 99.9% of my purchases I will never issue a chargeback for, so most of the time I choose to use a payment mechanism (cash, bitcoin when I can) that doesn't come with all that overhead. If I was frequently getting screwed by merchants, then my payment habits would change accordingly.
I did the same thing to grind levels in Runescape and I look back with regret, getting <4 hours of sleep during an important developmental stage in my life.
My parents didn't even suspect that I'd do such a thing. But they could've trivially stopped it. If they knew I was doing it, they would've removed the computer from the game room. Luckily for my kids, I know how addicting gaming can be unlike my parents did back then.
I don't really know what you're trying to say. Kids have almost zero resources. If they have an internet-connected device they can use 24/7, it's because you got them one and you let them.
Kids do have more disposable time than parents do, but that's also why kids are so good at creatively filling the void when they can't just turn on their dopamine machine. When I was bored at my grandma's house without electronics, that's when I learned to draw, a hobby I've taken into my 30s.
Agreed. In another comment, someone points out that LoL/Dota2 require a lot of dedication and metagame analysis to be good.
Which is true, but doesn't change the fact that I look back at all gaming I did as a massive waste of time, wishing I spent even 10% of that time doing anything else. And even in my early 20s, I couldn't get out of that "just one more game" compulsion many nights and it would impact my work performance and social life. Not really something I want for my children.
I'm in my 30s now and have healthy hobbies again like language learning, reading, and drawing.
I have a feeling a lot of these "gaming are no different than reading or playing a sport" are from young HN gamers. I would've argued the same thing when I was a kid. Not til later did I start wanting to live my life to maximize my sense of fulfillment and minimize regret, and I have a hard time believing gaming does that for anyone.
How is the internet "tipping over" going to change what's fundamentally human?
Changing the interpretation of what someone said to fit your argument can be seen on the school playground and in Plato's Gorgias. It's not going away anytime soon.
Agreeing on an interpretation is the first step to conceiving an argument. Wrestling through this is a big part of having a discussion, and someone can always try to unfairly assume the interpretation that suits them, often the least charitable one.
You mentioned Emacs as a solution which has a Rust plugin that has problems like most other Rust tooling. Yes, Rust's tooling landscape is immature and still a work in progress.
Obviously you can just forgo editor integration all together. But you can do that in any editor.
Well, that's always an option, so it isn't really advice. It's already what you have to do when the tooling support is bad. It's the poorest when an editor can instead inline its output of static analysis.
Integration has a lot of benefits like tell you the inference of intermediate types. "Don't care about good integration" isn't really advice.
It's like people who brag about syntax highlighting. The 99.9% rest of us consider it a good tool that improves our workflow.
What about the good qualities that websites have, like the ability to link (and deep link) people to specific parts of it?
The re-trending of the local application is a step back in this regard. And "when will this internet fad die off so we can return to native applications" throws a lot of baby out.
You could say this about anything though, so it's not very damning criticism of Kickstarter. Also applies to Hacker News and everything, individually, at the grocery store. And all the Amazon boxes piling up on our doorstep from holiday deals.
Maybe you'd agree with that. I just never was a fan of the "oh, it's those people who are doing it wrong" as we ourselves indulge in a different set of the same thing.
Well, those are GUI toolkits. A lisp doesn't compete with them. Any GUI that you build with a lisp still needs to support that sort of thing.
Also, when people praise a feature that RN or Flutter have, they are really saying that it's nice that a tool that's practical today has the feature, not that it's never been done before. That something has been done before isn't all that interesting.
If you don't realize this, you become the person running around unhelpfully reminding everyone that smalltalk or a lisp machine had a feature years ago, yet neither offers a practical way to build mobile apps today unlike RN/Flutter.
I think I have some lasting trauma for the year I was on call.
I still have nightmares that I'm getting woken up into a hellish situation to fix code I've never seen at 3am. Or that I'm out on a date or having a beer or trying to enjoy my life when I get called.
I remember the constant state of anxiety just knowing I could be called. Couldn't even wind down watching a movie much less read a book. I quit when I realized I felt a sense of relief commuting to work the next morning because I wouldn't have to field an emergency by myself.
I also remember fantasizing about being a cafe barista or security guard that year. Waited way too long to get out.
Though 4 Euros ($4.50) is less than half what I pay for most books I want on Amazon.
It would be very expensive for me to feed my book-reading habit like that. I couldn't afford it without libraries.
It's nice that you can afford to spend money on books, but we need a solution for everyone else, especially if we agree that books are a good thing for society.
The NPM organization could go much further to make these attacks harder.
You pitch a really good one: Any time you npm update/install, display ownership changes (especially compared to your prev version).
Another one is to show the source code on the NPM website itself instead of hiding it in a tarball. NPM basically trains people to assume the published code == the code at the linked repository. It's a hacky honor system that only helps attackers.
Be specific: what exactly would you do in Elm to pwn someone? It would be a much more limited and a much more visible attack.
NPM modules don't even have source code on display. Someone has to download and check the tarball before npm install.
Also, Elm packages are qualified by a github username so there isn't an ecosystem of ownership transfer. No juicy name squatting. People just fork.
Finally, don't forget that my point is "there are a few issues with NPM that make this kind of thing especially easy/lucrative". That's a far cry from "everything else is bullet-proof" but it's tempting to argue with me as if I'm saying that.
That's not very high praise, to me. Look at all the code you still have to write just creating a table view on iOS. If I avoid writing code, then I'm stuck with stringly-typed identifiers hidden in sidebar menus which is even harder to debug.
The bottom line is that client development is hard. So hard that our tools for more focused platforms than web (like mobile) aren't even better, they just have different trade-offs.