Здравствуйте, FR, Вы писали:
FR>Как будто с использованием ООП мы в этом случае получим что-то большее. Будет ровно тоже самое. Притом используя те же модули ML например код практически будет идентичным с ООП.
Конечно получим больше. Мы получим возможность не заморачиваясь писать то что мы хотим так как мы хотим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaPerouse, Вы писали:
C>>А это плохой дизайн в ООП. У тебя получится класс с asBytes(), asVector(), asList(), asStringInUTF() и т.д. Т.е. будет типичное нарушение SRP. LP>Разумеется, в данном конкретном случае логично иметь один интерфейс BinaryStream, а указанные тобой представления должны получаться из BinaryStream в каком-нибудь хелпере.
Мимо. BinaryStream подразумевает потоковое чтение, а не произвольный доступ. Тебе нужно контейнер, заточенный на произвольный доступ/изменение и не поддерживающий произвольное увеличение/уменьшение размера.
Это получается... э... массив байт.
LP>Я же совсем не про это говорил. А говорил я про скрытие используемых структур данных за интерфейсами. Насколько я понимаю, такой стиль кодирования в ФП не в почете.
Ибо нафиг он не нужен в 95% случаев. А для остальных 5% можно использовать и этот ваш полиморфизм с интерфейсами.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, что с ООП у него тоже все довольно не плохо.
Не хорошо, я проверял.. =))
VD> Инкапсуляция и полиморфизм не есть изобретения или достоинства только лишь ООП. Они достижимы где угодно. Наследование вообще спорная вещь. Тот же АВК не раз говорил о его вреде в ряде случаев. Вот и рождаются сомнения в умах.
Это все верно, но сомнения рождаются от недопонимания...
Здравствуйте, LaPerouse, Вы писали:
LP>Замыкание полностью эквивалентно функтору с параметрами, установленными из локального контекста, а функторы прекрасно делаются на любом процедурном языке, по крайней мере на С — точно (структуры). И по выразительности функторы ничем не уступят замыканиям, разве что немного — по удобству использования.
Здравствуйте, LaPerouse, Вы писали:
LP>Попытка почти любого практического применения функциональных языков оканчивается использованием монады IO, которая сама по себе императивна до безобразия.
Функциональные языки не ставят свой целью полностью исключить императив. У них цель гораздо более скромная изолировать его с целью минимизировать
связанные с ним ненадежность и непредсказуемость.
Здравствуйте, VladD2, Вы писали:
FR>>Как будто с использованием ООП мы в этом случае получим что-то большее. Будет ровно тоже самое. Притом используя те же модули ML например код практически будет идентичным с ООП.
VD>Конечно получим больше. Мы получим возможность не заморачиваясь писать то что мы хотим так как мы хотим.
Для тех же файлов и подобных вещей решаемых в процедурном программировании использованием абстрактных типов данных никаких преимуществ
не получим. Даже сахар не существенный.
Здравствуйте, FR, Вы писали:
FR>Для тех же файлов и подобных вещей решаемых в процедурном программировании использованием абстрактных типов данных никаких преимуществ FR>не получим. Даже сахар не существенный.
Не надо с умным видом говорить глупости. Прочти в вики определение абстрактных типов данных и ты поймешь, что как раз классы — это они и есть, только с блэкджеком и шлюхами, а вот в С таких средств вообще нет. Так что в С придется поплясать с бубном чтобы добиться того же результата.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не надо с умным видом говорить глупости. Прочти в вики определение абстрактных типов данных и ты поймешь, что как раз классы — это они и есть, только с блэкджеком и шлюхами, а вот в С таких средств вообще нет. Так что в С придется поплясать с бубном чтобы добиться того же результата.
С просто плохой процедурный язык, практически не поддерживает модульность. В языках с хорошей модульностью никаких плясок нет.
Объекты конечно одним из родителей имели абстрактные типы данных, но тут уже доходит до маразма если кто-то в той же функциональщине
использует АТД начинается крик что это объекты. Это не объекты.
Здравствуйте, FR, Вы писали:
FR>С просто плохой процедурный язык, практически не поддерживает модульность.
Да ладно тебе. С модульностью у него все ОК. Его проблемы — это прероцессор и плохой контроль за типами.
FR>В языках с хорошей модульностью никаких плясок нет.
Да ну? Хаскель обладает "хорошей модульностью"?
FR>Объекты конечно одним из родителей имели абстрактные типы данных, но тут уже доходит до маразма если кто-то в той же функциональщине использует АТД начинается крик что это объекты. Это не объекты.
Причем тут крики? Я утверждал, и продолжаю утверждать, что объекты — это отличная штука в первую очередь для той самой модульности. Кроме того они отлично подходят для, выражения АТД и кучи других задач.
В прочем, кому я это все рассказываю? Ты ведь у нас пишешь на Питоне и С++, так? Тебе ли всего этого не знать? Даже в ОКамле объекты не лишние. Хотя казалось бы язык сначала функциональный и только потом немного объектно-ориентированный. Согласен?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Да ладно тебе. С модульностью у него все ОК. Его проблемы — это прероцессор и плохой контроль за типами.
В языке вообще нет модульности, компиляторы да с грехом пополам ее обеспечивают.
В С++ с одной стороны улучшили, namespace классы, но с другой убили уничтожив ABI.
FR>>В языках с хорошей модульностью никаких плясок нет.
VD>Да ну? Хаскель обладает "хорошей модульностью"?
Наверно, я не знаток Хаскеля.
FR>>Объекты конечно одним из родителей имели абстрактные типы данных, но тут уже доходит до маразма если кто-то в той же функциональщине использует АТД начинается крик что это объекты. Это не объекты.
VD>Причем тут крики? Я утверждал, и продолжаю утверждать, что объекты — это отличная штука в первую очередь для той самой модульности. Кроме того они отлично подходят для, выражения АТД и кучи других задач.
Я тоже так думаю, но я думаю что и нормальные модули такая же отличная штука.
VD>В прочем, кому я это все рассказываю? Ты ведь у нас пишешь на Питоне и С++, так? Тебе ли всего этого не знать? Даже в ОКамле объекты не лишние. Хотя казалось бы язык сначала функциональный и только потом немного объектно-ориентированный. Согласен?
Конечно, но в OCaml давняя традиция не пользоваться объектами
Вот эту фразу не понял:
“Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой."
Может нам не ту математику преподавали, но вроде как в матемаике (например геометрии) все начинают с аксиом а уж потом даказательства разных теорем вытекают из аксиом.
Здравствуйте, FR, Вы писали:
FR>В языке вообще нет модульности, компиляторы да с грехом пополам ее обеспечивают.
Ты же на С++ пишешь!
Модульность обеспечивается за счет директив extern и typedef-ов.
Раздельная компиляция, объектники и т.п., если не ошибаюсь прописаны в стандарте.
FR>В С++ с одной стороны улучшили, namespace классы, но с другой убили уничтожив ABI.
Что убили?
VD>>Да ну? Хаскель обладает "хорошей модульностью"?
FR>Наверно, я не знаток Хаскеля.
Так вот у него тоже работа с файлами через хэндлы организована. А инкапсуляция идет в стиле С.
Единственное преимущество — это более удобные модули.
VD>>Причем тут крики? Я утверждал, и продолжаю утверждать, что объекты — это отличная штука в первую очередь для той самой модульности. Кроме того они отлично подходят для, выражения АТД и кучи других задач.
FR>Я тоже так думаю,
Ну, а зачем тогда спорить лезешь? Лучше поддержал бы тога.
FR>но я думаю что и нормальные модули такая же отличная штука.
А где они нормальные то? В том то и дело, что нормальные они в основном в ООЯ. Класс — это супер-пупер штуковина для решения задач инкапсуляции. Причем ты дже не обязан в нем состояние хранить, в общем-то.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты же на С++ пишешь! VD>Модульность обеспечивается за счет директив extern и typedef-ов. VD>Раздельная компиляция, объектники и т.п., если не ошибаюсь прописаны в стандарте.
Угу, только эта фигня не обеспечивает нормальной модульности. Все вручную, турбо паскаль
и тот лучше.
FR>>В С++ с одной стороны улучшили, namespace классы, но с другой убили уничтожив ABI.
VD>Что убили?
Application binary interface.
Я вот сейчас часто делаю dll на VC которые должны вызываться и из C++ Builder, интерфейс
приходится делать сишный.
FR>>Наверно, я не знаток Хаскеля.
VD>Так вот у него тоже работа с файлами через хэндлы организована. А инкапсуляция идет в стиле С.
И что в этом плохого?
В OCaml в общем также, но писать в этом стиле удобнее и проще чем на Си, модули (даже без функторов) рулят.
VD>Единственное преимущество — это более удобные модули.
Этого вполне достаточно для АТД.
FR>>Я тоже так думаю,
VD>Ну, а зачем тогда спорить лезешь? Лучше поддержал бы тога.
Я и не спорю, просто не разделяю твоего мнения (может неправильно понял) что только объекты хороши для АТД.
VD>А где они нормальные то? В том то и дело, что нормальные они в основном в ООЯ. Класс — это супер-пупер штуковина для решения задач инкапсуляции. Причем ты дже не обязан в нем состояние хранить, в общем-то.
В OCaml и вообще в ML семействе хорошие.
В питон — руби, паскаль — дельфи и по слухам и в modula, ada и oberon вполне нормальные.
Здравствуйте, deimos, Вы писали:
D>Вот эту фразу не понял: D>“Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой."
D>Может нам не ту математику преподавали, но вроде как в матемаике (например геометрии) все начинают с аксиом а уж потом даказательства разных теорем вытекают из аксиом.
В школе — да. Но если ты захочешь родить раздел математики, то тебе придется _найди_ базис. В ООП вобщем то тоже так — реально никто не начинает городить классы. Не ясно, что автор имел ввиду.
Материал из Википедии — свободной энциклопедии, -_*
Здравствуйте, FR, Вы писали:
FR>Угу, только эта фигня не обеспечивает нормальной модульности. Все вручную, турбо паскаль FR>и тот лучше.
Оно обеспечивает такую же "нормальную" модульность, как и большинство других не ООЯ.
Другое дело, что там других проблем хватает. Но уже устал это обсуждать.
FR>>>В С++ с одной стороны улучшили, namespace классы, но с другой убили уничтожив ABI.
VD>>Что убили?
FR>Application binary interface. FR>Я вот сейчас часто делаю dll на VC которые должны вызываться и из C++ Builder, интерфейс FR>приходится делать сишный.
Байнари в С небыло никогда. Это как раз соглашения негласные. А что до переименования, то таки — да, только через С. Спасибо Страуструпу за точ, что он в угоду совместимости со старыми сишными линкерами заложил в язык такую баяку.
VD>>Так вот у него тоже работа с файлами через хэндлы организована. А инкапсуляция идет в стиле С.
FR>И что в этом плохого?
А ты напиши такую библиотеку и узнаешь.
VD>>Единственное преимущество — это более удобные модули.
FR>Этого вполне достаточно для АТД.
Нет. Это только обеспечивает часть механизма абстрагирования. Причем при этом абстрагирование становится паттерном, а не фичей языка. Что и есть большой минус в сравнении с классами.
FR>>>Я тоже так думаю,
VD>>Ну, а зачем тогда спорить лезешь? Лучше поддержал бы тога.
FR>Я и не спорю, просто не разделяю твоего мнения (может неправильно понял) что только объекты хороши для АТД.
Я не говорил "только". Я говорил, что объекты (точнее классы) хороши. Просто модули, даже очень хорошие все равно вынуждают применять паттерн так хорошо известный по С. А паттерн — это набор действий который нужно постоянно повторять, плюс возможность допустить ошибку. Класс же описывает АТД за один прием и без приседаний.
VD>>А где они нормальные то? В том то и дело, что нормальные они в основном в ООЯ. Класс — это супер-пупер штуковина для решения задач инкапсуляции. Причем ты дже не обязан в нем состояние хранить, в общем-то.
FR>В OCaml и вообще в ML семействе хорошие. FR>В питон — руби, паскаль — дельфи и по слухам и в modula, ada и oberon вполне нормальные.
Да ладно. Не гони. Все это не обеспечивает того удобства что обеспечивают классы. Возможно на счет АДЫ я не прав. В остальных же языках или надо танцевать с бубном, или есть те же классы которые решают задачу прямо и удобно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Оно обеспечивает такую же "нормальную" модульность, как и большинство других не ООЯ.
Гораздо хуже, особенно си.
VD>Байнари в С небыло никогда. Это как раз соглашения негласные. А что до переименования, то таки — да, только через С. Спасибо Страуструпу за точ, что он в угоду совместимости со старыми сишными линкерами заложил в язык такую баяку.
Так в си хоть и неформальное соглашения, но его придерживаются все производители OS и компиляторов (куда денешься если хочешь вызывать
системные функции ), в C++ его вообще нет.
VD>А ты напиши такую библиотеку и узнаешь.
Неоднократно писал и на C/C++ и недавно на OCaml.
Писать такое:
module Dir : sig
type handle
val _open: utf8 -> handle
val _close: handle -> unit
val _read: handle -> DirData.t
end
Не сложнее чем класс.
VD>Нет. Это только обеспечивает часть механизма абстрагирования. Причем при этом абстрагирование становится паттерном, а не фичей языка. Что и есть большой минус в сравнении с классами.
Паттерн, да, но в языках с нормальной модульностью элементарный.
VD>Я не говорил "только". Я говорил, что объекты (точнее классы) хороши. Просто модули, даже очень хорошие все равно вынуждают применять паттерн так хорошо известный по С. А паттерн — это набор действий который нужно постоянно повторять, плюс возможность допустить ошибку. Класс же описывает АТД за один прием и без приседаний.
Хорошие модули также за один прием. Плюс в тех же модулях OCaml есть приватные и фантомные типы, плюс возможность параметризации, это с избытком покрывает АТД.
VD>Да ладно. Не гони. Все это не обеспечивает того удобства что обеспечивают классы. Возможно на счет АДЫ я не прав. В остальных же языках или надо танцевать с бубном, или есть те же классы которые решают задачу прямо и удобно.
В ML семействе обеспечивают. Трудности появляются только когда нужен полиморфизм в рантайме.
В новой версии OCaml (3.12) уже и в рантайме все нормально, модули стали первоклассными сущностями http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc81 можно завести модульную переменную
например.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Когда в рамках ООП я думаю об *экземпляре* класса Car, то я думаю о нем, как о конкретной машине.... И функция Drive в этом плане не просто какая-то там функция — я именно в этот Москвич сел, завел его и поехал.
ВВ>В ФП я совсем иначе смотрю на вещи. У меня есть одна обобщенная функция Drive. Я пишу ее так, чтобы результат работы функции зависел только от ее параметров. Я могу эту функцию каррировать хоть до опупения, передавая таким образом кол-во бензина и проч., но все равно она не превратится в мой старенький Москвич 2140.
ВВ>По этим причинам мне кажется, что с точки зрения моделирования ООП и ФП не очень совместимы.
Может это от задач зависит? Да и что значит несовместимы. Если в то смысле, что интеллектуальный труд функциональшика (алгоритмы которые он настрочил в функциональном стиле) невозможно соединить с трудами имеперативщика ООП-шника в единую полезную систему. То тут скорее такое соединение, если получится, может оказаться крайне выгодным. А если в плане того что они чаще как противоположности — там где рулит ФП, там плохо дело у ИП,ОПП, и наоборот. То такое наверное есть.
Лучше взять Excel, чем Москвич 2140. Точнее использование API Excel из своей программы. Без внутреннего состояния никому такой Excel не будет нужен. Ради этого состояния он вобще-то и нужен — сложным внутренним состоянием позволяет управлять через простой API (хотя могли бы сделать и постройнее). Excel это точно не одна pure function, и даже не две.
Задача очень сложная, по крайней мере сделать качественно (например чтобы оказаться в первой пятерке), алгоритмы реально сложные. А по сути то надо написать всего лишь одну функцию — на вход берет 2 массива простеньких структур с 2-5 полями, на выходе результат как один массив структур. Никаких состояний там просто нет нигде, не нужны они. Хотя каких-то игрушек с двумя игроками совсем без состояний не бывает — но в данном случае этим можно полностью пренебречь. Т.е. теоретически как бы можно сказать состояние есть — но на самом деле его нет.
И кстати, там правила игры такие, что императивщикам на С++ будет очень тяжко — все недостатики ИП проявятся во всей красе. Хотя плюсники тоже наверное будут в первой десятке, но не столько как в прошлом году было. Тода задача была потупее нужно было вернуть одно число 1..4, тупой перебор был выгоднее. А сейчас уже сложным образом прийдется молотить списки и структурки данных. Эта задача однозначно лучше для ФП.
Мы уже победили, просто это еще не так заметно...
.
