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

[metaclass]

Вчера 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

Comments

[zamotivator.livejournal.com]

Вакансию FreeBSD админов создают другие FreeBSD админы. Шетухин не так давно это доказал, смигрировав весь Рамблер на ubuntu.

Ущерб работе в том, что половину рабочего времени админ решает не задачи работодателя (чтобы почта и прочее работало) а проблемы FreeBSD проекта.
При работе с linux такого сорта задач ощутимо меньше.

Вот и с Haskell также. Сначала один шибко умный притащил haskell. Потом ему надоел проект и он поменял работу. В итоге работодателю приходится искать на не шибко богатом рынке haskell программиста, который с такими же альтернативными взглядами, как ушедший разработчик и мучаться с ним дальше.

Это косяк менеджмента, но что это меняет?

[zw0rk.blogspot.nl (from livejournal.com)]

> Это косяк менеджмента, но что это меняет?

Это меняет всё. Если такой менеджмент существует и выдерживает конкурентную борьбу, значит это не самый плохой из менеджментов.

[zamotivator.livejournal.com]

Вы не правы. Менеджер может банально демпинговать зарплатой во имя каких-то своих идеалов.
И да, замени любого человека в небольшой айти компании всегда болезненно.
Часто бывает, что эффективность кандидата в два раза лучше текущего сотрудника при прочих равных не является достаточным основанием для увольнения старого
Во-первых - фиг уволишь (самое доброе в мире ТЗ!)
Во-вторых - риски замены людей никто не отменяет. Фиг его знает, что там будет с новеньким. Старый хотя бы понятно что из себя представляет.
В-третьих - такие замены это неизбежные потери времени, пока человек входит в курс дел.

Это не означает, что менеджер Haskell программистов лучше менеджера программистов, что решает задачи проекта и уберегает от рисков в первую очередь, а на языки смотрит по вторую.
Просто старый раньше пришёл или меньше денег просит.

[zw0rk.blogspot.nl (from livejournal.com)]

Еще раз. Коль скоро существуют компании, которые вовсю пишут на хаскелле/используют FreeBSD/ковыряют в носу шваброй вместо использования Истинно Истинных Технологий -- значит их метод ведения бизнеса жизнеспособен. Это же закон рынка, неэффективные компании выживают только в монопольном положении.

[zamotivator.livejournal.com]

Ну, FreeBSD в последнее время становится меньше, это сильно радует.

Haskell - их особо много и не было, да и нет, и слава богу.

[zw0rk.blogspot.nl (from livejournal.com)]

Это страусиная позиция, извините. Их немного, значит их нет? Контор, которые используют R или erlang, например, тоже немного (в относительных величинах) -- это значит что R/erlang плохой и его надо заменить на то, что вы считаете правильным? Вот они так не думают и живут себе, засранцы.

[zamotivator.livejournal.com]

erlang сейчас существенно больше. Только за последний месяц меня с указанным в резюме "erlang: beginner" позвали в три разных места (!!!)
erlang выходит в mainstream, это их многих мест слышно, да и знакомые не пугаются при его виде.

R - вы простите, но у меня на рабоет с ним работать приходится. Биндинги в него писать. И он популярным в scientific кругах стал уже весьма прочно, последний год - так вполне определённо.

У каждого своя ниша. erlang позволяет легко писать в event-driven стиле распределённые системы (распределённые не обязательно из соображений производительности. Язык так себе, достаточно, к тому же, тормозной. Но есть и killer feature - типа общего пространства процессов и отсутствие необходимости в IPC/RPC как класса. Это всё искупает)

R - научные вычисления. Как и octave, как и matlab.

А где ниша Haskell?

[zw0rk.blogspot.nl (from livejournal.com)]

> erlang сейчас существенно больше. Только за последний месяц меня с указанным в резюме "erlang: beginner" позвали в три разных места (!!!)

Ну, это конечно фундаментальный показатель.

> R - вы простите, но у меня на рабоет с ним работать приходится. Биндинги в него писать. И он популярным в scientific кругах стал уже весьма прочно, последний год - так вполне определённо.

