![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программно-аппаратный комплекс из dvb-t тюнера и набора софта написанного инопланетными марсианами, чтобы принимать сигналы идентификации от самолетиков:
http://www.cacodaemon.org/content/adsb.png
http://www.cacodaemon.org/content/adsb.png
Jan. 11th, 2013
С одной стороны, мы имеем вот такое: 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: А вот лично мой аргумент за статическую типизацию: она снижает нагрузку на мозг при реализации типичных задач. Работ много, проектов много, голова не казенная - соответственно, не нужно включать мозг, чтобы думать над очевидными вещами, которые вычисляются автоматически. Тупиковые пути решения сразу же отсекаются тайпчекером в голове и остается только думать про действительно сложные и требующие мозговых усилий вещи.
Никто не спорит, что софт в плане интерфейса и функций чаще всего - кромешный ад, причем иногда виноваты программисты и тогда это можно поправить, достаточно объяснить им с занесением в мозги. Или лучше отобрать у них реализацию 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: А вот лично мой аргумент за статическую типизацию: она снижает нагрузку на мозг при реализации типичных задач. Работ много, проектов много, голова не казенная - соответственно, не нужно включать мозг, чтобы думать над очевидными вещами, которые вычисляются автоматически. Тупиковые пути решения сразу же отсекаются тайпчекером в голове и остается только думать про действительно сложные и требующие мозговых усилий вещи.
Козлопитоны позорные
Jan. 11th, 2013 10:46 pmtry: my_position = [float(self.ui.line_my_lat.text()), float(self.ui.line_my_lon.text())] except: my_position = None
Как же меня достали рукожопые радиолюбители своим UI - не передать. Если предметку (численные методы да DSP) они обычно знают более-менее нормально, то программирование и проектирование интерфейсов - это ад на земле. Хуже бывает только в вычислительных центрах крупных госконтор.