nm_work: (Default)
[personal profile] nm_work
Читаю исходные коды, написаные другими программистами, и понимаю, что в образовательных целях и для привития хорошего стиля в программировании надо просто заставлять людей какое-то время писать на функциональных языках.

Иначе они даже в 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 :)

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

Date: 2011-02-11 11:47 am (UTC)
From: [identity profile] smbatgogyan.livejournal.com
Urish lezu petq chi, menak C++ heriq e

Date: 2011-02-11 05:07 pm (UTC)
From: [identity profile] nm-work.livejournal.com
C++ редчайшее уродство :))))

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

Date: 2011-02-11 09:20 pm (UTC)
From: [identity profile] smbatgogyan.livejournal.com
esim, achqis sirum es fast food :-D

Date: 2011-02-14 09:47 am (UTC)
From: [identity profile] ex-norayr.livejournal.com
ապ, եթե դու չես սիրում, ապա ինչու C++ օրինակ բերեցիր, ու ոչ C-ն։ կամ ոչ ասմը։

Date: 2011-02-15 02:37 pm (UTC)
From: [identity profile] nm-work.livejournal.com
все существенно проще, я люблю языки, которые экономят _мое_ время при написании программ.

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

Date: 2011-02-14 10:06 am (UTC)
From: [identity profile] ex-norayr.livejournal.com
дело не только в высоком уровне.
вот хорошая ссылка http://yosefk.com/c++fqa/defective.html

Date: 2011-02-14 10:09 am (UTC)
From: [identity profile] ex-norayr.livejournal.com
для меня важной концепцией является encapsulation с которым в C все плохо.

Date: 2011-02-14 10:17 am (UTC)
From: [identity profile] grigory javadyan (from livejournal.com)
у меня в старом журнале был пост про инкапсуляцию в Си :)

Date: 2011-02-15 02:38 pm (UTC)
From: [identity profile] nm-work.livejournal.com
ну :) для меня нет - так как C надо использовать именно для того, для чего он хорош - для написания небольших и очень быстро работающих вставок кода.

а там обыкновенно можно обойтись спокойно и без инкапсуляций и прочего :)

Date: 2011-02-14 10:17 am (UTC)
From: [identity profile] grigory javadyan (from livejournal.com)
Динамическая типизация - страшная штука.
Покрывать свой код кучей юнит тестов чтоб исключить ошибки типов - мазохизм. Поэтому динамическим языки применимы для скриптования и быстрого прототипирования. Потому что быстро и думать не нада (к тому же когда добавляешь методы к объектам "на лету" в первый раз появляется ощущение, похожее на оргазм, но потом понимаешь, что это не нужно, опасно и уничтожает саму концепцию типа).

Цпп хорош именно потому, что он позволяет красиво реализовывать высокоуровневые абстракции, оставаясь при этом system-level языком со статической типизацией и прочими прелестями.

Date: 2011-02-15 02:31 pm (UTC)
From: [identity profile] nm-work.livejournal.com
ты не поверишь - в C++ катастрофически кривая и усложненная концепция типов :)

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

факт номер 2 - erlang вообще обходится без жесткой типизации (atom/number/tuple/list/binary) и отлично живет :)

Date: 2011-02-16 02:31 pm (UTC)
From: [identity profile] grigory javadyan (from livejournal.com)
> динамическом
> Haskell

лолшто
http://en.wikipedia.org/wiki/Haskell_%28programming_language%29
> Typing discipline *static*, strong, inferred

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

Date: 2011-02-14 10:14 am (UTC)
From: [identity profile] ex-norayr.livejournal.com
microsoft-ը ի դեպ այլեւս չի թողնում Windows Phone-ի համար C++-ով գրել, ինչպես եւ առհասարակ նեյթիվ կոդ օգտագործել - միմիայն դոթնեթ։ չեմ ասում որ լավ քայլ ա, պարզապես fyi էլի։

Date: 2011-02-15 02:35 pm (UTC)
From: [identity profile] nm-work.livejournal.com
ну и правильно, зачем извращаться на low-level языке :)

Date: 2011-02-16 02:32 pm (UTC)
From: [identity profile] grigory javadyan (from livejournal.com)
performance
total control

