HN user

always_good

4,605 karma
Posts0
Comments1,375
View on HN
No posts found.

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.

I don't see a righteous battle.

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.

Developer on Call 8 years ago

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.

I hope you can appreciate how fortunate you are.

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.

Recently there was that op-ed in Forbes that said we don't need libraries because we have Amazon: https://qz.com/1334123/forbes-deleted-an-op-ed-arguing-that-... -- Was such a disaster that Forbes limped away from it by deleting it.

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.

If a contributor's end goal is to publish a backdoor, then making them wait 0 or 100 commits to the project before trusting them doesn't change the end result.

In fact, if you had the energy to do the attack at all here (which took some work), having to fake trustworthiness doesn't require much more effort. Just look like a super enthusiastic contributor, put work into the readme, bike-shed over some issues every month, and bam.

Then let me ask you, how long should have dominic let right9ctrl contribute to the project before trusting him and giving him publish capabilities? With hindsight, we know that right9ctrl is going to publish a backdoor the second he gets rights. How long do you make right9ctrl wait? And does that accomplish what you want?

If you think that ownership transfer should exist at all, then the attack vector still exists no matter how long you wait to trust right9ctrl.

There are a few issues with NPM that make this kind of thing especially easy/lucrative:

- An ecosystem of massive amounts of transitive dependencies increases the number of people you need to trust. If I wanted to attack a project that used NPM, their package.json dependencies would be a really good place to start. Find the least popular transitive dep they use and email the owner to see if you can be a contributor (repeat for all of their xdeps). If they don't immediately give you publishing rights like OP did, then show some chutzpah and make valid commits until they do. While this attack works on any programming language's dep system, it's easier the more transitive deps a project has. People ITT blaming the OP don't understand this attack always works on a long enough timescale. Do you think there isn't someone out there who would make high quality contributions to an xdep of primedice.com (online gambling site) for 5 years to finally get publish access?

- Anything may run during `npm install`. npm install supports an --ignore-scripts argument to not run any scripts during install. This should be the default.

- Unqualified module names make it more desirable to "take over" a package than just publish your own package "npm install <username>/event-stream", so it contributes to an ecosystem of ownership-transfer that's far less likely to exist on, say, https://package.elm-lang.org/ where everything is qualified by a Github username.

- NPM website doesn't show you source code. The github link on the project page is just a convention. I think the NPM website should have a light source code browser of whatever is in the tarball that you download and execute during `npm install`. Bonus points for reproducible builds from that source.

- Developers don't actually review every bit of code they use and execute, especially not transitive deps. And we certainly aren't going to bother to download the tarball from NPM and unpack it to inspect the code of every dep. Most people reading this don't even know how to do that.

I've thought of some ideas to help the situation, like creating a Github shield that verifies that a conventional build script like `npm run publish-build` reproduces the tarballed code on NPM, but then I would just be doing free work for the NPM organization, and it's still just a hack.

you're a software developer and the setup would take you one day of work

I hear this a lot and I don't get it. Just because I'm tech savvy doesn't mean I want to do everything myself. My time on earth is finite like everyone else's. I don't value it less just because I can program.

I've built my own blog many times, actually. But the purpose of a blog is to write and share content. Every second I spend messing with the blog is energy I could've allocated towards writing content.

Also, static site generators tend to not have nice publishing editors, like the ability to just drag an image in.

But we really need to dispose of this idea that "you can build anything so why don't you want to build everything?" I also think hosting my email is a waste of my time.

Well, one problem is that apt-get's uninstall doesn't undo everything that could have happened during install.

It's just like how you need software like Revo Uninstaller on Windows to actually clean up everything: why?

It might not cause you day-to-day problems, but it's a massive defect in my eyes.

Type inference 8 years ago

The upside of type inference is that making small changes to types upstream doesn't necessary incur changes to code downstream.

