• 0 Posts
  • 212 Comments
Joined 2 年前
cake
Cake day: 2024年8月26日

help-circle
  • Not only would an engineer not need to consider the abstraction layer between their input and the code but they would be unable to fully interrogate that abstraction because the code extruder does not need to show its work.

    I think you’re actually right on the money here, nowhere near delusional, especially since you come from a Lisp background. I really appreciate Lisp (and Smalltalk) for the “live-coding” and universal inspectability/debuggability aspects in the tooling. I appreciate test-driven development as I’ve seen it presented in the Smalltalk context, as it essentially encourages you to “program in the debugger” and be aware of where the blank spots in your program specification are. (Although I’m aware that putting TDD into practice on an industrial scale is an entirely different proposition, especially for toolchains that aren’t explicitly built around the concept.)

    However, LLM coding assistants are, if not the exact opposite of this sort of tooling, something so far removed as to be in a different and more confusing realm. Since it’s usually a cloud service, you have no access to begin debugging, and it’s drawing from a black box of vector weights even if you do have access. If you manage to figure out how to poke at that, you’re then faced with a non-trivial process of incremental training (further lossy compression) or possibly a rerun of the training process entirely. The lack of legibility and forthright adaptability is an inescapable consequence of the design decision that the computer is now a separate entity from the user, rather than a tool that the user is using.

    I’ve posed the question in another slightly less skeptical forum, what advantage do we gain from now having two intermediate representations of a program: the original, fully-specified programming language, as well as the compiler IR/runtime bytecode? I have yet to receive a satisfactory answer.






  • Somebody vibe-coded an init system/service manager written in Emacs Lisp, seemingly as a form of criticism through performance art, and wrote this screed in the repo describing why they detest AI coding practices: https://github.com/emacs-os/el-init/blob/master/RETROSPECTIVE.md

    But then they include this choice bit:

    All in all, this software is planned to be released to MELPA because there is nothing else quite like it for Emacs as far as service supervision goes. It is actually useful – for tinkerers, init hackers, or regular users who just want to supervise userland processes. Bugs reported are planned to be hopefully squashed, as time permits.

    Why shit up the package distribution service if you know it’s badly-coded software that you don’t actually trust? 90% of the AI-coding cleanup work is going to be purging shit like this from services like npm and pip, so why shit on Emacs users too? Pretty much undermines what little good might come out of the whole thing, IMO.