HN user

the_other

2,469 karma
Posts1
Comments994
View on HN

I have no idea how an adult filming young girls on a train has anything to do with social media bans.

The article is, I think, making several points at once:

- some of the people involved in creating this new legislation are already responsible for the harms the legislation alleges to mitigate. We've already heard (here on HN at least) that Meta lobbies FOR age restrictions; now with this incident we have a civic leader abusing their position of power and targeting exactly the people this raft of legislation allegedly protect (although it might be stretch to assume this person is involved in bringing in said legislation; they might be quietly avoiding talking about it because they know they're part of the problem). We should be questioning who's responsible for the legislation and inspecting their motivations publicly. We should be questioning their motivations, and challenging the efficacy of the proposed solutions given the background of motivations of those proposing them. We should be challenging the decision-making: where's the evidence the mitigations will work? (and this is all in addition to the perceived harms to all adults from the increased breadth and accuracy of the dragnet surveillance the solutions create).

- we don't need this kind of legislation to help raise reasonably-minded children. We should be targeting the perpetrators of the harm, not targeting near-adults who are (potentially) being harmed. The current legislation is victim-blaming, not prosecuting the perpetrators. The situation described is somewhat allegorical, rather than "here, social media is good"

I think it's also saying this:

- how else are people, adults, near-adults, children, going to learn of, and discuss, situations like the one described, without social media? "The Kids" have been using social media for the last ten years, and many of them are, despite the harms, growing up sane, self-controlled, able to stand up for themselves.

The article is making me reflect on our household's ban on our teen using social media. We don't want them getting wrapped up in constant one-up-ing, gossiping, body-shaming, discrimination, and other social ills that go around, but we are also denying them some ability to discuss these issues, learn about them, find support from peers and experts. (I mean, they can... they can use the wider web and can talk with their parents, friends, and teachers, in person; but those media are slower or more awkward for being "in your face")

AI probably should be. The bulk of its efficacy comes from the work of “everyone else” (in loose terms). AI also aims/hope/threatens to replace such a large number and range of jobs that it probabky should be a commons.

It’s a reasonable course for helping yiu identify a single line of notes across the two staves. Or maybe just the “right hand” upper/trebble clef stave (the bormal one for most instruments).

It does teach a little anout scales. It wont teach chords. It doesn’t go very far into time signatures. It only has you play a virtual keyboard so it’s useless for learning how to feel your instrument.

It’s quite fun. My kid plays it every day and it’s helped get them feeling more confident to sit at our piano and noodle around. As a noodler myself, this seems valid.

It wont get you good enough to play pieces with other musicians, or to compose with weatern harmony. You’ll need extea tutorials for those.

I agree that we had much better patterns back then. The software industry in general worked towards sharing visual paradigms, making use of system designs of their host playforms, facilitated discovery etc etc. All that was good and the recent trends moving us away from that consistency and discoverability are a detrement being steamrolled over by agents…

But I don’t agree that it “looked nice”. I hated Windows 95 and 2000’s “style”. They looked like engineers had made them. They looked stiff and unfriendly, eith too much border and outline. Real life has no outlines. I was in my late teens when 2000 came out. My friends and I jumped on it and felt it was the Os we had been waiting for.

But even then I thought it looked like shit.

The affordances were great. I agree that details like button depress and consistent scrollbars are valuable.

But I genuinely prefer things a bit rounder, a bit flatter, less grey, or late Aqua-style flat-with-shiny-affordances.

I agree that backgrounds should be flat (or very subtly textured so they recede but arn’t “boring; again, late-00s Mac OS nailed this for me).

What I’d really like to see is something new that takes the consistency of NT/2000 and Mac OSX prior to Lion, mixed with the novel affordances of BeOS/Haiku (docking windows, small title handles), and puts it through Apple’s “zing” (but not too far - transparency is highly overrated).

Claude Corps 1 month ago

Context: I vibe code most of my production code, but I come from a long FED career so I'm vibe-coding small things, constantly tweaking, refining prompts, picking work to do that fits with the existing work, etc. So I'm either "doing it wrong" or "being careful". Anyway, that's the perspective I have ATM...

