I mean the goal is that the money invested increases the value of the company so that the founder's reduced stake is worth considerably more than the founder's full stake of the counterfactual company where he didn't take VC money. VCs can be strongly positive sum.
Because LLMs are not humans, and the code they produce will have a different distribution of failure modes than human written code, so attribution is useful info while reviewing?
Nope. It cannot be assumed at all. Maintainer could just as easily tell Claude to review the hand written code you sent instead of spending any effort on it. Maintainer could sit on the patch for months on end only to swoop in later and rewrite it instead of engaging with you, thereby erasing your contribution and attribution. Maintainer could just ignore you entirely despite the pervasive "patches welcome" attitude.
If there's one thing I learned not to do in open source, it's to assume nonsense like that.
I'm referring to the fact that "open source" quite literally means "readable by humans [and machines]", and anything beyond that is a subject of debate. There are more users than readers in nearly all cases, but being able to read the code as a user is a significant benefit at times, and it's one of the reasons it's such a large ecosystem in terms of both users and contributors. (it usually being free is another big reason, of course)
Even with coding agents gaining popularity, many humans still look at the code at some point.
I see. That depends on how much I care about the project. My favorite ones get weeks of review and refinement, to the point I still consider them to be more or less hand written. Not all projects get to be that important.
It's fascinating that Clojure has consistently the best performing solutions and yet at the same time such a low success rate.
Do you have an idea as to why that is?
If I had to guess, two things lowering reliability:
A) Balancing parens might be tough on an LLM one-shot.
B) LLMs generate tokens sequentially, but s-expressions mean the first forms to be evaluated in a body are usually the last to be written, so the LLM has to sequentially generate layers of evaluation backwards.
First, we would need to agree on what "such a low success rate" means. Programmers have a thundering herd mentality: there are usually 2-3 "top things" that are in fashion at any given time and the herd tends to go towards these top things. They are not necessarily good or "successful" (however you define that term), they are just popular today.
From my point of view, Clojure is a very successful language. It has been in stable development for >10 years now, with no major breaking changes (!). I was able to start a business using it and now make a living from it, all of it possible largely because Clojure reduces incidental complexity so much.
Now, as to LLMs, I can see this discussion is mostly theoretical, so let me pitch in with data. I've been using LLMs for Clojure for a while now and it works fantastically, from what I read about other languages, quite a bit better for me than for others. Balancing parens was a problem for early LLMs without tools, Claude Opus with clojure-mcp tools doesn't encounter that problem at all.
Additionally, the ability to try things in the REPL means that LLMs are very effective: all hypotheses and solutions are immediately tested, with automatic feedback.
Overall I get great value from LLMs and I am able to solve large problems with them.
I've found it helps to give the model a lower nesting limit than you might give a human who has access to a paren-balancing editor. If all functions are shallow, there's less opportunity for paren balancing to get out of control, and reasoning about the evaluation flow doesn't have to jump back and forth so much.
This also doesn't hurt the code from a human reader's point of view.
If B), then maybe the LLM should be instructed to prefer things like the -> and ->> operators. So the first forms evaluated are also the first written.
As someone who loves Clojure, I wonder about the real portability across host languages. Do you have experience with any of these other dialects? (beyond the obvious CLJS & Babashka?)
I build and maintain Portal, which runs on multiple platforms including: Clojure, Babashka, ClojureCLR, ClojureScript, nbb, joyride, basilisp and soon jank. The main thing that's different per platform is the os/fs/http/ws libraries but the runtime state and serialization is all the same and reused across all platforms. Also, recently I was able to get most of Portal's reagent viewers, which were designed primarily to run in a browser via ClojureScript, running on the JVM for Server Side Rendering. Clojure is the most portable language I have ever used!
I am learning Clojure this week, and my test project is a calculator / unit convertor [1]. I wanted it to run in the CLI and on the web, so it targets several hosted platforms: Babashka / JVM / ClojureScript. It's a single code base written in cross platform .cljc files. I already have about 250 tests written for the abstract calculator API, run as a test matrix across platforms, so the project is already in a good place for testing a new runtime.
I just learned about basilisp from the parent comment, so I asked Claude to add Python support to the same .cljc files I have, and we finished the port in about 30mins, and then fixed Python specific test cases for another 30 mins, but now all of the existing tests are passing. That's impressive in several ways.
Portability is achieved by testing. You have to put the platforms you want to support into your test harness, and the earlier the better. A calculator is purely functional, so this is a fairly straight forward port and really easy to test for. I'm not sure about larger projects, but it seems like there is something seriously right about Clojure's design that makes this easy to do.
Absolutely agree. Recently learning emacs with vertico/consult/orderless/embark has had me thinking constantly about how needlessly crippled most OS windowing system workflows are.
It is absolutely painful for interviewers and candidates. I used to be able to email managers & founders directly and discuss what they were looking for... today everybody is navigating a deluge of spam and the interview process is becoming dysfunctional.
It was.. but not in the way people generally think. Im not a native english speaker. Therefore, I use chatgpt to fix my comment sometimes. This was done the same way.
I get it and I'm not trying to get down on you, but I've seen people around say this and it bugs me.
I don't know Japanese at all. Sometimes I use LLMs to translate discord messages into Japanese so I can communicate with Japanese people. Then as verification I translate the messages back (with different LLMs) and they usually come out as a near-verbatim version of what I wanted to say. In other words, they don't come out in the chatgpt style of writing.
If I'm able to do that, then chatgpt should be able to fix your English without chatgpt-ifying the whole comment.
I agree. I'm as skeptical as many commenters but I also think the degree of polarization in HN around this technology and the degree to which people are calling those with different views shills or naysayers is pretty sad.
There's nothing sneaky about terms & conditions. If the gov wants a service they legally need to abide by its terms, same as us, if they don't like it they should choose another product.
Anthropic doesn't want their AI used for misaligned mass surveillance scanners and killbots, there are obvious reasons they might not want that.
reply