S/or, но учесть, что confirm добавит ключ метки

И после confirm поправить структуру

Честно говоря, если вот хорошенько подумать, я и не могу сказать, чем кложа сильно лучше, чем альтернативы. Мне профит видится в том, насколько сам язык хорош, насколько у него хорошая экосистема, интероп с основными платформами и высокое качество коммьюнити. Как язык кложа мне кажется просто одна из лучших инкарнаций динамических языков. Казалось бы, макросы это отличительная киллер фича, но все понимают, что надо их пореже использовать и в целом они редко используются.

Так как язык и многие инструменты для него хороши и удобны, но язык все же немейнстримный, то привлекает к себе в основном энтузиастов, которые ищут the better way

Думаю, что все прибавки продуктивности засчет 1) хороших либ и абстракций 2) интерактивная разработка 3) кодит энтузиаст, а не выпускник курсов по js на зарплате

Не понял

Если это про то что я не правильно написал s/or то это да

Завтра подробно отпишу

А вот как с s/or потом искать в чём ошибка, ведь оно все саб-спеки выводит в s/explain-data
Типо вот три проблемы, две из которых с delete
{:problems
 ({:path [:add :data],
   :pred clojure.core/map?,
   :val 1,
   :via
   [:server.spec/req
   :server.spec/add
   :server.spec/data],
   :in [:data]}
  {:path [:delete :method],
   :pred #{"delete"},
   :val "add",
   :via
   [:server.spec/req
    :server.spec/delete
    :delete/method],
    :in [:method]}
  {:path [:delete :data],
   :pred clojure.core/map?,
   :val 1,
   :via
   [:server.spec/req
    :server.spec/delete
    :server.spec/data],
    :in [:data]}),
:spec :server.spec/req,
:value {:method "add", :data 1}}

Вот спека
(s/def ::data map?)
(s/def :add/method #{"add"})
(s/def ::add (s/keys :req-un [:add/method ::data]))
(s/def :delete/method #{"delete"})
(s/def ::delete (s/keys :req-un [:delete/method ::data]))
(s/def ::req (s/or :add ::add :delete ::delete))

(s/explain-data ::req {:method "add" :data 1})

Где-то я читал про то, что единственная более-менее доказанная корреляция в программировании — это увеличение числа багов с ростом числа строк.

Выбор в тот момент был не слишком большой. Были варианты, но популярных было очень мало.

иммутабельные структуры данных, язык и его стандартная библиотека хорошо заточены для работы с данными.

Да, я это общими словами и описал, можно вдаваться в детали)

Примерно такие же доводы и у сторонников reasonml ) у них только нет такого репла. Но они на эту чашу весов кладут развитую типизацию )

мне кажется, спека усложнена. Отличается же только метод? Может, вот так?

(s/def ::method #{"add" "delete"})
(s/def ::data map?)
(s/def ::req (s/keys :req [::method ::data]))

На самом деле я сделал это чтобы не писать много кода в чате. В большой спеке не для примера data тоже отличается. Мне интересно есть ли какие-то удобные способы определения ошибки потому что при например (s/explain-data ::req {:a 1})
Вывод:
{:problems
({:path [:add],
  :pred
  (clojure.core/fn
    [%]
    (clojure.core/contains? % :method)),
  :val {:a 1},
  :via [:server.spec/req :server.spec/add],
  :in []}
 {:path [:add],
  :pred
  (clojure.core/fn
    [%]
    (clojure.core/contains? % :data)),
  :val {:a 1},
  :via [:server.spec/req :server.spec/add],
  :in []}
 {:path [:delete],
  :pred
  (clojure.core/fn
    [%]
    (clojure.core/contains? % :method)),
  :val {:a 1},
  :via [:server.spec/req :server.spec/delete],
  :in []}
 {:path [:delete],
  :pred
  (clojure.core/fn
    [%]
    (clojure.core/contains? % :data)),
  :val {:a 1},
  :via [:server.spec/req :server.spec/delete],
  :in []}),
:spec :server.spec/req,
:value {:a 1}}
Меня смущает что здесь в списке :path повторяется по нескольку раз

да, вывод получается шумный. Как вариант -- посмотреть мульти-спеку. Она работает как мультиметод, в твоем случае диспатч будет по методу.

ну или в коде сделать case -- если метод add, то взять такую спеку, если delete -- то другую. И отдельным шагом проверить данные

что по сути мультиспека и делает