Ок, спасибо, понятно. Т.е. я так понял часть работы по приведению схемы бд к коду выполняет платформа, а то, что автоматически невозможно — надо вручную прописывать в миграциях? Эх, никакой магии, жалко :)
Занятная штука, здорово что находите время так обстоятельно и конструктивно «работать с возражениями». Присоединюсь к мнению, что синтаксис и гуй чисто визуально действительно весьма олдскульные, хотя это конечно дело привычки, но всё-же мне кажется современный веб интерфейс будет в каком то не сильно отдаленном будущем the must, хотя я конечно не специалист по миру ерп, возможно там это ок, да и дело наживное.
Интересует вопрос — а как вы работаете с миграциями? Накидали кода, развернули сервак, бабах — перименовали в коде кучу свойств, как оно потом всё это обрабатывает?
Да много разных инструментов, я про задачу приведения базы к объектной схеме. Странно, что вообще мейнстрим для миграций до сих пор — это changelog, т.е. цепочки миграций бесконечные.
Лично мне интересно как в разных системах (не chengelog) с переименованием сущностей справляются, победив эту проблему можно вообще migration-less ormы делать.
Да уж, дзен питона где везде надо таскать self, которого становится по пол экрана, но при этом магическая комбинация подчеркиваний превращается в другую магическую комбинацию подчеркиваний молча — он прекрасен. Тем не менее питон — очень мощная штука, система типизации с динамическими атрибутами — это оч клево. Уверен на следующем витке чуток причесав синтаксис из этого сделают отличный инструмент.
Возвращаясь к Вашему примеру с crystal — это прекрасно, что такое отловит компилятор, но тут меня неизбежно всегда мучает вопрос про троллейбус из буханки. Да мы отловим на этапе компиляции некоторый весьма ограниченный набор багов, которые, на самом деле, одни из самых тривиальных. Но никакой компилятор не отловит ошибки в логике, да те же перепутанные местами аргументы одного типа, с которыми уже можно всего веселого наворотить, типа copy(input_file, output_file), а вызвать наоборот. Т.е. отбрасывание (ценой повышения трудоемкости написания кода в разы) заведомо небольшого количества проблем почему то постулируется как повышающее надежность до недостижимых другими методами высот. Что есть самообман, по-моему. То же TDD или контрактное программирование здесь выглядят гораздо более системным.
Вообщем придерживюсь мнения что статическая типизация суть анахронизм, абсолютно необходимый в компилируемых языках прошлого поколения, когда требуется точное знание размера бинарного представления объекта на этапе компиляции, там да. А коли у нас объект — это бирка с типом и счетчиком ссылок в куче — ну какой смысл таскать его тип в коде — понимать отказываюсь.
В рамках дискуссии выражу свое мнение. ORM суть способ сериализации дерева объектов. Все косяки выползают из необходимости поддерживать версионность в неявном виде. Ну то есть версионность объектов у нас в коде не ведется штатно, а база по своей природе версионностью обладает. Тут мы взяли редактор, переименовали Object.foo в Object.bar, на этом редактирование кода закончилось, осталось только базы привести в консистентный с версиями объектов вид, и вот тут и заверте. На мой взгляд тут правилен подход (не могу найти сходу ссылок, но на хабре много раз описывался), что система должна пытаться просто привести базу в состояние, консистентное текущей версии объектов в коде, а когда этого сделать не удается — единожды применять ко всем своим живым базам миграционный скрипт, который после применения уходит в небытие. Бессхемные базы требуют такой процедуры фактически только при операциях переименования сущностей, запретив которые, мы сделаем отображение вполне себе бесшовным.
Смена пароля — это не просто бесполезно, это абсолютное зло с точки зрения безопасности. Ибо раз в жизни выучить что то типа Ks!@j131klq еще хоть как то возможно, а раз в пол года перезапоминать такую дребедень никто не будет гарантированно.
Одна большая часть этого различия, вероятно, динамическая типизация. Только в нашем ast.rs 500 строк определений типов, и ещё много типов, определённых в других местах компилятора. Мы также всегда ограничены самой системой типов. Например, нам нужна инфраструктура для эргономичного добавления новой информации в AST по мере прохождения и доступа к ней позже. В то время как в Python вы можете просто установить новые поля на узлах AST.
Отлично! Чтд. Динамическая типизация рулит. Таскать с собой зверское мозголомство с ковариантными и контрвариантными шаблонами чтобы случайно переданную str вместо int отловил компилятор, при том что такая конструкция завалится на первом же тесте — ну такое.
Дзен про явное лучше неявного крайне своеобразный в Питоне. Типа self надо таскать везде, но при этом к магической комбинации подчеркиваний само собой имя класса прицепится и узнаешь ты об этом (если конечно не вызубрил все пепы) случайно из статьи на хабре.
Люди, объясните, зачем в 21м веке эти прыжки с бубном? На любом углу можно купить текстолит уже покрытый фоторезистом, лазерник, пленка, ультрафиолетовая лампа, крот. Всё. Качество на порядок лучше должно быть.
Интересует вопрос — а как вы работаете с миграциями? Накидали кода, развернули сервак, бабах — перименовали в коде кучу свойств, как оно потом всё это обрабатывает?
оно справится? Ибо самое интересное про типы, как известно, начинается в коллекциях.
Лично мне интересно как в разных системах (не chengelog) с переименованием сущностей справляются, победив эту проблему можно вообще migration-less ormы делать.
Но технологии то не особо домашние
Возвращаясь к Вашему примеру с crystal — это прекрасно, что такое отловит компилятор, но тут меня неизбежно всегда мучает вопрос про троллейбус из буханки. Да мы отловим на этапе компиляции некоторый весьма ограниченный набор багов, которые, на самом деле, одни из самых тривиальных. Но никакой компилятор не отловит ошибки в логике, да те же перепутанные местами аргументы одного типа, с которыми уже можно всего веселого наворотить, типа copy(input_file, output_file), а вызвать наоборот. Т.е. отбрасывание (ценой повышения трудоемкости написания кода в разы) заведомо небольшого количества проблем почему то постулируется как повышающее надежность до недостижимых другими методами высот. Что есть самообман, по-моему. То же TDD или контрактное программирование здесь выглядят гораздо более системным.
Вообщем придерживюсь мнения что статическая типизация суть анахронизм, абсолютно необходимый в компилируемых языках прошлого поколения, когда требуется точное знание размера бинарного представления объекта на этапе компиляции, там да. А коли у нас объект — это бирка с типом и счетчиком ссылок в куче — ну какой смысл таскать его тип в коде — понимать отказываюсь.