Clojurians Log v2

"clopen sets" / хотя вообще ничего не понял 🙂

ага, топология должно быть интересна. но не по учебнику

@dottedmag я читал переписку Алекса Миллера и Томпсона. Когнитект с самого начала сказал, что они сделали any? и not-any? с такой семантикой и просили прекратить дискуссию на эту тему. И поэтому любые призывы изменить это они просто не обсуждали. Поэтому когда в очередной раз перед релизом опять появились эти призывы Миллер написал, что "поезд ушел". Но ушел не в смысле, что они сначала профакапили, а потом исправлять не захотели. А в том, что это было осознанным решением и обсуждать не будут. На этой неделе, я решил приобрести печатное издание "Программирование на Clojure", где речь идет об версии 1.4 Сейчас на носу 1.9 и прошло уже 5 лет с момента издания книги. Ничто в книге не потеряло актуальности. Это благодаря тому, что Рич и команда продумывают целостность языка очень хорошо. И в этом большой плюс, что мы почти всегда в коде просто меняем версию clojure, без изменений в коде (за редким исключением). Такую суперстабильность в других языках еще поискать надо. Как написал Рич, он за продумыванием спеки уже последние N месяцев трудится (вместе с женой), чтобы выпустить релиз и any? и not-any? это нововведения за этой работы. Время покажет будут ли они такими же суперстабильными fn как и остальные функции в core.

В ответе Рича мне очень понравилось то, что кложа это не то, на чем они зарабатывают. То есть они поставили во главу угла качество языка и его целостность. Деньги вынесли за скобки. Не знаю, но мне интуитивно кажется, что великие вещи так и создаются, когда бабки выносят за скобки, т.к. бабки несут тлен времени: условно говоря, кто платит, тот и заказывает музыку, а это всегда в угоду моде или настроению. И поэтому о стабильности ядра языка можно забыть.

переписка про any? и not-any? https://groups.google.com/forum/#!topic/clojure-dev/Wl5-Ugzwqy4

да, один из трех известных мне тредов

> Когнитект с самого начала сказал, что они сделали any? и not-any? с такой семантикой и просили прекратить дискуссию на эту тему.

Это называется "идите в топку, мы решили, что это правильно, значит это правильно".

Они могут хоть миллион денег вбухать в кложуру, но это не означает, что они не ошибаются.

Не очень понял, где в этом подходе ошибка? Они говорят, вот новые any? и not-any? и семантика у них такая. в Clojure для того чтобы использовать функцию, нужно прочитать доки и узнать семантику функции. Семантика задекларирована. Хочешь используй, хочешь пиши свою. Главное, что она не меняется.

Тогда можно было бы их назвать fn17 и fn13338, почему нет?

да. правильно.

not-any? появилось в 1.0, а any? - в 1.9, при этом новая функция не является дополнением к старой.

Претензия была к тому, что именование сбивает с толку.

как по мне, имя функции и семантика неразрывны. а то что, у меня с каким либо именем могут возникать индивидуальные собственные ассоциации или семантика, это ж исключительно зависит от того, кто смотрит (субъективно). вот мне кажется что reduce не правильное название. а вот assembly более правильное название, т.к. мы ведь не уменьшаем/сокращаем коллекцию, как бы делаем сборку

так до любой функции можно докопаться.

Вот также думали первые разработчики топологии, и поэтому у них может быть одновременно открытое и закрытое множество.

not-any? должно быть (not (any?)).

А оно не так.

Если у тебя есть функция not-F, а ты добавляешь F, то not-F должно быть (not (F)), и никак иначе.

Если это нарушается, то названия функций просто перестают что-либо значить.

И можно их заменить закорючками, как в APL, или номерами, как в J.

Лексикон может быть любым (хоть reduce, хоть assembly, хоть fold), но он должен быть непротиворечивым.

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

Дилетантское имхо: все претензии к именованию и следующей из него семантики пытаются обосновать логическими доводами. Однако, забавно то, что порой "логические доводы" не особо таковы, и вырождаются в попытку хоть как-то обосновать выбранное решение. С одной стороны, я согласен с предыдущим оратором, что выглядит очень консистентно, когда not-F = not . F. С другой стороны, на всяких граничных случаях (а в Кложе их имхо больше, чем в иных (С) статических языках), поведение может не соответствовать. И ничего не остается, кроме как воспринимать это как фичу, и просто знать. ЗЫ как пример могу привести претензии к хаскельному length (1,2) == 1 Питонисты массово негодуют 🙂 Но если начнешь им объяснять, что length - это свертка Foldable типа (а это однопараметрический класс типов!) по моноиду Inc, а пара является инстансом любого однопараметрического класса по второму параметру с частично примененным первым, поэтому все правильно и логично (!), то смотрят как на идиота 🙂

ЗЫ Питонисты упомянуты условно (видимо, предыдущий пост навеял), все совпадения случайны 🙂

Интересно, полезно ли хоть где-нибудь, что "пара является инстансом любого однопараметрического класса по второму параметру с частично примененным первым", или это сделано из-за того, что математически это верно?

В математике много изоморфизмов, но не нужно их все тащить в языки программирования.

Чтоб далеко не ходить - в качестве функтора пара очень удобна

надо только выбрать, что положить во вторую позицию

