midnight_eclair

that doesn't make sense, why would they be talking about departure from traditional lisps if they weren't talking about macro-based DSLs?

> DSLs typically involves constructing macros that are domain specific

a DSL is a constrained language for expressing domain concepts.

in traditional Lisps they are often syntax-oriented, because code is lists and macros are a natural tool.

in Clojure, pervasive use of keywords, vectors and maps allows you to shift DSL design towards data interpretation rather than syntax transformation.

so in Clojure doesn't discourage DSLs - clojure practicioners simply prefer data-oriented DSLs to macro-oriented ones, mostly because they are easier to reason about and process with existing tools, while macros are used more selectively.

> I'm not sure a framework is really going to change that onboarding process, or help with network effects that much

having one commonly accepted and recommended way does improve onboarding, because it collapses the decision space beginners face. right now they are supposed to make decisions (not even directly, but just through selecting one of the many frameworks) about things like:

  1. which project templating tool to use? (lein, clj-new, neil)
  2. which dependencies management tooling to use? (lein, deps)
  3. which build tooling to use? (lein, tools build, boot)
  4. which web server? (jetty, httpkit, undertow)
  5. which routing library? (pedestal, reitit)
  6. which templating engine? (hiccup, rum, selmer)
  7. how to deal with javascript and it's build tooling? (clojurescript with a host of it's own decisions, bolt ts/js and wire it yourself, dodge that completely with htmx)

whats worse - most of the alternatives overlap in various ways, so making the "best choice" in order to reduce future headache induces quite a bit of anxiety.

yes, multiple frameworks exist that make those choices for you, but then you inevitably hit the problem that some of the components haven't been updated in a while, so documentation is out of date and when you try updating it just for your project you need to fix the framework plumbing and due to number of frameworks, the corpus of useful information on the internet is quite fragmented and the community help is limited, and on and on.

none of this is good beginner experience.

and don't get me wrong, choice by itself isn't bad, focus on composability of smaller libraries is important, dominant framework is not going to improve anything when it locks people into bad decisions.

what we lack is convergence behind a single "reference stack" of libraries that ought to be good enough for the general case and a minimal framework of plumbing that doesn't require dozens of files just to get started.

there doesn't need to be a single way of doing it, but there needs to be a single recommended way of doing it.

it really isn't, unless your goal is to scare away the casuals.

no, not really. when people talk about DSLs in context of lisps, they usually still mean staying in the domain of s-expressions.

yep, every word.

clojure itself is a joy to use, on the web or outside of it

BUT

it doesn't have the equivalent of rails, mostly because lispers are an opinionated bunch and can't come together to agree on how web development should be done

the frameworks that do exist are more of a collections of libraries with some plumbing to connect the dots

> Clojure style discourages building DSLs

does it really? https://github.com/simongray/clojure-dsl-resources

the wonders of visibility algorithm: https://news.ycombinator.com/item?id=47556827

virtually all abstractions are built on top of primitive data types and mappings

we're in the age of idea-men and garry is their prophet.

tests generated based on normative spec to validate if the implementation accepts the right inputs, rejects the wrong ones, produces correctly shaped outputs and to some extend also validates behavior.

normative specs allow generation of such tests deterministically - no need to spend tokens, no risk of hallucinations, much higher level of confidence that generated code is correct and much more accurate feedback from the test system into the LLM loop.

> Test specs with enforcement — test cases can be described as sections in lat.md/ and marked with require-code-mention: true. Each spec then must be referenced by a // @lat: comment in test code. lat check flags any spec without a backlink, so you can review and maintain test coverage from the knowledge graph.

if you mean this paragraph - imo that's still too hand-wavy compared to enforcement through generative tests for spec conformance.

i've had a related question recently but it didn't get much traction

https://news.ycombinator.com/item?id=47543324

what's the point of markdown? there's nothing useful you can do with it other than handing it over to llm and getting some probabilistic response

> text files with instructions to the LLMs

this is true for both mardown and normative specs

what's meaningfully different is that normative specs is something you can deterministically check for conformance with, use generative tests, etc and feed that information back into the agent loop

letting the same LLM generate both implementation and tests from markdown prompt is a) completely meaningless, because once the agent is done and test suite is green you still have no idea if the right thing was implemented and if the right thing is being tested; b) useless waste of tokens, because why would you spend them on probabilistic generation of tests that likely contain hallucinations if you could instead deterministically generate them from normative spec using external tool

this will work for your hobby projects, but not for larger codebases or constellations of systems where agent output grows faster than your ability to understand what is going on.

if it is your belief that understanding what is going on is not necessary nor important - agree to disagree.

my bad

~not unified memory tho~

i'm sure apply support is just one PR away, why shy away from it? embrace!

i encourage it - the faster and the more colorful this makes infrastructures around the world blow up and burn down, the quicker we might actually learn how to be resilient in presence of the ultimate chaos monkey.

can't wait to wreck my infrastructure in ways and with speed not conceivable before!

i returned to rails in 2025 after 12 years pause and my experience has been frustration and annoyance

rails lost it's convention over configuration ways, the generated app is dozens of files, lack of explanations and guidance on how to setup various things like environments, kamal being the worst offender and the changes between recent major releases aren't making it any easier to read the (often ai slop) articles and docs

llm-generated is for corporate mail

llm-assisted for when i care about precision and accuracy

brain-generated for when i feel safe to make mistakes