Здравствуйте, Курилка, Вы писали:
К>В свете этого сразу вспоминается идея параметризуемых модулей в Эрланге, которые фактически и являются экземплярами. К>Т.е. опять же эмуляция.
Изобретение велосипеда самое увлекательное занятие из придуманных человечеством.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, VladD2, Вы писали:
VD>>Изобретение велосипеда самое увлекательное занятие из придуманных человечеством.
__>С последущими попытками выдать его за очередную волшебную пулю...
Только вот попыток чтот не видать, вспоминают иногда правда, что была бы полезна такая фича, но, видимо, нынешним пользователям языка это не очень актуально.
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
__>Насколько я понимаю весь вопрос в храненении состояний, можно рассмотреть несколько примеров: __>1) "Моя первая программа на паскале" — состояние хранится просто — в виде глобальных переменных. __>2) "Струкутрнуе программирование по уму" — все переменные объявлены внутри каких-то процедур, которые вызывают другие процедуры __>(я намеренно не использую слово "функция"), использование глоабальных переменных не приветствуется. Сразу возникает вопрос как передавать __>эти переменные при вызове, единственный разумный вариант — в виде структуры. Но структуры — это первый шаг к ООП. При построение __>большого приложения, возможно потребуется подменить что-то не исправляя кода, а заодно привязать те или иные процедуры к строго определенному __>контексту. __>3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.
__>VladD2 совершенно справедливо заметил, что такой способ хорошо подходит для описание систем на макро уровне, например: __>public class JobSystem и сразу понятно что если нужно взаимодействие с шедулером то нужно смотреть список его методов, в нем __>же хранится текущее состоние (в виде конфига и запихнутого внутрь кварца(которй уже со своими потрохами)), там же лежат __>методы для управления подсистемой в целом (start/shutdown). __>А вот при описании этого же в термених ФП мы вернемся к пункту 2, отчего несколько десятилетий назад наооборот пытались уйти.
А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Zuka, Вы писали:
Z>Здравствуйте, mini_root_2, Вы писали:
__>>Насколько я понимаю весь вопрос в храненении состояний, можно рассмотреть несколько примеров: __>>1) "Моя первая программа на паскале" — состояние хранится просто — в виде глобальных переменных. __>>2) "Струкутрнуе программирование по уму" — все переменные объявлены внутри каких-то процедур __>>3) "ООП" — позволяет хранить состояние в виде переменных членов и набор ассоциированных с ними функций в виде методов.
Z>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1
а если мы это сделаем через конфигурационные файлы как в IoC контейнерах, т.е. декларативно соберем систему?
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
Не оверквоть, плиз.
Z>>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1
A>а если мы это сделаем через конфигурационные файлы как в IoC контейнерах, т.е. декларативно соберем систему?
То получишь еще один убогий и страшный язык, который к тому же будет динамическим. Фрэймворки вроде Струтса ни что иное как костыли.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Zuka, Вы писали:
Z>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1
Неее, мне кажется что ты меня не правильно понял. Я рассматривал не передачу параметров, от нее никуда не денешься, а
место где хранится состояние, в пункте два оно хранится в виде локальных переменных процедур. Глобальные не привиетствуются,
потому что глобальное пространство одно и если им активно пользоваться возникнет бардак.
Если же мы получаем это значение (JobSystem) через синглтон, то это отнюдь не пункт 1, т.к. в этом случае она располагается
не глобально а в контексте определенного класса...
Фишка ООП в том что оно по сути предоставляет контейнер для контекста или на уровне классов или на уровне их экземпляров+
набор ассоциированных с ним методов+определенные правила их расширения(наследования)..
Проправьте если я ошибаюсь.
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, aka50, Вы писали:
VD>Не оверквоть, плиз.
угу... что-то случайно получилось... Z>>>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1 A>>а если мы это сделаем через конфигурационные файлы как в IoC контейнерах, т.е. декларативно соберем систему? VD>То получишь еще один убогий и страшный язык, который к тому же будет динамическим. Фрэймворки вроде Струтса ни что иное как костыли.
Ну почему сразу струтс или spring вспоминают?. Например http://code.google.com/p/google-guice/ или http://tapestry.apache.org/tapestry5/tapestry-ioc/ работают без конфигурационных файлов на аннотациях. Т.е. все в пределах одного языка. Вот собственно и интересно куда это отнести и чем это будет отличаться от поиска модулей в том же erlang на уровне самой vm.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, aka50, Вы писали:
A>Ну почему сразу струтс или spring вспоминают?.
Потому что это самые популярные реализации. С них все началось.
A> Например http://code.google.com/p/google-guice/ или http://tapestry.apache.org/tapestry5/tapestry-ioc/ работают без конфигурационных файлов на аннотациях. Т.е. все в пределах одного языка. Вот собственно и интересно куда это отнести и чем это будет отличаться от поиска модулей в том же erlang на уровне самой vm.
Это все равно другие языки и у них те же пролемы с интеграцией. Во время компиляции они не проверяются и имеют массу проблем с отладкой и вообще мало гарантий того что общая система основанная на них заведется и будет работать. В общем, их примененеие связанно с перекладыванием отвественности на тех кто занимается развертыванием приложений, что не может не ухудшать качество ПО.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, Zuka, Вы писали:
Z>>А где мы возьмем этот JobSystem? Если создадим сами или примем в качестве параметра, то это пункт 2. А если используем его через статические методы, изменяющие состояние, то это будет уже пункт 1
__>Неее, мне кажется что ты меня не правильно понял. Я рассматривал не передачу параметров, от нее никуда не денешься, а __>место где хранится состояние, в пункте два оно хранится в виде локальных переменных процедур. Глобальные не привиетствуются, __>потому что глобальное пространство одно и если им активно пользоваться возникнет бардак. __>Если же мы получаем это значение (JobSystem) через синглтон, то это отнюдь не пункт 1, т.к. в этом случае она располагается __>не глобально а в контексте определенного класса... __>Фишка ООП в том что оно по сути предоставляет контейнер для контекста или на уровне классов или на уровне их экземпляров+ __>набор ассоциированных с ним методов+определенные правила их расширения(наследования).. __>Проправьте если я ошибаюсь.
Разница между пунктом 1-м и 2-м — техническая. Т.е. глобальные и локальные переменные по сути своей различные. А вот предлагаемый тобой "контекст" по сути является неявным параметром методов класса. Т.е. классы предлагают иной (и весьма продуктивный) взгляд на задачу, но разница между 3-м пунктом и первыми двумя носит скорее синтактический характер.
Что касается синглтонов. Проблема глобальных переменных не в том, что они засоряют пространство имен, а в том, что передача состояния через глобальные переменные приводит к весьма неочевидным (для читающего код) side-effect'ам. И синглтоны тут не исключения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
mini_root_2,
__>P.S. В процессе заигрывания со скалой заметил один неприятный момент, язык поощраяет написание большого кол-ва анонимных __>функций (а иначе получается не так уж компактно) — в этом на мой взгляд главный недостаток чрезмерного засахарения, __>но в целом он мне понравился, добивает только отсутствие документации (ScalaByExample и пр. не в счет) и отсутствие __>поддержки со стороны netbeans.
Посмотри вот этот proposal от Bob Lee, Doug Lea и Josh Bloch (если ты джавист, а похоже что так и есть, то эти имена должны быть для тебя небезызвестными). Всё, что я вижу, это что в Скале этот proposal уже реализован, причём решение куда более общее, чем те частности, которые предлагают эти товарищи. Какой можно сделать вывод? Функции как первоклассные значения и замыкания лучше иметь прямо в языке, чем уметь их эмулировать с помощью ООП. Это касается и остальных элементов ФП.
M>>Ну и чем это отличается от объекта?
VD>"Это" ничем, так как является эмуляцией ООП на не поддерживающем на прямую эту парадигму языке. То есть то же ООП, только слишком многословно и сложно.
Ну почему же обязательно ООП?
VD>Никто не спорит, что любой процедурный язык позволяет эмулировать ООП.
VD>Только вопрос был не в этом. Вопрос был в том, что ФП дает в области проектирования на макро-уровне.
VD>Если все что оно дает — это возможность эмулировать ООП так же как это делали 30 лет назад на С, да еще и ченит препятствия, то в пору задуматся, а на хрена козе баян?
Хм. Что есть "проектирование на макро-уровне"?
Эрланг предлагает возможность упаковывать код в модули, приложения (OTP Applications) и библиотеки. От публичных и приватных функций никуда не убежишь, но по-моему, это не указывает на попытку "эмулировать" ООП. Это просто другая реализация "черной коробки" с известным публичным интерфейсом и непонятно чем внутри (а внутре у ней — неонка, ага )
Может, это Эрлангистам стоит говорить "нафига козе баян", говоря об ООП?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, aka50, Вы писали:
A>> Например http://code.google.com/p/google-guice/ или http://tapestry.apache.org/tapestry5/tapestry-ioc/ работают без конфигурационных файлов на аннотациях. Т.е. все в пределах одного языка. Вот собственно и интересно куда это отнести и чем это будет отличаться от поиска модулей в том же erlang на уровне самой vm. VD>Это все равно другие языки и у них те же пролемы с интеграцией. Во время компиляции они не проверяются и имеют массу проблем с отладкой и вообще мало гарантий того что общая система основанная на них заведется и будет работать. В общем, их примененеие связанно с перекладыванием отвественности на тех кто занимается развертыванием приложений, что не может не ухудшать качество ПО.
Эти проблемы есть у любой компонентной архитектуры с возможностью гибкой настройки (JobSystemJBOSS, JobSystemJMS и проблему отсутсвия какого-то компонента компилятор решить не сможет, максимум проверит корректность типов, что могут делать и аннотации + annotation processor как часть компилятора)
Здравствуйте, aka50, Вы писали:
A>По этому дальше спорить не буду, ибо чистый ООП как и чистый FP — это максимализм. Гибчее надо быть
A>[off] A>И scala мне все больше нравиться A>[/off]
Мне тоже (хотя есть определенные моменты, когда сахара слишком много), жду нормальной литературы и поддержки со стороны netbeans, а пока продолжаю играться.
Re[14]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, aka50, Вы писали:
__>Мне тоже (хотя есть определенные моменты, когда сахара слишком много), жду нормальной литературы и поддержки со стороны netbeans, а пока продолжаю играться.
В intellj уже есть, но правда для этого надо 7-ку пользовать и еще эта поддержка пока слишком alpha... По этому тоже пока играюсь
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Mamut, Вы писали:
M>Ну почему же обязательно ООП?
По определению.
M>Хм. Что есть "проектирование на макро-уровне"?
Этому вопросу посвящено не мало умных книг. Есть масса методик и подходов.
M>Эрланг предлагает возможность упаковывать код в модули, приложения (OTP Applications) и библиотеки.
Это механизмы абстрации С и Паскаля.
M>Может, это Эрлангистам стоит говорить "нафига козе баян", говоря об ООП?
Речь о том, что ФП не предлагает никаких средств проектирвоания отличных от структурного программирования известного со времен Алгола. Причем уже давно никто не спорит, что этих средств явно недостаточно для проектирования больших ситем.
На мой взгляд напрашивается вывод — чистые ФЯ не имеют особого интереса на пракике. Нужны гибридные языки позволяющие возсопльзоваться премуществами всех подходов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, aka50, Вы писали:
A>Эти проблемы есть у любой компонентной архитектуры с возможностью гибкой настройки (JobSystemJBOSS, JobSystemJMS и проблему отсутсвия какого-то компонента компилятор решить не сможет, максимум проверит корректность типов, что могут делать и аннотации + annotation processor как часть компилятора)
1. Это не так. Строготипизированные компонентные языки позволяют налаживать контакты между динамическими честями с помощь строго определенных интерфейсов.
2. В данном случае ни динамика, ни компонентность не нужы. Они используются от бедности исходного языка. Нет в этом языке удобных конструкций, вот и используются разные внешние фрэймворки, которые по сути ни что иное как скрипты позволяющие обойти ограничения основного языка.
Вообще потребность в скриптах или подобных фрэймворках является четкой демонстрацией использования языка уровень которго (или средства расширения) недостаточены для решаемой задачи.
A>А в целом я считаю что ценен именно FP + OOP.
+1
A>[off] A>И scala мне все больше нравиться A>[/off]
Ей бы еще метапрограммирование добавить, и было бы просто замечательно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
VladD2, Вы писали:
M>>Хм. Что есть "проектирование на макро-уровне"?
VD>Этому вопросу посвящено не мало умных книг. Есть масса методик и подходов.
Всё что нужно на макро-уровне — это поименовать сущности, и формализовать (хотя бы как-нибудь) зависимости между ними и расположить в иерархию. Об этом ещё Гради Буч писал. А способы формализации конечно же зависят от языка, главное что средства выражения абстракций есть
.
M>>Эрланг предлагает возможность упаковывать код в модули, приложения (OTP Applications) и библиотеки.
VD>Это механизмы абстрации С и Паскаля.
Модули нормально подходят для построения больших систем. Причём невозможность создавать "экземпляры модулей" ничуть не уменьшает возможность абстрагирования, и вопрос о создании экземпляров — это чисто вопрос спецификации контрактов.
Можно создавать высоко-реюзабельные кусочки, из которых потом будет состоять три четверти всего функционала. Примеры: gen_server, gen_event, gen_fsm, библиотеки комбинаторов, модули, функторы (в ocaml).
Да, кстати, покажи мне хотя бы одну библиотеку комбинаторов на Паскале.
Здравствуйте, Mirrorer, Вы писали:
K>>Ну как это кому? Я вот на Хаскеле обсчитываю задания по матстатистике. Там есть вещи, которые не под силу Excel. Люди говорят, что для этих целей лучше подходит J, а мне вот лень его изучать, тем более синтаксис у него жуткий.
M>Синтаксис как раз не жуткий. А вот лексемы в нем .. непривычные это да. M>Поченму-то мне кажется что основные понятия в J можно выучить в течении дня-двух. А вот научиться эффективно им пользоваться это займет некоторое время.
M>Лично я считаю J чем-то сродни математическому ассемблеру. Очень узкоспециализированный. Хотя теоретически на нем можно написать все что угодно.
На случай, если кто не сышал — удивительно то, что создатели J и К занимались, кажется, в Mitsubishi автоматизацией бизнес-процессов на APL (нет ничего более далекого от математики). И пришли к выводу, что APL для этих дел немерянно крут.
Впоследствии разделились, и сделали каждый по языку. Причем, автор К наколбасил на нем серверное решение для обработки временных рядов (в основном — для биржевых/финансовых приложений — kdb). Это решение неплохо продается, и широко известно в узких кругах. Вот так. Компания CQG, где я раньше работал, думала одно время, не купить ли нам этот движок. Решили не покупать. Я тогда, помнится, был против покупки. Мы были шокированы языком К (у нас тогда никто не знал, кто его разработал — а дядька-то оказывается гуру, и что это вообще такое — К), и с недоверием относились к качеству решения, считая его априори глючной наколенной поделкой. А жаль, надо было разобраться как следует, и купить.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
