Ответ на »сообщение 2361« (Geniepro)
___________________________

Возможно, что Вы просто ошибаетесь, считая императив естественным для Ваших задач. Вот если бы Вы всерьёз попробовали - тогда можно было бы говорить о естественности императива для Вас.
А причин для использования ФП Вы не видите по той простой причине (пардон за тавталогию), что не хотите их увидеть, вот и всё...

Неправда Ваша. :)
Напротив, я, к примеру, периодически рассматриваю разные возможности, в т.ч. ФЯ для наших задач. (Меня действительно интересуют таящиеся в них возможности оптимизации.)
Но пока что ФЯ туда не втиснешь.
Основная причина: надо предоставить программистам возможность ручной оптимизации (увы, производительности всегда не хватает).
Другая причина: никто, кроме меня, ФП пока не интересуется; все "погрязли" в прикладных задачах.
Кстати, первый, кто посоветовал мне познакомиться с идеями ФП, был info21. Так что не стоит недооценивать своих "оппонентов". :)

Идеал - понятие субъективное.
Есть преподаватели, считающие ФЯ гораздо идеальнее других языков подходящими для начального обучения программированию. И таких преподователей существенно больше, чем преподователей Оберонов...

А потом, где-нибудь главе к третьей, они вдруг сообщают, что все-таки приходится использовать присваивание...

Ответ на »сообщение 2359« (Илья Ермаков)
___________________________

Для моих текущих задач императив естественен, а для использования ФП нет никаких причин.

Возможно, что Вы просто ошибаетесь, считая императив естественным для Ваших задач. Вот если бы Вы всерьёз попробовали - тогда можно было бы говорить о естественности императива для Вас.
А причин для использования ФП Вы не видите по той простой причине (пардон за тавталогию), что не хотите их увидеть, вот и всё...
Конечно же у Вас есть на это полное право, что тут возразишь, просто, возможно, что Вы многое теряете, как знать...

Правильно, на прикладных, в бизнесе - кто спорит-то? Поле широчайшее. Я и описал это поле - очень условно, но все же - как задачи "на вычисление".

Что такое - задачи не "на вычисление"? Непонятно... Разве есть хоть одна сколько-нибудь серьёзная задача, обходящаяся без вычислений? Я о таких никогда не слышал... Даже в жрайвере мышки и то есть какие-то вычисления...

Сфера применения Оберона достаточно ясна - и никто не выдает его давно за "серебрянную пулю" в целом. Это нечто близкое к "серебрянной пуле" для системных задач, идеал для начального обучения программированию, удачный выбор для образования в целом, неплохой инструмент и в типовых задачах. Вот так, по убыванию от "эксклюзива" к уровню "не хуже, чем другие".

Идеал - понятие субъективное.
Есть преподователи, считающие ФЯ гораздо идеальнее других языков подходящими для начального обучения программированию. И таких преподователей существенно больше, чем преподователей Оберонов...

Сфера применения ФП, по Вашим словам, выходит неограниченной и безграничной. А упорное доказывание, что "ФП и в системном программировании лучше, и операционные системы на нем будем писать" - это уж вообще, извините, ни в какие ворота...

То есть наличие операционных систем, написанных на ФЯ (в том числе и чистых ленивых ФЯ), в том числе написанных в далёкие семидесятые годы, для Вас абсолютно пустой звук? Другой вопрос - почему эти ОС на ФЯ не стали мэйнстримовыми и вообще малоизвестны. Но Вам эта причина и так известна - она та же самая, по которой и обероновские ОС не стали мэйнстримом...

Ответ на »сообщение 2356« (VPrin)
___________________________

Спасибо, нашел задачу. Не нашел двухкратно уменьшения кода при использовании Хаскеля по странению с ИЯ о котором говорил Jack Of Shadows.

Да, Вы правы, конечно же. Если считать строки чистого кода, то программа на Хаскелле почти в четыре раза короче программы на КП (63 строки против 230). Собственно, это и имелось в виду. А программа Трурля (на J, кажется) ещё в три раза короче (22 строки) :о)) Что любопытно, Ваша программа на Дельфях имеет около ста строк (среднее между Хаскеллем и КП).


Ну все равно это больше академическая задача. Есть более земные задачи, например поиск пути волновым методом на квадратной карте. Лучше б хаскелисты на них показывали крутость хаскеля, к ним бы вопросов о надуманости задач не возникало. Может кто нить из хаскелистов, как Вы там писали "найти на неё время, показать всю мощь их языков" с волновым алгоритмом на хаскеле? :) А интересно стало, а гугл ответа не дал.

А что это за задача, и насколько она полезна?
И разве нет её решений на других языках? Стоит ли изобретать велосипед? ;о))

Ответ на »сообщение 2357« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2354« (Илья Ермаков)
___________________________
ФП/ДП "чахло" в диапазоне 80-х не от того, что "еще не было гигабайт дешевой памяти", а из-за упадка своей сферы.
Отвергаются очевидные вещи, лишь бы успокоить себя что ФЯ это химера, а императив не мелкая идея, привязанная к состоянию техники 60-х годов, а нечто на тысячелетия.

Почему химера? Гиперболы навроде "императив - мелкая идея..." как раз с Вашей стороны постоянно слышно. Для меня это всего лишь параллельные подходы. У меня сложилось четкое представление о том, где бы я стал применять ФП. Т.е. ту границу, за которой я уверенно возьму в руки LISP али Haskell, я знаю. Например, из своего, хоть и небольшого, опыта работы над системами комп. лингвистики, я извлек урок, что императив для этого подходит слабо. ФП там не пробовал (ибо корпоративный стандарт и огромный code-base у них был на Ц++), но при возможности, если еще придется работать в подобной сфере, очень хотелось бы попробовать.

Для моих текущих задач императив естественен, а для использования ФП нет никаких причин.


Вот практика и показывает что чем дальше ширитя потенциальное поле применения ФЯ (те самые гигабайты памяти и гигагерцы, да ядра процессоров) тем больше и больше ФЯ применяются в различных сферах бизнеса. То есть самых что ни на есть прикладных, приземленных задачах.

Правильно, на прикладных, в бизнесе - кто спорит-то? Поле широчайшее. Я и описал это поле - очень условно, но все же - как задачи "на вычисление".


Нет. Илья, как и все остальные императивщики упорно отказывается иметь вообще какой бы то ни было опыт в этой области, одни суеверия.
Может потому что есть документированный негативный опят внедрения такого подхода другими людьми, компаниями ?
Нет, подход относительно новый. И те единичные случаи которые пока есть, только положительны.
В общем, как я уже говорил, давайте предоставим практике разобраться кто выживет а кто нет. Где граница применимости и практичности абсртакций, и полезно или вредно автоматическое выделение памяти.

Практика не сама по себе, практику делают люди. Наши ветки претендуют на роль "массового просветительства". Так давайте не на практику кивать, а разбираться уже сейчас, что да как...
А то наплодим оговорок, а потом еще MS (как Вы говорите) подключится - и получим еще раз вовсе не то, что ожидалось - как это произошло с мейнстримовским ООП. И будете на старости лет, подобно Алану Кею, говорить: "Когда я продвигал в массы ФП - то, я вам скажу, я отнюдь не имел в виду Microsoft Visual Some_Functional_Language".
Сфера применения Оберона достаточно ясна - и никто не выдает его давно за "серебрянную пулю" в целом. Это нечто близкое к "серебрянной пуле" для системных задач, идеал для начального обучения программированию, удачный выбор для образования в целом, неплохой инструмент и в типовых задачах. Вот так, по убыванию от "эксклюзива" к уровню "не хуже, чем другие".
Сфера применения ФП, по Вашим словам, выходит неограниченной и безграничной. А упорное доказывание, что "ФП и в системном программировании лучше, и операционные системы на нем будем писать" - это уж вообще, извините, ни в какие ворота...

Ответ на »сообщение 2356« (VPrin)
___________________________
Спасибо, нашел задачу. Не нашел двухкратно уменьшения кода при использовании Хаскеля по странению с ИЯ о котором говорил Jack Of Shadows.

Да вы правы. Я ошибся...в пользу оберона :))
Там более чем 3-х кратное уменьшение кода
Хаскель: 63 строчки.
Оберон: 227 строчек.

Коментарии и пустые строчки убраны.

Ответ на »сообщение 2354« (Илья Ермаков)
___________________________
ФП/ДП "чахло" в диапазоне 80-х не от того, что "еще не было гигабайт дешевой памяти", а из-за упадка своей сферы.
Бездоказательное утверждение. Почему это так ? Непонятно. Почему игнорируется факт проигрывания ФЯ на тогдашнем железе - непонятно. Почему игнорируется факт того что mainstream языки двигались исключительно бизнесом а не наукой, и каково положение языков в научной сфере не имело тут ВООБЩЕ никакого значения ? Непонятно.
Отвергаются очевидные вещи, лишь бы успокоить себя что ФЯ это химера, а императив не мелкая идея, привязанная к состоянию техники 60-х годов, а нечто на тысячелетия.

Однако не стоит абсолютизировать мощь сверхабстракций, в частности, математических - если потерять чувство меры, легко "переабстрагироваться" и получить эффекты, противоположные ожидаемому.

