Здравствуйте, eao197, Вы писали:
E>А вот можно эту тему развить (только на пальцах, примеры на Haskell-е для меня как китайский язык)? Буду очень признателен. Особенно про то, как разделять отдельные mailslot-ы в программе.
Например, параметризовав их тип неким фиктивным типом. Или сделать сам S типом второго порядка, тогда использовать в нём можно будет только созданные там же мейлслоты. И т.д.
Без примеров на Haskell очень тяжело — для подобных вещей он наиболее выразителен.
Здравствуйте, thesz, Вы писали:
G>>>>Лучше энергичность по-умолчанию, чем ленивость. T>>>Это контрпродуктивно с точки зрения программиста. Ниже модульность. G>>Как ленивость связана с модульностью?
T>Да это же, вроде, известная тема.
T>Например, в переборных алгоритмах я могу просто породить бесконечное дерево вариантов, а потом натравить на него отсекатель. Создатель дерева ничего не знает о его получателе, получатель ничего не знает о создателе — последний может быть результатом какого-то отсечения.
T>После ознакомления с этим вариантом решения он начинает возникать то тут, то там.
Ну для этого ленивость по-умолчанию не нужна. Вполне хватит ленивости на уровне библиотеки.
T>>>http://thesz.livejournal.com/906786.html G>>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.
T>И как понять, какой он когда? А не станет ли он энергичным раньше времени?
А зачем понимать? работайте как с ленивым, пока вам не потребуется обратное.
T>Примеры в статье очень простые для простоты изложения и рассмотрения.
Менее надуманными они не становятся. Надуманными примерами можно много чего показать.
G>>ИМХО для не-списков ленивость поумолчанию не нужна. T>Это ХО, наверное, поддержано каким-то практическим опытом? Каким же, если не секрет?
Ага, это поддержано опытом неиспользования ленивости не для списков\деревьев\подобных_структур.
Здравствуйте, gandjustas, Вы писали:
L>>Но ведь хочется, чтобы плохую программу написать было тяжело, верно? G>Хочется конечно, но кривой дизайн только средствами языка победить не получится.
Почему крайности? Почему обязательно "только"?
L>>Нет кучи имплементаций. G>Ну для этого существует много других способов, в том числе обобщенное программирование (generics и автоматическая генерализация как в F#).
Возможно.
Можно пример, как можно сделать map с помощью generics чтобы его легко можно было использовать и лениво и энергично?
G>>>ИМХО для не-списков ленивость поумолчанию не нужна. L>>Это потому что тебе показали только ленивые списки. G>Ну так покажите пример ленивости по-умолчанию без списков, где в ней реально есть смысл. G>Причем пример не надуманный.
Бесконечные структуры данных. Повышение переиспользования — за счёт склеивания — уже устал отсылать к Why FP matters.
Ну и потом с ленивостью по умолчанию элементарно писать надо меньше.
Да и вообще pure functional data structures как пример того, как может рулить ленивость по умолчанию.
Здравствуйте, thesz, Вы писали:
LP>>>>>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн? T>>>>>Хороший доступней, плохой невозможней. Переход к лучшему проще. LP>>>>На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы. T>>>Ты, эта... Много больших систем на ФЯ дизайнил, а затем программировал? T>>>Уж больно тон уверенный. T>>>Назови хотя бы парочку. LP>>Тон уверенный, потому что я в этом уверен. LP>>
LP>>Угадай-ка с трех попыток, с помощью какой парадигмы написан Module?
T>XML?
Я имел ввиду модуль, который описан данным XML-конфигом. Он может быть написан на чем угодно с применением чего угодно — это уровень реализации.
T>Эту штуку ты написал в функциональном стиле, как ты его понимаешь. И это только часть системы.
T>Систему целиком в функциональном стиле ты не проектировал, на навязывающем функциональный стиль ЯП ты не писал.
T>В каких пунктах я не прав?
На хаскель я писал только простые примеры. И уж подавно ничего не проектировал. Но не нужно есть кашу, чтобы...
LP>>При хорошем дизайне взаймодействие частей ПО описывается спецификациями, за которыми скрыты низкоуровневые вещи. Парадигма программирования — понятие, отсносящееся к реализации, а реализация-то как раз и скрыта за интерфейсами.
T>ФЯ не даст тебе сделать некоторые виды интерфейсов.
T>Например, ты не можешь получить (по крайней мере, простым путём) окошко для наблюдения за внутренностями другой системы.
Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.
T>Ты рассматриваешь системы с настолько высокого уровня абстракции, что между ними действительно нет разницы.
T>С этого уровня, действительно, всё так и есть. Но этот уровень настолько тривиален, что пользоваться им нет особого смысла. Более того, он противопоказан в качестве обоснования каких-либо выводов насчёт системы.
T>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.
Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.
T>Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею.
Если реализация оказывает влияние, тогда проектирование неправильное.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, thesz, Вы писали:
T>>>Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная. Q>>И к сорока годам остеопороз с остеохондрозом.
T>Так надо заниматься в 35+, когда тестостерон из пор кожи бьёт и все уже укрепилось.
T>ЗЫ T>Артрит, пока, мне встретился у человека, который ходил заниматься во время гриппа.
T>>В каких пунктах я не прав? LP>На хаскель я писал только простые примеры. И уж подавно ничего не проектировал. Но не нужно есть кашу, чтобы...
То есть, я прав по всем пунктам.
Ну, а я проектировал системы так и сяк, а ещё поддерживал такие и сякие системы. "Хорошо быть мной!" Сякие, правда, меньше, чем такие, но и нужда в них отпадала быстрей.
T>>Например, ты не можешь получить (по крайней мере, простым путём) окошко для наблюдения за внутренностями другой системы. LP>Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.
К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.
T>>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы. LP>Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.
Контракты ты как описывать будешь? Pre/postconditions? Нет? А как?
T>>Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею. LP>Если реализация оказывает влияние, тогда проектирование неправильное.
Чем быстрей ты выяснишь ошибку, связанную с реализацией, тем лучше.
Неужто твой контракт всегда может быть реализован в любой парадигме?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>>>Зато потом — спина прямая, мышцы по всему телу буграми, голова ясная. Q>>>И к сорока годам остеопороз с остеохондрозом.
T>>Так надо заниматься в 35+, когда тестостерон из пор кожи бьёт и все уже укрепилось.
T>>ЗЫ T>>Артрит, пока, мне встретился у человека, который ходил заниматься во время гриппа.
E>http://thesz.livejournal.com/757133.html: E>
E>Судя по всему, жим стоя в пятницу что-то нарушил в грудном отделе позвоночника, а понедельничный тренинг добавил.
Эта штука меня больше не беспокоит, поскольку я отменил жим вверх стоя.
Также меня не беспокоит нижний отдел позвоночника, который случался дважды, практически на ровном месте.
Вот уже два года, как.
И ещё: Дикуль.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Например, в переборных алгоритмах я могу просто породить бесконечное дерево вариантов, а потом натравить на него отсекатель. Создатель дерева ничего не знает о его получателе, получатель ничего не знает о создателе — последний может быть результатом какого-то отсечения. T>>После ознакомления с этим вариантом решения он начинает возникать то тут, то там. G>Ну для этого ленивость по-умолчанию не нужна. Вполне хватит ленивости на уровне библиотеки.
Если считать, что все, что мы пишем, может стать библиотекой, тогда да, достаточно ленивости на уровне библиотеки.
Кстати, один из критериев уровня ЯП — как сложно на нем писать библиотеки.
G>>>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком. T>>И как понять, какой он когда? А не станет ли он энергичным раньше времени? G>А зачем понимать? работайте как с ленивым, пока вам не потребуется обратное.
То есть, он ленивый.
А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания?
T>>Примеры в статье очень простые для простоты изложения и рассмотрения. G>Менее надуманными они не становятся. Надуманными примерами можно много чего показать.
Это часть беседы с Gaperton. Он рассматривал отображение на списках, я продолжил эту тему.
Напишите свои примеры, если угодно. Я их тоже рассмотрю, если они будут того стоить.
Одно условие — надо написать и в ленивом, и в энергичном стиле и хотя бы намекнуть, почему ленивый стиль будет хуже.
Буду признателен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Энергичность по умолчанию предпочитают из-за производительности. Q>ЧСХ, ленивость по умолчанию многие тоже предпочитают из-за производительности. Дескать, она даёт возможность избежать ненужных вычислений.
Из-за производительности программиста. Не надо заботиться, какие вычисления окажутся ненужными.
T>>Никаких других плюсов энергичность по умолчанию не даёт. Q>Даёт лучшую предсказуемость поведения (вспомни свои утечки невычисленных цепочек). (NB: Вот только не надо здесь поминать корень всех зол!)
Поведения программы — да. Поведения программиста — нет.
T>>В противном случае ты бы мыслил по-другому. Q>Т. е. не как прагматик, а как фанатик?
Идеализм — высшая степень любого прагматизма, что индивидуального, что коллективного. Идеалист прогибает реальность под себя сильнее всего. Идеализм экономит информацию при общении в коллективе.
Оппортунизм, который, обычно, и выставляют под именем прагматизма, даёт выигрыш на коротком участке времени и, в общем случае, требует больше мыслительных и других усилий.
T>>Выразительность, простота создания DS(E)L, модульность, строгая и мощная система типов. Q>И что, в этом плане Haskell впереди планеты всей, на два корпуса обгоняя F# и Nemerle? Нет убедительных оснований так считать.
Синтаксис в Хаскеле наикратчайший (выразительность). Ленивая семантика и операторы позволяют создавать развесистые DSEL, наиболее близкие к самой проблеме. Высокая модульность вычислений. Система типов Хаскеля на десяток фич мощней системы типов F# или Nemerle.
Из последних назову GADT и общее направление движения в сторону зависимых типов.
Здравствуйте, thesz, Вы писали:
T>К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.
А еще штангой мозги пудрил, я уже присматриватся начал какую купить, тем более раньше много ТФТ занимался, думал в изучении хаскеля поможет, но теперь ясно грибы рулят
G>>>>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком. T>>>И как понять, какой он когда? А не станет ли он энергичным раньше времени? G>>А зачем понимать? работайте как с ленивым, пока вам не потребуется обратное.
T>То есть, он ленивый.
T>А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания?
Нельзя. В энергичных языках zeros в правой части будет пытаться вычислиться.
Но в F# вполне можно написать так: let rec zeros = seq{ yield 0; yield! zeros}. И никакого расхода памяти.
На C# так сделать не получится, нету оптимизации хвостовой рекурсии.
Хотя для бесконечной последовательности нулей в .NET есть более простые способы.
T>>>Примеры в статье очень простые для простоты изложения и рассмотрения. G>>Менее надуманными они не становятся. Надуманными примерами можно много чего показать.
T>Это часть беседы с Gaperton. Он рассматривал отображение на списках, я продолжил эту тему. T>Напишите свои примеры, если угодно. Я их тоже рассмотрю, если они будут того стоить. T>Одно условие — надо написать и в ленивом, и в энергичном стиле и хотя бы намекнуть, почему ленивый стиль будет хуже. T>Буду признателен.
Я не говорил что будет хуже.
Я сомневаюсь что с ленивостью по умолчанию для не-списков будет лучше.
А учитывая приколы реализацией ленивости в хаскеле (утечки и прочее) может быть и гораздо хуже.
Здравствуйте, gandjustas, Вы писали:
T>>А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания? G>Нельзя. В энергичных языках zeros в правой части будет пытаться вычислиться. G>Но в F# вполне можно написать так: let rec zeros = seq{ yield 0; yield! zeros}. И никакого расхода памяти.
Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает.
А F# похоже не только функторы по пути растерял
Здравствуйте, Sinclair, Вы писали:
ГВ>>Два вопроса: что же такое "императивный программист" и почему ты решил, что он мыслит неким определённым образом? S>Поясняю еще раз: "императивный программист" — это программист, который мыслит императивными конструкциями. Это определение.
Это определение сферического коня в вакууме. У тебя миелофон за шкафом не завалялся? Нет? Тогда определение это не значит ровным счётом ничего. Пустышка. Нуль в знаменателе.
ГВ>>Не забываем, да, что процессы мышления и методы реализации алгоритмов — не одно и то же, хотя и некоторым образом они влияют друг на друга. S>Это избыточные подробности. Ок, я могу расписать длиннее:
К сожалению, почти вся дискуссия показывает, что эти подробности не избыточны.
S>"императивное программирование" — применение императивных конструкций для записи программы
Допустим.
S>"императивный программист" — программист, у которого набор техник программирования ограничен императивными конструкциями.
Отлично. Вот этого я и добивался. Теперь объясни ещё пару вещей: что такое техника программирования в данном случае? Это способ декомпозиции, семантика языковых конструкций, какой-то специфический синтаксис, ещё что-то? И что такое "императивные конструкции", которыми, по идее, ограничен набор техник программирования у императивного программиста?
P.S.: И ещё не снята куча вопросов о способах мышления.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, FR, Вы писали:
FR>Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает. FR>А F# похоже не только функторы по пути растерял
Да по моему любой язык с letrec должен нормально это кушать.
Здравствуйте, thesz, Вы писали:
T>>>В каких пунктах я не прав? LP>>На хаскель я писал только простые примеры. И уж подавно ничего не проектировал. Но не нужно есть кашу, чтобы...
T>То есть, я прав по всем пунктам.
T>Ну, а я проектировал системы так и сяк, а ещё поддерживал такие и сякие системы. "Хорошо быть мной!" Сякие, правда, меньше, чем такие, но и нужда в них отпадала быстрей.
Ты спрашиваешь у меня, проектировал ли я системы на Хаскеле, в том время как систем-то этих если и есть, то три штуки на всю планету. Само собой, можно ткнуть почти в любого, то ответ будет таким же, что же, из этого следует, что никто тебе возразить не сможет? Чушь какая-то, имхо.
T>>>Например, ты не можешь получить (по крайней мере, простым путём) окошко для наблюдения за внутренностями другой системы. LP>>Если так рассуждать, то ФЯ вообще не даст возможность написать программу. Ибо абсолютно функциональная программа абсолютно бесплезна ("абсолютно безопасное лекарство абсолютно бесполезно", Аристотель). Само собой, когда мы говорим про функциональный дизайн, мы имеем ввиду, что основная часть кода написана в функциональном стиле. Само собой, для обеспечения интерактивности, требуется некое императивное ядро.
T>К каким только передергиваниям не прибегнут фанаты императивщины, чтобы не программировать функционально. Даже более того, не думать функционально. Не смещать точку сборки.
Передергивание было у тебя, когда ты пытался представить модуль написанный на ФЯ чисто функциональным. Где у меня передергивания, в упор не вижу. К тому никакой я не фанат императивного программирования. Я очень даже за ФП, просто считаю, что оно имеет границы применимости, в отличие от тебя.
T>>>Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы. LP>>Подсистемы и контракты, правильно. При чем здесь ФП и ООП, понять не могу.
T>Контракты ты как описывать будешь? Pre/postconditions? Нет? А как?
Да, пред- и пост-условия, описывающее взаймодействие клиента и модуля. При чем здесь ФП и ООП? Может быть, тебя смущает, что понятие контракта было введено Мейерсом в рамках ООП?
T>>>Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею. LP>>Если реализация оказывает влияние, тогда проектирование неправильное.
T>Чем быстрей ты выяснишь ошибку, связанную с реализацией, тем лучше.
T>Неужто твой контракт всегда может быть реализован в любой парадигме?
Контракты, они конечно могут быть самыми разными. Например, некоторые предусловия императивного модуля в общем случае функциональнй модуль выполнить не сможет (в отличие от обратного случая). Но если сузить это понятие, скажем, до состояния структур данных, то да, практически при любой. К тому же я уже сказал, что "полностью функциональный модуль" — это сферический конь в вакууме. Для взаймодействия с остальными модулями разумнее использовать императивные интерфейсы и контракты. Это, конечно, мое мнение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Это определение сферического коня в вакууме. У тебя миелофон за шкафом не завалялся?
При чём тут миелофон?
ГВ>К сожалению, почти вся дискуссия показывает, что эти подробности не избыточны.
К сожалению, почти вся дискуссия показывает, что люди с заметным усердием занимаются terms misinterpretation. Причем цели этого намеренного непонимания лично мне остаются неясными.
ГВ>Отлично. Вот этого я и добивался. Теперь объясни ещё пару вещей: что такое техника программирования в данном случае? Это способ декомпозиции, семантика языковых конструкций, какой-то специфический синтаксис, ещё что-то?
Геннадий, не нужно включать дурака. Перечитай исходное сообщение, на которое ты столь невежливо ответил:
Это способ декомпозиции любого алгоритма на операции модификации, ветвления, и перехода, применяемые к некоторому глобальному состоянию
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
T>>>А можно ли на нём сделать zeroes = 0 : zeroes? Не будет ли чрезмерного расхода памяти? Не будет ли зацикливания? G>>Нельзя. В энергичных языках zeros в правой части будет пытаться вычислиться. G>>Но в F# вполне можно написать так: let rec zeros = seq{ yield 0; yield! zeros}. И никакого расхода памяти.
FR>Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает. FR>А F# похоже не только функторы по пути растерял
Дык у него вообще ленивости на уровне языка нету.
Я же и говорю что очень удобно было бы в .NET языках задавать ленивость декларативно.
FR>>Почему нельзя Ocaml нормально такое let rec zeros = 0::zeros;; кушает. FR>>А F# похоже не только функторы по пути растерял G>Дык у него вообще ленивости на уровне языка нету.
Ключевое слово lazy тоже отсутствует?
G>Я же и говорю что очень удобно было бы в .NET языках задавать ленивость декларативно.