So, it seems to me that there's quite a lot of skill to using these "god boxes": which models, connecting to your systems, hosting the code, running the model, running the code, not breaking your production pipelines, having a production pipeline in the first place.

Sure, the god boxes help with a lot of that. But they don't help setting up the accounts, connecting your code hosting to your production servers. You can't currently just give random people in your org access to an LLM account and have them safely make production changes w/out some engineering knowledge and oversight. In NGOs, especially the small ones, they already outsource all that to 3rd parties so they don't have to worry about it. But with "just the right amount" of in-house knowledge, gear, config (maybe one office computer hooked up with Claude, or a small GHCP account, with GH + hosting configured), it's possible that anyone in the company might be able to add to the company's suite of useful small tools, or add features.

(I also think there's more to "hey claude, make feature X" than we're capturing here, but as I said at the top, I might be doing it wrong.)

Thanks for replying.

I think I missed the significance of your narrowed definition of recursion, and didn't apply it the way you intended when I read the article. I admit to my bad reading.

I went on to discuss your article with an LLM and used the experiences I've had _using_ some functional approaches in JS to help it give me a tutorial on the combinators, to try to better understand your article and the underlying principles. I "mostly get it" now, but I will have to go over it a couple more times.

You shared a thought-provoking article, even if I didn't immediately get your intended lesson out of it.

I’ll re-read it, because clearly I don’t get it. And I’d like to.

My first two attempts made it seem like it was building on a function calling itself, with itself as an argument (so that it can call itself). I’m not sure how that isn’t recursion, and I didn’t read it as throwing away those approaches. But, as I say, I’ll re-read it…

I found it extremely confusing.

It sets a challenge as a rhetorical tool, but then completely fails to honour the challenge through the bulk of the explanation.

- don’t use recursion: spends multiple paragraphs implying that a function calling itself isn’t recursion

- don’t use declaration: ignoring that defining arguments to a function is declaration

I’m not saying the article is “wrong”. But I thunk I’d have preferred a plain intro to lambda calculus.

(Writing this as someone who has struggled to learn “real” functional programming the few times I’ve tried over the past 20+ years, but who very much likes using RxJS and the functional flavour of lodash and wishes I could see deeper into that black hole.)

Poor quality comes from the fact we have outsourced manufacturing.

My experience with software development suggests this is not the main driver. The main driver seems to be management not caring about quality, UX, long term maintainance costs, externalities, and by viewing customer service as a cost rather than as branding.

The "right" abstraction seems like quite an art. Sometimes it's not obvious, or it takes multiple rounds of exploration and testing (I'm thinking here of the mental shift moving from HTML + JS, via jQuery, Backbone, Knockout and up to React/Vue or Angular). At all points, we thought we had reasonable abstractions for a while. Vue and Svelt, or NextJS, now are so far from the mental model of early 00s "DHTML".

And I'm not sure how this relates to TFA's point. Are you saying we collectively need to get better at abstraction so that LLMs get better at abstraction (either by training, or our prompting), so that their code is easier to read?

My inherent pedantry drives me to say "this sounds like compression, not gating". Do lots of people use "gating" to mean "automated volume control"? In 30ish years of hobbyist music production I have only encountered it to mean "automated in/out control". It's "compression" that automates dynamics.

Thinking out load a bit here:

- maybe the existence of West-coast style "low pass gates" proves me wrong...

- gates sometimes have release controls, which would make them "automated volume control", but I still contend that aiming for zero gain when the gate closes makes them in/out controls not "dynamics" controls).

Another way in which it's not cheap to lose sight, I guess.

True.

We can frame it even more strongly: "default societal practices actively discriminate against people with disabilities; they intentionally, consciously choose to make life harder for people who're disadvantaged".

TypeScript interfaces just merge. You can aet any property name you like on a plain JS object, at any time.

The CSS version is a risk, for sure. The dev tools in all the main browsers will tell you where the extension happens and show yiu the order the complecting rules are applied, so it’s fairly easy to debug. Bugs/misbehaving code is usually a problem of structure. In other languages, we take on the need to apply structure; just do the same with CSS.

