?

Log in

No account? Create an account

Заповедник репрессивной психиатрии

Entries by category: психология

О гендерном неравенстве
metaclass
http://si14.livejournal.com/41832.html
Много ли вы видели женщин, которые даже при наличии бабла, пустят в дом постороннюю домохозяйку-няню для детей?
А без этого вариантов ровно три:
1) Женщина забивает на семью и занимается работой.
2) Женщина ни шатко ни валко работает, и занимается семьей. Такие специалисты НАХЕР никому не нужны. Много оплачиваемой работы есть только для тех, кто въябывает.
3) Женщина пытается правильно делать и то и другое и сходит к херам с ума от перегрузки и недосыпания.

PS: Уточню по поводу работников. Если у меня, как у работодателя, есть запас по рабочей силе хотя бы 1.5 раза - то ничего страшного в том, что кто-то из работников пинает херы/ушел в декрет/уходит посреди дня за дитенком в садик/сидит дома с ребенком - это норма. Или же, как это делаю я - я всегда сижу дома с детьми, но я 90% времени нахожусь на связи (в т.ч. и по ночам).

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

О перфекционизме, Петях, Васях и статической типизации.
metaclass
С одной стороны, мы имеем вот такое: http://tonsky.livejournal.com/272580.html
Никто не спорит, что софт в плане интерфейса и функций чаще всего - кромешный ад, причем иногда виноваты программисты и тогда это можно поправить, достаточно объяснить им с занесением в мозги. Или лучше отобрать у них реализацию UI и отдать ее специалистам по юзабилити. А еще лучше - по эргономике и технической эстетике.
Иногда - виноваты маркетологи и прочие выжиматели дохода, которым кажется, что анальные издевательства в софте заставят пользователя быстрее поделится содержимым кошелька. В таком случае исправлено не будет никогда, скорее все перейдут на более удобный софт (если он вообще есть), вне зависимости от того, платный он, с рекламой или бесплатный.

С другой стороны: любители лепить куличики из неподходящих материалов и долепливать за другими их поделия делятся копипастой, где рисуется благостная для них картина скоростной монетизации их несомненно нужных и полезных умений: http://artureg.livejournal.com/189640.html

Там же в комментариях менеджеры-монетизаторы обвиняют раввинатик в перфекционизме. Хотя, если вспомнить то что делали артурег и айседа для специальной олимпиады с оперденями - никакого перфекционизма там и близко нет.
Единственный, кого реально можно реально обвинить в этом - это я, потому что мне кривой код, идиотское юзабилити и грамматические ошибки жгут глаза, вплоть до того, что я прежде чем делать требуемую фичу, сначала починю все, что меня раздражает, потому что работать над кривым кодом - это не уважать себя.
Причем, что бы там не говорили любители "работать на результат" (термин из статьи, из комментариев к которой взята копипаста) - вычищение завалов их идиотизма из кода ускоряет дальнейшую работу настолько, что любая трата времени оправдывается многократно. А уж если этот софт потом твоей же конторе и сопровождать 10-15 лет - там получается так: 1 раз сделал нормально обработку ошибок - спас тыщи часов работы саппорту, один раз сделал повторно используемый корректный код вместо костылей - спас тыщи часов работы себе, когда понадобится очередная "мелкая фича из 3 строк кода на 5 минут".

При этом, статическая или динамическая типизация, вроде бы - должно быть ортогонально годности софта для пользователей и прочему, но я не могу избавится от мысли о том, что порядок в голове начинается с порядка в тумбочке. Т.е. орднунг в типах должен соответствовать орднунгу в поведении софта и орднунгу в юзабилити.
Например: у меня, по мере возможности, требования, бизнес-логика и интерфейс пользователя закодированы в системе типов. (Если что - схема БД, внешние контракты, форматы данных - это все или типы сами по себе, или соответствует типам, т.е. как только мы что-либо такое фиксируем в программе - мы занимаемся статической типизацией, даже если пишем на языке, который явно это не поддерживает). Соответственно, при таком подходе сделать интерфейс, противоречащий внутренней логике программы или требованиям, будет весьма сложно.

Аргументы против статической типизации, приведенные айседом и прочими:
0) "У меня в функции всегда приходят данные, тип которых я знаю". Я не уверен, что это аргумент "против", т.к. такая ситуация всего лишь перекладывает поддержку типов с компилятора на программиста.
Да, я, когда пишу на кложури, тоже в большинстве случае знаю, какой тип придет. Если лишнюю пару квадратных скобок в очередном DSL для бухгалтерии в нужном месте не воткну, после чего мне вместо Integer придет Vector of Integer и все ляснется в рантайме, с километровым стек-трейсом.

1) Оверхед на ее поддержку. Не совсем понимаю, что это означает, но могу представить: например в F# объявлять типы так, чтобы ими было удобно пользоваться, очень задалбывает. Типы вроде хэшей в кложуре/руби/js в этом плане очень удобны, т.к. их заранее объявлять не нужно и мы фактически на халяву имеем structural typing. Кроме этого, иногда в функцию желательно передать объекты разных типов, при этом в статик типизации нам придется для этого мудрить новый вариантный тип.

2) Расширяемость типов. Expression Problem, то бишь. "Юзер должен иметь возможность создать новый тип и подсунуть его в нашу либу, не меняя ее". Для вариантных типов это не работает, но реализуется в системах с субтипами/наследованием. И в случае с статик типизацией тянет за собой дикое вуду - экзистенциальные типы, ко- и контравариантность, LSP (впрочем, этот принцип и для динамической должен работать) и тому подобное.

3) Динамическая работа с кодом. Т.е. monkey patching, загрузка конфигурации ORM на старте, исходя из схемы БД, подключение к работающей системе и изменение кода в ней. С этим всем не просто плохо, а очень плохо.
Зависимые типы, эволюция типов с уже существующими данными, версионность, миграции - этого практически нет. Статик типы тут дают только возможность "не сломать в процессе миграции", но никак не помогают эту миграцию осуществить, особенно если у тебя там 100 млн записей где-нибудь в живой системе. Особой разницы в том, лежат эти данные в БД или находятся в памяти запущенных инстанстов узлов системы - нету. Ну и даже обычные проверки вида "мы запустили систему с БД, схема которой совместима с типами внутри программы" - и то приходится вручную закатывать.


PS: А вот лично мой аргумент за статическую типизацию: она снижает нагрузку на мозг при реализации типичных задач. Работ много, проектов много, голова не казенная - соответственно, не нужно включать мозг, чтобы думать над очевидными вещами, которые вычисляются автоматически. Тупиковые пути решения сразу же отсекаются тайпчекером в голове и остается только думать про действительно сложные и требующие мозговых усилий вещи.