![[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
no subject
Haskell - их особо много и не было, да и нет, и слава богу.
no subject
no subject
erlang выходит в mainstream, это их многих мест слышно, да и знакомые не пугаются при его виде.
R - вы простите, но у меня на рабоет с ним работать приходится. Биндинги в него писать. И он популярным в scientific кругах стал уже весьма прочно, последний год - так вполне определённо.
У каждого своя ниша. erlang позволяет легко писать в event-driven стиле распределённые системы (распределённые не обязательно из соображений производительности. Язык так себе, достаточно, к тому же, тормозной. Но есть и killer feature - типа общего пространства процессов и отсутствие необходимости в IPC/RPC как класса. Это всё искупает)
R - научные вычисления. Как и octave, как и matlab.
А где ниша Haskell?
no subject
Ну, это конечно фундаментальный показатель.
> R - вы простите, но у меня на рабоет с ним работать приходится. Биндинги в него писать. И он популярным в scientific кругах стал уже весьма прочно, последний год - так вполне определённо.
То есть R -- нужен? Потому что его используют. Но ведь у него те же проблемы, что и у хаскелля, нет? Тоже мало кто его знает, тоже понапишут шибко умные, потом сиди разбирайся.
Не надо мне объяснять что такое эрланг и с чем его едят. Вообще, зачем от темы уходить? По вашей логике получается, что эрланг тоже не нужен, как и R, по тем же причинам.
Это очень похоже на разновидность луддизма.
> А где ниша Haskell?
На этот вопрос я вам не отвечу, я хаскель использую редко.
no subject
Это очень важный показатель. Есть спрос - будут программисты - будет кому заменить человека в команде после ухода
> То есть R -- нужен? Потому что его используют. Но ведь у него те же проблемы, что и у хаскелля, нет? Тоже мало кто его знает, тоже понапишут шибко умные, потом сиди разбирайся.
"шибко умные" - это когда файлы сканируются на диске через эндофункторы или нужен гамак с лыжами и монадами для скачки файлов по http.
R сидит хорошо в своей нише - научные вычисления. Линейная алгебра, та же. Люди что берут R они знают, что такое матрицы, и язык ими выбранный адекватен их задаче.
Человек, что пишет простого робота для анализа сайтов для своей мелкой хотелки - ему нафиг не впёрлись эти монады и доллары. Ему нужно РЕШИТЬ ЗАДАЧУ. Вот на Питон это элементарно. Пара запросов в гугль. Этим скачиваем странички. Этим парсим и и ищем нужную нам инфу. А вот так складываем результат в файлик. Всё просто и понятно.
> Не надо мне объяснять что такое эрланг и с чем его едят. Вообще, зачем от темы уходить? По вашей логике получается, что эрланг тоже не нужен, как и R, по тем же причинам.
Как же с Хаскелл-фанатиками туго-то, а. Речь идёт не про то, лучше ищи хуже язык. Речь идёт про адекватность языка поставленным задачам и риски компании связанные с его использованием.
> На этот вопрос я вам не отвечу, я хаскель использую редко.
Нишы Ерланга и R я описал. Могу и нишу Питона описать - это скриптовый язык, что работает везде, и оптимально годится для автоматизации мелких рутинных задач.
Лучше чем shell.
no subject
Опять двадцатьпять. Мы уже это обсуждали. Это вопрос менеджмента -- ну вот выживают конторы сумасшедших хаскелефилов, стало быть находят они специалистов. Не иначе как без вмешательства сатаны не обходиться.
> "шибко умные" - это когда файлы сканируются на диске через эндофункторы или нужен гамак с лыжами и монадами для скачки файлов по http.
Шибко умные, это когда зачем-то свои матрицы и детерминанты тащат в СЛУ. Ведь любому дураку понятно, что можно решить простым перебором. Тоже ведь подход? И найти таких решателей на рынке еще проще, чем тех, кто знает про алгебру что-то?
> Человек, что пишет простого робота для анализа сайтов для своей мелкой хотелки - ему нафиг не впёрлись эти монады и доллары. Ему нужно РЕШИТЬ ЗАДАЧУ. Вот на Питон это элементарно. Пара запросов в гугль. Этим скачиваем странички. Этим парсим и и ищем нужную нам инфу. А вот так складываем результат в файлик. Всё просто и понятно.
Ну порадуемся за человека. А другой пишет "на эндофункторах" и у него тоже задача решается. Надо его убить, чтобы не смущал?
> Как же с Хаскелл-фанатиками туго-то, а. Речь идёт не про то, лучше ищи хуже язык. Речь идёт про адекватность языка поставленным задачам и риски компании связанные с его использованием.
Ну вот я уже и фанатик. Я привёл уже довод о законах рынка и хаскель/скала/whatever-конторах. Ну разбейте этот довод, раз я фанатик.
no subject
Либо они работают за такие деньги, на которые нормальных специалистов на других языках не наймёшь. Это называется "демпинг" и говорит не в пользу Haskell.
> Шибко умные, это когда зачем-то свои матрицы и детерминанты тащат в СЛУ. Ведь любому дураку понятно, что можно решить простым перебором. Тоже ведь подход? И найти таких решателей на рынке еще проще, чем тех, кто знает про алгебру что-то?
Никому "СЛУ" работе решать не нужно. Людям нужно решать задачи, то поставил менеджмент.
Один знакомый не так давно пришёл тимлидом в проект по написанию систему рекомендаций.
Почитал что и как делают в machine learning, почесал репу, взял Java + Hadoop, вспомнил матрицы, заколбасил решение, работает. СЛУ в процессе тоже решать приходилось. Только это детали реализации, особенности алгоритмов такие, что их удобней делать через СЛУ и линейную алгебру.
Для скачивания файла по http не нужно знать всякого дерьма типа монад.
Правильное решение задачи выглядит так:
import urllib
urllib.urlretrieve ("http://www.example.com/songs/mp3.mp3", "mp3.mp3")
И что, сука, характерно, будет работать на любом линуксе сразу, без всяких приседаний. запихивается в script.
Не нужно решать квест "как скачать haskell", квест "какую лтбу взять" и квест "как мне пофильтровать из скачанного файла через монады бесплатно без смс" когда приспичит.
> Ну порадуемся за человека. А другой пишет "на эндофункторах" и у него тоже задача решается. Надо его убить, чтобы не смущал?
Если он это притащил в рабочий проект без чёткого письменного обоснования почему это нужно и подписей менеджмента - то это попахивает саботажем, с моей точки зрения.
Вообще говоря, любые свои решения в проекте нужно обосновывать. Не абстрактными "эффективность выше", а конкретикой - вот линейная алгебра нужна, потому что через неё существенно проще описывать рекомендации и веса, алгоритм линейной регрессии через неё работает - другими способами решать сложней.
Понимаете? Когда ДРУГИЕ РЕШЕНИЯ - СЛОЖНЕЕ.
no subject
Нет, не на любом.
no subject
no subject
desktop или сервер версию. embedded - там другие линуксы, там не только haskell, но и python не пахнет.
no subject
Вопросы начнутся, когда потребуется чтобы при плохо работающем DNS и тормозящем сайте можно было прервать скачивание кнопочкой с GUI и чтобы при этом в лог были записаны ошибки, а в программе не было утечек хендлов. И чтобы это было оформлено в DLL, которую руками грузят и выгружают из какой-нибудь 1C.
Если что - хаскель рантайм под виндой не умеет работать после однократной переинициализации извне. Там статические переменные. Не очищаются инициализацией/деинициализацией, да :)
no subject
no subject
no subject
no subject
no subject
Если это полезное качество - вы можете быть против, конечно, - то может быть стоит считать это полезным архитектурным решением, чем неадекватным по сложности излишеством?
К слову, Cloud Haskell работает в своей монаде. А Cloud Haskell это практически Erlang 2.0, ибо использует исправленную семантику Эрланга.
Если счесть и это полезным свойством, то, может, и монады полезны?
no subject
А толку? MySQL на сях долго страдал на ядрах больше четырёх, но его взяли и починил в итоге.
Починили, а не на haskell переписали.
И я вам сейчас открою страшный-страшный секрет. Я вот в октябре 2010 был на Monty Programming Conference.
Туда приехал представитель компании Intel. За свой счёт (счёт Intel я имею ввиду). Он советовался с разработчиками MySQL, как ему правильно тестировать качество сгенерированного интеловским компилятором кода и качество новых процессоров на примере MySQL.
Вы понимаете? Под презренный MySQL написанный на презренном Си INTEL ЖЕЛЕЗО ЗАТАЧИВАЕТ.
Ваш haskell со своим SMP могут продолжать гнить на задворках. Под android и ios его до сих пор нету, ЕМНИП.
Си, Джава - есть.
Хорошая поддержка SMP. И это всё? Сочувствую.
no subject
Спрошу с другой стороны. Стоит ли писать новую программу на Хаскеле? Ту, которую вы до сих пор не писали, но от которой много ждёте.
no subject
Назовите задачу, и скажу:
1) компетентен ли и квалифицирован ли я достаточно в этой области, чтобы выбирать язык программирования для этой задачи
2) если (1) - да, то какая язык и платформу следует выбирать и почему.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(Anonymous) - 2012-10-13 15:19 (UTC) - Expand(no subject)
(no subject)
(no subject)
(Anonymous) - 2012-10-15 14:07 (UTC) - Expand(no subject)
(no subject)
(Anonymous) - 2012-10-15 20:13 (UTC) - Expand(no subject)
(no subject)
(Anonymous) - 2012-10-15 22:04 (UTC) - Expand(no subject)
(no subject)
(no subject)
no subject
Супер. Вот когда в императивных языках починят присваивание, тогда приходите.
no subject
Там все эти сказки про зеленые потоки, ожидания i/o и прочая асинхронность превращены в ебаную срань из костылей и утечек хендлов.
Короче, любимый пример с пиздатейшим TCP-сервером на хаскеле в пару строк под виндой под небольшой нагрузкой дохнет в сраку :)
no subject
Пару лет назад, я писал падвенду на хацкеле — ничего не падало, коннектов воспринимало сколько угодно.
Не хочется больше падвенду писать, но по другим причинам, с GHC не связанным.
no subject
Спрашивали ли вы у
no subject