Clojurians Log v2

Has the taste of inevitability to me. I think the advancement of science also lost something important when it became heavily dependent on computing power 40-50 years ago too

I do feel it's not really been doing mathematical discoveries though, as in there's no new conjecture, or theory, or algebra, but it's been finding proofs for certain existing theorem no? Or did I miss more news?

it really emphasized the compilation loop was far too slow

moving away from Haskell doesn't surprise me tbh

@dpsutton sure, but they'll soon figure out that running the test suite + mypy on a big project is not fast either

that's when they will discover a clojure REPL

Clojure isn't going away in the AI era for sure, it's wel positioned, although it was never made with that in mind

Maybe things will finally converge back to Common Lisp again :P

I'm curious what people think about this premise "the economics of software development have changed". Seems basically false to me. Companies with a need for software developers always cared about quick turnarounds and productivity, it's just been reframed in a certain way

I'm so glad I bet on clojure and not on Haskell ;)

I definitely agree that the economics of software dev have changed. An extreme example is that the bun rewrite only cost 146k. And took 11 days. Generating test corpus has never been easier. And some software projects are making their test suites closed source because porting has gotten materially cheaper and therefore feasible

Pocs have never been cheaper and debugging has gotten way nicer. I talk to heap dumps now

Definitely skeptical that the job has been automated away or even will be. But to me there are undeniable new and useful tools that have changed the economics of software engineering

> some software projects are making their test suites closed source because porting has gotten materially cheaper and therefore feasible How does feasible porting necessitate closing sources of test suites?

test suites are basically the spec of your product and if you have a good spec, it's easier to imitate

I still don't follow. So we equate writing tests based on specs to porting - alright, I can see that. Where does closing the sources come in? What's the motivation?

If tests can serve as a conformance suite and edge cases you can reimplement quite easily

There was a big project that recently did this. And saw others talking about how this was a big competitive advantage of SQLite.

But seems turso is getting there. But with an enormous amount of engineering effort

But why would you close the source code?

Or is the previous state of such projects "closed source except for tests"?

Leave the source open source. Close source the tests

Why?! :D I see no point in that at all.

"Here's a device that is perfectly repairable, everything can be taken apart and studied to the utmost detail. But we will not tell you the tolerances for those bolts and nuts, screw you."

After 34 years, Linux has reluctantly moved away from C. “We were looking at Rust”, Linus Torvalds, creator of Linux told this reporter, “since the hype wave had just reached the remote wildernesses where most hardcore Linux devs live. But it turns out LLMs have a much easier time to write Python, so that’s what were going with from here on out.”

Let me see if I can find the blog post and argument in a few minutes

But the idea is that the project is still open source. But it doesn't give a conformance suite for others to rewrite or steal edge cases

Mmm, system programming in Python... When the next bus stop, where can I get off?

btw nowadays when you have a binary or uberjar, your code is basically "open source" for AI tools kinda?

> it doesn't give a conformance suite for others to rewrite If open-source code base is available as is and does conform to its tests, purely logically speaking there is no need for those tests at all. The code base becomes the spec, that's it. Maybe I'm missing something but I still struggle to see any point in that. The test suite is also most likely written in the same language as the main code base. So in order for the suite to be useful to someone who's trying to recreate the same project in a different language, that test suite should first be rewritten into that language. And if an AI rewrite is not perfect, then all that test suite will also be as imperfect. So instead of doing a direct imperfect translation, they could be doing a direct imperfect translation of tests, and then on top of that an imperfect implementation. So what gives? And it is already open source, for crying out loud. What is there to steal? If someone wants to steal stuff, they will simple grab that code and completely disregard the license. So maybe rewriting based on a test suite can be considered legal from the POV of licensing. In that case, they can still generate a comprehensive test suite given particular source code and then generate new source code.

> Definitely skeptical that the job has been automated away or even will be. But to me there are undeniable new and useful tools that have changed the economics of software engineering > But people were always doing rewrites in python and typescript before LLMs because there were more people with knowledge of those languages out there and therefore existing people on the staff who were not hacking it (pun intended) could be canned and replaced more easily. That status quo hasn't changed except that the work can be done more mechanically now and whether or not the actual human knows X language. It's still about ability to rapidly produce code artifacts tho

> btw nowadays when you have a binary or uberjar, your code is basically "open source" for AI tools kinda? Always been the case, and not just for AI tools. Decompilers have been quite good for quite some time now, I don't even read sources all that often - just open .class in IDEA and see what's what if I need a quick glance and don't need a full understanding that usually demands docstrings.

> That status quo hasn't changed except that the work can be done more mechanically now The financial aspect has changed. Previously it cost X $, now it costs 1% of that. Low cost isn't just "the C suite and the shareholders will get more money". It actively enables things that were not feasible before. Possible, but not feasible.

I can eat restaurant food just fine - going to a restaurant, waiting, paying for that food is not a big deal by itself. That's totally possible. I don't eat at restaurants 3 time a day, 7 days a week - that's totally unfeasible due to time and money requirements.

> Something related, but different, https://github.com/chardet/chardet/issues/327#issuecomment-4005195078. The current maintainer reimplemented it from scratch by only pointing it to the API and the test suite. The motivation: enabling relicensing from LGPL to MIT. I personally have a horse in the race here because I too wanted chardet to be under a non-GPL license for many years. So consider me a very biased person in that regard. https://lucumr.pocoo.org/2026/3/5/theseus/

So yeah, licensing. So what prevents me from taking a source code for Clojure, generating a full spec of every single function and a bazillion tests per function and another bazillion "integration" tests, and then generating "MyClojure" in my language of choice, under my own license?

McClojure

a lack of tests can help prevent that

people are feeling it out. just wanted to point out that interesting bit there

Do you want a Big Gulp with your vibe coded McClojure on your customly hacked relicensed JVM?

If you have a magic code generator that can accept "should work like X" and spit out arbitrary code that adheres to that, tests are completely unnecessary. Helpful, but unnecessary. So sounds to me like it's just another temporary hoo-ha that will either be stopped by some court setting a precedent, or it will be allowed, which would mean a complete and utter devastation of open-source licenses.

and if people can't see your missing test suite, they also don't have an idea how good it actually is, so they might as well go with vibe-code cheap altImpl?

no i think it’s a notion of an established benchmark

I mean to be frank the whole open source community has already been screwed over by them training their llms on that code with no regards for licenses etc. I feel like slopforks are just a drop in the ocean

I've never looked into this stuff before getting into this thread and software licenses sort of make my eyes glaze over but it seems like this notion of a derivative work could very easily be applied to literally any human-written software that borrows ideas or patterns from other code. A "slopfork" (I guess that's the term) just takes the actual statistical likelihood of infringing patterns and content etc and ratchets it up quite a bit

For instance, if I wanted to write my own Rust version of a USB driver that had a C implementation, I'd probably take a good look at the original code, and thus be influenced by it

as i understand it, basically none of this stuff is really litigated and the cost of litigation makes this eye watering for almost anyone but large corporations unfortunately

Fun times, fun times... Good thing I got that welding machine. I should really start learning how to use it properly.

Historically, trying to battle Microsoft in court has gone badly for people and companies

Hey I wanna learn to weld too, seems so cool

Closer to clojure is scala which certainly feels the same pain as haskell regarding compile time. Not sure many scala devs will go to clojure though...

The economics of software has completely changed. Companies have an insatiable appetite for software, but for a long time, building systems has been extremely expensive and fraught. As a result, the cost-benefit analysis has usually come back as “not now.” With the correct use of AI, which is still something of an art, that has changed and will continue to change. The amount of software being written will increase dramatically. Jevons paradox. The number of job ads for programmers has also increased dramatically in recent years, which runs counter to the original narrative. And, yes, given this is the ai-skeptics channel, I apologise in advance for my annoyingly positive tone :-)

> We put Haskell through a serious production test, and many of its promises held up. The code was reliable. The type system caught real bugs. The language forced us to be thoughtful about how we modelled our domain. High performance code has been generally straight-forward to achieve. More appropriate title: After 7 years in production, Scarf has reluctantly(?) changed their priorities. Everything they said was important to them and Haskell was good for, was by their own admission thrown out the window when switching to the new development flow. Notice that in the article they do a 180 on all of these above stated benefits. So it would be more honest to stop comparing Haskell to Python; and instead write an article on the choice of pivoting their business and engineering focus.

It is very infuriating that LLMs draw people away from lisps or any other PLs that aren't mainstream. Even though LLMs benefit from lisps

If I understood what the crux of it is, he doesn't think there's any hope of it going away, so he's resigned to instead learn how to leverage it in ways that are good instead of bad. And he's found that if you are kept in the loop, and review/steer the models it results in higher quality output than without.

I was kind of hoping he was going to say: I agree with all criticism but I'm lazy so I still use AI 🤣 , but I guess that's just me then.

The people selling the shovels don't even accept gold as payment.

> The LLM Critics Are Right. I Use LLMs Anyway. He does not understand the critics. > It is full of copyrighted materials, yes. It is bad for the environment, yes. All the ethical problems, yes. Not bad a bad start, but he does not describe or address these concerns at any other point in the article. He also leaves out many other important negative effects. > Let me go through the biggest ones one by one. > Let’s start with the most common critique “LLMs produce a lot of slop”. This is a problem, but I don't think it is the biggest problem. Overall, I find his argument problematic because he pretends to address the critics, but instead, mischaracterizes them.

I think this really comes down to "people use LLMs because they want to" and "people will come up with post-hoc rationalisation to justify the choices they make". Most of us make choices on a daily basis that we know are not ideal, morally or ethically. Because we want to, because it's convenient, because we don't experience the negative consequences ourselves, and everyone else is doing it, and do you really want to be like those zealots that are eschewed by polite society? The marketing has been tremendously effective here. It made it seem like eveyone was/is on board, which makes it socially acceptable, and makes you feel like the odd one out if you opt out. And really they're so convenient, and so addictive... I empathise with the dissonance, I really do, cause I am not free of LLM usage either. But let's be clear to ourselves and admit that, even though we nominally subscribe to certain values, some of us are in this case choosing not to live by them. Instead of blogging our rationalisations in the hope someone will come along and say "you are right, those are good reasons, you are absolved".