Re: Программирование на функциональных языках - как научить?
Hello!
On Thursday 20 August 2009 12:31:19 Artem Chuprina wrote:
> Alexey Pechnikov -> debian-russian@lists.debian.org @ Wed, 19 Aug 2009 22:58:58 +0400:
> AP> А примеры подскажете? В данный момент человек не видит, почему
> AP> нужно использовать функции вместо кусков кода с глобальными
> AP> переменными, т.к. ему кажется, что чем меньше кода - тем проще и
> AP> удобнее, а опыта в поддержке у него нет. Я думал, что ему подскажет
> AP> правильное направление мой фрэймворк, на котором он и работает, но
> AP> он полагает, что у меня использование функций оправдано, а у него -
> AP> нет. Как бы объяснить и показать... Когда говорю, что у меня можно
> AP> переписать реализацию целого модуля, не затрагия весь остальной код
> AP> (скажем, некие часто изменяющиеся данные из in-memory массива с
> AP> мьютексом перенести в сетевую in-memory БД), ответ просто убивает -
> AP> он, мол, не собирается переписывать код, а если придется, все равно
> AP> все придется переделывать... Пытался делать примеры - он их берет
> AP> и "обвешивает" глобальными переменными...
>
> Ты будешь смеяться. Он может быть прав.
>
> Принцип KISS (Keep It Simple, Stupid!). Зачастую действительно дешевле
> первую версию сделать как попало - потому что заранее предусмотреть,
> куда она будет потом развиваться, чаще не получается, чем получается.
> И чтобы успешно предсказывать это самостоятельно, нужно иметь
> _собственный_ опыт развития. Чужой не помогает. Свой из соседней
> предметной области - тоже.
Если программист помнит весь код проекта, то не долго и поправить в нужном
месте - мне-то приходится сначала разбираться, как все это устроено...
Но версия проекта далеко не первая, хотя в этот раз код переписывался целиком,
т.к. за прошедшие годы я и базовый фрэймворк переписал, да и сами принципы
работы изменились - сейчас многое выгодно делать на яваскрипт.
Но, пока он в отпуске и поддержку я сам выполняю, я тут вывел список переменных,
имена которых генерятся в коде, и обнаружил, что огромное их число просто не
существует. Передает он их в мои функции, где все это проверяется и ошибок не
возникает, но в интерфейсе временами появляются артефакты, причины которых
понять почти нереально, можно только поправить код, избавившись от переменных-
фантомов. Это один из результатов перехода от С к динамическому языку.
> Работа в функциональном стиле в языке без встроенной хвостовой рекурсии
> оправдана очень и очень не всегда - очень красиво работающий код может
> очень неизящно навернуться по причине stack overflow при удлинении в
> несколько раз обрабатываемой последовательности данных, например. А
> если в нем еще и нельзя array нормально передать или вернуть (пара из
> array get/array set - это НЕ нормально)...
>
> В результате у меня на tcl работа с array чаще сделана через upvar, а
> если в деле замешаны еще и асинхронные обработчики (fileevent или какой
> tk'шный биндинг), то через global. Потому что в них, блин, куда сложнее
> запутаться, чем в суперпозициях eval, concat и list.
В тикле 8.5 жить полегче стало - раскрытие списков {*} помогает. Ради
этого я пересобрал AOL 4.5.1 с тиклем 8.5 и выловил баги, причем затраченное
на это время с лихвой уже окупилось. Другие новые возможности полезны,
но не так критичны.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Reply to: