IggleSniggle

Depends on the writer.

Speaking only for myself, I _love_ coding. But I haven't done refactoring by applying a needle (with a steady hand) to a roll of magnetic tape in _YEARS_ /snark.

I love monkey-patching some python or js. But never have I ever suggested that anyone would should do it. Writing everything in Haskell sounds lovely but I wouldn't advise that either.

I honestly don't care what language I'm writing in. LLMs bring us back to the smalltalk days: your code is data and your data is code. LLMs bring a translation layer so that even if you're writing some high-level language, some DSL that exists only on some 1-off platform that no one else is aware of, _everybody_ has access to a self-bootstrapping codebase.

I feel more empowered to _code_ than ever: now, every single input carries semantic weight that gets carried through the "compiler." Every claim of determinism can much more easily be fuzz-tested and made more robust. "'sup, this broke, fix yo" and "Would you be so kind as to fix this error?" contain semantic context that actually affects the output of the generated code. That restores empowerment around code _authorship_ while still preserving the guarantees we want from the published artifact.

"Deep understanding" doesn't disappear when you gain the ability to be more expressive. "Deep understanding" disappears when people become incurious.

I loved it. It was cathartic to read, too. It's really a rather short story. There's no accounting for taste.

Back in those times we made a distinction between nerds and geeks, with geeks really being a sort of subset of nerds that was just interested in the technicals.

Some artists use a brush, but others use a chisel.

And then there's the bullshit artists.

Just because we never had the option of a chisel before doesn't mean all chiselers are bullshit artists.

I apologize. I didn't mean to suggest it is a super power, and it has also been a struggle in my life. I find it useful to frame this way because the struggle is not only because of the way that I am, but also because of the way everyone else is. I'm not asking anyone to change on my behalf, but it took me a long time to accept myself as I am. It took me a long time to accept that I didn't need to change for the benefit of everyone else.

For me, one of the big improvements is the ability to legitimately work via text message. That probably sounds dystopian in a bunch of ways to some people. But there are times that I want to work, but couldn't, previously.

Now I can work from wherever, whenever, by speaking into my headphones, and have it persist. Sure, I want to be in front of a screen to do final syntax review, but I don't mind planning out architecture and guiding an LLM towards a cohesive result while going for a walk or jog. That's just not a workflow that would have been viable 3 years ago.

I always thought of myself as merely ADD, but your comment is so incredibly relatable across all dimensions that I find myself wondering how far along the autism spectrum I am. Although, in my personal opinion, neither term is especially helpful: it's not a sensory/executive processing disorder if it's clearly benefiting both yourself and the people around you. It might make being sociable difficult, but that's the tradeoff for being willing to engage your mind in ways that others filter out as "too much information."

They are building them because they can ask an AI to spin it up. They could have asked it to spin up the public API just as easily. The MCP choice is a fashion choice vs an openapi spec with similar documentation (or any number of other human+machine readable tooling). It might accidentally win or accidentally lose just because of the timing / network effects.

Right; isn't this already captured by an openapi spec with RBACs? Plus the benefit that your ai agent can keep using all the pre-AI tools that already interface with those specs. What is MCP bringing that an openapi spec doesn't?

Source?

Caveat emptor, I'm not a Haskeller, just an admirer. But Haskell let's you run functions over the type system itself very elegantly, so you can have a type that is derived from a type that composes three types that are derived from several functions' declared runtime behavior. This kind of type inference can provide arbitrarily rich information about anything in the entire program, letting you encode more than just range-types etc at compile time.

This comes with some design drawbacks. I think Rust's borrow checker would be implementable but unreasonable in Haskell: Haskell already does lazy-evaluation on types to enable its arbitrary depth of type expressivity. But the borrow checker also wouldn't really make sense for Haskell because the default programming model uses a GC. I think Linear Haskell might be a kind of Rust-in-Haskell, though.

Again, caveat emptor.

Great story thanks for sharing

Depends. Within the US, there are data export laws that could make the "whoever" part illegal. There are also conspiracy to commit a crime laws that could imply liability. There are also laws that could make performing/demonstrating certain exploits illegal, even if divulging it isn't. That could result in some legal gray area. IANAL but have worked in this domain. Obviously different jurisdictions may handle such issues differently from one another.

What do you recommend if I've been regularly producing blog-length posts in Slack for years, no LLM present? It's where I write man...should I quit that out? I try to be information dense...

