о программировании

[nm_work]

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

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

Comments

[smbatgogyan]

Urish lezu petq chi, menak C++ heriq e

[nm_work]

C++ редчайшее уродство :))))

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

[smbatgogyan]

esim, achqis sirum es fast food :-D

[ex_norayr]

ապ, եթե դու չես սիրում, ապա ինչու C++ օրինակ բերեցիր, ու ոչ C-ն։ կամ ոչ ասմը։

[narjan]

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

ne sip' mne sol' na rani
ya vot javu nenavizhu, za to chto v ney netu daje tuple-ov. Prichem netu ne potomuchto nedodelali, a potomu chto chey to krivoy mozg reshil, chto eto protivorechit idee OOP

ksta, v matlab e ochen' krasivo

[ a b c ] = foo()

gde a, b, c kakie ugodno lhs statementi

[nm_work]

я не был бы рад, если бы lhs были бы именно statements :) а вот просто переменные - да, отлично :)

мозг правильно решил - tuples противоречат идеет OOP :))))) и язык начинает походить на что-то функциональное сразу.

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

[gasparian]

> не задается вопросом - а как я могу красиво вернуть сразу _несколько_

а $result = $this->validate( $data );

где $data передается по ссылке, не вариант?

[nm_work]

я бы постарался этого бы не делать - потому что ты тоже создаешь side effect - меняешь данные, которые тебе передали.

т.е. 3 раза подряд вызвать эту функцию и получить одинаковые результаты - не получится.

для упрощения структуры программы лучше никогда не рассматривать возможность менять входные аргументы функции.

[nm_work]

т.е. я считаю передачу данных в функцию по reference костылем, который вынужденно используют, так как VM не может минимизировать копирование данных при возврате их в отдельном аргументе. т.е. это вопрос, который лечится внутри VM и не должен контролироваться программистом :)

[gasparian]

> так как VM не может минимизировать копирование данных при возврате их в отдельном аргументе

на самом деле я довольно долго и нудно отстаивал свою точку зрения на счет НЕ реализации "передачи по ссылке" аргументов при удаленном вызове (подобие RPC для собственного маршалинга), но всегда наталкивался на непонимание со стороны C++ -истов.

а на счет минимизации при копировании, то задача, по крайней мере для C++, решается упаковкой tuple-объекта в оболочку из смарт-поинтера с референс-каунтером.

[levgem]

У тебя не очень хороший пример по той причине, что ты немного спутал уровни на которых используется validate

Поясню (с некоторыми отхождениями от действительности) на примере того, откуда эти валидации появились в PHP: на рельсах.

В модуле ActiveModel::Validation есть функция get_validation_errors Она то вполне себе немодифицирующая, возвращает список ошибок.

А вот метод validate на объекте очень даже должен быть модифицирующим, потому что это посылка командного слова уровня бизнес-логики: поменяй своё состояние. Это нужно, потому что именно так устроена концепция MVC: контроллер посылает командные слова объектам уровня модели, что бы потом их рендерить во view.

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

[nm_work]

эээээээ. опять таки. такой подход наверно имеет право на жизнь

[ext_344899]

Ну, если запретим сайд эффекты, сделаем переменные иммутабельными, потом будем со всякими монадами маяться и заново учиться имплементить стандартные структуры данных. Мне кажется, эти меры слишком радикальны только и мешают программисту. Код отлаживать легче, не спорю, ведь о purely functional программе гораздо легче делать логические умозаключения. Но в процессе написания чувствуешь себя закованным в кандалы.

Наверное, надо просто найти золотую середину и придерживаться ее. Ну и, конечно, читать маны отладчика :)

[nm_work]

:)))))

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

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

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