Clojurians Log v2

You'll never hear from an LLM proponent the idea that Lisps are best languages for LLM-assisted programming, although that is true. LLMs hallucinate. They invent names of functions all the time, put inexisting variables, leave dead code around, and so on. But the bane, as is with humans, is subtle bugs. With LLMs they happen more often because the clanker does no thinking about the problem, does not enter flow state where some convoluted shit code that takes days to understand makes perfect sense and acts almost exactly how a programmer predicts it would. Have you guys read Karnap's "Overcoming metaphysics..."? He made a roadmap for logical positivism: create such a formal language in which you will not be physically able to express metaphysical jibber-jabber that has no actual precise meaning based on empirical data and inferred laws of nature. They later found this to be a bad idea for science. However, this very mechanism is how programming languages actually progress from lower level to higher level (btw this is why analitical philosophy doodoo is appealing to programmers. i'm calling it doodoo to piss you off). There is a whole class of errors that you can express in asm but not in C. A class of errors possible with for loops that use indexes but not with iterators. A class of errors possible with manual memory management, but not with garbage collection. A class of errors possible with manually writing schedule breakpoints in threads for async-like behavior, and impossible with green threads or core.async. And so on and so forth. Further, each domain may need such a specific formalized language, that it won't need all the liberties that exist in a general purpose programming language. A DSL may remove variables, mutation, functions, it may strip everything, and leave only 3 keywords that are needed in the domain and tied to each other, expressing only valid logic for the domain and avoiding entirely any programming error outside of domain errors. So what about giving LLMs 2 things: 1. Structured outputs in s-expressions (so that it doesn't confuse parens with brackets etc.) 2. The usage guides for a bunch of DSLs that are extremely narrow in their use cases and are almost error-proof because of their properties. You as a programmer will get less code to review. The glue between the DSLs will stand out as a place to look for possible errors. The DSL code will be pretty readable and some contradictory instructions too will stand out much more than if the code had if err != nil sprayed all over it. If we don't assume clojure, but a lisp that compiles to native and controls the entire stack, the DSLs may even automatically provide highly-specific annotations that enable aggressive optimizations. This is a win-win-win scenario. Why then don't we hear such opinions? Not even from the clojure community? I'm following a common lisper, and he too doesn't point this out. So, what's up? Why is it, that expensive precious tokens are wasted on if err != nil and even on attempts to... generate assembly with LLMs... I wrote this sentence with utter disgust... This is vomit-inducing, isn't it? Well, the spirit of Paul Graham and of the other righteous warriors for lisp has left most lisp communities. It is a fact. It is considered "cringe" to be fighting for lisp today. Because we folded under pressure. No wonder, even Paul Graham lost the spirit of Paul Graham! The guy's startup accelerator boosted OpenAI, so I'd say this is as close to treason as it gets. I'm not accusing those who choose not to fight. Not everyone is capable of going against the current their entire life. Hell, I'm writing this from the POV of a fighter, might feel condescending, but who knows what the next cruel blow from life I'll receive, how I myself will go away. But anyway, fighting is still important. And using logic and bettering our tools to get better end results will lead us to eventual victory. A positive thing I see is what Rama and Electric do. They got the hang of the idea that I pointed out. They hove figured out how to turn the power of lisp into words that LLM fans like to hear: less token use, more results, better results, more reliability, solutions to problems such as code churn and tons to review. I mean imagine a backend that Rama can do, but in Go. You'll be looking at millions of lines of slop, all of them containing subtle concurrency issues or whatever. With Rama, it's thousands of lines, most issues that you'd face with Go wouldn't be even possible to create. A super reactive constant stream in Electric? 10 lines. In React/raw js with websockets? Thousands of lines. Do you remember the not-so-smart objections and demands to "show how exactly lisp is useful"? Well, this is it, congrats. You can show the token count to the pointy-haired bosses and say "lisp when token less, more cheap. non-lisp when token much much more, less cheap, bad business!!!" Who knows, maybe if Uber used lisp, they'd actually see the benefit from LLMs? ;)

I must note that nowadays, even for projects that deal with topics that are interesting to me, when I see that they have any amount of vibe coding, I immediately think well, if that can be vibe coded, why would I even use that project? If I ever need that functionality, my agent can certainly out-slop that! In all seriousness, I don't know why at this point in time anyone thinks they'd impress anyone with autogenerated content? Slop's a dime a dozen trillions.

And once again - note the abyss between "made with some help from GenAI" and "completely vibe-coded". Every single "we want X" discussion here has people not differentiating the two.

Yeah that's the irony. If I want to slop I can make my own and it's more likely to suit me better than random slop. I guess when tokens become really expensive that might not be an option and I'll have to consume second hand slop. What a time to be alive.

+1 for human spaces.

Can anyone please outline the logistics for your poor p-himik? How would that work, in detail? Do the members manually check every post in #C06MAR553 and then re-post it in #human-announcements if the announced project has zero visible AI usage? Or are people invited to be honest about it and cross-post everything they do themselves? What happens when someone suddenly uses an LLM in a single commit? Do they get ostracized? We've discussed all those things already, just scroll a bit higher. It's exactly the same as every other suggestion under the "we want X" umbrella, with exactly the same problems.

Awhile ago some people here decided that they will be reacting with 🤖 to announcements of projects that used GenAI to some unspecified degree. The last usage of that reaction was more than 3 weeks ago. Just a single reaction. So either even just checking an announcement and reacting to it is way too much work, or there are simply not that many announcements here that warrant any action. That was a false dichotomy - naturally, it's both.

I have VS Code configured so that if Copilot even contributes some auto-complete of text, it gets a co-author credit in the commit. So, this commit was co-authored by Copilot—a one-line addition to the CHANGELOG: https://github.com/seancorfield/honeysql/commit/a9a01587102d554e1ad9de634450881258be1b9f I don't remember what auto-complete suggested there but I suspect it was the URL after I typed PR [#603]. Looks like five commits to HoneySQL in the past month got AI-assisted auto-complete somewhere in the committed changes—and it looks like all five of those were primarily changelog or readme updates, with one auto-complete involving deps.edn I believe. Does that honesty about auto-complete make people here not want to use HoneySQL, because I accept Copilot-suggested auto-complete fragments occasionally? Just trying to figure out where the line is here...

I think the problem is, how do I tell? How do I know it is just a bit in the changelog, and you read it? How do I know which parts of the pr are you and which parts are a LLM? So commits from Claude, copilot and others would be enough. I figure the way people would know if it was human made is that they would brag about it tbh. If it is important enough to do it the amount of effort nowadays justifies the bragging

And yes, it does give me second thoughts about honeysql and would be part of my decision making process about using it

@p-himik Let's keep in mind that when someone just "used some help from AI" I wouldn't even know, just like I don't know whether any programmer personally typed the whole identifier, or it was autocompleted by vscode or whatever tool. People complain about blatant AI, projects and texts where the authors themselves did not take time to understand properly, or at all.

Of course, but people here have had problems with even help from AI, not only vibe coding. The OP clearly states: "things that are made w/o GenAI". Not "things that aren't vibe-coded". > I figure the way people would know if it was human made is that they would brag about it tbh. I have seen it maybe 3 times in total. Virtually nobody does that. > If it is important enough to do it the amount of effort nowadays justifies the bragging Important to whom though? Why would it be important to an author of a project to brag about the fact that they haven't used GenAI or haven't vibe-coded the project?

Re: bragging - the feeling of being surrounded by vibe coded stuff has really been hitting me three last few weeks (human Emacs and gcd008 in guix being other responses). Projects have been changing underneath me. I've been looking at starting a new project and trying to find libraries has been difficult.

What does any of that has to do with the Clojurians Slack though?

> Projects have been changing underneath me. In no way would any kind of a new channel alleviate that.

Slack is a community space where we discuss clojure and projects and I'm wondering if there are other people willing to discuss a similar subset to me and this channel doesn't seem to be the right place to do it

If you have a topic that fits a particular channel and the only gripe is that you don't want to hear anything GenAI-related, then just post a message and specify that you want to hear only about purely-human-made things. That's it, that's all it takes.

As there is another thread talking about the trade offs of a human clojure channel, I'll start a new one here for people who are actually interested in having one or more #C0JDVNT6J-* channels and what they might be

I'm also tired of deciding what is worth my time paying attention to now there is a ton of information and is hard to tell apart interesting stuff from pure slop. That said I don't think it is a good idea to push for "interesting iff not AI involved" or tie AI usage to projects and authors reputations. IMHO that does more harm than it helps.

Back to HoneySQL, since I think it's a good example for this topic of discussion... At first, I had VS Code configured so only actual generated code triggered the Copilot co-author tag. That was VS Code's default. I saw no commits crediting Copilot in my OSS projects, even when I thought I had used Copilot to write some code—but I think that was because I was double-checking all the output and often tweaking it so it wasn't "purely genAI". At work, there were several commits that credited Copilot as a co-author, so I knew the machinery worked. But because of discussions here in #C0B7Q4XRM1U I was curious about the line where VS Code/Copilot considered the co-author credit and adjusted the setting to also flag for auto-complete. That made it pretty clear that a lot of the auto-complete suggestions I got (and accepted) were not coming from Copilot. Work pay for Copilot. They expect me to use it. I do OSS work on the same machine, with the same editor/config, so now I can see the extent to which auto-complete comes from Copilot or not in that OSS work. That's why I asked how folks here would react to seeing a Copilot co-author on a commit, when almost all the other commits don't. I could easily go back to the default VS Code / Copilot setting and no one would ever see whether my auto-completed code was "just" VS Code or was from Copilot. I agree with jp here that treating projects and maintainers differently because the auto-complete suggestions they accepted came from an LLM rather than just their editor seems... problematic... If the line y'all draw is "absolutely no AI involved at all in any way" that's going to cut you off from a lot of software. If the line is "absolutely no projects that were vibe-coded", that's a very different position to take (and I have a lot of sympathy for that).

The problem is that as I'm not the author, I don't know what the extent is

And yeah, it will affect a lot of software, and some things are harder to avoid than others (like Linux)

You cannot know, in principle, at all. Even if someone says "I wrote it all myself and never used any kind of AI", you just cannot know.

I would think it's absolutely no-AI generated content/code. I'm assuming here we're not even talking about projects. But channels where discussions should be about human-only generated content/code. That could include projects that are like that, even if there's not many.

Sean: (filter pred coll) #ai-skeptics: LGTM. GenAI: (filter pred coll) #ai-skeptics: Straight to jail. I mean, come on...

Why not? It's like fair trade vs normal trade, the process matters to some.

@p-himik See other thread about how many channels

@p-himik the obvious place to start is by finding a community of like minded people and move from there. It has worked for me in the past. I hope it does now

@p-himik Why don't we try with #C0BLJS63J2Y?