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

[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

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

Какой ущерб наносят "проекту" FreeBSD админы, которые приходят на вакансию админа FreeBSD?

Про эндофункторы уже было в жуйке, нет смысла по новой заводить шарманку.

[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-конторах. Ну разбейте этот довод, раз я фанатик.

[thesz.livejournal.com]

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

[zamotivator.livejournal.com]

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

[thesz.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/]

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

[metaclass.livejournal.com]

Обычно есть вакансия "системный администратор и чтобы все работало". FreeBSD там возникает только тогда, когда предыдущий персонаж притащил фряху из каких-то соображений и работодателю дальше некуда деваться.