Для справки: если в констраинт добавить is_actual, который имеет значение true для актуальных записей и null для архивных, то все продолжит работать...
Даже сейчас один и тот же промпт, введённый дважды, даст два разных результата. Так что про "копирование" можете забыть. Не говоря уже о том, что там не "софт" а "дата", которая постоянно плывет...
Создание новых типов в таких случаях плодит лишние сущности, иногда подобные типы «выламываются» из общей системы, которую приходится под них адаптировать. А если еще добавить к этому, что это расширение библиотеки, которая не тобой писана… Увы, на частном примере это не очень хорошо заметно, поэтому и кажется, что проблема искусственная. В реальной ситуации, когда в системе десятки типов, это становится заметно, но как впихнуть такой пример в формат статьи, я пока не очень понимаю. Постараюсь все же развернуть тему чуть позднее.
Да, именованные экземпляры были бы неплохим решением. Интересно, что мешает их реализовать? Еще одну возможность я вижу в том, чтобы предоставить возможность перекрытия экземпляров в пределах модуля. В случае паранойи можно было бы предусмотреть расширение, которое отключающает проверку перекрытия экземпляров в некоторых случаях. А то получается, как в известной присказке — «Хаскель не даст вам прострелить свою ногу» :-).
Насчет «нужных в данный момент». Слишком часто такие определения многократно повторяются. Иначе не возникало бы желание обобщить их. Но не больше, чем это необходимо :-).
Двупараметрический тип попытались использовать как однопараметрический, редуцировав совершенно произвольно первый по порядку параметр. Или математика запрещает рассматривать другие случаи, когда нужно редуцировать, скажем, последний параметр, а остаток рассматривать как функтор?
Впрочем, в аппендиксе я все развернул. Я всего лишь против того, чтобы частное решение выносилось на уровень системы, тем более, в условиях, когда последствия такого решения невозможно заблокировать. Математика тут ни при чем.
Говорят, он с BBC писал образы, где работал...
Лучше всего на rust, но python тоже сойдёт...
А как же бессмертное "можно грабить корованы"?
Для справки: если в констраинт добавить is_actual, который имеет значение true для актуальных записей и null для архивных, то все продолжит работать...
Написанную документацию тоже будут читать ИИ-агенты...
Я не извозчик, я водитель кобылы (с)
...пока не начнется вырождение в результате имбридинга...
Semver и Lock-файлы: ну да, ну да, пошли мы нахрен...
Поломку сортировки при смене таймзоны тоже можно поручить ИИ, он это неплохо умеет...
Коли человек разумен, то в принципе возможен только NGI, но не AGI. А так да, Пастернака не читал, но опровергаю (с)
Ещё веселее байка про "нема сечі терпіти ці пекельні борошна" (с) :-)
Никто и никогда не знает, какое из человеческих желаний приведет к экономическому прорыву. :-)
...и тут внезапно окажется, что опыт из реального мира вообще никак не коррелирует с опытом из "прочитанных" книжек :-)
Не получится. Потому что даже уже собранный человеческий мозг всё ещё нужно обучать, и то не всегда получается...
Даже сейчас один и тот же промпт, введённый дважды, даст два разных результата. Так что про "копирование" можете забыть. Не говоря уже о том, что там не "софт" а "дата", которая постоянно плывет...
Я бы написал. Ибо KISS рулит...
Что характерно, такая же хрень и с ИИ в ИТ будет...
Я переконвертировался в свидетеля раста :-)
Да, именованные экземпляры были бы неплохим решением. Интересно, что мешает их реализовать? Еще одну возможность я вижу в том, чтобы предоставить возможность перекрытия экземпляров в пределах модуля. В случае паранойи можно было бы предусмотреть расширение, которое отключающает проверку перекрытия экземпляров в некоторых случаях. А то получается, как в известной присказке — «Хаскель не даст вам прострелить свою ногу» :-).
Насчет «нужных в данный момент». Слишком часто такие определения многократно повторяются. Иначе не возникало бы желание обобщить их. Но не больше, чем это необходимо :-).
Впрочем, в аппендиксе я все развернул. Я всего лишь против того, чтобы частное решение выносилось на уровень системы, тем более, в условиях, когда последствия такого решения невозможно заблокировать. Математика тут ни при чем.