Очень правильная концепция — отделить то что нужно для работы самому компьютеру от того, что по сути нужно другим людям. Интерпретатор прекрасно отработает без всякой информации о типах. Отлично. Теперь сбоку прикручиваем инструмент, который дает всем этим удобно пользоваться людям. И это мне кажется куда как более грамотно, чем хватать программиста за руки.
Да не может быть! То есть если вылезаем из песочницы с куличами — тут же госплан, да? И такая себе конкуренция в стиле ты мне я тебе? Кто бы мог подумать.
Про повара кстати особенно смешно. Тот кто там у вас на раздаче в столовке — это не повар, это в терминах айти даже не джун, а стажер техподдержки первой линии. Тимлиды — они же Шефы — они не только учились подольше чем Вы, они еще и на стажировки в разные рестораны должны ездить что бы оставаться в струе, и новое всякое придумывать что бы быть востребованными, не говоря уже что работа по 16 часов на ногах иногда без выходных и при этом крайне творческая, фреймфорки там тоже конечно есть, но на них толковым шефом не станешь. Как то вот так походя обдать профессию, вообще ничего в ней не понимая — это сильно конечно.
В унылое говно она скатывается, когда группа предателей наверху решает монетизировать в деньги свое положение и влияние в обществе, для чего организовывают рукотворный кризис и разваливает страну. А там где этого не происходит (см. Коммунистический Китай) — всё с плановой экономикой пятилетками и т.п. нормально. И можно себе позволить даже игру в бирюльки типа айфонов отдать на откуп «свободному рынку».
Офигенно! Прям вот очень круто. И изобретение весьма хитроумное, и то что ниша оказалась незанятой, и как всё это реализовано, дизайн и т.п. Главное, дает надежду что еще не всё окучено мегакорпорациями и есть место изобретениям в нашем мире ;)
Объяснять бесполезно. Будут рефлексировать простынями на хабре и испытывать смутную тревогу с вялотекущей депрессией, но при этом в голову наложено так, что признать очевидный источник всего этого (разумеется это именно отчуждение от результата своего труда) — не в состоянии.
Желательно, при этом, в задачке чтоб был чужой код с багами. Единственно правильный подход на мой взгляд (нанимаемого). Понятно, не универсальный — наверное какого то крутого спеца или лида таким образом нанимать не надо. Но для найма обычных рабочих лошадок почему такой такой подход не практикуется повсеместно — загадка. Видимо лень людям задачи придумывать под каждую позицию.
С другой стороны бывает обидно, когда после выполнения тестового задания тебе без объяснения причин дают отлуп. Но если задание непростое и интересное — то вообщем то и не так обидно.
Но вообще говоря по старой и новой версии кода теоретически нельзя угадать, что если в старом коде было f и g, а в новом h и k, кого в кого надо переименовать.
факт, собственно интересно как именно с этой проблемой на разных платформах справляются. Ибо именно переименование — какая то прям магическая операция, не позволяющая полностью миграции автоматизировать.
Ок, спасибо, понятно. Т.е. я так понял часть работы по приведению схемы бд к коду выполняет платформа, а то, что автоматически невозможно — надо вручную прописывать в миграциях? Эх, никакой магии, жалко :)
Занятная штука, здорово что находите время так обстоятельно и конструктивно «работать с возражениями». Присоединюсь к мнению, что синтаксис и гуй чисто визуально действительно весьма олдскульные, хотя это конечно дело привычки, но всё-же мне кажется современный веб интерфейс будет в каком то не сильно отдаленном будущем the must, хотя я конечно не специалист по миру ерп, возможно там это ок, да и дело наживное.
Интересует вопрос — а как вы работаете с миграциями? Накидали кода, развернули сервак, бабах — перименовали в коде кучу свойств, как оно потом всё это обрабатывает?
Да много разных инструментов, я про задачу приведения базы к объектной схеме. Странно, что вообще мейнстрим для миграций до сих пор — это changelog, т.е. цепочки миграций бесконечные.
Лично мне интересно как в разных системах (не chengelog) с переименованием сущностей справляются, победив эту проблему можно вообще migration-less ormы делать.
Да уж, дзен питона где везде надо таскать self, которого становится по пол экрана, но при этом магическая комбинация подчеркиваний превращается в другую магическую комбинацию подчеркиваний молча — он прекрасен. Тем не менее питон — очень мощная штука, система типизации с динамическими атрибутами — это оч клево. Уверен на следующем витке чуток причесав синтаксис из этого сделают отличный инструмент.
Возвращаясь к Вашему примеру с crystal — это прекрасно, что такое отловит компилятор, но тут меня неизбежно всегда мучает вопрос про троллейбус из буханки. Да мы отловим на этапе компиляции некоторый весьма ограниченный набор багов, которые, на самом деле, одни из самых тривиальных. Но никакой компилятор не отловит ошибки в логике, да те же перепутанные местами аргументы одного типа, с которыми уже можно всего веселого наворотить, типа copy(input_file, output_file), а вызвать наоборот. Т.е. отбрасывание (ценой повышения трудоемкости написания кода в разы) заведомо небольшого количества проблем почему то постулируется как повышающее надежность до недостижимых другими методами высот. Что есть самообман, по-моему. То же TDD или контрактное программирование здесь выглядят гораздо более системным.
Вообщем придерживюсь мнения что статическая типизация суть анахронизм, абсолютно необходимый в компилируемых языках прошлого поколения, когда требуется точное знание размера бинарного представления объекта на этапе компиляции, там да. А коли у нас объект — это бирка с типом и счетчиком ссылок в куче — ну какой смысл таскать его тип в коде — понимать отказываюсь.
В рамках дискуссии выражу свое мнение. ORM суть способ сериализации дерева объектов. Все косяки выползают из необходимости поддерживать версионность в неявном виде. Ну то есть версионность объектов у нас в коде не ведется штатно, а база по своей природе версионностью обладает. Тут мы взяли редактор, переименовали Object.foo в Object.bar, на этом редактирование кода закончилось, осталось только базы привести в консистентный с версиями объектов вид, и вот тут и заверте. На мой взгляд тут правилен подход (не могу найти сходу ссылок, но на хабре много раз описывался), что система должна пытаться просто привести базу в состояние, консистентное текущей версии объектов в коде, а когда этого сделать не удается — единожды применять ко всем своим живым базам миграционный скрипт, который после применения уходит в небытие. Бессхемные базы требуют такой процедуры фактически только при операциях переименования сущностей, запретив которые, мы сделаем отображение вполне себе бесшовным.
С другой стороны бывает обидно, когда после выполнения тестового задания тебе без объяснения причин дают отлуп. Но если задание непростое и интересное — то вообщем то и не так обидно.
факт, собственно интересно как именно с этой проблемой на разных платформах справляются. Ибо именно переименование — какая то прям магическая операция, не позволяющая полностью миграции автоматизировать.
Интересует вопрос — а как вы работаете с миграциями? Накидали кода, развернули сервак, бабах — перименовали в коде кучу свойств, как оно потом всё это обрабатывает?
оно справится? Ибо самое интересное про типы, как известно, начинается в коллекциях.
Лично мне интересно как в разных системах (не chengelog) с переименованием сущностей справляются, победив эту проблему можно вообще migration-less ormы делать.
Но технологии то не особо домашние
Возвращаясь к Вашему примеру с crystal — это прекрасно, что такое отловит компилятор, но тут меня неизбежно всегда мучает вопрос про троллейбус из буханки. Да мы отловим на этапе компиляции некоторый весьма ограниченный набор багов, которые, на самом деле, одни из самых тривиальных. Но никакой компилятор не отловит ошибки в логике, да те же перепутанные местами аргументы одного типа, с которыми уже можно всего веселого наворотить, типа copy(input_file, output_file), а вызвать наоборот. Т.е. отбрасывание (ценой повышения трудоемкости написания кода в разы) заведомо небольшого количества проблем почему то постулируется как повышающее надежность до недостижимых другими методами высот. Что есть самообман, по-моему. То же TDD или контрактное программирование здесь выглядят гораздо более системным.
Вообщем придерживюсь мнения что статическая типизация суть анахронизм, абсолютно необходимый в компилируемых языках прошлого поколения, когда требуется точное знание размера бинарного представления объекта на этапе компиляции, там да. А коли у нас объект — это бирка с типом и счетчиком ссылок в куче — ну какой смысл таскать его тип в коде — понимать отказываюсь.