metaclass | Динамическая типизация, или статическая типизация для ленивых

Entry tags:

Динамическая типизация, или статическая типизация для ленивых

Вчера

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

Flat | Top-Level Comments Only

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

по моим личным наблюдениям и ощущениям - адеватный взгляд.
Людям работать надо, а не на язык дрочить.

Зачем вам работать?

Потому что мне нравится работать.
Особенно над теми проектами, на которых я специализируюсь (разработка СУБД)

А что?

Ну вот, кому-то нравится дрочить на языки, кому-то на СУБД.

Мне нравится работать.
В первую очередь
Это не мешает мне выбирать интересную работу.

"Если Евтушенко против..."

Ваше мнение только усиливает мои подозрения в наличии логических провалов в рассуждениях автора поста.

Ну так найдите их, в чём проблема? :)

В логических провалах, которые автор тщательно скрывает?

Вот возьмите основной параграф про Хаскель: "Хаскель сразу закапываем - там на каждый случай имеется 3-4 расширения и 10 пакетов в hackage различной степени недоделанности, идиоматический подход - писать в point-free style, чтобы коллеги не разобрались, а работать в продакшене можно только с теми сторонними библиотеками, которые я могу сам починить."

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

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

Примените последовательно к себе свои собственные правила - напишите пост "как правильно работать в haskell'е со структурами", и спросите у автора, какие именно пакеты недоделаны, а потом опровергните это утверждение про недоделанность.

Edited 2012-10-11 19:32 (UTC)

Это не мои правила. Это придуманные вами правила, приписанные мне.

В принципе, мой комментарий к посту и был призывом раскрыть карты. Он проигнорирован, и это не значит, что я должен что-то делать. Ровно наоборот.

Ощущаемые мной проблемы автора пусть остаются его проблемами. Может, мне только кажется, что это проблемы. Может, так ему легче жить. Быть может, это конкурентное преимущество.

У меня есть забота протестировать, как Хаскель разбирает регекспы на скорости в 1,25ГБайт/сек. Укладываемся ли мы в указанный диапазон. Вот это на самом деле интересно.

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject