Здравствуйте, Gaperton, Вы писали:
G>Так что, Wolfhound, можешь праздновать победу! G>Ну, пока кто-нибудь не сделал пример на OCaml (или на Sisal, чего мы вряд-ли дождемся).
Просто я так и не понял "условий игры". Что нужно вывести, за какое время и насколько можно оптимизировать. И, кстати, какого размера должна быть программа.
Вобщем, предлагаю такой вариант. Я пишу на OCaml программу, с количеством _слов_ меньше, чем у Wolfhound и более быструю, хотя и не чисто ФО. В "Эратосфене" достаточно места для высокоуровневой оптимизации, соответственно Ocamlу есть где развернуться.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, Gaperton, Вы писали:
G>>Так что, Wolfhound, можешь праздновать победу! G>>Ну, пока кто-нибудь не сделал пример на OCaml (или на Sisal, чего мы вряд-ли дождемся).
INT>Просто я так и не понял "условий игры". Что нужно вывести, за какое время и насколько можно оптимизировать. И, кстати, какого размера должна быть программа.
INT>Вобщем, предлагаю такой вариант. Я пишу на OCaml программу, с количеством _слов_ меньше, чем у Wolfhound и более быструю, хотя и не чисто ФО. В "Эратосфене" достаточно места для высокоуровневой оптимизации, соответственно Ocamlу есть где развернуться.
INT>Если интересно, давайте точные условия.
Может тему новую откроем? Конкурс на самую быструю реализацию решета эратосфена .
Мне было-бы интересно сравнить эффективность компиляторов на одном алгоритме, с одинаковой асимптотикой.
Но Wolfhound занялся алгоритмической оптимизацией, что затрудняет такое сравнение. Если хочется с ним посоревноваться — welcome.
Re[31]: Сильные стороны функционального программирования
Здравствуйте, Quintanar, Вы писали:
Q>Чего там непонятного-то? Любой человек, знающий хоть один функциональный язык программирования, легко поймет, что делает программа.
Вот только множества "любой человек" и "любой человек, знающий хоть один функциональный язык" если и пересекаются, то не очень значительно. И подобная запись, для обычного человека не знакомого ни с одинм ФЯ является совершенно не понятным набором слов и символов.
Q>Тебе запись кажется малопонятной, поскольку ты просто не знаешь, что к чему — интиуиция наработанная на использовании императивных языков здесь не поможет.
Я говорю о интуиции наработанной вообще без знания каких бы то нибыло языков программирования.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Сильные стороны функционального программирования
Здравствуйте, Gaperton, Вы писали:
VD>>Далее остается отключить функциональный стиль ивсе будет в пордяке. G>В Clean нельзя отключить функциональный стиль. Но все равно все будет в порядке.
Юмор нужно прокачивать...
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали:
VD>Вот только множества "любой человек" и "любой человек, знающий хоть один функциональный язык" если и пересекаются, то не очень значительно. И подобная запись, для обычного человека не знакомого ни с одинм ФЯ является совершенно не понятным набором слов и символов.
И что? Множества любой человек и любой человек, знающий хотя бы один императивный язык программирования пересекаются тоже не слишком значительно.
VD>Я говорю о интуиции наработанной вообще без знания каких бы то нибыло языков программирования.
Это демагогия. Интуитивно можно только кувалдой по шпалам дубасить, если речь идет о чем-то более сложном, нужно обучение.
Большинство людей в мире вообще не способны программировать даже на ИЯ, которые тут некоторые причислили к интуитивно понятным, в тоже время они прекрасно справляются с не менее сложными задачами, которые программисты своими программами решить не способны, — водят машину, например.
Re[30]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
VD>>>Далее остается отключить функциональный стиль ивсе будет в пордяке. G>>В Clean нельзя отключить функциональный стиль. Но все равно все будет в порядке.
VD>Юмор нужно прокачивать...
Чтобы облегчить эту задачу предлагаю ввести специальный тэг — [humor]. Иногда тяжело, знаешь ли, прокачать, без ключевого слова "лопата". А так — шутники могли бы пользоваться этим тэгом, и никаких непоняток .
Re[33]: Сильные стороны функционального программирования
Здравствуйте, Quintanar, Вы писали:
Q>И что? Множества любой человек и любой человек, знающий хотя бы один императивный язык программирования пересекаются тоже не слишком значительно.
И тем неменее императивная запись придложенная рядом будет понятна большинству "не посвященных". Что нельзя сказать о функциональной. То есть на лицо явная не интуитивность записи. Не факт, что это проблема подхода. Но все же.
VD>>Я говорю о интуиции наработанной вообще без знания каких бы то нибыло языков программирования.
Q>Это демагогия.
Демагогией тут как раз явлются заявления о демагогии. Так что не надо.
Q> Интуитивно можно только кувалдой по шпалам дубасить,
Вот это заявление чистейшей воды проявление демагогии. Такой, знаете ли, яркий образ без млалейшего лаогической связи с делом.
Q> если речь идет о чем-то более сложном, нужно обучение.
Обучение обучением. Но если простой человек не может за месяц въехать в базовые понятия, значит система переусложена.
Любой человек имет немлаый жизненный опыт. Логические выводы делал кадый и не раз. И если данный принцип записи не соотвествует этому опыту, то можно смело говорить о общей неинтуитивности этого способа записи.
Q>Большинство людей в мире вообще не способны программировать даже на ИЯ, которые тут некоторые причислили к интуитивно понятным,
Пример приведен довольно четкий. Результат тоже. Зачем домысливать? Возможно освоение императивного подхода и не просто. Но функционального еще сложнее. Если бы это было не так, то и расклад сил был бы совсем другим.
Q> в тоже время они прекрасно справляются с не менее сложными задачами, которые программисты своими программами решить не способны, — водят машину, например.
Вот это уж безусловно демагогия. ФЯ точно до вождения машин еще не дошло. Так что... Ну, да я так понимаю тут вообещ главное "одогреть своих". Вот только кому это нужно?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Сильные стороны функционального программирования
Здравствуйте, Gaperton, Вы писали:
G>Чтобы облегчить эту задачу предлагаю ввести специальный тэг — [humor]. Иногда тяжело, знаешь ли, прокачать, без ключевого слова "лопата". А так — шутники могли бы пользоваться этим тэгом, и никаких непоняток .
Мне кажется такая примитивизация нужна не многим. Уж лучше пусть каждый сам развивает свой юмор. Для этого даже отедьный форум есть. На крайняк есть "".
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется такая примитивизация нужна не многим. Уж лучше пусть каждый сам развивает свой юмор. Для этого даже отедьный форум есть. На крайняк есть "".
Эх ты, императивщик. Юмор не прокачал?
[humor] G>>Чтобы облегчить эту задачу предлагаю ввести специальный тэг — [humor]. Иногда тяжело, знаешь ли, прокачать, без ключевого слова "лопата". А так — шутники могли бы пользоваться этим тэгом, и никаких непоняток .
[/humor]
Рекурсивное определение, типичное для функциональных языков
Re[34]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали:
VD>И тем неменее императивная запись придложенная рядом будет понятна большинству "не посвященных". Что нельзя сказать о функциональной. То есть на лицо явная не интуитивность записи. Не факт, что это проблема подхода. Но все же.
Давай, как ты постоянно предлагаешь, не будем голословными. Приведи ссылки на исследования, где утверждается, что для человека незнакомого с программированием, императивные языки интуитивно понятны.
VD>Обучение обучением. Но если простой человек не может за месяц въехать в базовые понятия, значит система переусложена.
Не понимаю о чем ты говоришь. В основы любого ФЯ можно легко въехать за неделю неторопливого изучения, если человек уже знает один подобный язык, срок, естественно, сокращается. Количество новых для императивщика понятий невелико — рекурсия вместо циклов, иная система типов, pattern-matching (понятен интуитивно) и еще может быть чуть-чуть.
VD>Любой человек имет немлаый жизненный опыт. Логические выводы делал кадый и не раз. И если данный принцип записи не соотвествует этому опыту, то можно смело говорить о общей неинтуитивности этого способа записи.
Способ программирования на ФЯ близок к записи математических утверждений. Никто особо не жалуется на неинтуитивность математической записи. Просто одни люди способны ее воспринимать, другие нет. Для гуманитария с филологического факультета и императивный и функциональный стили одинаково интуитивно непонятны.
Re[35]: Сильные стороны функционального программирования
Здравствуйте, Quintanar, Вы писали:
Q>Давай, как ты постоянно предлагаешь, не будем голословными. Приведи ссылки на исследования, где утверждается, что для человека незнакомого с программированием, императивные языки интуитивно понятны.
Сслыка была тут рядом. Читай внимательнее.
VD>>Обучение обучением. Но если простой человек не может за месяц въехать в базовые понятия, значит система переусложена.
Q>Не понимаю о чем ты говоришь.
Веренее делашь вид, что не понимаешь.
Q> В основы любого ФЯ можно легко въехать за неделю неторопливого изучения, если человек уже знает один подобный язык,
Т.е. если он уже "словам голову". А если нет?
Q> срок, естественно, сокращается. Количество новых для императивщика понятий невелико — рекурсия вместо циклов, иная система типов, pattern-matching (понятен интуитивно) и еще может быть чуть-чуть.
И тем не менее изучение "первого" ФЯ крайне не простая задача.
Q>Способ программирования на ФЯ близок к записи математических утверждений.
Но они сами по себе долек от записи к которым привыкли люди долекие от математики.
Q> Никто особо не жалуется на неинтуитивность математической записи.
Да жалуются. Более того есть четкая обратная зависимость от количества мат. формул в статье и ее понятности и доступносте.
Q> Просто одни люди способны ее воспринимать, другие нет.
Да почти все способны если их как следует надресировать.
Q> Для гуманитария с филологического факультета и императивный и функциональный стили одинаково интуитивно непонятны.
И все же императивный стиль проще для восприятия. Причем мне кажется дело тут не функциональном подходе, а в конкретном синтаксисе. Ведь есть примеры специализированных языков с функциональным уклоном легко осваеваемых даже не программистами (SQL, XPath, XSLT).
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Сильные стороны функционального программирования
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Quintanar, Вы писали:
Q>>Давай, как ты постоянно предлагаешь, не будем голословными. Приведи ссылки на исследования, где утверждается, что для человека незнакомого с программированием, императивные языки интуитивно понятны.
VD>Сслыка была тут рядом. Читай внимательнее.
Я не нашел ее. Приведи ее здесь.
Q>> В основы любого ФЯ можно легко въехать за неделю неторопливого изучения, если человек уже знает один подобный язык,
VD>Т.е. если он уже "словам голову". А если нет?
Не надо искажать мои слова. Если человек не знает ФП, то изучит за неделю, если уже знаком, то за пару дней. Я в свое время научился разбираться в программах на SML именно за такой срок.
VD>И тем не менее изучение "первого" ФЯ крайне не простая задача.
Это не так. В строгих ФЯ (SML, OCaml, MoscowML) нет абсолютно ничего сложного. Особняком здесь, может быть, стоит Haskell, сначала лучше изучать очень простой SML. У O'Caml раньше была очень плохая документация и сам он переусложнен многими нечасто используемыми фичами типа объектов, но сейчас есть книга, где все достаточно грамотно и просто рассказано.
VD>И все же императивный стиль проще для восприятия. Причем мне кажется дело тут не функциональном подходе, а в конкретном синтаксисе. Ведь есть примеры специализированных языков с функциональным уклоном легко осваеваемых даже не программистами (SQL, XPath, XSLT).
У всех ФЯ одной группы очень похожий синтаксис (Scheme, Lisp и Haskell, SML, OCaml) как и у императивных языков (C++, Java, C#), другого просто нет. Шаблоны в С++ тоже примитивный ФЯ, так они гораздо непонятнее любого из вышеприведенных ФЯ.
Re[33]: Сильные стороны функционального программирования
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
VD>>Мне кажется такая примитивизация нужна не многим. Уж лучше пусть каждый сам развивает свой юмор. Для этого даже отедьный форум есть. На крайняк есть "". G>Эх ты, императивщик. Юмор не прокачал?
Видимо он был каким-то не таким... каким-то функциональным.
G>[humor] G>>>Чтобы облегчить эту задачу предлагаю ввести специальный тэг — [humor]. Иногда тяжело, знаешь ли, прокачать, без ключевого слова "лопата". А так — шутники могли бы пользоваться этим тэгом, и никаких непоняток . G>[/humor]
G>Рекурсивное определение, типичное для функциональных языков
Видимо ФЯ накладывает свой отпечаток на образе мышления.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Сильные стороны функционального программирования
VD>И все же императивный стиль проще для восприятия. Причем мне кажется дело тут не функциональном подходе, а в конкретном синтаксисе. Ведь есть примеры специализированных языков с функциональным уклоном легко осваеваемых даже не программистами (SQL, XPath, XSLT).
Ну и возитесь дальше с императивным стилем.
Дейкстра в свое время писал: "the goto statement should be treated on equal syntactic footing with the assignment statement."
Так что вы мне напоминаете человека, который орет, что goto это круто.
Здравствуйте, ON, Вы писали:
ON>Совсем замечательно было бы, если бы лямбда, куда подставляем пакет, могла заказать у этого пакета переменную некоторого типа, то есть даем пакету тип и получаем такую переменную если там есть такая. Такое вообще, бывает? Какой-нибудь Call-by-callback?
Оказывается, в Haskell'е можно работать с динамическими типами. Для этого там есть тип данных Dynamic. В него можно положить значение, а потом достать. Вот, например:
dl = [toDyn "aaa", toDyn 'a', toDyn (10::Int), toDyn ((\x->x)::(Int->Int))]
as::(Typeable a)=>Dynamic->a->Maybe a
as v t = fromDynamic v
tChar::Char
tChar = undefined
tInt::Int
tInt = undefined
tString::String
tString = undefined
getVals (x:xs) _type =
case (x `as` _type) of
Nothing -> getVals xs _type
Just x -> x:(getVals xs _type)
getVals [] _type = []
main = putStrLn ("Strings:"++(show (getVals dl tString))++"\nInts:"++(show (getVals dl tInt))
++"\nChars:"++(show (getVals dl tChar))
Я создаю сначала список со значениями разных типов, а потом их достаю обратно. as по смыслу работает, как в C#, только возвращает Nothing в случае неудачи. Переменная t в его определении нужна для того, чтобы компилятор правильно определил тип возвращаемого значения.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Конечные автоматы нет нужды писать на С/C++. Проще писать на чем-то более подходящем (например на SDL), а затем генерить C(или C++) код. Получается эффективней. G>Знаю. Только известные мне SDL тулзы очень дорогие (кинь ссылки, если знаешь халяву, плз). Но в любом случае, иногда приходится делать КА и руками.
Не очень понятно, в чём трудность реализации КА на C/C++/Java:
void transite (Event e)
{
int old_state = state;
switch(state)
{
case WAITING:
a1.transite(e);
a2.transite(e);
action1();
action2();
if (e==Event.TICK)
{
// действие на переходе
action3();
state LISTENING:
}
else if (...)
...
case LISTENING:
...
ну и дальше в таком же духе
...
}
}
Здравствуйте, LCR, Вы писали:
LCR>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, _Obelisk_, Вы писали:
_O_>>>Конечные автоматы нет нужды писать на С/C++. Проще писать на чем-то более подходящем (например на SDL), а затем генерить C(или C++) код. Получается эффективней. G>>Знаю. Только известные мне SDL тулзы очень дорогие (кинь ссылки, если знаешь халяву, плз). Но в любом случае, иногда приходится делать КА и руками.
LCR>Не очень понятно, в чём трудность реализации КА на C/C++/Java:
В целом трудности конечно нет. Но в твоем примере все переменные состояния будут свалены в кучу. При сложном КА это некрасиво и нехорошо, особенно учитывая, что в каждом состоянии своя логика и свои переменные состояния. Более правильно завести по классу на каждое состояние, чтобы избавиться от switch и воспользоваться "родным" полиморфизмом Java. Здесь ФЯ выигрывает благодаря более развитому полиморфизму.
Здравствуйте, Gaperton, Вы писали:
LCR>>Не очень понятно, в чём трудность реализации КА на C/C++/Java: G>В целом трудности конечно нет. Но в твоем примере все переменные состояния будут свалены в кучу. При сложном КА это некрасиво и нехорошо, особенно учитывая, что в каждом состоянии своя логика и свои переменные состояния. Более правильно завести по классу на каждое состояние, чтобы избавиться от switch и воспользоваться "родным" полиморфизмом Java. Здесь ФЯ выигрывает благодаря более развитому полиморфизму.
Так, вот с этого места поподробнее, если можно...
Если в каждом состоянии потребуется своя логика и свои переменные состояния, то это легко добиться использовав паттерн State, все состояния — это объекты класса, производного от класса State, в самом простом случае таком:
abstract class State
{
public abstract State transite(Event event);
}
производные классы переопределяют метод iteration нужным содержимым. Ну и классы-автоматы просто делают полиморфный вызов
state = state.transite(Event);
Разумеется, эту простейшую модель можно развивать, пряча всякие вещи от посторонних глаз, выделяя интерфейсы. Можно сделать статические переменные класса State, а можно создать коллекцию состояний — вариантов куча и каждый себе выберет по душе.
Какой принципиальный плюс мы получим, если решим использовать функциональный язык здесь?
LCR>Так, вот с этого места поподробнее, если можно...
LCR>Если в каждом состоянии потребуется своя логика и свои переменные состояния, то это легко добиться использовав паттерн State, все состояния — это объекты класса, производного от класса State, в самом простом случае таком:
Знаю, делал.
LCR>Какой принципиальный плюс мы получим, если решим использовать функциональный язык здесь?
Плюс очень простой — красота и лаконичность. Для кого-то, впрочем, это не принципиальный плюс.
Для того, чтобы вызов функции был полиморфным, нет необходимости определять новый тип (класс), или интерфейс. Потому, что при диспетчеризации вызова кроме типов принимаются во внимание еще и значения величин. В результате, грамотная реализация КА в ФЯ прямолинейна, проста, компактна и красива, для этого совсем не надо изобретать никаких паттернов.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
