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

Ответ на »сообщение 2020« (Илья Ермаков)
___________________________
Обертываем три строчки кода в процедурную обертку...
А если не три ? А если вложенность ?
Вы не учитываете что вашие легкие три строчки на практике оочень быстро превращаются в нечитабельный клубок. Эдакие джунгли через которые без мачете (дебагера) не продерешься.

Функции циклической обработки данных (map, fold) это не "сотни непонятных библиотек" - Это азбука функуционального программирования, такая же азбука как для вас операторы цикла for, while

Ну, мы в Блэкбоксе работаем прекрасно при полном отсутствии пошагового дебагера.
Вот о том и речь - что для ФЯ это - азбука. А у ИЯ азбука другая. И бездумно мешать их вряд ли стоит... У каждого направления есть свои эффективные методы решения проблем.

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

Ответ на »сообщение 2011« (Илья Ермаков)
Почему же Вирт не ввёл в Оберон полиморфность как средство, доступное и в прикладных процедурах, т.е. в самодельных процедурах программистов, а ограничил её только несколькими стандартными процедурами?

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

Да, кроме того - опять же проблемы с динамической модульностью. Представим себе - в модуле A у нас есть процедура Proc(a: INTEGER).
Модуль B вызывает ее для аргумента типа BYTE. Все нормально.
Затем в следующей версии A появляется процедура Proc(a: BYTE). По правилам полиморфизма она более точно соответствует аргументу, передаваемому в B. Разработчики в новой версии модуля изменили логику так, что Proc(a: INTEGER) больше не умеет корректно работать с BYTE (допустим! Представим, что у нас будут не целые, а другие типы).
Однако модуль B скомпилирован с вызовом процедуры Proc:INTEGER.
Противоречие, несовместимость, прямо говоря - дырка. Compile-time и run-time конфликтуют. Так что как расширять полиморфные процедуры в компилирующей реализации - с ходу неясно.

Дженерики в Компонентном Паскале ждут еще своего часа. Однако в компилирующей реализации они будут либо неполноценными, либо противоречивыми.
Здесь путь один - переходить на промежуточное представление Франца и JIT. Вот тогда мы примирим дженерики с динамической модульностью.

Ответ на »сообщение 2022« (Сергей Перовский)
___________________________
У меня в голове не укладывается.
Ссылку на "укладыватель" уже приводил :))
Purely Functional Data Structures

Сергей, как долго вы собираетесь требовать от меня "напеть вам Паваротти" ?
Домашнее задание делать не будете ?

Ответ на »сообщение 2020« (Илья Ермаков)
___________________________
Обертываем три строчки кода в процедурную обертку...
А если не три ? А если вложенность ?
Вы не учитываете что вашие легкие три строчки на практике оочень быстро превращаются в нечитабельный клубок. Эдакие джунгли через которые без мачете (дебагера) не продерешься.

Функции циклической обработки данных (map, fold) это не "сотни непонятных библиотек" - Это азбука функуционального программирования, такая же азбука как для вас операторы цикла for, while
И функции эти позволяют очень хорошо держать под контролем безудержное нарастание энтропии, хаоса, которое и приводит на определенном этапе роста системы к "тепловой смерти" то есть невозможности уже что либо исправить в это потерявшем форму какфоническом нагромождении циклов, проверок, выходов, изменений состояний.

Ответ на »сообщение 2018« (Jack Of Shadows)
___________________________
>>>И разница между ФЯ и ИЯ не в возможностях языка
Так раскажите, как может быть устроена СУБД на чисто функциональном языке.
У меня в голове не укладывается.

Ответ на »сообщение 2018« (Jack Of Shadows)
___________________________
>>>Хотя мне уже Сергей напомнил (в который раз!!!) что ФП на этой ветке - офтопик.
Ничего подобного я не говорил. Я просил вместо эмоций конструктивного сравнения.
"Я знаю как надо, а остальные-лохи" офтопик в любой ветке :)

Ответ на »сообщение 2019« (Geniepro)
___________________________
Процедура должна быть а) значимой б) целесообразной.

Процедура map не удовлетворяет, на мой взгляд, ни а), ни б).
Обертываем три строчки кода в процедурную обертку... Причем три строчки, не содержащие конкретной смысловой нагрузки, только сценарий обработки, простейший сценарий, который непосредственно выражается одной-единственной конструкцией языка. Смысл?

INC/DEC - не пример, это не процедуры, а инструкции языка. И используются они не для наглядности, а так уж повелось издревле - вводить их по причине значительно большей скорости процессорной инструкции инкремента, чем присваивания со сложением. Хотя для нормального компилятора это не проблема. Просто - так повелось.

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

Однако в данном конкретном случае я не понимаю смысла огород городить - неужели ради того, чтобы заменить очевидное FOR i := 0 TO LEN (res) - 1 DO на Map(container, f)?
В первом случае совершенно очевидно, что делают три строчки кода.
Во втором случае мы получаем одну строчку, чтобы понять эффект которой, нам надо лезть к определению функции Map и читать документацию на нее.

Скажите, вы в своих программах используете такие процедуры, как INC(i), DEC(i) ?
Хм, странно. А почему не операторы i := i + 1; и i := i - 1; ?
Ведь это тоже самое!..

Вот видите, даже в таком простейшем примере видна выгода от полиморфных процедур...