To me, you are describing a fluency problem. I don't know you or how fluent you are in code, but what you have described is the case where I have no problem with LLMs: translating from a native language to some other language.

If you are using LLMs to precisely translate a set of requirements into code, I don't really see a problem with that. If you are using LLMs to generate code that "does something" and you don't really understand what you were asking for nor how to evaluate whether the code produced matched what you wanted, then I have a very big problem with that for the same reasons you outline around prose: did you actually mean to say what you eventually said?

Of course something will get lost in any translation, but that's also true of translating your intent from brain to language in the first place, so I think affordances can be made.

Totally agree on js, but it doesn't have the same easy same-language comparison that you get from compiled Lua vs LuaJIT. Although I suppose you could pre-compile JavaScript to a binary with eg QuickJS but I don't think this is as apples-to-apples comparison as compiled Lua to LuaJIT.

I think it's worth remembering that this was a storage procedure that was also already abnormal/odd because of the specifics of the existing shielding. I think it's somewhat understandable for a technician to trust that the chemists know what they're doing in that kind of circumstance. If they had concerns, they may have even voiced them, but as is often the case, if the authority confirms that even though it's strange it's correct, it's not surprising that a technician would follow the directive. Even the authority figure may have verbally confirmed, "you said an organic absorbent??" "Yes, that's right, inorganic absorbent." Maybe even in a meeting that was meant to clarify written procedures.

Compiled Lua vs LuaJIT is a major example imho, but maybe it's not especially pertinent given the looseness of the Lua language. I do think it demonstrates that the concept that it is possible to have a tighter type-system at runtime than at compile time (that can in turn result in real performant benefits) is a sound concept, however.

I simply choose to believe that people do this out of a place of genuine curiosity / excitement to share knowledge. I believe this approach of assuming the best of intentions is even in the HN guidelines! Or maybe it was just the old Reddit ones from long long ago when Reddit was more like what HN is now. Either way, maintaining the background assumption, even when it is challenging to do so, makes HN a far more pleasant place to inhabit.

In the broadest sense of the word, aliasing refers to a problem where an insufficient number of samples create a misrepresentation of an intended signal source. I was being a bit poetic, because in graphics programming, where the term "antialiasing" is most often encountered by lay audiences, antialiasing generally refers to X/Y sampling coordinate correction rather than representations across time. It's not usually considered a major issue in vision, because our brains naturally fill in the gaps pretty easily across time for motion (they already naturally do this for eg blinking, you don't see your eyelids when you blink). So usually antialiasing across time is only an issue in audio domains for the layperson, where a misrepresentation of a sample might be perceived as an entirely different pitch, since our ears need >40k samples per second (for accurate high pitches) vs the 24 samples per second that we are accustomed to getting in old fashioned film. When our eyes "miss" a frame or two, our brain is happy to fill in the gaps, ie "antialiasing."

Edit: to clarify, I'm suggesting that some people might prefer to let their brains "fill in the missing frames" rather than see the extra frames shown explicitly. For example, you might be more likely to notice visual tearing at 60Hz than you are to take note of visual tearing at 24Hz when you're already accustomed to filling in the missing pieces, or to a greater extreme, across two panels of a comic strip portraying motion.

But they said it sends them to Netfçix? That seems incorrect

Just because someone has different taste doesn't make it bad taste. Books have lower resolution still, and they evoke far greater imaginative leaps. For me, the magic lies in what is not shown; it helps aid the suspension of disbelief by requiring you imagination to do more work filling in the gaps.

I'm an avid video game player, and while FPS and sports-adjacent games demand high framerates, I'm perfectly happy turning my render rates down to 40Hz or 30Hz on many games simply to conserve power. I generally prefer my own brain's antialiasing, I guess.

That's good, because the "O" should never be dotted. You use slash OR dot for zero, unless you vaguely remember them both as useful for disambiguating but forgot that both marks are for zero and vary by typeface. Mostly dotted zero was just during the dot matrix era. I wouldn't mind being shown counter examples.

The Luddites weren't against automation, they were retaliating against the capital class. Their demands were to have dignified work, not for automation to go away. They attacked the machines because it was the tool the capital class used to deny them their livelihood.

Rivals of Aesther - like Super Smash Bros but with Steam Workshop support for player-made characters... TARS (interstellar) vs Ronald McDonald vs Obama anyone??

nidhogg - deserves to be in an arcade cabinet but honestly this one is ALWAYS a hit...just 2player though

