Здравствуйте, VladD2, Вы писали:
VD>В грануляности. Нет экземлпяров.
Увы! Модули — это не аналог классов, это аналог пакетов.
VD>Спроектировать большую систему в терминах модулей просто невозможно. В терминах функций можно, но очень сложно.
А в терминах групп функций? Разумеется поименованных. Экземпляры есть.
Здравствуйте, konsoletyper, Вы писали:
K>Вообще-то, ник я придумывал не для того, чтобы его пытались зачитать вслух или перевести на русский. Может, специально для этих целей мне поменять ник на фамилию/имя?
K>PS: напоминает случай с Cyberax'ом
Так, а что тебя не устраивает? Мне просто влом переключаться на англицкий.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, lomeo, Вы писали:
L>А в терминах групп функций? Разумеется поименованных. Экземпляры есть.
Вот это и называется структурной декомпозицей. ООП как раз и придумывали потому как при некотором объеме задачи она становится мало пригодной.
Собщственно сейчас даже при разработке на ЯП не поддерживающих ООП напрямую все равно проектирование ведется обычно именно в ООП. Достаточно взглянуть на API Линукса и Виндовс.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, lomeo, Вы писали:
VD>>Паттерны есть в любых языках в независимости от применяемой парадигмы.
L>Ежу ясно. Речь о GoF.
Я незнаю о каком еже речь, но GoF тут ты произнес первым. До этого речь шала о паттернах вообще.
VD>>А зачем тогда было ему возражать?
L>Я возражал не этому. Так что не в кассу.
VD>>В ФП есть свои паттерны. А то что в нем "некоторые паттерны из GoF просто не нужны" — это следствие того, что в ФП просто не продуман вопрос проектирования крупных систем. В качетсве средств проектирования используются дедовские сдерства структурной декомпозиции, а подается все это с понтом новеших технологий.
L>-1
Да что толку с твоих "-1"? Не согласен? Тогда продемонстрируй обратное. Покажи нам что за средства декомпозиции предоставляет ФП? Как их применять для проектирования больших систем? Чем они отличаются от приемов проектирования исползовавшихся в С 20 лет назад и от которых люди убежали в ООП?
VD>>Да, ну? Ну, как привиди пример хоть одного.
L>Не хочу. Ты до слов пытаешься докопаться,
Я хочу до сути докопаться. Я вижу тупую религию и хочу показать, что если подумать, что этот фанатизм бессмысленен. ФП и ООП прекрасно друг друга дополняют. Точнее даже можно сказать, что в ФП выработан ряд красивых решений которые можно применять и в гибридных языках. И совсем не ясно почему надо бороться за чистоту.
L>Мало ли что что-то там позволяет. Насквозь императивное железо позволяет нам программировать функционально. Так что? Оно функционально?
Не позволяет. Как только ты обращаешся к железу, то начинается императив. Просто ты работаешь в рамках концепций которые создают иллюзию "чистой функциональности". А по стути на современном железе функциональность в чистом виде невозможна. Она только в математике и есть.
VD>>Это потому что честный ответ банально тебя не устроит.
L>Не угадал. Подумай ещё раз.
А я и не гадал. Я знал.
L>Так. Ты что хочешь узнать? Средства проектирования в ФП аналогичные по мощи паттернам GoF?
Мне вообще интересно послушать о хоть каких-то средствах проектирвоания ФП которые не пересекались бы со средствами структурного программирования.
Вот в ООП даже не поднимаясь к каким-то там паттернам я могу представить сложную систему как совокпность взаимодействующих объектов. Они абстрагируют меня от сложности системы.
А что предлагает ФП на этом уровне?
L>Если хочешь, давай перейдём к конкретике. Скажи что нибудь из области императива "проблема-решение на верхнем уровне", я попытаюсь найти аналогию в мире ФП.
Я уже сказал. ООП основной целью имеет проектирование на уровне абстрактных объектов и их взаимодействия. С функциями это не прокатывает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
VD>А то что в нем "некоторые паттерны из GoF просто не нужны" — это следствие того, что в ФП просто не продуман вопрос проектирования крупных систем.
А как одно из другого следует? И какое отношение GoF имеют к размеру системы?
now playing: Phace — Krunk Time
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
VD>Спроектировать большую систему в терминах модулей просто невозможно.
А ничего, что самые большие системы именно в терминах модулей и проектировались?
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
L>>А в терминах групп функций? Разумеется поименованных. Экземпляры есть.
VD>Вот это и называется структурной декомпозицей. ООП как раз и придумывали потому как при некотором объеме задачи она становится мало пригодной.
Чем это отличается от классов?
VD>Собщственно сейчас даже при разработке на ЯП не поддерживающих ООП напрямую все равно проектирование ведется обычно именно в ООП. Достаточно взглянуть на API Линукса и Виндовс.
Поясни. Ты имеешь в виду работу с хендлами? Посылку сообщений? Что то ещё?
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
VD>Я незнаю о каком еже речь, но GoF тут ты произнес первым. До этого речь шала о паттернах вообще.
многие современные ФЯ поддерживают паттерн-матчинг, который позволяет выкинуть паттерн посетитель. Остальные же паттерны приходится по-прежнему реализовывать ручками.
Как прикажешь воспринимать "остальные"? Универсальное множество паттернов во всех возможных случаях проектирования минус посетитель?
L>>Я возражал не этому. Так что не в кассу.
VD>Хм... А это что?
Ну и? Мне в третий раз повторить, что я хотел сказать?
VD>Да что толку с твоих "-1"? Не согласен? Тогда продемонстрируй обратное. Покажи нам что за средства декомпозиции предоставляет ФП? Как их применять для проектирования больших систем? Чем они отличаются от приемов проектирования исползовавшихся в С 20 лет назад и от которых люди убежали в ООП?
Ты недостатки скажи. Или в чем преимущества ООП расскажи, я пока совершенно не понимаю, где и какого монстра ты увидал.
VD>Я хочу до сути докопаться. Я вижу тупую религию и хочу показать, что если подумать, что этот фанатизм бессмысленен. ФП и ООП прекрасно друг друга дополняют. Точнее даже можно сказать, что в ФП выработан ряд красивых решений которые можно применять и в гибридных языках. И совсем не ясно почему надо бороться за чистоту.
Где религия? Я вот на Яве по большей части пишу А бороться за чистоту надо в особенных случаях — когда на неё нападают фанатики единственного-верного-пути и хотят изжить из отдельных языков, изначально созданных чистыми. Потому что чистота имеет ряд преимуществ. Перечислить?
L>>Мало ли что что-то там позволяет. Насквозь императивное железо позволяет нам программировать функционально. Так что? Оно функционально?
VD>Не позволяет. Как только ты обращаешся к железу, то начинается императив. Просто ты работаешь в рамках концепций которые создают иллюзию "чистой функциональности". А по стути на современном железе функциональность в чистом виде невозможна. Она только в математике и есть.
Аналогично и с монадами По сути они чисто функциональны.
VD>>>Это потому что честный ответ банально тебя не устроит.
L>>Не угадал. Подумай ещё раз.
VD>А я и не гадал. Я знал.
Какое самомнение! Вынужден тебя огорчить, причины совершенно иные.
L>>Так. Ты что хочешь узнать? Средства проектирования в ФП аналогичные по мощи паттернам GoF?
VD>Мне вообще интересно послушать о хоть каких-то средствах проектирвоания ФП которые не пересекались бы со средствами структурного программирования.
Полиморфные функции? Type classes?
VD>Вот в ООП даже не поднимаясь к каким-то там паттернам я могу представить сложную систему как совокпность взаимодействующих объектов. Они абстрагируют меня от сложности системы.
VD>А что предлагает ФП на этом уровне?
Функциональную декомпозицию.
VD>Я уже сказал. ООП основной целью имеет проектирование на уровне абстрактных объектов и их взаимодействия. С функциями это не прокатывает.
Разумеется. ФП имеет своей целью проектирование на уровне функций и их взаимодействий. С объектами это не прокатывает.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, konsoletyper, Вы писали:
K>>Вообще-то, ник я придумывал не для того, чтобы его пытались зачитать вслух или перевести на русский. Может, специально для этих целей мне поменять ник на фамилию/имя?
K>>PS: напоминает случай с Cyberax'ом
VD>Так, а что тебя не устраивает? Мне просто влом переключаться на англицкий.
Ну, тогда не Косолетайпер, а Консолетайпер. Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!
Здравствуйте, konsoletyper, Вы писали:
K>Ну, тогда не Косолетайпер, а Консолетайпер. Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!
Ну эт без проблем набрать можно, на русском это будет примерно так: ыряячслгоящзшстт
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>В грануляности. Нет экземлпяров.
L>Увы! Модули — это не аналог классов, это аналог пакетов.
VD>>Спроектировать большую систему в терминах модулей просто невозможно. В терминах функций можно, но очень сложно.
L>А в терминах групп функций? Разумеется поименованных. Экземпляры есть.
Насколько я понимаю весь вопрос в храненении состояний, можно рассмотреть несколько примеров:
1) "Моя первая программа на паскале" — состояние хранится просто — в виде глобальных переменных.
2) "Струкутрнуе программирование по уму" — все переменные объявлены внутри каких-то процедур, которые вызывают другие процедуры
(я намеренно не использую слово "функция"), использование глоабальных переменных не приветствуется. Сразу возникает вопрос как передавать
эти переменные при вызове, единственный разумный вариант — в виде структуры. Но структуры — это первый шаг к ООП. При построение
большого приложения, возможно потребуется подменить что-то не исправляя кода, а заодно привязать те или иные процедуры к строго определенному
контексту.
3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.
VladD2 совершенно справедливо заметил, что такой способ хорошо подходит для описание систем на макро уровне, например:
public class JobSystem и сразу понятно что если нужно взаимодействие с шедулером то нужно смотреть список его методов, в нем
же хранится текущее состоние (в виде конфига и запихнутого внутрь кварца(которй уже со своими потрохами)), там же лежат
методы для управления подсистемой в целом (start/shutdown).
А вот при описании этого же в термених ФП мы вернемся к пункту 2, отчего несколько десятилетий назад наооборот пытались уйти.
Глупый вопрос к VladD2: а что дают макросы? Они позволяет встроить кодогенерацю внутрь программы и управлять ей из нее же?
Вещь конечно заманчивая, но не возникнет ли бардака?
P.S. В процессе заигрывания со скалой заметил один неприятный момент, язык поощраяет написание большого кол-ва анонимных
функций (а иначе получается не так уж компактно) — в этом на мой взгляд главный недостаток чрезмерного засахарения,
но в целом он мне понравился, добивает только отсутствие документации (ScalaByExample и пр. не в счет) и отсутствие
поддержки со стороны netbeans.
Здравствуйте, konsoletyper, Вы писали:
K>Ну, тогда не Косолетайпер, а Консолетайпер.
Ну, это просто очепятка. Извини. Я с тем же успехом мог бы написать kosoletyper.
K> Хотя, лучше я переименуюсь в "shzzxckujzopicnn", чтобы неповадно было!
Э... тогда могут начать писать "этот !@#$%^" .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
___>P.S. В процессе заигрывания со скалой заметил один неприятный момент, язык поощраяет написание большого кол-ва анонимных __>функций (а иначе получается не так уж компактно) — в этом на мой взгляд главный недостаток чрезмерного засахарения, __>но в целом он мне понравился, добивает только отсутствие документации (ScalaByExample и пр. не в счет) и отсутствие __>поддержки со стороны netbeans.
А чем тебя смущает большое количество анонимных функций? Если одни и те же функции, то повод для рефакторинга и лишения их анонимности
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, mini_root_2, Вы писали:
__>Глупый вопрос к VladD2: а что дают макросы? Они позволяет встроить кодогенерацю внутрь программы и управлять ей из нее же? __>Вещь конечно заманчивая, но не возникнет ли бардака?
Макрос позволяют оформлять свои мысли максимально близко к идеалу. Простой пример — сплайс-строки. Со времен С (да, пожалуй по раньше) люди хотели записать код формирования строк максимально близко к внешнему виду этой строки при выоде. Но ни ООП, ни ФП не дает возможности получить действительно желаемый результат. Точнее иногда удается приблизиться к идеалу, но постоянно что-то получается не так. В С printf был захардкожен в язык (как тип вызова процедуры) и при этом был очень небезопасным. В Яве и Шарпе пошли ОО-путем, но получилось довольно не эффективно и все проверки типов переехали в рантайм. Почти замечательно все получилось только в нитерпретаторах, но опять же все проверки в рантайме.
Единственное что смогли предложить создатели статически типизированных языков — это замену внятной и выразительной строки формата, на последовательность вызовов методов некоего объекта потокового взыова, но получилось весьма громоздко (даже не сморя на сахар вроде переопределения операторов побитового сдвига).
Метапрограммирование же дало ясный и прекрасно подходящий ответ на этот вопрос. Мы смогли получить наиболее выразительный вариант используемый в интерпретируемых языках который во время компиляции преоразуется в эффективный код последовательный код.
Но это тоже микро-уровень. На макро-уровне МП позволяет создавать решения на основе DSL-ей. Это позволяет нам оперировать еще более высокоуровневыми и чистыми абстракциями нежели ООП. В прочем, ООП и ФП опять же замечательно сочетаются с МП. Или точнее МП замечательно их дополняет.
Панацей небывает. Любое средство имеет свой набор ТТХ. И только сочетакние передовых срредств в купе с хорошей подготовкой специалистов и созедательной фантазией позволит нам выйти на новый, более продуктивный уровень разработки ПО.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
__>3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.
__>VladD2 совершенно справедливо заметил, что такой способ хорошо подходит для описание систем на макро уровне, например: __>public class JobSystem и сразу понятно что если нужно взаимодействие с шедулером то нужно смотреть список его методов, в нем __>же хранится текущее состоние (в виде конфига и запихнутого внутрь кварца(которй уже со своими потрохами)), там же лежат __>методы для управления подсистемой в целом (start/shutdown).
-module(job_system).
-export([
public_method/1,
public_method_two/1,
public_method_three/2
]).
%% ------------------------------------------------------
%% Публичные методы aka интерфейс взаимодействия
%% ------------------------------------------------------
public_method(Param) ->
ok.
%% Функция является перегруженной
%% Перегрузка на основе паттерн-матчинга
%% Эта функция принимает список и вызывает внутреннюю, приватную функцию
public_method_two([Head|Tail]) ->
private_method(Head, Tail);
%% Эта функция принимает кортеж и вызывает внутреннюю, приватную функцию
public_method_two({A,B}) ->
private_method(A, B).
public_method_three(Param1, Param2) ->
{я, не, знаю, что, мне, делать, с, этою, бедой}.
%% ------------------------------------------------------
%% Приватные функции
%% ------------------------------------------------------
%% Приватная функция также прегружена на основе
%% сопоставления с образцом
private_method(A, [Head|Tail]) ->
another_Module:do_something(A),
private_method(Head, Tail);
private_method(A, []) ->
another_Module:do_something(A);
private_method(A, B) ->
another_Module:do_something(A),
another_Module:do_something(B).
Ну и чем это отличается от объекта? Состояние этот модуль тоже может хранить (см. gen_server в документации по Эрлангу ну или здесь).
Здравствуйте, Mamut, Вы писали:
M>Ну и чем это отличается от объекта? Состояние этот модуль тоже может хранить (см. gen_server в документации по Эрлангу ну или здесь).
Это тот же паскаль (или дельфи), там тоже есть unit(module),interface(типа export),implementation.
А нахрена козе баян? А как реализовать наследование — создать еще один модуль в котором протащить
все публичные методы первого и добавить что-то еще?.
P.S. Если я не ошибаюсь ООП через модули было реализована в Perl5, откуда я в свое время благополучно
сбежал на Яву.
P.P.S. А вот по поводу кодогенерации, макросов и DSL — это уже интересно. Я с некоторых пор начал зашиваться и понял что самый реальный способ строить что-то большое это набирать функциональность
из готовых блоков, а сверху прикручивать какой-нибуль интерпретатор (хоть Groovy, хоть XSLT с расширениями), вто недавно встроил скалу в яву, щас пребываю в раздумье...
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, mini_root_2, Вы писали:
__>Это тот же паскаль (или дельфи), там тоже есть unit(module),interface(типа export),implementation. __>А нахрена козе баян? А как реализовать наследование — создать еще один модуль в котором протащить __>все публичные методы первого и добавить что-то еще?.
Вот этого я долго ждал — когда же кто нибудь скажет о subtyping. Это имхо единственное отличие. Наследования, действительно, нет.
Правда, можно поговорить о двухуровневом наследовании (варианты); HOF + полиморфизм как решение задач, которые решает наследование, или даже polymorphic variants; недостатках наследования, но это уже скорее в философию ;-)
Важно другое — средства есть.
Ещё какие отличия ООП от ФП в плане проектирования?
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Mamut, Вы писали:
M>Ну и чем это отличается от объекта?
"Это" ничем, так как является эмуляцией ООП на не поддерживающем на прямую эту парадигму языке. То есть то же ООП, только слишком многословно и сложно.
M> Состояние этот модуль тоже может хранить (см. gen_server в документации по Эрлангу ну или здесь).
Это, как я понимаю, эмуляция глобальных переменных.
Модуль же отличается от объекта, тем что не позволяет создать свои экземляры.
ЗЫ
Никто не спорит, что любой процедурный язык позволяет эмулировать ООП.
Только вопрос был не в этом. Вопрос был в том, что ФП дает в области проектирования на макро-уровне.
Если все что оно дает — это возможность эмулировать ООП так же как это делали 30 лет назад на С, да еще и ченит препятствия, то в пору задуматся, а на хрена козе баян?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
А бороться за чистоту надо в особенных случаях — когда на неё нападают фанатики единственного-верного-пути и хотят изжить из отдельных языков, изначально созданных чистыми. Потому что чистота имеет ряд преимуществ. Перечислить?
Перекуём баги на фичи!
