![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВчера ![[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
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-10-11 09:06 pm (UTC)Ну эдак мы возвращаемся к тому недавнему треду на жуйке про ivan-ghandi и аппликативные функторы и монады. То, что кому-то помешало оценить, не говорит, что кому-то другому тоже помешает оценить. Я тут некоторый максимализм вижу.
no subject
Date: 2012-10-11 09:13 pm (UTC)Денег дают раза в два-три больше, чем С. З. в своей вакансии Haskell в Москве предлагал, проекты - 90% унылы, остальные 10% бывают вполне так себе интересными.
Советуются с интересными проблемами, опять же.
haskell и эти все эндофункторы выглядят эмблемами некоторого клуба людей, которых я могу описать примерно так:
* про командную работу думают не часто, либо нашли/создали на работе отдел единомышленников
* про риски работодателя и проекта не задумываются
* вариант "выбрать язык под задачу" им часто даже в голову не приходит
* уязвлённоё удивление и обидчивое непонимание, когда им рассказывают, почему их любимый язык такой хреновый (или что эндофункторы в их проекте не нужны).
С моей точки зрения, если они успешно решают задачи на работе - то это благодаря тому, что они умные, а не блогадаря тому, что Haskell. А если бы больше думали про то, что нужно проекту, а не то, чего хочется лично им, были бы ещё умней и успешней, и денег получали бы соразмерно больше.
Я не говорю, что деньги критерий, но 70к в Москве получают пыхеры средней руки.
Есть такое пенальти между требуемыми интеллектуальными усилиями и сложностью проекта, а также зарплатой.
В этом смысле мне товарищи напоминают FreeBSD админов. Те часто идут на зарплату в полтора раза ниже рынка, и половину рабочего времени сидят и пилят свою FreeBSD, патчи отправляют, portage упаковывают и так далее.
no subject
Date: 2012-10-11 09:18 pm (UTC)> В этом смысле мне товарищи напоминают FreeBSD админов. Те часто идут на зарплату в полтора раза ниже рынка, и половину рабочего времени сидят и пилят свою FreeBSD
Кому-то нравится это делать. Все всегда ищут баланс между "интересно" и "сколько денег". Разные люди находят этот баланс в разных точках. Причем здесь хаскель и ваши психологические комплексы -- совершенно неясно.
no subject
Date: 2012-10-11 09:21 pm (UTC)Я не иду в веб-разработку не потому, что там нет интересных задач, а потом, что задачи интересные мне в веб-проектах нахер не нужны обычно. А если я заскучаю и начну их тащить - это будет прямой ущерб проекту и, пожалуй, даже саботаж.
Мне вот scala интересна. Сижу и прохожу coursera, книжки читаю, pet-project пилю.
Но на работу я scala не потащу. Потому что она там нахер не нужна.
И что-то мне подсказывает, что в 90% случаев притащенные эндофункторы и haskell не так уж и нужны были, и малой кровью можно было обойтись без них.
В итоге есть у нас эндофункторы и haskell в отдельных проектах - огромной гемморой для владельца кодовой базы в поддержке в будущем.
no subject
Date: 2012-10-11 09:23 pm (UTC)Про эндофункторы уже было в жуйке, нет смысла по новой заводить шарманку.
no subject
Date: 2012-10-11 09:27 pm (UTC)Ущерб работе в том, что половину рабочего времени админ решает не задачи работодателя (чтобы почта и прочее работало) а проблемы FreeBSD проекта.
При работе с linux такого сорта задач ощутимо меньше.
Вот и с Haskell также. Сначала один шибко умный притащил haskell. Потом ему надоел проект и он поменял работу. В итоге работодателю приходится искать на не шибко богатом рынке haskell программиста, который с такими же альтернативными взглядами, как ушедший разработчик и мучаться с ним дальше.
Это косяк менеджмента, но что это меняет?
no subject
Date: 2012-10-11 10:25 pm (UTC)Это меняет всё. Если такой менеджмент существует и выдерживает конкурентную борьбу, значит это не самый плохой из менеджментов.
no subject
Date: 2012-10-11 10:29 pm (UTC)И да, замени любого человека в небольшой айти компании всегда болезненно.
Часто бывает, что эффективность кандидата в два раза лучше текущего сотрудника при прочих равных не является достаточным основанием для увольнения старого
Во-первых - фиг уволишь (самое доброе в мире ТЗ!)
Во-вторых - риски замены людей никто не отменяет. Фиг его знает, что там будет с новеньким. Старый хотя бы понятно что из себя представляет.
В-третьих - такие замены это неизбежные потери времени, пока человек входит в курс дел.
Это не означает, что менеджер Haskell программистов лучше менеджера программистов, что решает задачи проекта и уберегает от рисков в первую очередь, а на языки смотрит по вторую.
Просто старый раньше пришёл или меньше денег просит.
no subject
Date: 2012-10-11 10:31 pm (UTC)no subject
Date: 2012-10-11 10:34 pm (UTC)Haskell - их особо много и не было, да и нет, и слава богу.
no subject
Date: 2012-10-11 10:36 pm (UTC)no subject
Date: 2012-10-11 10:40 pm (UTC)erlang выходит в mainstream, это их многих мест слышно, да и знакомые не пугаются при его виде.
R - вы простите, но у меня на рабоет с ним работать приходится. Биндинги в него писать. И он популярным в scientific кругах стал уже весьма прочно, последний год - так вполне определённо.
У каждого своя ниша. erlang позволяет легко писать в event-driven стиле распределённые системы (распределённые не обязательно из соображений производительности. Язык так себе, достаточно, к тому же, тормозной. Но есть и killer feature - типа общего пространства процессов и отсутствие необходимости в IPC/RPC как класса. Это всё искупает)
R - научные вычисления. Как и octave, как и matlab.
А где ниша Haskell?
no subject
Date: 2012-10-11 10:45 pm (UTC)Ну, это конечно фундаментальный показатель.
> R - вы простите, но у меня на рабоет с ним работать приходится. Биндинги в него писать. И он популярным в scientific кругах стал уже весьма прочно, последний год - так вполне определённо.
То есть R -- нужен? Потому что его используют. Но ведь у него те же проблемы, что и у хаскелля, нет? Тоже мало кто его знает, тоже понапишут шибко умные, потом сиди разбирайся.
Не надо мне объяснять что такое эрланг и с чем его едят. Вообще, зачем от темы уходить? По вашей логике получается, что эрланг тоже не нужен, как и R, по тем же причинам.
Это очень похоже на разновидность луддизма.
> А где ниша Haskell?
На этот вопрос я вам не отвечу, я хаскель использую редко.
no subject
Date: 2012-10-11 10:50 pm (UTC)Это очень важный показатель. Есть спрос - будут программисты - будет кому заменить человека в команде после ухода
> То есть R -- нужен? Потому что его используют. Но ведь у него те же проблемы, что и у хаскелля, нет? Тоже мало кто его знает, тоже понапишут шибко умные, потом сиди разбирайся.
"шибко умные" - это когда файлы сканируются на диске через эндофункторы или нужен гамак с лыжами и монадами для скачки файлов по http.
R сидит хорошо в своей нише - научные вычисления. Линейная алгебра, та же. Люди что берут R они знают, что такое матрицы, и язык ими выбранный адекватен их задаче.
Человек, что пишет простого робота для анализа сайтов для своей мелкой хотелки - ему нафиг не впёрлись эти монады и доллары. Ему нужно РЕШИТЬ ЗАДАЧУ. Вот на Питон это элементарно. Пара запросов в гугль. Этим скачиваем странички. Этим парсим и и ищем нужную нам инфу. А вот так складываем результат в файлик. Всё просто и понятно.
> Не надо мне объяснять что такое эрланг и с чем его едят. Вообще, зачем от темы уходить? По вашей логике получается, что эрланг тоже не нужен, как и R, по тем же причинам.
Как же с Хаскелл-фанатиками туго-то, а. Речь идёт не про то, лучше ищи хуже язык. Речь идёт про адекватность языка поставленным задачам и риски компании связанные с его использованием.
> На этот вопрос я вам не отвечу, я хаскель использую редко.
Нишы Ерланга и R я описал. Могу и нишу Питона описать - это скриптовый язык, что работает везде, и оптимально годится для автоматизации мелких рутинных задач.
Лучше чем shell.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-10-11 10:52 pm (UTC)no subject
Date: 2012-10-11 10:53 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From: (Anonymous) - Date: 2012-10-13 03:19 pm (UTC) - Expand(no subject)
From:(no subject)
From:(no subject)
From: (Anonymous) - Date: 2012-10-15 02:07 pm (UTC) - Expand(no subject)
From:(no subject)
From: (Anonymous) - Date: 2012-10-15 08:13 pm (UTC) - Expand(no subject)
From:(no subject)
From: (Anonymous) - Date: 2012-10-15 10:04 pm (UTC) - Expand(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2012-10-12 07:14 am (UTC)no subject
Date: 2012-10-12 07:15 am (UTC)Примерно как администрирование RedHat и разработку под FreeBSD
no subject
Date: 2012-10-12 07:21 am (UTC)no subject
Date: 2012-10-12 07:22 am (UTC)начиная с gmake и заканчивая неработающими atomic functions.
no subject
Date: 2012-10-12 07:24 am (UTC)no subject
Date: 2012-10-12 07:24 am (UTC)no subject
Date: 2012-10-12 07:27 am (UTC)что с freebsd, что с хаскелем.
no subject
Date: 2012-10-12 07:28 am (UTC)(no subject)
From:no subject
Date: 2012-10-12 04:59 am (UTC)