> И ничего не остается, кроме как воспринимать это как фичу, и просто знать

Есть два разных типа сложности: наносная и необходимая.

В языках и так очень много наносной сложности, придумывать себе ещё один фактоид для запоминания глупо.

Когда нужно пришить к возвращаемому некоторой сложной функцией значению что-то еще: лог работы, "мутабельный" стейт (привет, велосипедная State-монада), список ошибок при вычислении значения и т.п. - спариваешь это с нужным результатом функции, и тут отлично помогает что пара - и функтор и аппликатив и монада и фолдабл и вышивать и на машинке 🙂

Но чтобы сразу расставить точки над i - разумеется можно все это делать и не думая о таких вещах и не говоря эти слова. Кому как удобнее

Хаскельный пример, кстати, не является наносной сложностью. Там непонятка проявляется как логический результат.

А в случае с any? это разведение проблемы на пустом месте.

И да, на clojuredocs появится пример, состоящий из объяснения, что (not (any? x)) - это не то же самое, что (not-any? x), и мы все запомним, и будем чморить новичков. Но зачем?

Просто весы - на другой чаше аргументы оппонентов, и они перевесили...

Обратная совместимость, "дикари не поймут" или что там еще

Да не. На другой чаше аргумент "мы уже так зарелизили".

Очень удобно, когда весы в руках того, кто наваливает на одну чашу аргументы 🙂

Реал ворлд... 🙂

Рич часто смеётся над другими – "но мы-то можем сделать лучше!", а получается, что упс, не всегда. И поза, в которую он при этом встаёт, не слишком красивая.

Но можно построить свои -not-any? с любым поведением и семантикой

Можно. Можно даже форкнуть.

На самом деле я оппонирую не потому что не разделяю точку зрения, наоборот 🙂 Просто как попытка рассмотреть ситуацию со всех 3 сторон 🙂

А про пару - буквально на днях писал на Кложе функцию, которая должна возвращать в общем случае немалый такой иерархично вложенный текст SQL-запроса. С которым надо лазить в базу и результат отправлять на клиента. Так хорошо было бы при этом проверять возможные ошибки, собирать их все (!), и если они есть - то не лазить в базу а отправлять их на клиента. Хорошо я с опытом Хаскеля, как-то вывернулся, примотал изолентой возвращаемую пару - текст SQL и лист ошибок. Только все внутренние преобразования пришлось пилить руками (ибо не умею в сабже это идиоматично делать, а функторы/монады знаю что есть, но пока не курил их в Кложе). А в Хаскеле, с этими якобы "ненужными" инстансами и математикой, это решил бы добавив несколько символов. Хорошо еще что хаскельные реально иммутабельные паттерны помогают, а то бы налепил внешний реф/атом для накопления ошибок, и апдейтил/мутировал его из свой функции, как в сях и т.п.

У этого обсуждения есть один плюс: думаю, теперь все запомнили, что any? и not-any? надо запоминать отдельно 🙂

@ivana В clojure.algo.monads есть Writer.

Но я тоже не курил их.

Спасибо, я видел что есть пакет с монадами. Обязательно его раскурю. Просто для рабочего решения "по-бырому" написал сам руками 🙂 Это я просто тебе привел пример из недавней реальной жизни, как реализация инстансов пары помогает. По крайней мере тем, у кого однопараметрические инстансы головного мозга 🙂

А про any?, all?, some? и т.п. остальное значит все нормально? 🙂 Вот вам еще пример "запомним, что это фича" - что это не предикаты! 😉 Они возвращают не булевское значение, а первый не фалсовый элемент - что меня например повергает в изумление, я привык (понятно где) к другому поведению.

Это тоже очень весело, да.

any? предикат, это просто (constantly true)

nil-puning та ещё байда, но это ж лисп.

Но опять же, смотри пункт первый - не переноси аналогии из других языков и свои представления о логичности, а читай мануалы 🙂

Если на клетке слона прочтёшь надпись "буйвол", не верь глазам своим.

Думаю, что уже есть сборники сабже-паззлеров, просто добавлять туда новинки и давать ссылку всем удивляющимся

Ну да. Впрочем, это всё мелочь.

Вот я сегодня узнал, что в JVM никак не поменять "текущую директорию"

треды про any? не читал, но кажется мне, что всё в контексте спеки происходит. типа если норм спеками покроешь проект, так и не нужно будет предикаты в "классических" юзкейсах применять, типа шальные ифы и кейсы по коду в случайных местах. спека + мультиметодный полиморфизм, и поехали

а если пытаться писать "питон" на кложе - сразу вознимают вопросы о знакомом названии, но неожиданном поведении

+ рич и стю очень любят делать привычные вещи неудобно, чтобы цена сделать иначе, но круче, казалась ниже, как тут: https://github.com/cognitect-labs/transcriptor#keep-dumb-tests-ugly > This is ugly by design, as an inducement to test properties instead of specifics.

это хороший UX приём, когда юзеров нужно переучить с легкого неверного на новое верное

@dottedmag возьми lumo. там можно поменять текущую директорию. переучиваюсь все скрипты писать не на баше, а на lumo.

@misha да, все в контексте спеки.

прикольная либа: https://github.com/vvvvalvalval/scope-capture

демо работы либы тут: https://vimeo.com/237220354