?

Log in

No account? Create an account
о программировании - Сделать невозможное (камень -> пар) [entries|archive|friends|userinfo]
Сделать невозможное (камень -> пар)

[ website | Мой основной блог ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| Мой блог о личностном росте Vim-Erlang package Translation tool Пошли свои страхи на ... Задолбали длинные линки? ]

о программировании [Feb. 11th, 2011|03:30 pm]
Сделать невозможное (камень -> пар)
[Tags|]

Читаю исходные коды, написаные другими программистами, и понимаю, что в образовательных целях и для привития хорошего стиля в программировании надо просто заставлять людей какое-то время писать на функциональных языках.

Иначе они даже в OO модели пишут классический спагетти код - с сайд эффектами, с использованием переменных класса в качестве глобальных переменных и т.д.

классический пример (на php)

$data = $this->validate($data);
if (isset($this->validation_results)) { ... }

программист, писавший до этого на чистых функциональных языках написал бы

list($data, $validation_results) = $this->validate($data);
if ($validation_results) { ... }

Я лично считаю, что это идет
  • во-первых от того, что пишущий никогда не задается вопросом - а как я могу красиво вернуть сразу _несколько_ результатов из функции - это тяжелое наследие языка типа Pascal/C, где для этого пришлось бы создавать отдельную структуру
  •  

  • во-вторых, из-за недостатка кругозора в других языках программирования. Даже в том-же самом Python (который уже стал мейнстримом) упаковка/распаковка данных из tuple является очень синтаксически естественной операцией и читая чужой код, учащийся языку воспринял бы эту конструкцию и начал ее использовать. В php это не так принято - и поэтому на нее и не обращают внимание. Написание двух лишних слов array/list в php я не считаю препятствием - просто небольшое неудобство.

В этом плане мне очень нравится подход perl, который даже ссылку на экземпляр объекта передает в качестве аргументов функции - поэтому, когда начинаешь менять что-то в экземпляре объекта - сразу видишь, что в этот момент создаешь side effect :)

Резюме: учите другие языки программирования, хотя бы для расширения кругозора ;)
LinkReply

Comments:
[User Picture]From: nm_work
2011-02-15 06:04 pm (UTC)
эээээээ. опять таки. такой подход наверно имеет право на жизнь.

но у него есть проблема с отладкой. большая проблема всех процедурных языков (OO в том числе) - функции имеют side effects. Я хочу иметь гарантированно выделенные куски кода, которые не трогают ничего, кроме своих аргументов. Т.е. работают строго над своими аргументами, их не меняют, возвращают все что надо.

В классическом функциональном языке это выглядит как (NewState, Result) = f(OldState, Input), т.е. имеет классический детерменированный автомат.

Отлаживать/писать тесты на такой автомат _существенно_ легче, чем код, который внутри себя что-то там изменяет.

Иначе написание unit тестов превращается в следующее:
- загоним объект в нужное исходное состояние (как-то, зачастую это не так то и легко, потому что часть состояния в private/protected)
- вызовем метод, проверим что нам возвратили
- посмотрим как поменялось состояние объекта (если мы сумеем до него добраться)

в случае, если применять подход с минимум side effects - тестирование получается следующее

- дадим известное состояние + данные на вход
- проверим, что получили на выходе правильные данные + новое состояние

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

а подход MVC - он порождает много костылей все-таки :)
(Reply) (Parent) (Thread)
[User Picture]From: Grigory Javadyan
2011-02-16 03:41 pm (UTC)
Ну, если запретим сайд эффекты, сделаем переменные иммутабельными, потом будем со всякими монадами маяться и заново учиться имплементить стандартные структуры данных. Мне кажется, эти меры слишком радикальны только и мешают программисту. Код отлаживать легче, не спорю, ведь о purely functional программе гораздо легче делать логические умозаключения. Но в процессе написания чувствуешь себя закованным в кандалы.

Наверное, надо просто найти золотую середину и придерживаться ее. Ну и, конечно, читать маны отладчика :)
(Reply) (Parent) (Thread)
[User Picture]From: nm_work
2011-02-16 06:32 pm (UTC)
:)))))

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

ты смотришь с точки зрения программиста - 'как бы так красиво разойтись и сделать Архитектуру' :))))

поэтому и разные точки зрения :)
(Reply) (Parent) (Thread)