То есть R -- нужен? Потому что его используют. Но ведь у него те же проблемы, что и у хаскелля, нет? Тоже мало кто его знает, тоже понапишут шибко умные, потом сиди разбирайся.

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

Это очень похоже на разновидность луддизма.

> А где ниша Haskell?

На этот вопрос я вам не отвечу, я хаскель использую редко.

[zamotivator.livejournal.com]

> Ну, это конечно фундаментальный показатель.

Это очень важный показатель. Есть спрос - будут программисты - будет кому заменить человека в команде после ухода

> То есть R -- нужен? Потому что его используют. Но ведь у него те же проблемы, что и у хаскелля, нет? Тоже мало кто его знает, тоже понапишут шибко умные, потом сиди разбирайся.

"шибко умные" - это когда файлы сканируются на диске через эндофункторы или нужен гамак с лыжами и монадами для скачки файлов по http.

R сидит хорошо в своей нише - научные вычисления. Линейная алгебра, та же. Люди что берут R они знают, что такое матрицы, и язык ими выбранный адекватен их задаче.

Человек, что пишет простого робота для анализа сайтов для своей мелкой хотелки - ему нафиг не впёрлись эти монады и доллары. Ему нужно РЕШИТЬ ЗАДАЧУ. Вот на Питон это элементарно. Пара запросов в гугль. Этим скачиваем странички. Этим парсим и и ищем нужную нам инфу. А вот так складываем результат в файлик. Всё просто и понятно.

> Не надо мне объяснять что такое эрланг и с чем его едят. Вообще, зачем от темы уходить? По вашей логике получается, что эрланг тоже не нужен, как и R, по тем же причинам.

Как же с Хаскелл-фанатиками туго-то, а. Речь идёт не про то, лучше ищи хуже язык. Речь идёт про адекватность языка поставленным задачам и риски компании связанные с его использованием.

> На этот вопрос я вам не отвечу, я хаскель использую редко.
Нишы Ерланга и R я описал. Могу и нишу Питона описать - это скриптовый язык, что работает везде, и оптимально годится для автоматизации мелких рутинных задач.
Лучше чем shell.

[zw0rk.blogspot.nl (from livejournal.com)]

> Это очень важный показатель. Есть спрос - будут программисты - будет кому заменить человека в команде после ухода

Опять двадцатьпять. Мы уже это обсуждали. Это вопрос менеджмента -- ну вот выживают конторы сумасшедших хаскелефилов, стало быть находят они специалистов. Не иначе как без вмешательства сатаны не обходиться.

> "шибко умные" - это когда файлы сканируются на диске через эндофункторы или нужен гамак с лыжами и монадами для скачки файлов по http.

Шибко умные, это когда зачем-то свои матрицы и детерминанты тащат в СЛУ. Ведь любому дураку понятно, что можно решить простым перебором. Тоже ведь подход? И найти таких решателей на рынке еще проще, чем тех, кто знает про алгебру что-то?

> Человек, что пишет простого робота для анализа сайтов для своей мелкой хотелки - ему нафиг не впёрлись эти монады и доллары. Ему нужно РЕШИТЬ ЗАДАЧУ. Вот на Питон это элементарно. Пара запросов в гугль. Этим скачиваем странички. Этим парсим и и ищем нужную нам инфу. А вот так складываем результат в файлик. Всё просто и понятно.

Ну порадуемся за человека. А другой пишет "на эндофункторах" и у него тоже задача решается. Надо его убить, чтобы не смущал?

> Как же с Хаскелл-фанатиками туго-то, а. Речь идёт не про то, лучше ищи хуже язык. Речь идёт про адекватность языка поставленным задачам и риски компании связанные с его использованием.

Ну вот я уже и фанатик. Я привёл уже довод о законах рынка и хаскель/скала/whatever-конторах. Ну разбейте этот довод, раз я фанатик.

[zamotivator.livejournal.com]

> Опять двадцатьпять. Мы уже это обсуждали. Это вопрос менеджмента -- ну вот выживают конторы сумасшедших хаскелефилов, стало быть находят они специалистов. Не иначе как без вмешательства сатаны не обходиться.

