It definitely is vibe-coded, but yogthos is a competent programmer who has been working on public Clojure projects and repos since 2009, and has maintained a large Clojure framework since well before LLMs were a thing.
I don't think "2k commits in 2 months" is enough to dismiss as slop when it's being developed by a competent Clojure dev.
Competent or not, slop is still slop. The website in particular uses the exact same copy-paste layout/style produced by LLMs and used by pretty much every slop project out there.
One very quick "slop or not?" test is to see if em dashes are used in the source code where they literally never make sense. It's not a great test, but it's one that consistently turns out to be good enough. The results should speak for themselves: https://github.com/search?q=repo%3Ajolt-lang%2Fjolt+%E2%80%9...
The website layout is the same one I used in projects like Luminus long before LLMs even existed https://luminusweb.com
If you have specific comments about the quality of the code then I'd be happy to discuss that. Attacking other people's work because they used tools you don't understand is just toxic trolling. And the fact that you judge code quality by the number of em dashes in the comments really speaks volumes.
Maybe spend a bit of time figuring out how to use new tools effectively instead of harping on what other people are doing.
It's very telling that whenever somebody starts braying about slop, they never have anything of substance to say. All the noise you add to discussions people are trying to have is the real slop.
If you consider all AI generated text or code slop, then sure, the project's code is AI generated.
But in my case I think there are levels. In this case, the author has the expertise needed to properly design the work and assess the quality of the output. And it seems they intend to maintain and evolve the library actively and long term.
Would I prefer a serious Clojure on chez that's all hand-written, for sure, but beggars can't be choosers.
I am almost certain that, on a daily basis, you use dozens (or hundreds) of things that:
1. Were produced via plastic injection molding.
2. Were machined by CNC.
3. Have PCBs that were fabricated by machine, milled by machine, and populated via pick-and-place machine.
4. Were laser engraved, or silk screened, or printed.
5. For food/foodstuffs: were processed in an automated factory.
When you use all of these things, do you complain about using/consuming something that someone "couldn't be bothered to hand craft"?
If you don't see/anticipate the utility in a thing (like I don't have any interest in wicker baskets, hand crafted or not), why complain about that thing, instead of just moving along? I'd get it if you wanted to provide constructive feedback, but you can't do that if you're not willing to read the code.
Harboring (and expressing) negative sentiment for things that you opt to not be involved in sounds like a recipe for misery, as there's an infinite number of things to actively dislike if you go looking for them: movies/music that aren't to your tastes, mediocre restaurants, cities you wouldn't want to live in, etc.
I really love how people keep trotting out this straw man man that working with LLMs is just typing a prompt and then having LLM magically produce a working project. In practice, you obviously read the code to understand if it makes sense, and iterate on a solution just as you would when writing it by hand.
All you're doing here is exposing the fact that you have no clue how these tools actually work, or how to use them effectively.
It makes me wonder if these same people take issue with task delegation in software development: is it also problematic when a staff engineer delegates tasks across teams, or a senior engineer mentors a junior developer?
It's such a stifling, self-limiting belief that it's actually saddening :(.
It's also a hypocritical belief: the machine they used to type out these thoughts were assembled in a factory, using CNC, pick-and-place, laser engraving, plastic injection molding, etc. With the exception of a few things (ex: the silicon itself) all of these things could be hand crafted - it would just make the price of computer impractical. Commoditization is a good thing, and automation is necessary for that.
I can only imagine that what is actually happening is that these people are attached to the craft of software development, and AI represents a threat to that, just as CNC milling has displaced manual machinists. But then everyone would be better off if they found an appropriate place to vent that frustration (a therapist? a friend? like-minded forum dedicated to AI complaints?), rather than projecting onto (and leveling complaints at) people using AI.
If said staff engineer would then claim junior’s work as his own, then yes. But for an entirely different reason, as well as this whole analogy doesn’t work here.
I'm a Jolt user and active Clojure user, and I'd say you're right in a sense.
The caveat is that this isn't typical AI slop. The author knows the subject deeply, designed the system themselves, has extensive Clojure test suites to validate against, and has basically been working on it 24/7.
Can you trust it like a compiler someone spent 7 years writing and knows line by line? Probably not. But it's closer to alpha software than useless slop. As more people use it, we'll find out how robust it is, and whatever issues exist can be fixed as they're found.
So ya, I agree you shouldn't be asked to review AI generated code the author didn't review themselves. I think the ask here is more to try it and see how complete and robust it actually is. And even that only makes sense because the author is a known expert who appears to be steering the model carefully.
The real question is why you feel the need to comment on something you don't care to understand. Thanks for admitting you're just trolling and there's no point trying to engage with you.
'Slop' is a word about quality, like in 'AI slop' - a low quality code generated with LLM. Did OP managed to achieve reasonable quality notwithstanding the speed? I don't know yet, but unless you can point to something sloppy in the repo, calling it slop may not be warranted.
This is such a disingenuous, childish, immature and ignorant take - I can't even remain calm without getting angry.
Have you ever, kids, tried building anything useful? Anything practical, anything that actually works, anything beneficent? With or without AI?
Well, if you have in fact ever tried, perhaps you'd know that building reasonably complex software remains a difficult, challenging, unappreciated work. With or without the help of any tooling. AI-assistants included.
Maybe try building something good first. Earn your right to throw the first stone, come engaged, come prepared, ask questions.
What you're doing is a fucking slop. Human slop of ignorance. Worst kind.
This appears to be vibecoded but not disclosed as such. 2k commits from a single author starting from June 1st with really long commit messages and source code comments. The GitHub org has 19 additional projects that are all recently created.
I think the author has been very open about the use of LLMs. And while I am very wary of LLM slop, this is one use case where it makes complete sense to utilize them to the fullest. A Clojure implementation already exists for LLMs to reference, and tons of test cases to verify behavior. It doesn't get better than that for LLM usage.
What are the best books/papers/blog posts to learn about Morphic's architecture? I'm not a user of any Smalltalk implementation but I'd like to learn more as the Smalltalk approach to UI is very interesting.
After Self, the short lineage is Self (~1992, Smith & Maloney) -> Squeak port (Maloney & Ingalls, Etoys/Scratch 1) -> two independent JavaScript reimplementations, plus Squeak-in-the-browser via SqueakJS.
I dug into this same question a decade ago and posted a longer treatment -- my email exchange with Alan Kay on MVC vs Morphic vs watchers, plus replies on Self's "soup of objects" UI. Good philosophical complement to the architectural links below:
Self Morphic is not a classical class hierarchy. The handbook describes parallel traits objects (shared behavior) and prototypes (structure), with instances delegating via parent* slots and "copy-down" differential prototypes. Bottom-up: morph copy, tweak, factor shared behavior into a traits object. Worth reading section 7.3 alongside pjmlp's links.
The Squeak port is single-inheritance Smalltalk classes -- closer to what most people mean by "OOP UI toolkit." Etoys is Morphic. Full Squeak Morphic in a browser, no install:
In JavaScript there are two Morphic implementations people often conflate. Same family, not the same code.
Dan Ingalls's Lively Kernel / Lively Web (~2008, Sun) is the full live system: modular core/lively/morphic/ (Halos, Serialization, Scrubbing, Connectors, constraints), plus IDE, parts bin, world persistence. JSConf 2012 demo:
Jens Monig's morphic.js (~2010, BYOB4/Snap!) is a separate codebase: single-file Canvas kernel (~13k lines), World/Hand/stepping/dirty rects, template peel-off, ScrollFrame inertial pan. Jens names Ingalls's LK as the gold standard but says it is not a direct port -- though fullCopy() was ported almost literally from Squeak, comments included. Snap bundled it from day one (2013-03-16). Standalone extract:
On multiple inheritance: neither JS port uses it, and Self Morphic didn't really either. LK cheats with an explicit Trait composition layer (Object.subclass plus Trait(...) mixins). Snap cheats with Squeak-style copying (fullCopy, isTemplate peel-off). The live feel comes from copyable morph trees and shared behavior, not MI.
If you want one more readable architecture tour beyond sin-ack's intro, the Self handbook chapter 7 is still the root document; everything else is commentary on it.
I vouched as well, but it's [flagged][dead] not just [dead] which is usually the result of user moderation, not the mods or auto moderation (which typically will just render as [dead] in either case). Which was odd because it was [flagged][dead] by the time it was 4 minutes old (maybe earlier, that's just when I saw it).
After Self, the short lineage is Self (~1992, Smith & Maloney) -> Squeak port (Maloney & Ingalls, Etoys/Scratch 1) -> two independent JavaScript reimplementations, plus Squeak-in-the-browser via SqueakJS.
I dug into this same question a decade ago and posted a longer treatment -- my email exchange with Alan Kay on MVC vs Morphic vs watchers, plus replies on Self's "soup of objects" UI. Good philosophical complement to the architectural links below:
Self Morphic is not a classical class hierarchy. The handbook describes parallel traits objects (shared behavior) and prototypes (structure), with instances delegating via parent* slots and "copy-down" differential prototypes. Bottom-up: morph copy, tweak, factor shared behavior into a traits object. Worth reading section 7.3 alongside pjmlp's links.
The Squeak port is single-inheritance Smalltalk classes -- closer to what most people mean by "OOP UI toolkit." Etoys is Morphic. Full Squeak Morphic in a browser, no install:
In JavaScript there are two Morphic implementations people often conflate. Same family, not the same code.
Dan Ingalls's Lively Kernel / Lively Web (~2008, Sun) is the full live system: modular core/lively/morphic/ (Halos, Serialization, Scrubbing, Connectors, constraints), plus IDE, parts bin, world persistence. JSConf 2012 demo:
Jens Monig's morphic.js (~2010, BYOB4/Snap!) is a separate codebase: single-file Canvas kernel (~13k lines), World/Hand/stepping/dirty rects, template peel-off, ScrollFrame inertial pan. Jens names Ingalls's LK as the gold standard but says it is not a direct port -- though fullCopy() was ported almost literally from Squeak, comments included. Snap bundled it from day one (2013-03-16). Standalone extract:
On multiple inheritance: neither JS port uses it, and Self Morphic didn't really either. LK cheats with an explicit Trait composition layer (Object.subclass plus Trait(...) mixins). Snap cheats with Squeak-style copying (fullCopy, isTemplate peel-off). The live feel comes from copyable morph trees and shared behavior, not MI.
If you want one more readable architecture tour beyond sin-ack's intro, the Self handbook chapter 7 is still the root document; everything else is commentary on it.
Can I suggest you take a look at Cuis Smalltalk (a simplified fork from squeak), and any of the talks given by Juan Vuletich (main author of cuis). In Cuis, Juan took morphic back to basics and updated it heavily. Now submorphs use relative geometry (not absolute), and everything is hardware accelerated vector graphics - EVEN THE FONTS.
Seriously, reading Unicode enhanced code in a 45 degree tilted editor window, while zooming in and out just for kicks (all of this can be done by manipulating the morph with its halo's menu) just to see how crisp everything is - thats FUN!
Also, try taking apart the standard system browser (4 panes + editor), rearrange everything as per your tastes (by drag & drop), and ... everything still works
Posts like this remind me how much JavaScript could benefit from something like Lisp's quasiquote. JSX is a terrible creation but templating in JS is pretty unpleasant without quotation operators. That said, I think Mithril's 'm' function did it the best of all libraries I have seen.
I'm not sure what they mean by "native" here but (ref extern) is for host references, JS or otherwise. The i31 type is for "immediate" values, things that can fit in 31 bits and thus don't need to be allocated on the heap.
What would you call 2k commits in 2 months by a single committer if not slop?