Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaPerouse, Вы писали:
FR>>>То есть ты пишешь на Ocaml?
LP>> LP>>а он есть под jvm? я имею ввиду полноценный компилятор, а не разные хадкорные интеропы
VD>Ocaml не имеет серьезных приемуществ по сравнению с той же Скалой. Фактически Скала — это перенос идей МЛ-я на Яву. А Ocaml перенос (причем плохой) идей ООП в МЛ.
VD>Так что выбирая Скалу вы можно сказать выбираете близкого родственника ОКамла.
Честно говоря я имею о Ocaml лишь отдаленное представление (смотрел где-то год назад F#), какое-то определенное мнение не смог составить. Не думаю, что для него существует поддержка платформы java, сравнимая со Scala, которая только для jvm и разрабоатывается. Так что если выбирать между ними, то конечно, выберу Scala — уже только из практических соображений.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, VladD2, Вы писали:
VD>А мне больше заняться не чем чем доказывать упертым очевидные прописные истины. Веришь в Хаскель? Ну, так молись и верь. Не буду мешать. А у меня своих дел навалом. Тут пенисометрии по форуму разбросано тонна.
Хватит проецировать свою религию на остальных. Я не фанат Хаскеля, но твои аргументы смешны. Не можешь привести примера, ну и не надо, а записывать всех в фанаты (а потом удивляться, почему фанатом считают тебя) — не надо.
Здравствуйте, LaPerouse, Вы писали:
LP>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).
Согласен, конечно, извращения!
Собственно, у нас была дискуссия по поводу "императивных алгоритмов", мол, в функциональном виде это выльется во что-то страшное.
Плюс ещё была дискуссия об этих же императивных алгоритмах, что их запись на ФЯ хуже, чем на ИЯ — но тут мы вроде уже закончили?
LP>Поэтому, чтобы создать измененную копию схемы, мне нужно на порядок больше действий. Но зато у меня реализация эффективнее с точки зрения скорости выполнения и памяти.
Думаю, да. Но сейчас сюда придёт thesz и докажет, что функциональные алгоритмы на графах быстрее императивных
T>>Это не так. Дей1ствия ровно те же. Клонирования большей части нод нет. LP>Есть, есть.
И где же они?
Вот у нас есть структура Map Int Component. Я удаляю компонент с каким-то индексом. Какое количество информации будет скопировано?
Правильный ответ: log(количество компонент). Но не самих компонент, а только дерево Map.
Теперь я добавляю компоненту. Ситуация ровно та же самая.
log(количество компонент) это никак не копирование большей части узлов.
LP>>> Потом для каждой ноды, удовлетворяющей условию, нужно добавить элемент, заменяющий прилегающие к ноде элементы. Я только с командировки вернулся и адски хочу спать, поэтому нет времени сделать набросок. T>>Во-во. Выспишься и увидишь, в чём был неправ. LP>Не вижу
Гляди снова.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, LaPerouse, Вы писали:
LP>>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).
L>Согласен, конечно, извращения!
Это шутка
L>Собственно, у нас была дискуссия по поводу "императивных алгоритмов", мол, в функциональном виде это выльется во что-то страшное.
Ну, ты немножко изменил представление данных — сделал граф по значениям, а не по ссылкам, как у меня. Кроме того, это лишь один случай. Максимум на что я могу согласиться — это то, что конкретно этот пример можно написать функционально, и это будет сопоставимо по сложности с императивным алгоритмом.
L>Плюс ещё была дискуссия об этих же императивных алгоритмах, что их запись на ФЯ хуже, чем на ИЯ — но тут мы вроде уже закончили?
Не совсем. Оборачивать результаты в какую-то там IO — это и есть извращение.
LP>>Поэтому, чтобы создать измененную копию схемы, мне нужно на порядок больше действий. Но зато у меня реализация эффективнее с точки зрения скорости выполнения и памяти.
L>Думаю, да. Но сейчас сюда придёт thesz и докажет, что функциональные алгоритмы на графах быстрее императивных
Мое мнение — быстрее они быть не могут, ибо компилятор с человеком не может сравниться в разруливании идентитей. Могут быть близкими, если компилятор хороший и будет копировать по минимуму. Вопрос, существует ли в природе такой компилятор?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, lomeo, Вы писали:
L>>Здравствуйте, LaPerouse, Вы писали:
LP>>>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).
L>>Согласен, конечно, извращения!
LP>Это шутка
То есть хотело спросить, ты в самом деле так считаешь или пошутил?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).
Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк.
LP> Поэтому, чтобы создать измененную копию схемы, мне нужно на порядок больше действий. Но зато у меня реализация эффективнее с точки зрения скорости выполнения и памяти.
Зато тебе сложней писать сложные преобразования. Больше приходится держать в уме.
Скорость выполнения вторична по отношению к функциональности, по крайней мере, в первой версии.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>В смысле? Который день я уже "тусущеся" в этой теме? VD>Ага.
Please reconsider.
Ни на один мой вопрос ответ "ага" не имеет смысла.
T>>О чем мои комментарии здесь? VD>А ни о чем. Тупо рекламируешь Хаскель в теме где ему совсем не место и попутно откровенно наезжаешь на окружающих.
Ну, тебе одному меня не окружить, окружающий ты наш.
Я рекламирую Хаскель невероятно удачно подобранными примерами, смелым искромётным юмором и очарованием моей притягательной личности. Назвать этот блестящий комплекс тупым можно только из черной зависти.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
LP>>Секрет того, что у тебя получилось так легко пересоздать схему, потому что исползуется ссылочная прозрачность, то есть Element содержит просто значения-ноды, а не ссылки на инстансы INode, как у меня. Мне же использовать такой подход не с руки, имхо на java заниматься этим — извращение (кстати, что ты считаешь по этому поводу?).
T>Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк.
Так — это как? Использовать ссылки (как у меня) или значения (как у lomeo)? Не забывай, что речь идет о java.
LP>> Поэтому, чтобы создать измененную копию схемы, мне нужно на порядок больше действий. Но зато у меня реализация эффективнее с точки зрения скорости выполнения и памяти.
T>Зато тебе сложней писать сложные преобразования. Больше приходится держать в уме.
Даже не знаю, сложней ли. Может, и сложней.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
T>>Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк. LP>Так — это как? Использовать ссылки (как у меня) или значения (как у lomeo)? Не забывай, что речь идет о java.
Так — это перестраивать структуру.
Я, если честно, не вижу, чем ссылки отличаются от значений, если ссылки на read-only объекты.
LP>>> Поэтому, чтобы создать измененную копию схемы, мне нужно на порядок больше действий. Но зато у меня реализация эффективнее с точки зрения скорости выполнения и памяти. T>>Зато тебе сложней писать сложные преобразования. Больше приходится держать в уме. LP>Даже не знаю, сложней ли. Может, и сложней.
Если привык менять на месте, то проще, конечно. Но если умеешь делать и так, и так, то уже сложней.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, LaPerouse, Вы писали:
LP>Да, мы его уже немного смотрели. Неплох, но не понравилось, что некоторые java-фичи реализованы не до конца. Например, вложенных аннотации не реализованы,
Здравствуйте, thesz, Вы писали:
T>>>Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк. LP>>Так — это как? Использовать ссылки (как у меня) или значения (как у lomeo)? Не забывай, что речь идет о java.
T>Так — это перестраивать структуру.
T>Я, если честно, не вижу, чем ссылки отличаются от значений, если ссылки на read-only объекты.
Это понятно, что ничем. Только ссылки потому то и нужны, чтобы адресовать изменяющиеся объекты c identity. Иначе их никто и ссылками не называл (то есть это название отражало бы лишь только способ размещения в памяти).
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, thesz, Вы писали:
T>>>Я думаю, что только так и надо делать, если задача больше, чем в 300 (несколько сотен) строк. LP>>Так — это как? Использовать ссылки (как у меня) или значения (как у lomeo)? Не забывай, что речь идет о java.
T>Так — это перестраивать структуру.
Интересно, как это ты себе представляешь на java. Тогда придется программировать, нарушая чуть ли не все принципы и паттерны объектно-ориентированного программирования. Например, абстрактную фабрику как реализовать? Передавать подряд все параметры, которые нужны объекту фабрике, чтобы она забила намертво эти данные в конструкторе?
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
L>>Собственно, у нас была дискуссия по поводу "императивных алгоритмов", мол, в функциональном виде это выльется во что-то страшное.
LP>Ну, ты немножко изменил представление данных — сделал граф по значениям, а не по ссылкам, как у меня. Кроме того, это лишь один случай. Максимум на что я могу согласиться — это то, что конкретно этот пример можно написать функционально, и это будет сопоставимо по сложности с императивным алгоритмом.
Да, но обрати внимание, это был твой аргумент и он не прошёл
Если говорить откровенно, то я не знаю, есть ли задачи, для которых императивные алгоритмы имеют лучшую сложность. Я что-то такое слышал, как слышал и обратное. Не разбирался, поэтому не могу сделать никаких заявлений. Но вот то, что для большинства встречающихся мне задач фп подходит лучше — могу. Но это уже будет ИМХО, так что спора опять не получится
L>>Плюс ещё была дискуссия об этих же императивных алгоритмах, что их запись на ФЯ хуже, чем на ИЯ — но тут мы вроде уже закончили?
LP>Не совсем. Оборачивать результаты в какую-то там IO — это и есть извращение.
Я уже слышал подобное заявление от VladD2 и ещё от кого то (не вспомню). Никто из них не дал обоснование — почему извращение? Может быть ты попробуешь? Ведь преимущества очевидны — отделение императива от функционального кода на уровне типов. Из-за полностью императивной записи в do-нотации недостатки тоже не заметны. Где извращение?
LP>Мое мнение — быстрее они быть не могут, ибо компилятор с человеком не может сравниться в разруливании идентитей. Могут быть близкими, если компилятор хороший и будет копировать по минимуму. Вопрос, существует ли в природе такой компилятор?
В случае уникального типа модификация должна быть по месту. Надо посмотреть Clean и Mercury.
T>>Так — это перестраивать структуру. LP>Интересно, как это ты себе представляешь на java. Тогда придется программировать, нарушая чуть ли не все принципы и паттерны объектно-ориентированного программирования.
"Хороша ложка к обеду".
В смысле — шаблоны должны применяться по месту. Как и принципы программирования — только программирования, жизненные лучше пусть будут неизменными.
LP>Например, абстрактную фабрику как реализовать? Передавать подряд все параметры, которые нужны объекту фабрике, чтобы она забила намертво эти данные в конструкторе?
Я не предлагаю так программировать везде. Я предлагаю так программировать в сложных местах, где легко ошибиться.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, lomeo, Вы писали:
L>>>Плюс ещё была дискуссия об этих же императивных алгоритмах, что их запись на ФЯ хуже, чем на ИЯ — но тут мы вроде уже закончили?
LP>>Не совсем. Оборачивать результаты в какую-то там IO — это и есть извращение.
L>Я уже слышал подобное заявление от VladD2 и ещё от кого то (не вспомню). Никто из них не дал обоснование — почему извращение? Может быть ты попробуешь? Ведь преимущества очевидны — отделение императива от функционального кода на уровне типов. Из-за полностью императивной записи в do-нотации недостатки тоже не заметны. Где извращение?
Извращение в том, что это выглядит искуственно. Зачем вообще отделять императивное от фукционального, да еще подобным костылем? Программист сам прекрасно может это делать без всяких проверок со стороны компилятора.
LP>>Мое мнение — быстрее они быть не могут, ибо компилятор с человеком не может сравниться в разруливании идентитей. Могут быть близкими, если компилятор хороший и будет копировать по минимуму. Вопрос, существует ли в природе такой компилятор?
L>В случае уникального типа модификация должна быть по месту. Надо посмотреть Clean и Mercury.
Я на досуге посмотрел Prolog, сложилось такое ощущение, что для трансформации-преобразования схем оно самое то.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Извращение в том, что это выглядит искуственно. Зачем вообще отделять императивное от фукционального, да еще подобным костылем? Программист сам прекрасно может это делать без всяких проверок со стороны компилятора.
1. Зачем отделять императивное от функционального? Затем, что если не отделять, то всё будет императивное. Если же отделять, то мы будем иметь много-много чистого кода и чуть-чуть грязного. Преимущества чистого кода расписывать не буду.
2. Зачем отделять именно таким способом? Ну, это один из возможных способов. Предложи лучше для чистого ленивого языка.
Искусственно выглядит — это как? Я вот когда пишу IO код, я совершенно не думаю о том, что это монада, и что тут функция протягивается туда или сюда. Для меня это императивный кусочек, который я могу набросать в императивной манере в функциональном языке.
Приведу пример. Когда я на Яве пытаюсь нарисовать, скажем, функцию высшего порядка, то это выглядит искусственно. Причина — синтаксис. Я вижу анонимные классы с единственным методом и т.д. Когда я пишу императив в IO монаде синтаксис мне помогает — я не вижу монаду, поэтому не вижу искуссвтенности. Но при этом, когда я захочу, я легко могу воспользоваться тем фактом, что это монадное вычисление.
LP>Я на досуге посмотрел Prolog, сложилось такое ощущение, что для трансформации-преобразования схем оно самое то.
Здравствуйте, LaPerouse, Вы писали:
L>>Я уже слышал подобное заявление от VladD2 и ещё от кого то (не вспомню). Никто из них не дал обоснование — почему извращение? Может быть ты попробуешь? Ведь преимущества очевидны — отделение императива от функционального кода на уровне типов. Из-за полностью императивной записи в do-нотации недостатки тоже не заметны. Где извращение?
Как где. Какое-то IO непонятное, do ещё... А ещё эти, чёрт их побери... А! Монады! Непонятная штука вообще.
LP>Извращение в том, что это выглядит искуственно. Зачем вообще отделять императивное от фукционального, да еще подобным костылем? Программист сам прекрасно может это делать без всяких проверок со стороны компилятора.
Искуственно выглядит ключевое слово pure.
Как программист, проекрасно могущий это сделать, расскажи мне всё, что ты можешь, об этой функции:
[float] foo(int x, [float] f)
А что ты можешь сказать о такой (псевдокод):
foo int (n :[float]) : [float], IO, Complexity O(log n)
Когда для определения свойств функции надо лезть в её реализацию, вот извращение. Можно, конечно, плётками заставлять документацию писать, но лучше, когда это заставляет делать компилятор. Да и то, не заставляет, а сам выносит на уровень декларации свойства функции.
Здравствуйте, lomeo, Вы писали:
L>Думаю, да. Но сейчас сюда придёт thesz и докажет, что функциональные алгоритмы на графах быстрее императивных
Он уже доказал обратное. Как он верно заметил изменение дерева дает логарифмическое усложнение алгоритма. В то время как в императивном скорость остается линейной.
Другой вопрос, что действительно есть много выгод от функционального преобразования деревьев и графов. Но это нужно прочувствовать на своей шкуре. Объяснить это практически нельзя.
Когда человек помается с отладкой сложного алгоритма модифицирующего дерево, то он согласится, что логарифмическое усложнение не так страшно по сравнению с возможностью упростить отладку.
Я вот сильно матерился когда наткнулся на то, что в немерловом компиляторе в некоторых местах дерево токенов и дерево типизированных выражений менялось императивно. Это приводило к тому, что найти ошибку было ну очень сложно. Ведь дерево то огромное.
С другой стороны иногда императивное изменение является единственным выходом к достижению приемлемой производительности. И с этим ничего не поделаешь. Потому каждый случай рассматривать отдельно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