Либо они работают за такие деньги, на которые нормальных специалистов на других языках не наймёшь. Это называется "демпинг" и говорит не в пользу Haskell.

> Шибко умные, это когда зачем-то свои матрицы и детерминанты тащат в СЛУ. Ведь любому дураку понятно, что можно решить простым перебором. Тоже ведь подход? И найти таких решателей на рынке еще проще, чем тех, кто знает про алгебру что-то?

Никому "СЛУ" работе решать не нужно. Людям нужно решать задачи, то поставил менеджмент.
Один знакомый не так давно пришёл тимлидом в проект по написанию систему рекомендаций.
Почитал что и как делают в machine learning, почесал репу, взял Java + Hadoop, вспомнил матрицы, заколбасил решение, работает. СЛУ в процессе тоже решать приходилось. Только это детали реализации, особенности алгоритмов такие, что их удобней делать через СЛУ и линейную алгебру.

Для скачивания файла по http не нужно знать всякого дерьма типа монад.
Правильное решение задачи выглядит так:
import urllib
urllib.urlretrieve ("http://www.example.com/songs/mp3.mp3", "mp3.mp3")

И что, сука, характерно, будет работать на любом линуксе сразу, без всяких приседаний. запихивается в script.
Не нужно решать квест "как скачать haskell", квест "какую лтбу взять" и квест "как мне пофильтровать из скачанного файла через монады бесплатно без смс" когда приспичит.

> Ну порадуемся за человека. А другой пишет "на эндофункторах" и у него тоже задача решается. Надо его убить, чтобы не смущал?

Если он это притащил в рабочий проект без чёткого письменного обоснования почему это нужно и подписей менеджмента - то это попахивает саботажем, с моей точки зрения.
Вообще говоря, любые свои решения в проекте нужно обосновывать. Не абстрактными "эффективность выше", а конкретикой - вот линейная алгебра нужна, потому что через неё существенно проще описывать рекомендации и веса, алгоритм линейной регрессии через неё работает - другими способами решать сложней.
Понимаете? Когда ДРУГИЕ РЕШЕНИЯ - СЛОЖНЕЕ.

[thesz.livejournal.com]

Чем Cloud Haskell не ниша Хаскеля? Помимо всякого другого, той же REPA.

[zamotivator.livejournal.com]

Вот когда I/O, монады и ленивость починят, вот тогда и станет нишей. А пока не тянет.

[thesz.livejournal.com]

То есть, надо починить только то, что вы не смогли освоить? Так?

[zamotivator.livejournal.com]

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

[metaclass.livejournal.com]

Это ты еще внутренностей виндовс-рантайма хаскеля не смотрел наверно :)
Там все эти сказки про зеленые потоки, ожидания i/o и прочая асинхронность превращены в ебаную срань из костылей и утечек хендлов.
Короче, любимый пример с пиздатейшим TCP-сервером на хаскеле в пару строк под виндой под небольшой нагрузкой дохнет в сраку :)

[http://users.livejournal.com/_slw/]

столько еботни, сколько есть у тебя с редхатом, у админов freebsd не бывает никогда.

[zamotivator.livejournal.com]

Сравнивать разработку под RedHat и администрирование FreeBSD это охуенно корректно, ага.
Примерно как администрирование RedHat и разработку под FreeBSD

[http://users.livejournal.com/_slw/]

разработка под freebsd легка и приятна, а администрирование redhat -- страх и ужас.

[zamotivator.livejournal.com]

Разработка под FreeBSD - это кровь, кишки, и распидарасило.
начиная с gmake и заканчивая неработающими atomic functions.

[http://users.livejournal.com/_slw/]

ты все врешь и я тебе это уже объяснял.

[zamotivator.livejournal.com]

Слава богу, FreeBSD умерла, и больше меня не тревожит ни в каком виде

[http://users.livejournal.com/_slw/]

любишь ты свой опыт генерализировать.
что с freebsd, что с хаскелем.

[zamotivator.livejournal.com]

Я при этом промахиваюсь существенно меньше Haskell и FreeBSD фанатиков

[http://users.livejournal.com/_slw/]

не, ты при этом постоянно промахиваешься.