Broforce - 80s action stars in 80s action movie multiplayer platformer

Ultimate Chicken Horse - competitively build a platformer level and then race to complete the level first, best with 4 players

TowerFall Ascension - 2-4 players, also deserves to be in an arcade cabinet

Screen Cheat - FPS made for the couch; think N64 Goldeneye or Quake, but all the players are invisible, so the only way to figure out where your opponents are is to look at their quadrants (screencheat)

Overcooked 2 - it's pretty kid-oriented on the surface, but it's a game where you must out-communicate the absolute chaos unfolding around you in order to succeed...such a good couch-multiplayer experience, but best for experienced gamers imho

Rocket League

Magicka

Regular Human Basketball - control giant basketball automatons by jumping inside them and operating the manual controls in a team v team. Minimum 4 players to really work well, supports up to 10 players shared screen

That should get you started! But oops that wasn't my casual coop list, more my "makes for memorable group experiences" list.

It Takes Two, Portal 2, Untitled Goose Game, Halo Master Chief Collection was like $10 recently, all come to mind as positive local coop experiences I've had.

This is why I've been all in on Steam for so long! The catalog is so huge, there's a massive number of fantastic couch multiplayer games. It is indeed a bit more fiddly... I've found that it's generally easier to connect my Steam Deck to the TV and play lower fidelity games than it is to fiddle with a Windows machine that needs to be prepped for friends popping in every other month.

Although, Nintendo is still doing a good job at keeping the couch-social experience alive, and building 1st party games that can be good solo experiences but really shine when played next to a friend sitting on the same couch.

That's been me before. If you're wondering why people ghost at the technical when they seemed like great candidates: sometimes, at least, they like engineering because it's a discipline where they can get things "right" within some defined band / acceptable tolerance. In interview context, where there's somebody watching and judging, the degree of tolerance is unknown, and you know you won't be given time to choose the most correct approach regardless, and that solving the technical problem is just an indirect proxy for solving the "is this person a good social fit" problem (because you know you have the technical ability), all acts as anti-motivator for practicing for leetcode style interviews.

Its easier to say "I just didn't study and that's why I didn't get the job" than it is to say "even though I spent a bunch of time optimizing for this interview scenario and know I absolutely aced the technical interview, they still didn't like me."

Heck, I've been in interviews where I found the technical aspect a relatively easy bar to pass, and I blurted out something strange just to sabotage myself. If they can look past that and still see that I know what I'm doing and bring a lot to the table, I know they are people that I can do my best work with without needing to be constantly second guessing myself in conversation.

Some companies seem to forget that interviews go both ways, and that job candidates are screening for something different than what companies are screening for.

It does if you do DNS over TLS or HTTPS, although I guess that information would still be knowable to your DNS provider if they terminate your TLS behind the scenes

Of course. And I thought I acknowledged that mentorship is many things and there are many things that we need to grow as individuals. I've had a lot of great mentors in my life.

I still think you've missed the point. You can be grateful for the many gifts you've received and still wish to have had engineering guidance from a trusted mentor. There is not enough time in a life to go down every single rabbit hole; it's nice to have experienced people accurately point out where the rabbit holes are. Non-engineers are not equipped to help spot engineering rabbit holes; they might even tell you that engineering itself is ultimately a pointless rabbit hole.

But even then...that's just my own experience and my own wishes for my past self. I try to give what I wish I had had, of course.. think that's what drives most mentorship, and maybe that's the point you're trying to make, that mentorship is given out of that wistful feeling of wishing you had received advice/help and passing along the lessons that took you too long to find.

But still, if your role is getting stuck alone in the server room or whatever with a team of people who don't understand or respect what you do, good luck.

The point I was trying to make (and maybe failed because I got too focused on my own experience) is that really, not everyone gets mentors, even of the broader sort that you're referring to (which I might say are more accurately called friends or peers). But even if we widen the scope of what mentorship is, it's also perfectly reasonable for field-specific mentorship to be a cultural expectation for software engineering. I think it's a good thing to expect this of each other, and to encourage explicitly making space for the practice.

But again, however you want to widen the scope of what mentorship is, not everyone is getting it. The reason people look under rocks is because they don't know where to look. Or they do know where to look but also know they have blind spots and don't know how to get them addressed. "Look up" is nice and all, but it's a bit rude and distracting when you're trying to build something and need help understanding the foundation below your feet. Sometimes you don't need someone telling you to look up, you need help seeing where to look closer.