Здравствуйте, VladD2, Вы писали:
VD>Дык нам никто не запрещает использовать циклы и даже if-ы с goto. Важен сам принцип решения проблемы — без абстракций.
Это я специально потроллил, по привычке, что бы извлечь из тебя толковую формулировку.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, Lloyd, Вы писали:
VD>>А что не так с этим могучим языком?
L>Его нельзя задать регулярной грамматикой, которые эквивалентны конечным автоматам. L>Регулярная грамматика
Я всего лишь наступил ему на язык а про полноту он не может не знать.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, VladD2, Вы писали:
VD>Давай лучше опиши как бы ты выразил работу с файлами в функциональном мире.
(ReaderFunc, byte[]) ReaderFunc(int length);
Не?
VD>ФП просто протаскивает состояние через стек. И это во многом удобно. Но и тут его удобнее таскать в виде объекта, а не в виде открой структуры с тучей полей или в виде хэндла.
Не только. Есть, как минимум, экземпляры функторов, которые содержат в себе аргументы. Ну и замыкания. Правда, Василий считает, что замыкания толи с ФП несовместимы, толи еще что.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
И как этим открыть файл и прочесть его содержимое (скажем первые 100 байт)?
VD>>ФП просто протаскивает состояние через стек. И это во многом удобно. Но и тут его удобнее таскать в виде объекта, а не в виде открытой структуры с тучей полей или в виде хэндла.
AVK>Не только. Есть, как минимум, экземпляры функторов, которые содержат в себе аргументы. Ну и замыкания.
Что такое фанктор пока что люди договориться не смогли. В каждом языке под этим понимают разные вещи. Так что не понял о чем конкретно речь.
Что до замыканий и прочего, то я повторяю свой вопрос. Что с хэндлами то делать?
Да и зачем вручную каждый раз создавать какие-то замыкания, когда можно один раз создать класс который и будет этим замыканием только с блэкджеком и шлюхами?
AVK>Правда, Василий считает, что замыкания толи с ФП несовместимы, толи еще что.
Этого я в его рассуждениях не заметил. Он вроде бы автор ФЯ, так что что такое ФП должен понимать не хуже нас с тобой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
VD>>-_*>Например язык вида 0000011111 не распознается КА, т.к.
VD>>А что не так с этим могучим языком?
L>Его нельзя задать регулярной грамматикой,
Да, ну?! (хотя причем тут грамматики не ясно)
L>которые эквивалентны конечным автоматам. L>Регулярная грамматика
Вот регекс разбирающий ваш язык:
0000011111
Можете проверить его на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, -_*, Вы писали:
VD>>Дык нам никто не запрещает использовать циклы и даже if-ы с goto. Важен сам принцип решения проблемы — без абстракций.
-_*>Это я специально потроллил, по привычке, что бы извлечь из тебя толковую формулировку.
Меня уже Лойд подобными вещами достал (но он похоже это от чистого сердца делает, а не ради тролинга), так теперь еще и ты? Это какой-то заговор против розовых слоников. Где Грипис, а?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>А что не так с этим могучим языком?
L>>Его нельзя задать регулярной грамматикой,
VD>Да, ну?! (хотя причем тут грамматики не ясно)
См. ниже.
L>>которые эквивалентны конечным автоматам. L>>Регулярная грамматика
VD>Вот регекс разбирающий ваш язык: VD>
VD>0000011111
VD>
VD>Можете проверить его на практике.
Я думаю ты прекрасно понял, что имелось в виду. Если все-таки не понял, перейди по ссылке и прочти, что там написано.
Здравствуйте, VladD2, Вы писали:
VD>Общая задача. Функции работы с окнами логично поместить в класс "Окно", а функции работы с файлами в класс "Файл". Все же просто и очевидно. Это если не умничать и не идеологизировать ООП.
Я не идеологизирую. Но неужели у тебя нет никаких других критериев, по которым ты "распихиваешь" функции по классам? Просто мне кажется у тебя в таком случае класс выступает в виде этакого неймспейса для функций. "Все для работы с окном". "Все что нужно для ваших файлов". ООП — это что-то еще, не?
ВВ>>
ВВ>>class Math {
ВВ>> int Sum();
ВВ>> int FirstOperand;
ВВ>> int SecondOperand;
ВВ>>}
ВВ>>
VD>Даже страшно такое представлять .
VD>Конечно и такое бывает, но это ведь не лучший образчик ОО-ситиля, правда?
Это я приводил как пример того, что не является ООП-классом в принципе. Т.е. формально — да, класс. По сути — нет. Это, если хочешь, отправная точка для рассуждений.
Если ты считаешь это классом, просто "в плохом стиле" — то я тебе ничего объяснить не смогу. Ибо само понятие "ООП класс" у нас становится настолько широким, что оно ничему не может противоречить в принципе.
VD>Опять какая-то херня из бредовых учебников.
Я всего-лишь высказал мысль, что у нас возникает повод говорить об "ООП классе", когда в классе этим присутствует взаимная детерминированность его членов. Именно взаимная. Ты с этим не согласен? Может привести контр-пример?
VD>Давай ближе к делу. Вот у нас есть файл. Он по определению есть состояние. В ОС вроде Винды он описывается хэндлом. Хэнд — это, можно сказать, материализация того что мы называем объектом. VD>Вот для него имеет смысл ввести класс (объект) и объединить его все функции в нем.
А зачем вводить "класс"? Что это даст? Может просто модуль File и накидать туда функций? В чем разница?
VD>Да ладно фантазировать про гипотетические кары и драйвы. VD>Давай лучше опиши как бы ты выразил работу с файлами в функциональном мире.
В функциональном языке у меня была бы структура "Файл", описывающая файл *в конкретный помент времени*. В ООП — просто структура "Файл".
VD>Что снова изобретем хэндл? О боги! Да это же старое доброе процедурное программирование! VD>А где же та замечательная завеса таинства что так привлекала многих в ФП? VD>Вот классы надо расстраивать как средство борьбы с хэндлами. Инкапсуляция — это оно и есть.
Иначе говоря, это что-то вроде туалета? Завернули, запрятали — и уже не страшно?
Не, я как бы согласен. Но вопрос прежний — почему "классы"? Такой вот "туалет" и в Си есть — там тоже можно завернуть, спрятать, инкапсулировать. Зачем мужики С++ придумали?
VD>У нас? Не... это у вас дохтор картиночки такие. А у нас все ОК. Мы и в ФП и в ООП моделируем все совершенно одинаково. VD>В объекты мы превращаем то что обладает состоянием. Причем объекты не обязаны быть изменяемыми. Я создаю неизменяемые объекты куда чаще чем изменяемые.
Обладает что ли состоянием "внутри" или же это состояние у тебя будет "снаружи" (в чем собственно отличие ФП и ООП, не?) — ты решаешь сам. Здесь не существует каких-то объективных критериев для выбора. И вот выбор первого — это ООП выбор. Выбор второго — ФП выбор.
VD>Так вот я для себя сделал открытия. Не бывает ОО-дизайн или ФП-дизайн. А бывает хороший (красивый, удобный и т.п.) дизайн, и притянутый за уши. Когда преобразование А в Б пытаются оформить классом — это кривой дизайн, но все эти хэндлы — это точно такой же кривой дизайн.
Если два разных человека, которые а) имеют мозг и б) используют его, то у них получится разный дизайн. Есть огромное кол-во разных способов решить задачу, не только два, из них нельзя выбрать какой-то "более правильный" или "более красивый" способ.
VD>Состояние есть, его не может не быть! Это объективная реальность. Состояние опасно! Точнее опасно не оно, а то что человеческий мозг не может представить состояние во времени и то, что мы не имеем возможности взглянуть в прошлое. VD>ФП просто протаскивает состояние через стек. И это во многом удобно. Но и тут его удобнее таскать в виде объекта, а не в виде открой структуры с тучей полей или в виде хэндла.
Ну да, через стек, отлично. Только вот "объект", в котором ты будешь таскать это состояние, является единомоментным иммутабельным слепком этого состояния, т.е. это значения для конкретного момента времени. Сам по себе этот объект не будет иметь состояние, он будет лишь его описателем. В ООП же такой объект именно что несет в себе состояние.
AVK>>Не?
VD>И как этим открыть файл и прочесть его содержимое (скажем первые 100 байт)?
var (rest, buffer) = OpenFile(...)(100);
var (nextRest, nextBuffer) = rest(...)(100);
...
Как то так.
VD>Что такое фанктор пока что люди договориться не смогли. В каждом языке под этим понимают разные вещи. Так что не понял о чем конкретно речь.
Если мы делаем карринг, значение аргументов хранится не в стеке.
VD>Да и зачем вручную каждый раз создавать какие-то замыкания, когда можно один раз создать класс который и будет этим замыканием только с блэкджеком и шлюхами?
Это не ко мне вопрос. Я точно так же не смог добится никакого вразумительного объяснения, чем все таки ФП с ООП не совместимо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, VladD2, Вы писали:
VD> Он вроде бы автор ФЯ, так что что такое ФП должен понимать не хуже нас с тобой.
Я бы не идеализировал этот факт. По крайней мере, что такое ООП он точно не очень уверенно понимает. =)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>>Давай лучше опиши как бы ты выразил работу с файлами в функциональном мире.
AVK>
Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является. Меня удивляет, как много людей не знает такого простого факта (ведь откуда-то берется преклонение перед методикой, устаревшей 30 лет назад).
Социализм — это власть трудящихся и централизованная плановая экономика.
AVK>>Не?
LP>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию.
Просто уровень инкапсуляции ниже — только функция, а завязаться на реализацию даже еще сложнее, чем в ООП.
LP>Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является.
Не является оно частным случаем. Как ты, например функции высшего порядка на процедурном языке изобразишь?
LP>Меня удивляет, как много людей не знает такого простого факта (ведь откуда-то берется преклонение перед методикой, устаревшей 30 лет назад).
Здравствуйте, LaPerouse, Вы писали:
LP>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию.
Можно раскрыть мысль?
LP> Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является.
Неверно. Процедурное программирование императивно, ФП декларативно (ООП не детерминирует вообще этот аспект).
LP> Меня удивляет, как много людей не знает такого простого факта (ведь откуда-то берется преклонение перед методикой, устаревшей 30 лет назад).
Про преклонение это какие то странные фантазии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
AVK>>>Не?
LP>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. L>Просто уровень инкапсуляции ниже — только функция,
В этом примере нету инкапсуляции — голый byte[] на выходе.
L>а завязаться на реализацию даже еще сложнее, чем в ООП.
Почему сложнее? Где пример правильной реализации этой функции на ФЯ?
LP>>Ничего удивительного, ведь ФП наследует все недостатки процедурного программирования, частным случаем которого и является. L>Не является оно частным случаем. Как ты, например функции высшего порядка на процедурном языке изобразишь?
Указатели на функции? В С ими сто лет пользуются. Замыкания сделать не получится, но это сущие мелочи.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я не идеологизирую. Но неужели у тебя нет никаких других критериев, по которым ты "распихиваешь" функции по классам?
Нет. Точнее, я просто думаю каждый раз головой. Взвешиваю все за и против. Так что можно сказать, что их слишком много чтобы их перечислять, а можно сказать, что их нет.
ВВ> Просто мне кажется у тебя в таком случае класс выступает в виде этакого неймспейса для функций. "Все для работы с окном". "Все что нужно для ваших файлов". ООП — это что-то еще, не?
А меня не трогает чистота идей. Мне нужно ехать, а не шашечки.
К тому же от нэйспэйса это отличается наличием того самого инкапсулированного состояния. Ведь это не только набор функций, но и структура данных описывающая файл.
ВВ>Если ты считаешь это классом, просто "в плохом стиле" — то я тебе ничего объяснить не смогу.
Ну, не можешь так не можешь.
ВВ>Я всего-лишь высказал мысль, что у нас возникает повод говорить об "ООП классе", когда в классе этим присутствует взаимная детерминированность его членов.
Давай не будем жонглировать терминами. Что за "взаимная детерминированность"?
ВВ> Именно взаимная. Ты с этим не согласен? Может привести контр-пример?
Я не могу быть согласен с тем чего не понимаю. В прочем как и не согласен.
VD>>Давай ближе к делу. Вот у нас есть файл. Он по определению есть состояние. В ОС вроде Винды он описывается хэндлом. Хэнд — это, можно сказать, материализация того что мы называем объектом. VD>>Вот для него имеет смысл ввести класс (объект) и объединить его все функции в нем.
ВВ>А зачем вводить "класс"? Что это даст?
Это даст удобство использования и инкапсуляцию.
ВВ>Может просто модуль File и накидать туда функций? В чем разница?
Модуль (в обычном понимании этого термина) не может иметь экземпляров. Модули можно использовать для реализации инкапсуляции. Сам объект при этом придется прятать за тот самый хэндл.
В итоге мы получаем эмуляцию ООП. Безусловно даже на С можно сэмулирвоать ООП и добиться приемлемого результата. Но использование для этих целей средств языка намного удобнее и интуитивно понятнее.
ВВ>В функциональном языке у меня была бы структура "Файл", описывающая файл *в конкретный помент времени*. В ООП — просто структура "Файл".
Если структура с отрытыми полями, то ты получаешь все прелести отсутствия инкапсуляции. Если ты начинаешь скрывать состав структуры за псевдонимом типа реализованного приватно в модуле, то ты опять же эмулируешь ООП, но менее удобными для этого средствами.
Короче, ты опять уперся в терминологию и какое-то свое понимание. Я с тобой бодаться не намерен.
Повторю только еще раз, что если не делать из ООП догмы, то это удобная и полезная технология.
Можешь рассматривать ее как модули на стеройдах плюс ряд других вкусностей.
Причем никто не заставляет все это применят. Не надо — не применяй.
ВВ>Т.е. классы нужны для:... ВВ>Иначе говоря, это что-то вроде туалета?
Странные у тебя ассоциации.
Я, в общем-то, все уже сказал. Интерпретировать мои слова не нужно.
ВВ> Завернули, запрятали — и уже не страшно?
Это называется инкапсуляция. Сложное прячется за интерфейсом и действительно становится проще.
ВВ>Не, я как бы согласен.
Как бы или согласен?
ВВ> Но вопрос прежний — почему "классы"?
А почему нет? Почему модули и внеположной секс с хэндлами и прочей самопальщиной?
ВВ>Такой вот "туалет" и в Си есть — там тоже можно завернуть, спрятать, инкапсулировать. Зачем мужики С++ придумали?
То что ты называешь туалетом в культурных кругах принято назыать инкапсуляцией. И таки — да, инкапсуляции можно добиться и в С, и в Хаскеле. Вопрос только сколько при этом танцев с бубнами надо предпринять.
В ООЯ мне нужно просто создать класс, описать в нем понятный/логичный интерфейс и скрыть за ним все детали реализации (данные, алгоритмы и т.п.).
Да инкапсуляция придумана не в ООП. Да она не является преимуществом именно ООП. Но мне пофику, если в ООП это сделано удобнее нежели в ФП или процедурном программировании (ПП), что по сути одно и то же.
VD>>У нас? Не... это у вас дохтор картиночки такие. А у нас все ОК. Мы и в ФП и в ООП моделируем все совершенно одинаково. VD>>В объекты мы превращаем то что обладает состоянием. Причем объекты не обязаны быть изменяемыми. Я создаю неизменяемые объекты куда чаще чем изменяемые.
ВВ>Обладает что ли состоянием "внутри" или же это состояние у тебя будет "снаружи" (в чем собственно отличие ФП и ООП, не?) — ты решаешь сам.
Я хотел сказать "изменяемым состоянием".
ВВ>Здесь не существует каких-то объективных критериев для выбора. И вот выбор первого — это ООП выбор. Выбор второго — ФП выбор.
Да нет тут никакого выбора. Погляди на любой немерловый проект. Все решения ОЧЕВИДНЫ. Тебе внутренний голос подсказывает где лучше класс создать, а где еще что-то.
Возьми к примеру простенький проект макроса поддержки XML-литералов. Тут тебе и вполне функциональная реализация AST + его преобразование, и классы, и даже методы внутри в общем-то функциональных структур (вариантов). Причем реализация методов в большинстве случаев вполне себе функциональная.
ВВ>Если два разных человека, которые а) имеют мозг и б) используют его, то у них получится разный дизайн. Есть огромное кол-во разных способов решить задачу, не только два, из них нельзя выбрать какой-то "более правильный" или "более красивый" способ.
Причем тут разные люди? Ну, да — есть. И что? Разный дизайн все равно может быть как плохим, так и хорошим. В хорошем по любому будет сочетаться лучшие подходы. А догматический ООП-дизайни, как и догматический ФП-дизайн точно будут плохим.
ВВ>Ну да, через стек, отлично. Только вот "объект", в котором ты будешь таскать это состояние, является единомоментным иммутабельным слепком этого состояния,
А вот это уже догмы. Может быть так, а может быть иначе. Как удобно, так и делай.
ВВ>т.е. это значения для конкретного момента времени. Сам по себе этот объект не будет иметь состояние, он будет лишь его описателем. В ООП же такой объект именно что несет в себе состояние.
Ты мне еще расскажи про "миры".
ФП в чистом виде способен решать исключительно те задачи которые укладываются в трансформацию данных. Скажем интерактивный ГУЙ на чистом ФП не сделать в принцие. Для этого уже нужно придумывать разные реактивные системы в которых ФП станет не более чем частью реализации. Так почему бы изначально не рассматривать ФП как средство реализации частей программы которые укладываются в парадигму трансформации, а само приложение рассматривать как нормальное ОО-приложение внутри которого реализация методов преимущественно осуществляется методами ФП? Это дает отличные результаты. И что характерно, не надо разрушать старый мир, чтобы воспользоваться преимуществами нового.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaPerouse, Вы писали:
LP>>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. L>>Просто уровень инкапсуляции ниже — только функция, LP>В этом примере нету инкапсуляции — голый byte[] на выходе.
Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, LaPerouse, Вы писали:
LP>>>>Налицо недостатки ФП и процедурного программирования вообще — отсутствие инкапсуляции, завязка на реализацию. L>>>Просто уровень инкапсуляции ниже — только функция, LP>>В этом примере нету инкапсуляции — голый byte[] на выходе. C>Ну оберни в VeryCompicatedFunctionalWrapperForASimpleArrayWithBuiltInSupportForRemoteProcedureCalls.
Ты не понял, что я имел ввиду. Я совсем не про byte[] как таковой, а про то, что он торчит наружу вместо того, чтобы сидеть внутри класса File и доступен к примеру, через метод asByte(). Тем самым происходит абстрагирование от использования конкретной структуры данных (массива).
Социализм — это власть трудящихся и централизованная плановая экономика.
а про полноту он не может не знать.
.
Мы уже победили, просто это еще не так заметно...