Почему же Вирт не ввёл в Оберон полиморфность как средство, доступное и в прикладных процедурах, т.е. в самодельных процедурах программистов, а ограничил её только несколькими стандартными процедурами?
Использование SYSTEM.PTR, ANYREC и ANYPTR - слишком низкоуровневый подход...


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

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

Ответ на »сообщение 2017« (Илья Ермаков)
___________________________
:))) Илья вы меня за уши тянете обратно. Хотя мне уже Сергей напомнил (в который раз!!!) что ФП на этой ветке - офтопик.

Согласен по поводу обратной корреляции уровня абстракции с уровнем доступности изучения.

Но тут уже инженеру и учителю - в разные стороны.
Учителю важнее доступность изучения, пусть даже в ущерб возможностям языка.
Инженеру важнее мощность и возможность неограниченного роста в сложности системы без спонтанной потери контроля над качеством, надежностью, прозрачностью. Легкость изучения особого значения для него не имеет. Сложность систем над которыми он работает и так превышает сложность любого инструмента которым он будет пользоваться.
Менеджеру важна доступность кадров, их стоимость и легкость замены.
Поэтому не будет повальной вытеснения ИЯ на ФЯ.
Всем места хватит.

И разница между ФЯ и ИЯ не в возможностях языка (теоретически они одинаковы) и не в типах задач "удобных" для языка (это я вам Сергей, уже в который раз :)) ) А в возможностях человека. Его месте в социуме, его видении своей карьеры, своего профессионального роста.

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

Ответ на »сообщение 2004« (Снегурочка)
___________________________
Ограничением уровня надежности является потолок абстракции. Чем он выше, тем большей надежности может достигнуть человек до тех пор пока не стукнется в потолок.
Потолок абсракции в ФЯ гораздо выше чем в ИЯ. И вот вам результат.
Он подтверждается практикой - десятками лет разработки больших систем (в несколько миллион строк кода)
Императивные языки имели свой шанс доказать свои возможности много раз, и до сих пор не смогли преодолеть планку надежности которую сходу взял Erlang в своем первом же применении.

Ограничением уровня надежности, кроме потолка абстракции (с чем я совершенно согласен), является даже в большей степени квалификация разработчиков. Именно поэтому "в своем первом применении" - еще не доказательство, так же как UNIX, написанный на Си, еще не доказательство удачности последнего. Квалификация его создателей была на голову выше среднего.
Виртовские языки в системах реального времени - это правило, а не случай, и уже много лет. Это накатанный подход, дающий прогнозируемый, стабильный результат.
ФЯ до этой стабильности еще тянуться и тянуться - нужно в первую очередь доказать, что успех конкретных штучных проектов на Эрланге не коррелирует на все 100% со "звездностью" команд, работавших над этими проектами.
Вон QNX на Си написана - и тоже сверхнадежна. Но каково соотношение квалификации, времени, трудозатрат и стоимости, затраченных на это?

Не спешите возражать, что ФЯ на голову выше по абстракциям, а значит - и по этому соотношению. Не спешите. Если рассмотреть не один, а два фактора - уровень асбтракции и уровень квалификации, то окажется, что все не так просто.

Чтобы быть правильно понятым, подчеркну: далее под повышенной квалификацией я буду иметь в виду большой, неординарный опыт и практику. Под обычной квалификацией - не уровень среднего программиста-недоучки, а уровень нормального, интеллектуального человека, который не так давно пришел в профессиональное программирование, и участвует в промышленном проекте 1/2/3-й, но никак не десятый раз.

Можно работать на меньшем уровне абстракции. Это уменьшает надежность, затрудняет разработку и потому - для достижения качественного результата - требует повышенной квалификации команды. Как в случае с Си-семейством.

ФЯ - это очень высокий уровень абстракции. Уровень чистой теоретической математики. Если разработчики владеют этим уровнем, то все превосходно. Но... Если владеют! Квалификация команды должна быть также повышенной, просто чтобы владеть этими абстракциями. Здесь мало нормальных способностей, здесь нужна предрасположенность к чистому математическому мышлению. Отсюда - соотношение квалификации, времени, трудозатрат и стоимости опять-таки становится неясным.

Именно поэтому абстрагирование - это палка о двух концах. Именно поэтому я за то, чтобы без нужды не уходить со среднего уровня абстракции, уровня высокоуровневых императивных языков с богатой системой типов. Проще говоря - с виртовского уровня.
Здесь есть воспроизводимый опыт создания надежных и красивых систем, а самое главное воспроизводимый опыт воспроизводства (пардорн за намеренную тавтологию) новых кадров.
Как обучить способного человека с техническим мышлением разрабатывать программные системы на Обероне/Аде/другом Паскале - мне, как и многим другим, совершенно ясно. Более того, я могу быть уверенным, что человек, которого я обучаю с 10 класса по 3 курс, уже на четвертом сможет влиться в команду и участвовать в проекте без ущерба для качества продукта.
Чтобы подготовить ФП-программиста, в совершенстве владеющего своим инструментом, нужно подготовить полноценного математика-теоретика. Чтобы этот математик-теоретик начал работать на практике, нужно выдать все тот же объем технических программистских дисциплин. Да тут 6 лет мало будет, пожалуй...

Уровень абстракции Оберона оптимален как для легкой разработки, так и для легкого интеллектуального восприятия.
Уходим в сторону С - теряем первое. Уходим на ФЯ - теряем второе.
Вот почему не все так гладко с ФП.