Кто определает это чувство меры - непонятно. Казалось бы практика должна определять. Она расставит все по своим местам. Те кто потеряют чувство меры - проиграют, провалят задачу, сгинут со сцены программирования.
Вот практика и показывает что чем дальше ширитя потенциальное поле применения ФЯ (те самые гигабайты памяти и гигагерцы, да ядра процессоров) тем больше и больше ФЯ применяются в различных сферах бизнеса. То есть самых что ни на есть прикладных, приземленных задачах. Вот пусть они и поплатятся за свою "чрезмерную" и "непрактичную" абстракцию. Ан нет. Впролне успешны эти применения, вполне конкурентноспособны. Настолько конкурентноспособны что вышибают из некогда традиционных сфер императивные языки. Настолько конкурентноспособны, что сами идеи ФП начинают потихоньку просачиваться в mainstream языки, такие как сишарп и java. Настолько жизнеспособны, что все три главные ведущие силы индустрии программирования (не научные а именно бизнес силы), MS, Sun, IBM держат у себя за пазухой команды функциональщиков. Оплачивают их работу.
Хаскель по существу развивается исключительно на деньги MS.
Но, о чем это я. Стенания оберонщиков по этому поводу мы уже слышали. Ведь вся эта огромная масса народу, либо тупицы, либо вредители, которые специально все это делают чтобы нас всех обмануть, лапшу повесить, и побольше денег с нас содрать.


Освобождение памяти, безусловно, для абсолютного большинства задач можно переложить на автоматику. Выделение же - увы...


Опять, голое и ничем не обоснованное утверждение. ЧЕм выделение памяти ПРИНЦИПИАЛЬНО отличается от ее освобождения ? Почему одно можно запросто автоматизировать а второе - НИ НИ ?
Может потому что это невозможно физически ? Нет, возможно и уже давно осуществляется.
Может потому что у Ильи негативный опыт с этим ?
Нет. Илья, как и все остальные императивщики упорно отказывается иметь вообще какой бы то ни было опыт в этой области, одни суеверия.
Может потому что есть документированный негативный опят внедрения такого подхода другими людьми, компаниями ?
Нет, подход относительно новый. И те единичные случаи которые пока есть, только положительны.

В общем, как я уже говорил, давайте предоставим практике разобраться кто выживет а кто нет. Где граница применимости и практичности абсртакций, и полезно или вредно автоматическое выделение памяти.

Ответ на »сообщение 2338« (Geniepro)
___________________________

Ответ на »сообщение 2299« (VPrin)
___________________________

А я кажется пропустил эту задачу. А где на нее можно посмотреть?

Решение на Хаскелле с ссылками на решение на Компонентном Паскале и собственно условиями задачи .
Так же в этой теме ранее было показано решение на Дельфах.
Спасибо, нашел задачу. Не нашел двухкратно уменьшения кода при использовании Хаскеля по странению с ИЯ о котором говорил Jack Of Shadows. Ну все равно это больше академическая задача. Есть более земные задачи, например поиск пути волновым методом на квадратной карте. Лучше б хаскелисты на них показывали крутость хаскеля, к ним бы вопросов о надуманости задач не возникало. Может кто нить из хаскелистов, как Вы там писали "найти на неё время, показать всю мощь их языков" с волновым алгоритмом на хаскеле? :) А интересно стало, а гугл ответа не дал.

Ответ на »сообщение 2354« (Илья Ермаков)
___________________________

Могут ли инженер-строитель и профессор матанализа работать на одном и том уровне абстракций? Как можно первому абстрагироваться от материала, сопромата и других деталей, совершенно неинтересных второму? Хотя второй по пьяни может такую прекрасную абстрактную систему для первого выстроить, вот только променяет ли первый когда-нибудь строительный чертеж на рекуррентное аналитическое описание здания в общем случае в многомерном пространстве? :-)

Эх, непонятно всё-таки, где Вы откопали этот миф, что ФП якобы пригодно только для решения высшематематических задач, но никак не для прикладного программирования. Разве у Вас есть такой негативный опыт? Если есть, так поделитесь им! ;о)
Ведь есть множество примеров решения и прикладных, и системных задач с помощью различных ФЯ - почему Вы их упорно игнорируете? Выглядит так, как будто у Вас обероновские шоры на глазах... :о))

Ответ на »сообщение 2351« (Jack Of Shadows)
___________________________
Ответ на »сообщение 2348« (Илья Ермаков)
Впереди большие изменения. А вы почему то считаете что мы уже достигли вершины в программировании, и надо останавливаться и оттачивать то что уже есть.
Как японцы, которые тысячу лет оттачивали искусство боя холодным оружием и довели его до совершенства, в то время как европейцы перешли на огнестрельное.
Оберон вполне может быть и жемчужина императивного программирования, так же как и катана - жемчужина холодного оружия. Но поезд уехал :) вы господа опоздали лет на 20 с признанием оберона.

