![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Динамическая типизация, или статическая типизация для ленивых
Вчера ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
ivan_gandhi сделал замечание что я, пользуясь динамически типизированной кложурью, при этом требую, чтобы в Java проверяли входные параметры на валидность. (Если что, проверка валидности в дотнете есть на каждом шагу, а объяснения вида "экономят циклы и не делаю проверки" в контексте жабы, тяжелого железа, JIT и прочего звучат крайне странно).
Собирался на эту тему устроить срач с утра, ноthedeemon уже начал, так что я продолжу :)
Так вот, динамически типизированными языками мы пользуемся от бедности - нету статически типизированных языков, которые давали бы ту же функциональность.
Например, я хочу использовать кортеж с именованными полями (потому что позиционные кортежи нихера нечитабельны и их тип вида int*string*smallint*money*bool*Chervie ни о о чем не говорят). От входа в F# при этом нужно:
1) объявить этот чертов record где-то
2) сослаться на модуль с объявлением везде где он нужен
3) создавать экземпляры рекорда кривопачвярными конструкциями, причем оставить поля значениями по умолчанию нельзя.
4) паттерн матчинг с декомпозицией вроде не работает с рекордами.
Хаскель сразу закапываем - там на каждый случай имеется 3-4 расширения и 10 пакетов в hackage различной степени недоделанности, идиоматический подход - писать в point-free style, чтобы коллеги не разобрались, а работать в продакшене можно только с теми сторонними библиотеками, которые я могу сам починить.
При этом, у меня при работе с оперденями постоянно ситуации вида: есть запись с тремя полями, полученная из БД, мне нужно произвести обработку этой записи и добавить результат обработки в виде четвертого поля, получив новый тип записи.
Я НЕ хочу объявлять каждый раз такое руками и в Clojure это делается элементарно, добавлением нового ключа в map в функции-обработчике записей.
При этом РЕАЛЬНО динамическую типизацию я не использую. Она мне почти не нужна, потому что единственная ситуация, где вменяемый человек будет на одном цикле биндить к имени число, на втором строку, на третьем - список записей - это когда по условию задачи нужна, например, EAV-модель во все поля. И то - обычно EAV делается от безысходности, потому что пользователь не может нормально работать со схемой БД, а задача требует чего-нибудь вроде "добавить к части записей атрибут "фаза луны в которую производилась приемка товара"". В норме должны быть зависимые типы и миграции и пользователи бы пользовались той же системой типов что и разработчик.
Т.е. нормальный вывод типов - это когда программа берет типы из тут же описанного SQL-запроса, а рекорды расширяемые и объявлять их не нужно.
Второй use-case, где "вроде бы динамическая типизация" - это когда я делаю документы в виде кложурных структур данных, подгоняя комбинации списков-мапов-массивов-множеств под предметную область. В кложуре же это делается в лоб, а в хаскеле в один список не положишь три разных по структуре(типу) раздела документа. Но на самом деле, то что я делаю в кложури - это просто алгебраический тип данных "для бедных", без объявления заранее и без явно выделенных-именованных конструкторов данных. Если бы была возможность делать расширяемые и объявляемые по месту типы данных (чтобы каждый раз при разработке не переключаться между объявлением типа и конструированием данных по этому типу) - то было бы то же самое что в кложури - но статически типизированное.
PS: На ту же тему: http://justy-tylor.livejournal.com/190153.html
ivan_gandhi сделал замечание что я, пользуясь динамически типизированной кложурью, при этом требую, чтобы в Java проверяли входные параметры на валидность. (Если что, проверка валидности в дотнете есть на каждом шагу, а объяснения вида "экономят циклы и не делаю проверки" в контексте жабы, тяжелого железа, JIT и прочего звучат крайне странно). Собирался на эту тему устроить срач с утра, но
thedeemon уже начал, так что я продолжу :)Так вот, динамически типизированными языками мы пользуемся от бедности - нету статически типизированных языков, которые давали бы ту же функциональность.
Например, я хочу использовать кортеж с именованными полями (потому что позиционные кортежи нихера нечитабельны и их тип вида int*string*smallint*money*bool*Chervie ни о о чем не говорят). От входа в F# при этом нужно:
1) объявить этот чертов record где-то
2) сослаться на модуль с объявлением везде где он нужен
3) создавать экземпляры рекорда кривопачвярными конструкциями, причем оставить поля значениями по умолчанию нельзя.
4) паттерн матчинг с декомпозицией вроде не работает с рекордами.
Хаскель сразу закапываем - там на каждый случай имеется 3-4 расширения и 10 пакетов в hackage различной степени недоделанности, идиоматический подход - писать в point-free style, чтобы коллеги не разобрались, а работать в продакшене можно только с теми сторонними библиотеками, которые я могу сам починить.
При этом, у меня при работе с оперденями постоянно ситуации вида: есть запись с тремя полями, полученная из БД, мне нужно произвести обработку этой записи и добавить результат обработки в виде четвертого поля, получив новый тип записи.
Я НЕ хочу объявлять каждый раз такое руками и в Clojure это делается элементарно, добавлением нового ключа в map в функции-обработчике записей.
При этом РЕАЛЬНО динамическую типизацию я не использую. Она мне почти не нужна, потому что единственная ситуация, где вменяемый человек будет на одном цикле биндить к имени число, на втором строку, на третьем - список записей - это когда по условию задачи нужна, например, EAV-модель во все поля. И то - обычно EAV делается от безысходности, потому что пользователь не может нормально работать со схемой БД, а задача требует чего-нибудь вроде "добавить к части записей атрибут "фаза луны в которую производилась приемка товара"". В норме должны быть зависимые типы и миграции и пользователи бы пользовались той же системой типов что и разработчик.
Т.е. нормальный вывод типов - это когда программа берет типы из тут же описанного SQL-запроса, а рекорды расширяемые и объявлять их не нужно.
Второй use-case, где "вроде бы динамическая типизация" - это когда я делаю документы в виде кложурных структур данных, подгоняя комбинации списков-мапов-массивов-множеств под предметную область. В кложуре же это делается в лоб, а в хаскеле в один список не положишь три разных по структуре(типу) раздела документа. Но на самом деле, то что я делаю в кложури - это просто алгебраический тип данных "для бедных", без объявления заранее и без явно выделенных-именованных конструкторов данных. Если бы была возможность делать расширяемые и объявляемые по месту типы данных (чтобы каждый раз при разработке не переключаться между объявлением типа и конструированием данных по этому типу) - то было бы то же самое что в кложури - но статически типизированное.
PS: На ту же тему: http://justy-tylor.livejournal.com/190153.html
no subject
В принципе, мой комментарий к посту и был призывом раскрыть карты. Он проигнорирован, и это не значит, что я должен что-то делать. Ровно наоборот.
Ощущаемые мной проблемы автора пусть остаются его проблемами. Может, мне только кажется, что это проблемы. Может, так ему легче жить. Быть может, это конкурентное преимущество.
У меня есть забота протестировать, как Хаскель разбирает регекспы на скорости в 1,25ГБайт/сек. Укладываемся ли мы в указанный диапазон. Вот это на самом деле интересно.
no subject
По сути - просто высказали своё оценочное суждение.
Призыв открыть карты я не видел.
no subject
Но теперь-то уж всем понятно, что я хотел услышать.
no subject
no subject
no subject
Вот тут по ссылкам ищите. Haskell'истов поди сами опознате.
no subject
Я достаточно глупый человек, я опираюсь на статическую типизацию из-за моей неспособности охватить всё и сразу. Я также достаточно тугоумен, чтобы проверять гипотезы по мере их выдвижения, просто чтобы не забыть.
Поэтому не могли бы вы немного разжевать свой ответ выше, и увязать его с другими своими и моими комментариями? Ибо я не успеваю за полётом вашей мысли.
no subject
Смирения вам не хватает. Слов "пожалуйста", и "спасибо".
А ещё умения признавать, что не существует серебрянной пули, и того, что вы можете ошибаться.
Потому и дискуттировать с вами не очень хочется.
Помнится, ещё в 2008 году вы мне заявляли, что я идиот, когда я вас спрашивал "где вакансии Haskell?".
Жаль видеть, что ничего с тех пор не поменялось.
Тут: http://metaclass.livejournal.com/735575.html?thread=14542423#t14542423 я это уже писал.
no subject
А идиотом я вас назвал после того, как мне пришлось повторять одно и то же несколько раз, не меньше пяти. Кто же устоит?
И само собой, что человеку, который так тратит чьи-то нервы, не имеет смысла говорить "пожалуйста" и "спасибо". Это вызовет закрепление не тех навыков, которые мне полезны.
Хотя, я бы сказал вам спасибо, если бы вы взяли на себя труд посмотреть на посты про 15 разных версий curl. Что вам стоит? Ну пожалуйста?
no subject
no subject
no subject
no subject
Забавно это слышать от PHP программиста :)
no subject
Там есть баттхёртЪ.
p.s. Не, я за Haskell агитировать не буду.
no subject
no subject
no subject
no subject
Не знаю я про того человека. Давно не ищу в России, но с моим опытом это слабо согласуется. Не, найти-то можно, если задаться целью, но так причем тут Россия. :-)
no subject
Во-первых придётся снижать уровень жизни.
Во-вторых в таких местах часто одни неудачники тусуются
В-третьих - ну как можно ожидать уважения к твоей работе в месте, где тебя настолько мало ценят? :)
no subject
no subject
Да, меньше штуки зелёных - это практически всегда вот такой пиздец
no subject