Здравствуйте, Tonal-, Вы писали:
T>Я ж вроде там его разименовал.
Извини, видимо, не заметил.
DC>> Я пытался operator[] забаиндить, мне это так и не удалось, между прочим, пробовал на 2х современных компиляторах использовал std::tr1::bind. Ну как? T>Вот этот код скомпилировался без проблем на g++ (GCC) 3.4.5 (mingw-vista special r3):
T>Вчера было ленно проверять.
Ну xlC 9 и gcc (который стоит по дефолту в ubuntu) меня послали нафиг с трёжэтажным шаблонным матом, кроме того кто-то из них не мог понять какой именно оператор биндится, пришлось писать явное приведение. — короче написал вроде тоже самое, толи бустовкий биндер умнее, толи компиляторы не разобрались.
T>Хотя я согласен, что распознать в этом обращение по индексу довольно проблематично, а если ещё заметить, что barMap используется по значению а хочится по ссылке, поэтому нужно использовать find и разименовывать итератор или нужна таки композиция, то bind всяко сольёт функтору по понятливости. А вся конструкция тупому for-у.
Да кто-бы спорил , просто у for-а переиспользуемость на уровне copy-paste.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, thesz, Вы писали:
Q>>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.
T>Хаскель помогает авторам самих Nemerle и F#. Если, вдруг, ты этого не заметил.
Здравствуйте, thesz, Вы писали:
Q>>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.
T>Хаскель помогает авторам самих Nemerle и F#.
Это да. Это правильный подход — взять из языка лучшее, оставив синтаксический шлак фанатам.
Q>>А мне «вся тела такая» не нужна. В F# мне нравится энергичность по умолчанию.
T>Ещё один сторонник преждевременной оптимизации.
Это уже не смешно. Ты в любом сообщении готов увидеть преждевременную оптимизацию. Дело в том, что всё это время я абсолютно осознанно следил за тем, чтобы в мои комментарии не просочились аргументы о производительности. Просто задал себе ограничивающее правило: не тыкать в лицо производительностью, не обсуждать кроссплатформеность. Во-первых, как раз для того, чтобы не дать тебе повода придраться. Во-вторых, в данный момент (в пространстве текущих задач) производительность программиста для меня важнее, чем производительность программы. Просто потому что интересны вещи, которые в основном не требовательны к процессорным ресурсам. (С другой стороны, в вопросах памяти я более ограничен, стараюсь избегать утечек.) Плюс нет требования переносимости, и платформу можно выбирать самому. Это очень сильные допущения, далеко не все программисты имеют подобную степень свободы, поэтому не согласятся с моим пренебрежением вопросами производительности.
Но каким-то образом я таки дал повод обвинить себя в преждевременной оптимизации. У тебя должно быть запасён целый вагон заблаговременно распечатанных ярлычков «преждевременный оптимизатор», чтоб обильно навешивать на окружающих.
Здравствуйте, eao197, Вы писали:
E>Я привел пример, когда по стечению обстоятельств одна часть системы стала зависеть от поведения другой. Проверить работоспособность такой зависимости в моем случае можно только тестами, т.е. организационными мероприятиями. Изменить дизайн слишком дорого. И очевидно, что можно. Но, вопрос не в этом. А в том, что есть такого в ФП, что не позволяет возникать таким ситуациям в принципе? Или же в ФП при возникновении дилемы -- либо переделать дизайн, либо доказывать корректность тестами -- выбор всегда можно будет сделать в пользу переделки дизайна?
Как я понял, произошло следующее. thesz показал, где ФП выигрывает. Затем ты показываешь ситуацию и спрашиваешь — а как здесь ФП выигрывает? Даже не разбираясь в том, что за ситуацию ты предлагаешь, можно сказать, что
1. Возможно здесь никак
2. Это никак не опровергает того, что ФП выигрывает так, как показал thesz.
Если же слова thesz и твоё предложение рассмотреть эту ситуацию никак не связаны, то я извиняюсь — недопонял.
L>>Есть data Mailslot с определённой функцией sendStateNotification :: Mailslot -> Result. Есть data S, содержащая этот мейлслот, необходимо, чтобы функция queryState :: S -> Result (ну хорошо, SInterface s => s -> Result) можно было определить только единственным образом. Ну так оно и есть!
E>Если не сложно, тоже самое, только на русском.
Смысл такой — с помощью системы типов можно ограничить возможные реализации функции для данного типа (существование единственного доказательства для данной теоремы).
Я показал примитивный пример, для подробностей можно посмотреть
Djinn — программка, выводящая реализацию функции по её типу.
Практические применения ограничений с помощью системы типов
Lazy Functional State Threads. Наверное, одна из самых лучших статей на тему. Как rank-2 полиморфизм (логика второго порядка) помогает вставлять императивный кусок в функциональный код безопасно.
Beautiful Concurrency. Преимущество этой статьи — необязательно знать синтаксис Хаскеля.
LP>>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн? T>>Хороший доступней, плохой невозможней. Переход к лучшему проще. LP>На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы.
Ты, эта... Много больших систем на ФЯ дизайнил, а затем программировал?
Уж больно тон уверенный.
Назови хотя бы парочку.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Их разрабатывает нереальное число людей. E>>Осталось подождать, пока на Haskell-е небольшие команды сделают что-нибудь типа Intellij IDEA.
T>Thou shalt hold thy breath!
Вообще-то это клон Emacs-а, а не IDEA на хаскеле.
<< RSDN@Home 1.2.0 alpha 4 rev. 1128>>
Сейчас играет Василь Жданкін — Наливаймо, браття
Q>>>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет. T>>Хаскель помогает авторам самих Nemerle и F#. Q>Это да. Это правильный подход — взять из языка лучшее, оставив синтаксический шлак фанатам.
Или просто не догнав, как можно сделать хотя бы так же хорошо.
# The central claim of (*) is that the program's actual Halstead length may be computed using the n1 and n2 parameters (the sum of which Halstead defines as the program's vocabulary), even though the program has not been written yet.
# For example : if a program is written using 20 keywords and uses a total of 30 data objects, its Halstead length equals 233.6, and it has been empirically observed that this estimates compares with the actual length quite closely. This even happens to hold when the program is subdivided into modules (subroutines).
С её помощью можно посчитать "уровень языка", то есть, насколько он выразителен. Хаскель рвёт всех в клочья.
Q>>>А мне «вся тела такая» не нужна. В F# мне нравится энергичность по умолчанию. T>>Ещё один сторонник преждевременной оптимизации. Q>Это уже не смешно. Ты в любом сообщении готов увидеть преждевременную оптимизацию. Дело в том, что всё это время я абсолютно осознанно следил за тем, чтобы в мои комментарии не просочились аргументы о производительности. Просто задал себе ограничивающее правило: не тыкать в лицо производительностью, не обсуждать кроссплатформеность. Во-первых, как раз для того, чтобы не дать тебе повода придраться. Во-вторых, в данный момент (в пространстве текущих задач) производительность программиста для меня важнее, чем производительность программы. Просто потому что интересны вещи, которые в основном не требовательны к процессорным ресурсам. (С другой стороны, в вопросах памяти я более ограничен, стараюсь избегать утечек.) Плюс нет требования переносимости, и платформу можно выбирать самому. Это очень сильные допущения, далеко не все программисты имеют подобную степень свободы, поэтому не согласятся с моим пренебрежением вопросами производительности. Q>Но каким-то образом я таки дал повод обвинить себя в преждевременной оптимизации. У тебя должно быть запасён целый вагон заблаговременно распечатанных ярлычков «преждевременный оптимизатор», чтоб обильно навешивать на окружающих.
Энергичность по умолчанию предпочитают из-за производительности. Потому, что ленивость по умолчанию более подходит для записи более модульных программ.
Никаких других плюсов энергичность по умолчанию не даёт. Наоборот, даёт минусы.
То, что ты говоришь о том, что тебе важна производительность программиста, это, ну, преувеличение. В противном случае ты бы мыслил по-другому. Выразительность, простота создания DS(E)L, модульность, строгая и мощная система типов.
Где это всё в твоих рассуждениях?
То, что ты не касался вопросов производительности в общении, не мешает тебе подсознательно о ней всё время думать и выдавать себя неосторожными комментариями, совсем чуток забыв о контроле.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>А почему обязательно IDEA? Чем не подойдёт модель процессора или видеоконтроллера
Никогда не занимался моделями процессоров и видеоконтроллеров. Но с IDEA ситуация простая -- она очень хороший пример продвинутой IDE, которая окупается (в отличии от конкурирующих с ней Eclipse и NetBeans). Раз это товар, пользующийся массовым спросом, значит сократив издержки на его производство можно серьезно выгадать в прибыли. Поэтому, если сменить Java на Haskell в качестве языка реализации, то, веря в серебрянность ФП, можно и сократить количество разработчиков, и увеличить качество, и снизить сроки разработки.
T> в сроки и даже раньше?
Интересно, вы поверите, если я скажу, что в сроки и даже раньше разрабатываются проекты и на C++? Особенно в небольших командах.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали:
LP>>>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн? T>>>Хороший доступней, плохой невозможней. Переход к лучшему проще. LP>>На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы.
T>Ты, эта... Много больших систем на ФЯ дизайнил, а затем программировал?
T>Уж больно тон уверенный.
T>Назови хотя бы парочку.
Угадай-ка с трех попыток, с помощью какой парадигмы написан Module?
При хорошем дизайне взаймодействие частей ПО описывается спецификациями, за которыми скрыты низкоуровневые вещи. Парадигма программирования — понятие, отсносящееся к реализации, а реализация-то как раз и скрыта за интерфейсами.
Разработка программного обеспечения — это комплексный процесс, в котором парадигме программирования отведена определенная роль, и не стоит эту роль преувеличивать. Ты с фанатизмом ударяешься в крайность, придавая парадигме (ФП) прямо таки определяющую роль, соответственно считаешь, что ФП революционно меняет процесс разработки. А на самом деле парадигма — ни что иное, как один из винтиков в общем процессе, не более. Процесс разработки программ на ФЯ подчиняется все тем же общим законам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, thesz, Вы писали:
L>>>4) грязные G>>Это хорошо, можно писать императивный код там где он уместен.
T>Мультипарадигменный подход контрпродуктивен с точки зрения программиста.
С точки зрения какого программиста?
T>http://thesz.livejournal.com/509595.html
Не надо доказывать что любую программу можно написать плохо. Это очевидно.
L>>>5) энергичные G>>Лучше энергичность по-умолчанию, чем ленивость. T>Это контрпродуктивно с точки зрения программиста. Ниже модульность.
Как ленивость связана с модульностью?
T>http://thesz.livejournal.com/906786.html
Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.
ИМХО для не-списков ленивость поумолчанию не нужна.
LP>>>>>Неужели ты в самом деле считаешь, что ФП настолько посеребрена, что с ним становится невозможен плохой дизайн? T>>>>Хороший доступней, плохой невозможней. Переход к лучшему проще. LP>>>На самом деле при проектировании программных систем парадигма не имеет никакого значения, или по крайней мере значит очень мало. На первое место выходит такие общие, более высокоуровневые характеристики, нежели используемая парадигма, как то: слабосвязанность, разделение ответственностей, изолированность подсистем и пр. ФП там или ООП — уже побоку. Разница между парадигмами сказывается максимум на уровне модулей, а потом начинают работать более общие законы. T>>Ты, эта... Много больших систем на ФЯ дизайнил, а затем программировал? T>>Уж больно тон уверенный. T>>Назови хотя бы парочку. LP>Тон уверенный, потому что я в этом уверен. LP>
LP>Угадай-ка с трех попыток, с помощью какой парадигмы написан Module?
XML?
Эту штуку ты написал в функциональном стиле, как ты его понимаешь. И это только часть системы.
Систему целиком в функциональном стиле ты не проектировал, на навязывающем функциональный стиль ЯП ты не писал.
В каких пунктах я не прав?
LP>При хорошем дизайне взаймодействие частей ПО описывается спецификациями, за которыми скрыты низкоуровневые вещи. Парадигма программирования — понятие, отсносящееся к реализации, а реализация-то как раз и скрыта за интерфейсами.
ФЯ не даст тебе сделать некоторые виды интерфейсов.
Например, ты не можешь получить (по крайней мере, простым путём) окошко для наблюдения за внутренностями другой системы.
LP>Разработка программного обеспечения — это комплексный процесс, в котором парадигме программирования отведена определенная роль, и не стоит эту роль преувеличивать. Ты с фанатизмом ударяешься в крайность, придавая парадигме (ФП) прямо таки определяющую роль, соответственно считаешь, что ФП революционно меняет процесс разработки. А на самом деле парадигма — ни что иное, как один из винтиков в общем процессе, не более. Процесс разработки программ на ФЯ подчиняется все тем же общим законам.
"В теории практика неотличима от теории".
Ты рассматриваешь системы с настолько высокого уровня абстракции, что между ними действительно нет разницы.
С этого уровня, действительно, всё так и есть. Но этот уровень настолько тривиален, что пользоваться им нет особого смысла. Более того, он противопоказан в качестве обоснования каких-либо выводов насчёт системы.
Систему надо спроектировать ещё на уровень разбиения вниз (на подсистемы и их контракты), вот тогда можно делать выводы.
Но тогда и реализация проступает сильней. И влияние парадигмы вместе с нею.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, lomeo, Вы писали:
L>>>Есть data Mailslot с определённой функцией sendStateNotification :: Mailslot -> Result. Есть data S, содержащая этот мейлслот, необходимо, чтобы функция queryState :: S -> Result (ну хорошо, SInterface s => s -> Result) можно было определить только единственным образом. Ну так оно и есть!
E>>Если не сложно, тоже самое, только на русском.
L>Смысл такой — с помощью системы типов можно ограничить возможные реализации функции для данного типа (существование единственного доказательства для данной теоремы).
Т.е., грубо говоря, все это дело можно на C++ выразить чем-то вроде:
class Mailslot { public: void sendStateNotification(); };
class NonchangeableMailslotUsedSignal {
private:
// Создавать этот объект может только один класс.friend class S::NonchangeableMailslotHolder;
NonchangeableMailslotUsedSignal() {}
};
class SInterface {
public:
virtual void NonchangeableMailslotUsedSignal queryState() = 0;
};
class S : public SInterface {
private :
class NonchangeableMailslotHolder {
Mailslot & mailslot_;
public :
MonchangeableMailslotHolder( Mailslot & m ) : mailslot_( m ) {}
NonchangeableMailslotUsedSignal sendStateNotify() {
// Только здесь можно создать объект, тип которого указывает,
// что обращение к sendStateNotify произошло.
mailslot_.sendStateNotify();
return NonchangeableMailslotUsedSignal();
};
};
NonchangeableMailslotHolder mailslot_;
public :
S( Mailslot & m ) : mailslot_( m ) {}
virtual NonchangeableMailslotUsedSignal
queryState() { return mailslot_.sendStateNotify(); }
};
Получается, что мы требуем от SInterface.queryState() возвращение объекта такого типа, который производит только операция sendStateNotify() для неизменяемого, лишь однажды проинициализированного объекта Mailslot.
L>Я показал примитивный пример, для подробностей можно посмотреть
За ссылочки спасибо. Но на первый взгляд для меня это overkill.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Qbit86, Вы писали:
Q>Это зависит от вкладываемого смысла в «помогает». Можно понимать в смысле «помогает по сравнению с». По сравнению с C++, возможно, Хасель помогает. По сравнению с Nemerle и F# — нет.
На Немерле удобнее писать ФП код?
L>>Я правильно понял, что единственная претензия к синтаксису Хаскеля, это наличие в библиотеках идентификаторов типа восклицательного знака? Q>Нет, не правильно. Выше встречались примеры кода на Хаскеле в сравнении с другими языками. Из этих примеров молчаливые анонимусы, читающие из-за спины спорщиков, могут сделать определённые выводы. И, боюсь, не в пользу Хаскеля.
И сделают ложный вывод. Потому что "человеческие слова" не означают удобство в ФП.
L>>Только это скучно — БД, гуй... Есть библиотеки, значит их можно нарисовать или сгенерить — интереснее дизайн и алгоритмы. Q>Должен же кто-то и горшки обжигать. GUI, кстати, вовсе не так скучно, если инструмент правильный.
Кому как.
L>>4) грязные L>>5) энергичные Q>Ты так говоришь, будто это что-то плохое :)
T>>А почему обязательно IDEA? Чем не подойдёт модель процессора или видеоконтроллера E>Никогда не занимался моделями процессоров и видеоконтроллеров. Но с IDEA ситуация простая -- она очень хороший пример продвинутой IDE, которая окупается (в отличии от конкурирующих с ней Eclipse и NetBeans). Раз это товар, пользующийся массовым спросом, значит сократив издержки на его производство можно серьезно выгадать в прибыли. Поэтому, если сменить Java на Haskell в качестве языка реализации, то, веря в серебрянность ФП, можно и сократить количество разработчиков, и увеличить качество, и снизить сроки разработки.
Другие примеры не подойдут? Только IDEA? Galois, Inc не подойдёт? Bluespec?
T>> в сроки и даже раньше? E>Интересно, вы поверите, если я скажу, что в сроки и даже раньше разрабатываются проекты и на C++? Особенно в небольших командах.
Поверим. Чудеса случаются.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, lomeo, Вы писали:
L>На Немерле удобнее писать ФП код?
Пока что я прихожу к выводу, что на Nemerle удобнее писать код вообще. В том числе и функциональный, и объектно-ориентированный, и мета.
L>И сделают ложный вывод. Потому что "человеческие слова" не означают удобство в ФП.
Вообще говоря, не означают.
Q>>Ты так говоришь, будто это что-то плохое :)
L>Не плохое. Менее ФП-шное.
Лишь бы удобное и не сковывало. А менее труЪ оно, или более — вопрос философский и второстепенный.
Здравствуйте, eao197, Вы писали:
E>Т.е., грубо говоря, все это дело можно на C++ выразить чем-то вроде:
E> NonchangeableMailslotUsedSignal sendStateNotify() {
E> // Только здесь можно создать объект, тип которого указывает,
E> // что обращение к sendStateNotify произошло.
E> mailslot_.sendStateNotify();
E> return NonchangeableMailslotUsedSignal();
E> };
E>
Разве тут нельзя опустить строчку mailslot_.sendStateNotify();, чтобы по прежнему программа компилировалась?
Но идея такая, верно — чтобы не компилировался неверный код, надо описывать инварианты в типах. Зависимые типы в этом отношении наиболее близки к идеалу.
E>За ссылочки спасибо. Но на первый взгляд для меня это overkill.
У меня есть пара постов на эту тему, но там синтаксис Хаскеля
Может проблема в том, что мы говорим на разных языках?
L>>>>4) грязные G>>>Это хорошо, можно писать императивный код там где он уместен. T>>Мультипарадигменный подход контрпродуктивен с точки зрения программиста. G>С точки зрения какого программиста?
Да, очевидно. И интересным является то, как любую программу написать лучше.
От чего надо избавиться, чтобы писать программы лучше. Или чего взять.
Вот если избавляться, то от мультипарадигменности, по-моему.
G>>>Лучше энергичность по-умолчанию, чем ленивость. T>>Это контрпродуктивно с точки зрения программиста. Ниже модульность. G>Как ленивость связана с модульностью?
Да это же, вроде, известная тема.
Например, в переборных алгоритмах я могу просто породить бесконечное дерево вариантов, а потом натравить на него отсекатель. Создатель дерева ничего не знает о его получателе, получатель ничего не знает о создателе — последний может быть результатом какого-то отсечения.
После ознакомления с этим вариантом решения он начинает возникать то тут, то там.
T>>http://thesz.livejournal.com/906786.html G>Примеры в статье сильно надуманные. Вывод "везде, где по дизайну программы могут проходить ленивые значения и их надо сохранить ленивыми", в .NET это как раз достигается типом IEnumerable<T>, который может быть как ленивым, так и энергичным списком.
И как понять, какой он когда? А не станет ли он энергичным раньше времени?
Примеры в статье очень простые для простоты изложения и рассмотрения.
G>ИМХО для не-списков ленивость поумолчанию не нужна.
Это ХО, наверное, поддержано каким-то практическим опытом? Каким же, если не секрет?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>Никогда не занимался моделями процессоров и видеоконтроллеров. Но с IDEA ситуация простая -- она очень хороший пример продвинутой IDE, которая окупается (в отличии от конкурирующих с ней Eclipse и NetBeans). Раз это товар, пользующийся массовым спросом, значит сократив издержки на его производство можно серьезно выгадать в прибыли. Поэтому, если сменить Java на Haskell в качестве языка реализации, то, веря в серебрянность ФП, можно и сократить количество разработчиков, и увеличить качество, и снизить сроки разработки.
Оффтопик: на Java сложно писать без IDE, на Haskell — просто. Как причина отсутствия IDE a la IDEA для Haskell пойдёт?
Хотя — многое из того, что есть в IDEA и полезное для Haskell есть в том же Emacs haskell-mode. Или в vim.
— короче написал вроде тоже самое, толи бустовкий биндер умнее, толи компиляторы не разобрались.