But the downside of type inference is that it makes reading code harder and you may depend on an IDE to know what your intermediate types are. Especially wrt generics and higher-order types where intermediate function calls don't have a concrete type in their signature.

Nothing demonstrates this better than any time you've written code yourself only to immediately invoke the IDE tooling to inspect what the type is. If you didn't know, good luck to the person reading it in git diffs. I've had to git clone someone's Rust project recently just to follow the type transformation across a bunch of future/stream chains.

This isn't an argument against static typing but rather an argument against inference excess. There's a nice middle ground where asserting the concrete type in critical places makes the code more readable but also checks your own assumptions. Like any time you received Maybe<Maybe<Int>> where you wanted Maybe<Int>.

I have a hard time believing that you never used or heard of English's ubiquitous gender-neutral pronoun.

You certainly weren't using "it" to refer to humans.

I'm actually dumbfounded that someone would make this claim. It's almost as unbelievable as someone saying they've heard "ze" more than they've heard "they" in real life.

I don't believe it for a second and think it's more like when my girlfriend recently admitted she's never seen the metric system in recipes. I found this hard to believe and, sure enough, when I made her scroll through the recipes she'd saved in just the last month, "g" and "ml" are at least half the measurements. "Oh, haha, nevermind," she says.

Edit: You use "they" all the time in your comment history for genderless entities like Apple and TechCrunch (didn't want to scroll further). Some could say this is the plural pronoun, like when people pluralize "Radiohead {is->are} a good band", but since you do use "is" in these contexts, you are indeed quite familiar with the singular "they". And if you consume any English at all (as you certainly do on HN and Reddit), you see it daily.

It might seem like I'm making a big deal about nothing, but more and more often I'm starting to see a certain reality revisionism that makes me feel like I'm being gaslit by the people around me.

Or do the kids just think that's how it is/has to be these days?

I just don't think that's the defining feature of a job for most people, and most people don't care so much. All of my schooling happened in "open office" plans, like studying at the uni library. I also learned to cope with an eight hour workday. Why are more people not demanding four hour workdays?

Open plans are less stifling/depressing to me than cubicles, and I don't watch enough Mad Men to be fixated on having my own office.

To me, it's like being fixated on any office perk. You could die on the hill of demanding catered food. And that may be worthwhile to you. But I think I'd be at a worse position in life if I suddenly needed catered food to tolerate my job.

If we're ranking job perks, floor plan just isn't in my top 5, and I reckon it's the same for most people. Pay, how interesting the day-to-day, how cool are my coworkers, how long is my commute, is it slave labor, is there a culture of people interrupting me regardless of floor plan, etc.

Finding a good job just isn't Build-a-Bear workshop, so you have to pick your battles. Keep that in mind when you look around and assume "I guess other people aren't up in arms over $thing because they know no better."

I still have plenty of reasons to communicate with the drivers. From giving more specific information about where I'd like to be dropped off, asking if they can make a detour, talking to them when they call me because I'm at a busy pick-up spot like a festival that just let out, saying hi, etc.

Lately in Guadalajara, police have been unfairly cracking down on Uber drivers even thought it's legal (they're in bed with the taxistas), pulling them over for things like not having a baby seat (???). And I've had to communicate with most drivers through the app so we can arrange a more low-key pickup away from the police hotspots.

Besides, I'm human. I don't mind talking to others. Maybe it's because I'm 30 and part of the old guard now, but talking to another human isn't the worst thing in the world.

Well, you were misinformed that you could learn a language by doing any one thing.

Apps like Duolingo are just a method for daily exposure on the long journey of language learning.

For example, reading only grammar books isn't going to get you there, either. But doing something every day is possibly the most important part, and Duolingo can help you build a habit.

I see this criticism of Duolingo all the time by people who sound like they think it failed them because they weren't fluent after finishing it. There is no roadmap that will make you fluent without serious, multifaceted effort on your own part, so it's quite weak criticism when one tool doesn't take you end-to-end.