jynelson
jynelson on Hacker News
> What is it? Can it be this autonomous terrifying entity or can it not be?
the difference between attack and defense is that attacks can be throwaway code. it's much easier to let an llm hack out a prototype than to get it to build maintainable code that people want to read and review. it's not enough to get Daybreak or Mythos to write you a patch, you need the author of the project to accept and merge it.
that is not what the policy says. it says "authors must disclose", "reviewers don't need to play detective", and "if a reviewer is not sure whether a post is LLM-created they should handle it privately, consulting mods". and the recourse is "go to this zulip channel", because closing a PR isn't the same as geting banned.
yes. there's a reason there's exactly two things in the policy that are marked as moderation consequences and they're directly next to each other. "no harassment" doesn't work if people are paranoid that any PR could be LLM slop, and "disclosure is required" doesn't work if people are worried about harassment. you need both, and you need them to go into force at the same time.
it says “that’s right” in bold red cursive font. i know what the policy says, i wrote it, you nincompoop.
if an LLM says "I can't open a PR automatically until you solicit a review from a maintainer", i think that's good actually. likewise for proactively following the rest of the rules.
> Ultimately that's something the hook author has to solve, not the framework which runs them.
correct. i'm saying that hook authors almost never do this right, and i'd rather they didn't even try and moved their checks to a pre-push hook instead.
this completely breaks `git add -p`.
the pre-commit framework does not abstract away “hooks shouldn’t be run during a rebase”, nor “hooks should be fast and reliable”, nor “hooks should never change the index”.
i think you would be interested in demoscene, it’s about exactly this thing: making art out of extremely harsh requirements.
tbh i think you just hate trans people but you're afraid to say it directly
> Software should be an engineering field, which exists to help humans, not as some personal art project for your self expression
it makes me sad that you see these things as somehow in conflict with each other :(
> it's often that the amount of time i've spent thinking about something (a lot) is totally disproportionate to the time i spend typing my thoughts up (a little)
oh, this is a really good way of putting it! that’s exactly what happened :)
you could build an emacs frontend for this model! the thing i am trying to describe is “getting out of the box”. imagine a terminal session that is shared between emacs, iTerm, and a mobile phone ssh’d in over the network, that’s my vision.
omg i've wanted something like shelter for literal years
it "cheats" a little because it requires the underlying filesystem to support snapshots but it's still really really cool, thank you for the link!
> Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly.
Yes, this is the work. https://becca.ooo/blog/vertical-integration/
whoa this looks fascinating, i've never heard of it before! thank you for the link :)
this is really cool omg! i didn't know that, i'll do some research.
one of the strange things to me about the terminal landscape is how little knowledge sharing there is compared to other domains i'm familiar with. iTerm has a bunch of things no one else has; kitty influenced wezterm but otherwise no one else seems to have valued reflection; there's a whole bunch of extensions to ANSI escapes but most of them are non-standard and mutually incompatible. it's weird. if i compare to something like build systems, there's a lot more cross-pollination of ideas there.
i would describe the main idea of the post as opening up the data model of the terminal. the list of wishes are an example of things you can build once you've done that, not the primary reason that opening the data model is useful.
yeah! so i somehow forgot to include this in the post, but one of the thing i would want as part of this is tab complete that integrates with the shell, essentially it would make an RPC call (in the step 3 sense). there’s things that work like this already today, they’re just extremely cursed ^^ but that’s never stopped me before.
https://github.com/Aloxaf/fzf-tab?tab=readme-ov-file#differe...
I think so, yes. If you remove any of the things in the “core” I mention in the post, the language hangs together much worse even though it’s smaller; enums without pattern matching is a simple example.
I’m not just saying that I want to go back to the “good old days”, I really do think that those parts of Rust were designed as a coherent whole, in the same way that Uiua is designed as a coherent whole.
I think we are using different meanings of the term "cohere" and I am not sure how to reconcile them. I agree that Rust with async is a more useful language. I don't think being useful implies anything about how coherent a language is (I would point to bash and perl as examples of useful languages with very little coherence). "Coherence" to me means that all the features fit together tightly and are designed with each other in mind, and I don't think that's the case for async and const in Rust—simply because they aren't finished being designed.
note that RAII in Rust is not as simple as calling drop() at the end of each lexical scope, because of drop flags.
you were reading very closely, well done. yes, that is my claim, Rust was smaller and cleaner before async and const. I was so indirect about it because many of my best friends work on those features and I wasn’t sure how to word it. fortunately Matklad has worded it very well on the other site: 2015 rust was a more complete language that cohered better, but the vision of Rust is not to cohere perfectly, it’s to be an industrial language that is useful even if it’s not beautiful.
https://lobste.rs/c/b8kevh
> I understand the point they’re trying to make, that being that rust forces you to explicitly deal with the complexity of the problem rather than implicitly
This is not the point I am trying to make.
I think I disagree that you
can have a Rust program that doesn't use all these concepts, at least outside of very basic tutorial material. You will very very quickly run into compiler errors that mention them the second you write your own program.
> The author conveniently left out all of the things needed to understand that JavaScript version, including async/await, promises, modules, string interpolation, [...] not to mention the runtime that is running this, etc.
These are also left out of the Rust version.
no. the JS program has obvious syntax bugs that TS wouldn't compile. commentors above are right that I was just lazy (ty for the callout, I have since fixed the JS program).
