![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_r![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
levgem удивляется, почему для решения самых элементарных задач передовые программисты выбирают самые неадекватные методы. По поводу вопроса и, особенно, расцвётшего под ним обсуждения приходится повторить давно наблюдаемый базовый принцип функционирования айтишного народа.Программирование в подавляющем большинстве случаев - скучная рутина, а людям хочется творчества и самовыражения. В результате они делают всё возможное, чтобы результат не (просто) работал, а ярко демонстрировал крутизну и оригинальность его создателя.
Этот принцип работает везде и на всех уровнях.
Студенты и учёные, которые сидят на языках и пишут книжки, прославляют «изящные решения, которые компактно и красиво решают задачу», правда требуют десяти страниц подробных объяснений. И не факт, что Раджниш, который будет «добавлять небольшие изменения» в скопированный из гениального учебника рабочий код, знает о последнем условии.
Программисты, вылезшие в менеджеры, обставляют себя хитроумными тулами и начинают при каждом удобном случае произносить заклинания вроде «Lean», «Kanban», «Scrum», «CMMI», «ISO/IEC 15504». При удачном раскладе они прячутся за ними так надёжно, что якобы подчинённые не видят их неделями. А если случайно и встретят, не в состоянии понять смысл руководящих указаний.
Вместо решения задачи с нуля элементарными средствами фирма покупает хитроумный тул, из которого потом путём героических усилий пытается добиться минимально адекватной этой самой задаче функциональности.
Если же люди дорываются до создания архетектур, дизайнов и видений, свобода творчества вырывается из всех границ разума. Тем более, что воплощать это в жизнь приходится совсем другим (и сидящим на гораздо более низких позициях)
Не стоит надеяться, что, если человек программирования не знает, начал недавно и просто немного туп, его творческие порывы будут ограничены. Мне попадались образцы, где элементарный выбор имён функций и переменных порождал головоломку по уровню претендующую на обладателя минимум второго разряда по шахматам. (Да, я позорно сдавался и просто менял имена на понятные, но даже так мне удавалось осознать красоту идеи и весь гений человека, пытающегося это поддержать и искать там ошибки).
Чтоб не заканчивать на грустном: в очередной серии Chu-2 авторы опять выдали прекрасное, создав в десятке секунд выброс адреналина объёмом, не доступном для занудных дорогущих и приправленных спецэффектами погонь Голливуда. Хотел бы я уметь так делать сюжеты.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-11-29 09:46 am (UTC)все то что можно загнать в трубу функции без сильного усложнения кода - нужно загонять
no subject
Date: 2012-11-29 10:39 am (UTC)Ну или потребует адаптации кода.
no subject
Date: 2012-11-29 01:12 pm (UTC)no subject
Date: 2012-11-29 01:12 pm (UTC)Чем мне нравится Перл, так это то, что все парадигмы мне пофиг. Если задача решается циклом, я делаю цикл. Если функциональный подход даёт результат быстрее и проще, я иду им.
И потом через пол года не надо думать, почему это сделано и как это работает.
no subject
Date: 2012-11-29 01:59 pm (UTC)Миф о том, что ФП даст волшебным образом распараллелить обработку массива не более чем миф, не надо его трогать.
no subject
Date: 2012-11-29 02:43 pm (UTC)А распараллеливание без применения мозгов и понимания происходящего - это великолепная маркетинговая приманка для менеджеров любого калибра.
no subject
Date: 2012-11-29 08:03 pm (UTC)no subject
Date: 2012-11-30 06:36 am (UTC)Наши дедушки писали спецификации программ, а потом их реализации (в машинных кодах). Мы дожили до времён, когда можно писать одну только спецификацию и её запускать. Уже когда написали “спецификацию”, запустили и убедились, что она корректна — вот после этого можно уже посмотреть: если что-то работает слишком медленно, не параллелится или памяти много жрёт, можно отдельные места низкоуровнево оптимизировать. И не надо думать, что низкоуровневая оптимизация это обязательно на ассемблере/Си и прочих close to machine языках. Когда вещь, которая естественным образом выражается через цикл, насильно запихивают в рамки ФП чтобы она лучше параллелилась — это низкоуровневая оптимизация.
Спецификация это такое описание процедуры или модуля, из которого _очевидно_, что именно она/он делает. Таких описаний бывает много, конечно. Ну вот например одна из спецификаций процедуры sort:
“Процедура sort берёт конечное множество и возвращает список, состоящий из минимального элемента этого множества, потом минимального элемента оставшегося множества и так далее.”
sort(items: Сollection) = min(items) cons sort(items without min(items))
sort(Collection.Empty) = List.Empty
Чем хорошо такое определение? Тем что оно функционально? — хрена с два; то, что оно функциональное это мелкая частность и стечение обстоятельств. По-настоящему оно хорошо тем, что соответствует понятному непрограммисту описанию на естественном языке, и при этом максимально просто, вероятность допустить в таком определении ошибку минимальна. А если ещё делать перекрёстное ревью кода и написать пару юнит-тестов, то вообще исчезающе мала.
А вот если, скажем, процедуру sort определять через алгоритм, который хитрый и ещё надо доказывать, что он вообще работает, возникает вопрос что значит "доказывать что Х работает верно". Это значит, что нужно доказать что Х работает эквивалентно своей спецификации. А где эта спецификация? Её так или иначе надо написать, и доказательство так или иначе провести, потому что иначе вероятность ошибки колоссальна: я знаю как ошибки в нетривиальной алгоритмике выявлялись спустя _годы_ использования софта в продакшине, то есть никакое закидывание юнит-тестами бы их не вскрыло. Вот потому я и адепт того, чтобы писать программы их конструктивными спецификациями, а оптимизации использовать максимально редко.
ФП я люблю ровно постольку поскольку функциональный стиль часто идеален для написания конструктивных спецификаций функций. Однако для написания конструктивных спецификаций модулей и сущностей доменной модели приложения, которое я делаю, функциональщины обычно нехватает. Поэтому в ещё большей степени я адепт мультипарадигменных языков, где можно за день накатать DSL отвечающий доменной модели и дальше писать код в таком вот спецификационном стиле, избегая частностей.
Сейчас таких языка, кстати, два: Perl и Scala. Оба люто прекрасны, однако имеют и общий недостаток: в руках неопытного программиста они как боевая граната в руках у двухлетнего карапуза.
no subject
Date: 2012-11-30 08:53 am (UTC)Ну алгоритмы же разные. И понятно, когда массив данных большой и параллелить надо с самого начала. "После этого" обычно ничего путного не получается, если с самого начала не думать.
Дёшево параллелится только то, что построено на парадигме обмена сообщениями.
По-настоящему оно хорошо тем, что соответствует понятному непрограммисту описанию на естественном языке,
Не-а. Понятна непрограммисту, способному к абстрактному мышлению. Абсолютно не у всех есть способности к математике даже на таком уровне.
На самом деле тут фокус только в том, что мы теоретически можем абстрагироваться от реализации и говорить на языке предметной области.
Насчёт же математических алгоритмов - их делают не программисты, а математики. И оптимизируют тоже люди, которые понимают, что делают. По крайней мере, в теории. Основная масса программистов должна заниматься только применением готовых библиотек.
Perl и Scala плохи тем, что создатели разрушают их изнутри, пытаясь научить делать всё. Мне больше импонирует подход смеси языков. Тем более, задача, как правило, делится на этапы или домены без проблем.
Техническое добавление
Date: 2012-11-30 08:32 pm (UTC)Код - это послание
1. Компилятору
2. Себе для анализа и поиска текущих ошибок
3. Неизвестному продолжателю, который это через Х лет будет изменять или переписывать.
Стиль для пунктов 2 и 3 важнее языка. И тут мы натыкаемся на главный трабл: любители языка Ха говорят в терминах и понятиях, не доступных простым смертным. Плюс пытаются записать код, как профессор математики мелом на доске во время факультатива для продвинутых студентов пятого курса. И вот тут пункт три летит к чертям.
no subject
Date: 2012-11-29 04:17 pm (UTC)Вот кстати большой вопрос, почему она решила идти не по "дорожке из досок", а именно по скату..
Но то, такое.
Мне больше понравились выползающие из под кровати волосы :)
Почти звонок, лол.
no subject
Date: 2012-11-29 05:46 pm (UTC)Тут всё чисто и очень хорошо показано. Она не "решила". Она "вскочила, не видя ничего вокруг себя"
С картинкой тоже замечательно. Но, как я говорил, это всё-таки "три сцены". Финал же её затмил. Там авторам удалось на несколько секунд поместить зрителя в шкуру героя. Это дорого стоит.
no subject
Date: 2012-12-02 01:10 pm (UTC)Вы это
http://hackage.haskell.org/package/chu2
имели в виду?...
no subject
Date: 2012-12-02 01:54 pm (UTC)http://www.anime-chu-2.com/ (http://www.anime-chu-2.com/) мультфильмы, что я детям показываю (в любительской русской озвучке, пока немцы не лицензировали и не выпустили на немецком. Когда выпустят, куплю диски)
no subject
Date: 2012-12-02 01:57 pm (UTC)Тот chu2, что я привёл, детям нельзя показывать.