Я бы тогда уже сравнил с рукопашным боем в целом. А рукопашный бой как важное "оружие" и в современной войне никто не отменял, наоборот - это очень важная составляющая подготовки бойца.
С появлением нового оружия растет "специализация", разные задачи на разных уровнях решаются разными средствами - это так.

В целом основной момент спора, к которому в очередной раз возвращаемся - уважаемые оппоненты опрометчиво списали императивное программирование в "каменный век", хотя этому противоречит даже сама логика истории - и теоретические основы, и практическое развитие двух "миров" шло совершенно параллельно, что только подтверждает их равноценность. И развитие оборудования тут ни при чем, больше влияние имеет специфика решаемых задач и актуальность тех или иных проблемный областей в разные периоды. ФП/ДП "чахло" в диапазоне 80-х не от того, что "еще не было гигабайт дешевой памяти", а из-за упадка своей сферы. Зачахли активные исследования по ИИ - некуда было прикладывать инструменты. В 90-х начался всплеск прикладных задач с математической, аналитической подоплекой, так скажем, "приземленный ИИ" -  - ФП вновь испытывает подъем.

Далее - про абстрагирование. Абстрагирование - это замечательно. Без него никуда. Однако не стоит абсолютизировать мощь сверхабстракций, в частности, математических - если потерять чувство меры, легко "переабстрагироваться" и получить эффекты, противоположные ожидаемому. Нужно работать на уровне абстракций, адекватном решаемым задачам.

Абстрагирование - это отвлечение от несущественных деталей.
Могут ли инженер-строитель и профессор матанализа работать на одном и том уровне абстракций? Как можно первому абстрагироваться от материала, сопромата и других деталей, совершенно неинтересных второму? Хотя второй по пьяни может такую прекрасную абстрактную систему для первого выстроить, вот только променяет ли первый когда-нибудь строительный чертеж на рекуррентное аналитическое описание здания в общем случае в многомерном пространстве? :-)

Я уже как-то условно делил задачи на вычислительные (нацеленные на получение результата, безотносительно к тому, каким путем к нему пришли) и управляющие (когда ценность имеет именно процесс работы системы, ее "жизнедеятельность"). Если я решаю управляющие задачи, то глупо абстрагироваться от того, от чего предлагаете вы - от синхронного выполнения (понятие "оператор"), от разделяемых данных, распределенного по системе - по модулям, по объектам - состояния (понятие классической, многократно используемой переменной). Глупо - потому что эти аспекты устройства системы как раз-таки в данном случае существенны. Конечно, абстрагироватьс можно - но потом все равно придется эмулировать те же самые понятия, "поверх", чем и занимаются подходы аля "функциональное реактивное программирование". Ну вот просто обязательно нужно абстрагироваться от синхронной дискретной машины, построить чистую функциональную модель, а затем поверх нее смоделировать ту же самую машину - и плевать, что непонятно - зачем, зато можно теорий понастроить и диссертаций понаписать :-)

Это по задачам управления. Но даже для "предельных" задач на вычисление часто невозможно абстрагироваться от стратегии вычислений (последовательность инструкций) и стратегии использования памяти (разделяемые переменные). Освобождение памяти, безусловно, для абсолютного большинства задач можно переложить на автоматику. Выделение же - увы...

Про олимпиады

Обсуждение того, какой инструмент более подходит для решения олимпиадных задач, не имеет смысла.

Ибо главная задача олимпиад - выявление светлых голов. Громкими буквами: СВЕТЛЫХ ГОЛОВ, и уж никак не лучших инструментов. И поэтому важно тщательно подобрать задачи и инструменты, чтобы ни один из разрешённых инструментов ни в одной задаче не давал бы преимуществ относительно другого.

Если на олимпиаде даётся задача (неудачная, на мой взгляд) на вычисление суммы цифр 100! - подразумевается, что участник должен САМ, без помощи "волшебных" инструментов написать код для умножения сверхбольших целых чисел. Таким образом, как я думаю, проверяется умение быстро решать довольно сложные технически задачи (хотя, на мой взгляд, это немножко не то, что нужно бы проверять, но это тема другого разговора). Именно поэтому, а не потому, что кто-то чего-то там лоббирует, так ограничивают разрешённые языки программирования. Чтобы все были по возможности в равных условиях.

И если даже разрешить использование ФЯ на олимпиадах, то боюсь, придётся проводить даже не отдельную олимпиаду по ФЯ, а одну по Лиспу, другую по Схеме, третью по Хаскелю и т.п.