Date: 2011-02-16 06:27 pm (UTC)
From: [identity profile] nm-work.livejournal.com
тебе не нужен _total_ control :) реально оптимизация 10-15% кода убирает все узкие места с производительностью. оставшееся может выполняться хоть вручную ;) оно все равно не повлияет на конечный результат :)

я понимаю, хочется "чувствовать себя богом" - но на практике это нафиг не надо :)

Date: 2011-02-11 12:15 pm (UTC)
From: [identity profile] narjan.livejournal.com
// во-первых от того, что пишущий никогда не задается вопросом - а как я могу красиво вернуть сразу _несколько_ результатов из функции //

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

Date: 2011-02-11 05:10 pm (UTC)
From: [identity profile] nm-work.livejournal.com
я не был бы рад, если бы lhs были бы именно statements :) а вот просто переменные - да, отлично :)


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

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

Date: 2011-02-11 02:32 pm (UTC)
From: [identity profile] gasparian.livejournal.com
> не задается вопросом - а как я могу красиво вернуть сразу _несколько_

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

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

Date: 2011-02-11 05:05 pm (UTC)
From: [identity profile] nm-work.livejournal.com
я бы постарался этого бы не делать - потому что ты тоже создаешь side effect - меняешь данные, которые тебе передали.

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

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

Date: 2011-02-11 05:16 pm (UTC)
From: [identity profile] nm-work.livejournal.com
т.е. я считаю передачу данных в функцию по reference костылем, который вынужденно используют, так как VM не может минимизировать копирование данных при возврате их в отдельном аргументе. т.е. это вопрос, который лечится внутри VM и не должен контролироваться программистом :)

Date: 2011-02-11 08:45 pm (UTC)
From: [identity profile] gasparian.livejournal.com
> так как VM не может минимизировать копирование данных при возврате их в отдельном аргументе

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

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

Date: 2011-02-15 02:34 pm (UTC)
From: [identity profile] nm-work.livejournal.com
> а на счет минимизации при копировании, то задача, по крайней мере для C++, решается упаковкой tuple-объекта в оболочку из смарт-поинтера с референс-каунтером.


нууу, ты по любому меняешь первоначальный объект, не так-ли? речь идет о том, чтоб максимально НЕ копировать данные, пока это не надо.

кстати erlang пошел дальше - данные всегда копируются, кроме binary. и ничего, жить можно :) в последнее время вроде lists тоже оптимизируют, но все равно :)
правда у них есть один плюс - при рекурсивном вызове себя, если все правильно сделано - данные вообще не копируются, так как вызов происходит внутри этого-же stack frame, без создания нового :)

Date: 2011-02-15 05:01 pm (UTC)
From: [identity profile] levgem.livejournal.com
У тебя не очень хороший пример по той причине, что ты немного спутал уровни на которых используется validate

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

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

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

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

Date: 2011-02-15 06:04 pm (UTC)
From: [identity profile] nm-work.livejournal.com
эээээээ. опять таки. такой подход наверно имеет право на жизнь.

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

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

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

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

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

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

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

а подход MVC - он порождает много костылей все-таки :)

Date: 2011-02-16 03:41 pm (UTC)
From: [identity profile] grigory javadyan (from livejournal.com)
Ну, если запретим сайд эффекты, сделаем переменные иммутабельными, потом будем со всякими монадами маяться и заново учиться имплементить стандартные структуры данных. Мне кажется, эти меры слишком радикальны только и мешают программисту. Код отлаживать легче, не спорю, ведь о purely functional программе гораздо легче делать логические умозаключения. Но в процессе написания чувствуешь себя закованным в кандалы.

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

Date: 2011-02-16 06:32 pm (UTC)
From: [identity profile] nm-work.livejournal.com
:)))))

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

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

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

Date: 2011-02-16 06:29 pm (UTC)
From: [identity profile] nm-work.livejournal.com
кстати, а в такой модели программирования - вот пришли входные данные, скажем из POST - кто их должен забрать/проверить/начать использовать? :)

April 2013

S M T W T F S
 123456
7891011 1213
14151617181920
21222324252627
282930    

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 21st, 2017 04:51 pm
Powered by Dreamwidth Studios