The mechanism that allows this merging behavior is the means by which intentional reuse is composed. It allows yiu to set general and specific rules sets. This seems conceptually similar to OO classes and subclasses, to me.

With CSS names are global.

In your "programmatic" code (your JS/TS, python, C++, whatever..) your classes are global. Even if the language supports flexible namespaces, or module scoping, you still have to take great care naming because reusing a name will cause you confusion. Giving two things the same name makes them harder to import, and risks clashes and bugs.

No-one complains about this. This is just how you code in all those other languages.

Mix this 3d graphics, with data science notebooks, with local LLMs, and perhaps an integrated coding harness, with visibility over your personal data and you’d have something absurdly good.

This might overtake “a haiku+macOS mashup” as my idealised computing future.

My banks provide different colour options for their cards. All my digital cards differ, even from the same bank. The alternate colours helps within the banks/ apps as well as within Wallet, so it's not just an iOS "workaround".

I agree, it would be nice if Apple added stickers, but the problem isn't, IMO, as bad as you make out.

Exceptions include transport and concert tickets. Most of the time this doesn't cause problems because I'm standing with the other people I'm travelling/gigging with, and the agent scanning the tickets doesn't care about any names on them.

I don't think you're making a useful point about the situation.

In the case of the orange in the bag, both Altman and his interlocutor can see the bag and the truth can be exposed by rummaging.

In the case of ads in the oAI chat feed, at the time Altman made the comment he was probably planning to puts ads in the feed. But there might not even be emails about this, just conversation. And the engineers might not solve the "how" for a while... so there's nothing to rummage for.

However, in both cases Altman wants you to think something other than what's on his mind. There's an orange in his bag, but he wants you to think there is not. There's going to be ads because he owes the investors a tonne of money but he wants you to think it wont happen, or wont happen soon, or will be "nice" ads...

The distinction is in the nature of the underlying truth, not in Altmans words or actions in the moment. In the moment, in both cases, he's lying.

Stop Flock 3 months ago

It’s easier to consider responses or solutions to specific problems, rather than to solve for a broad, general principle. You can see this in many areas of life. Solving for general principles requires group effort (usually); you can get buy-in from individuals if you csn focus them on specific cases or subsets. So the Floxk fetish is reasonable at this point, IMO.

There’s also nothing inherently wrong with carrying sensors in your pocket. The “wrong” is in the providers/manufacturers exploiting the position they put themselves in. Managing data is hard, and most people don’t want to do the necessary work most of the time, so the providers/manufacturers offer to do that for their users/customers. However, they also exploit their csretaker position by tresting the data like they own it too, and extracting profit.

If the solutions to the Flock problems could be framed such that other providers/manufacturers had to build systems that were “local first” or “private by default” (as in pre-internet home computing plus explicit, finegrained shsring consents), then it would also be fine to carry sensors. I want my fitness tracker and GPS. I just don’t want the data it generates used to build advertising profiles on me such that ads (and government mass surveillance dragnets) can follow my every other move.

You could think about it this way:

All AI prices will rise soon - probably shortly after the IPOs. The new prices will be eyewatering compared with today’s. This bulling change is lengthening the time until Anthropic have to raise the subscription prices, so those of us who’re not doing 24hr claw stuff can continue to use the tools the way we’ve gotten used to.

I'm a beginner with agentic coding. I vibe code something most days, from a few lines up to refactors over a few files. I don't knowingly use skills, rarely _choose_ to call out to tools, haven't written any skills and only one or two ad hoc scripts, and have barely touched MCPs (because the few I've used seem flaky and erratic). I answered as such and got... intermediate.

I read the implication too, as well as the fatigue.

They offered nothing to counteract the idea that we should just shut up and accept it. Then they closed with "And I actually like the concept of reward cards (although I don't use them) because it is pretty much the only way how you can make money off your data." - which sounds like they have given up opposition, and are now considering ways to profit from the situation rather than fight it.