VGn>>Только в одних задачах — это борьба со сложностью вглубь, а в других — вширь.
L>Что такое вглубь и что такое вширь? То, что Влад называл микро и макро?
Похоже, но не совсем.
Вглубь — это решение небольших по объёму требований, но алгоритмически сложных задач.
Вширь — решение большого количества связанных мелких задач по большому количеству динамически изменяющихся требований.
Иногда, но очень редко, сумма второго рождает первое. Но чаще всего в этих случаях нет соответствующих людей, потому что задачи второго списка им не интересны по определению.
Re[19]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, palm mute, Вы писали:
VGn>>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред. PM>Не торопитесь. Функционально-реактивные графические интерфейсы — очень активная область исследований в последнее время. Пролистайте туториал по flapjax, например, и убедитесь, что функциональное описание поведения интерфейса в терминах зависимостей между контролами может быть значительно проще привычных Form1.Button1_OnClick().
Что-то не вижу противоречий с предыдущим утверждением. Логика работы формы — это одно. А презентационная часть совсем другое.
К тому же для логики нужны скорее подходы вроде континюэшонов или конечных автоматов (в прочем первые можно считать плоской и понятной записью последних).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VGn, Вы писали:
VGn>Похоже, но не совсем. VGn>Вглубь — это решение небольших по объёму требований, но алгоритмически сложных задач. VGn>Вширь — решение большого количества связанных мелких задач по большому количеству динамически изменяющихся требований. VGn>Иногда, но очень редко, сумма второго рождает первое. Но чаще всего в этих случаях нет соответствующих людей, потому что задачи второго списка им не интересны по определению.
Добрый день, товарищи!
А если по диагонали?
Например: пишется что-нибудь объемное, функционал, не зависящий от задачи, можно накидать из готовых компонентов или написать на тех Java/C# а сверху прикрутить что-нибудь ДикоФункциональноЗасахареннное+сПоддержкойООП (например scala хорошо встраивается в Яву) и прикладные вещи писать уже на нем. Таким образом никаких проблем с декомпозицей не будет(ООП и там и там), можно использовать все фичи ФП и в то же время функцилнальная зараза(сахар) не распротраняется по всей программе.
Возникает два вопроса:
1)Стоит ли оно того?
2)Как отлаживать код исполняемый востроенным интерпретатором?(Впрочем если его будет немного то можно
обойтись и отладочными сообщениями).
Re[23]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, mini_root_2, Вы писали:
__>2)Как отлаживать код исполняемый востроенным интерпретатором?(Впрочем если его будет немного то можно __>обойтись и отладочными сообщениями).
Может я чего не понимаю, но вот чистофункциональный код вообще отлаживать (пошагово) не нужно, если корректна декларативная логика кода.
Ну а Яву дебажить без проблем. Т.е. чистофункциональные куски "перескакиваем". Или ты хочешь дебажить "до инструкции"?
Здравствуйте, Курилка, Вы писали:
К>Может я чего не понимаю, но вот чистофункциональный код вообще отлаживать (пошагово) не нужно, если корректна декларативная логика кода. К>Ну а Яву дебажить без проблем. Т.е. чистофункциональные куски "перескакиваем". Или ты хочешь дебажить "до инструкции"?
1) В реальности не все так гладко...
2) Я не предлагаю использовать в надстройке чистое ФП, вместо этого можно спользовать гибрид,
где есть императив+ООП и функциональный сахар, в любом случае отладка (желательно удаленная) необходима.
D>Может человеку Coldfusion и отсутствие ФП в проекте говорит о многом?
Тогда перефразирую.
ФП в проекте используется только в виде использования функциональных подходов во время программирования на Яваскрипте Благо функции как first-class objects и замыкания он поддерживает на ура
Здравствуйте, Аноним, Вы писали:
А>Вопрос: А что мне мешает вернуть объект и запихнуть туда что угодно?
А зачем объект-то? Что вам мешает вам вообще без объектов на чистом С писать — будете структурками пользоваться, в чем проблема? Да что там С — на ассемблере можно вообще что хочешь изобразить. Неудобно? Вот так и мне не нравится на каждый писк класс заводить — с туплами любой (в том числе и императивный) код на порядок выигрывает в читабельности. Чем конкретно вам не нравятся туплы?
А>Я прекрасно понимаю что ФП в чистом виде мало применимо и есть такие языки как scala, сочетающие в себе оба подхода. Но вот после недели изучения скалы у меня сложилось такое впечатление что это обычный ИЯ с синтаксическим сахаром (анонимные параметризированные функции, матчинг) и несколько специфичным синтаксисом.
А глядя на С++ — в начале девяностых у меня тогда сложилось впечатление, что это самый обыкновенный С с синтаксическим сахаром — например, можно где угодно переменные объявлять. Удобно . Еще помню, бесило, что компилятор автоматически void* к MyType* не приводит — приходится руками приведение писать. Ну не все же сахар, есть и недостатки у языка, да.
А>В процессе прочтения статей я видел кучу примеров (в основном всякие математические вычисления или сортировка). Но я нигде не видел РЕАЛЬНЫХ примеров (из тех областей для которых пишется большинство программ).
Jabber-сервер подойдет? http://ejabberd.jabber.ru/
А>По поводу шаблонов проектирования: я понимаю что GoF мало соответствует функциональному подходу, но не слышал чтобы кто-нибудь из функциональщиков приводил свой аналог, позволяющий стандартным образом провести декомпозицю задачи...
GoF решает проблемы микродизайна, характерные для ОО систем. Там динамический полиморфизм слабенький — по одному аргументу, и частенько приходится городить черт знает что в простейших случаях. В языках с паттерн-матчингом и функциями высшего порядка все гораздо проще — очевидное решение чаще оказывается правильным. Паттерны какие-то наверное есть (foldr, foldl, и прочее к ним можно отнести), но на книгу их точно не хватит .
Пример хотите? Расскажите, как вы будете делать конечный автомат, реагирующий на сообщения разных типов. (У вас там появится две иерархии классов + дабл диспатч на них вылезет — хрен поймешь по коду потом что за нафиг). А я вам покажу, как это делается в языках с паттерн-матчингом.
Другой эффектный пример — алгоритмы на деревьях. Они примерно раз в 5 компактнее, чем в классическом ОО языке.
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
Т>G Паттерны какие-то наверное есть (foldr, foldl, и прочее к ним можно отнести), но на книгу их точно не хватит .
Т>Собрать несколько таких статей и хватит .
Ахренеть! Посыпаю голову пеплом, ухожу в монастырь.
Re[24]: Так в чем же принципиальные отличия ФП от ИП?
>Это из разряда "87.34569712% всех приводимых цифр взяты с потолка"?
Это — придирка к словам.
VGn>Во многих задачах ФП просто не имеет сысла. Имхо формочки на ФП — это бред.
>А кто говорит о формочках? Мы же говорили о "системах по типу системы, разрабатываемой тысячей разработчиков + сотня архитекторов + сотня аналитиков + толпы манагеров и другого сброда. С соответствующей архитектурой"
А чем занимается 90% народа при разработке таких систем? Реализацией бизнес-логики.
А что такое бизнеслогика в крупных корпоративных системах? По большей части формочки.
>Телекоммуникации, data mining — это вполне такие системы. А ФП там применяются.
Я работаю в телекоммуникациях. У нас ФП не применяется. (Не скажу что это правильно. Но это — факт.)
Минус поставил, надеясь не отвечать. Потому что считаю такой разговор малосодержательным.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[24]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Курилка, Вы писали:
К>Может я чего не понимаю, но вот чистофункциональный код вообще отлаживать (пошагово) не нужно, если корректна декларативная логика кода.
Это миф который насаждают фанатики ФП пользующиеся языками и компиляторамии не имеющими полноценных средств отлакди (например, Хаскелисты).
На самом деле отладчик и/или средства отладки нужны всегда и в любом языке, если речь идет о создании сложного, объемного продукта.
Наши предположения не всегда соответствуют действительности. По этому всегда полезно иметь возмоность поставить точку останова и проверить, что в этом месте некоторая переменная имеет предполагаемое значение. Если это не так, то полезно иметь возможность просмотреть стек вызовов и найти то место, где началось расхождение с ожинаниями.
Более того, ни одна серьеная программа не мыслима без состояния. Фанитики ФП могут говорить, что угодно, но состояние будет обязательно. Просто возможно вместо объектов оно будет храниться в разных монадах, хэш-таблицах процесса и т.п.
Так вот, конечно отладкой можно заниматься как 40 лет назад: вставлять отладочную печать, ставить ассерты... Но это дико замедляет процесс отладки. Даже перекомпилятция болшой системы может занимать вренмя. Для проверки каждого предположения прийдется менять код и прогонять программу.
И не надо рассказывать, что каждую фукнцию можно отлаживать отельно. Вам в начале нужно найти проблему. А без отладчика это сделать куда сложнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, mini_root_2, Вы писали:
__>2)Как отлаживать код исполняемый востроенным интерпретатором?(Впрочем если его будет немного то можно обойтись и отладочными сообщениями).
Какие еще интерпретаторы? Скала компилируется в байткод Явы и (наверно) можно использовать Явовские отладчики.
И вообще, Скала ничем не уступает Яве (как языку) и при использовании Скалы использовать Яву уже смысла особого нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, mini_root_2, Вы писали:
__>>2)Как отлаживать код исполняемый востроенным интерпретатором?(Впрочем если его будет немного то можно обойтись и отладочными сообщениями).
VD>Какие еще интерпретаторы? Скала компилируется в байткод Явы и (наверно) можно использовать Явовские отладчики.
VD>И вообще, Скала ничем не уступает Яве (как языку) и при использовании Скалы использовать Яву уже смысла особого нет.
Как язык — да.. Однако поддержка IDE хромает на обе ноги. Не знаю, как самая распоследняя версия Эклипс-плагина, однако в предпоследней регулярно пропадала подсветка синтаксиса. А плагин для Идеи каждый раз при запуске бросает непонятную ошибку. В общем, до полноценной интеграции как с Эклипсом, так и с Идеей, ИМХО, ещё далеко.
А чтобы можно было пользовать мощь гибридного ФП-ИП подхода в промышленном программировании, нужны ещё и библиотеки, написанные с учётом этого подхода (например DB-маппер уровня Хибернейта или враппер над оным) да тулзы разные (к примеру, визуальный редактор GUI)... Вот тогда можно будет писать проекты только на Скале.
<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Within Temptation — Candles & Pears Of Light (remix)
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Quintanar, Вы писали:
G>>>Впоследствии разделились, и сделали каждый по языку. Причем, автор К наколбасил на нем серверное решение для обработки временных рядов (в основном — для биржевых/финансовых приложений — kdb). Это решение неплохо продается, и широко известно в узких кругах. Вот так. Компания CQG, где я раньше работал, думала одно время, не купить ли нам этот движок. Решили не покупать. Я тогда, помнится, был против покупки. Мы были шокированы языком К (у нас тогда никто не знал, кто его разработал — а дядька-то оказывается гуру, и что это вообще такое — К), и с недоверием относились к качеству решения, считая его априори глючной наколенной поделкой. А жаль, надо было разобраться как следует, и купить.
Q>>С недоверием — это, типа, на сайт даже не зашли? Вообще, странно, пару-тройку лет назад здесь была дискуссия по поводу К, ты же тогда же выступил в его пользу.
G>Почему — зашли. Только было это очень давно — в районе 2001 года, кажется. До дискуссий о К.
Да, интересно. А вот ваши конкуренты похоже давно и плодотворно его используют.
Кстати у них на сйте лежит мануал по KDB+, выгодно отличающийся от материалов на родном сайте презентабельностью. Некоторые места вообще выдержаны в стиле рекламных буклетов.
А вдруг кому-нибудь поможет в принятии правильного решения при выборе новой БД.
