Прогрессъ въ языкахъ программированiя
Вынесено изъ комментовъ здѣсь https://akuklev.livejournal.com/1306754.html
Реальный прогрессъ въ языкахъ программированiя пока что происходилъ въ двухъ ситуацiяхъ. Первая ситуацiя - наличiе готовой "декларативной предметной области" съ извѣстнымъ языкомъ спецификацiй. Вторая ситуацiя - ФП, когда оказалось, что можно математически вывести новые design patterns, сформулировать и доказать правильность ихъ работы.
"Декларативная предметная область" это значитъ, что уже есть принятый и понятный людямъ языкъ, на которомъ люди объясняютъ другъ другу спецификацiи задачъ въ этой области, и этотъ языкъ однозначно и адекватно задаетъ и формулировку задачи, и ея рѣшенiе.
Два примѣра "декларативной предметной области":
1. Традицiонная запись ариѳметическихъ выраженiй. Мы пишемъ (x + y) / 2 + 1 и намъ сразу понятно, что и какъ будетъ вычислено. Когда придумали языкъ Фортранъ, гдѣ такiя выраженiя автоматически правильно компилируются, продуктивность программистовъ на порядокъ выросла. Не надо писать тесты, провѣряющiе, что мы правильно распредѣлили память или что второй знакъ "плюсъ" вычисляется послѣ дѣленiя. Мы написали выраженiе, какъ мы его понимаемъ, и все "само работаетъ". Языкъ спецификацiи (инфиксныя выраженiя съ числами и функцiями) является однозначнымъ способомъ записать и формулировку, и рѣшенiе задачи.
2. Языкъ SQL. Мы пишемъ select NAME,SALARY,DEPARTMENT from EMPLOYEES,SALARIES where EMPLOYEES.ID = SALARIES.EMPLOYEE_ID order by NAME limit 10 - и база данныхъ все сама правильно дѣлаетъ. И человѣку тоже сразу понятно, что и какъ будетъ вычислено. Когда изобрѣли реляцiонныя базы данныхъ, продуктивность программистовъ на порядокъ выросла.
Примѣры design patterns ФП -
1. Фильтрованный траверсальный функторъ-монада (filterable traversable monadic functor). Это структура данныхъ, выглядящая какъ массивъ, для котораго опредѣлены операцiи map, filter, reduce, flatMap. Методъ программированiя въ стилѣ map/filter/reduce позволилъ на порядокъ повысить производительность программистовъ. Теоретическiя свойства этой структуры описываются на языкѣ теорiи категорiй, доказываются необходимые законы, и послѣ этого программистъ можетъ быть увѣренъ, что программа, которая правильно выглядитъ ("сначала мы фильтруемъ то-то, потомъ дѣлаемъ map въ то-то и т.д."), будетъ всегда правильно работать.
2. Свободно порожденная аппликативная монада (free monad/free applicative). https://www.youtube.com/watch?v=Qg48XucSvlg Это комбинацiя свободно порожденной монады и свободно порожденнаго моноидальнаго функтора. (Эти слова мало помогаютъ понять, почему эта конструкцiя полезна, но главное, что есть четкая математическая теорiя съ доказательствомъ, что написанный кодъ реализуетъ структуру данныхъ правильно и всѣ необходимые законы выполняются.) Данная конструкцiя интересна тѣмъ, что ее изобрѣли сначала на бумагѣ, выведя правильный конструкторъ типа, и лишь потомъ написали кодъ реализацiи. Такой порядокъ дѣйствiй - сначала мы что-то на бумажкѣ вычисляемъ, и лишь потомъ начинаемъ конструировать рѣшенiе задачи - характеренъ для инженерной дисциплины. До появленiя ФП, это было невозможно - программы дѣлались чисто интуитивно, и лишь потомъ иногда доказывалась ихъ корректность.
До появленiя FP, въ трудѣ программиста не было мѣста для математическихъ концепцiй. Ни теорiя категорiй (съ функторами, монадами и естественными преобразованiями), ни теорiя логическихъ доказательствъ (изъ которой пришло Curry-Howard correspondence), ни "обычная" теорiя типовъ, ни гомотопическая теорiя типовъ не были нужны, потому что они никакъ не облегчали трудъ программиста и даже вообще не относились къ процессу написанiя программъ. Если посмотрѣть на книгу Кнута "Искусство программированiя", то она заполнена угадыванiемъ того, какъ написать программу и потомъ доказательствомъ, что Кнуту удалось угадать правильно.
Только въ FP математика реально используется для построенiя языка программированiя и для написанiя программъ. Только въ FP построенiе языковъ и программъ можно формализовать достаточно содержательнымъ образомъ, чтобы программистъ могъ думать о программѣ въ терминахъ "здѣсь у меня коварiантный функторъ - здѣсь у меня естественное преобразованiе - значитъ, тутъ тоже долженъ быть коварiантный функторъ" и создавать кодъ, пользуясь этими концепцiями.
Примѣры того, какъ не достигался прогрессъ въ языкахъ программированiя:
1. Языки, имитирующiе естественные (англiйскiй, русскiй и т.п.) Были COBOL, AppleTalk, ну и хрестоматiйное "ЕСЛИ нога поднята ТО опустить ногу ИНАЧЕ упадёшь и ВСЁ". Подражанiе естественнымъ языкамъ ничего не дало - всѣ проблемы организацiи и провѣрки правильности кода остались, кодъ сталъ существенно длиннѣе, но читать и писать кодъ проще не стало.
2. Языки, построенные полностью на какомъ-то одномъ простомъ принципѣ, выбранномъ ad hoc.
LISP - программы являются синтаксическими деревьями выраженiй untyped lambda calculus.
PROLOG - программы являются наборами Horn clauses.
Smalltalk - программы являются наборами объектовъ, посылающихъ другъ другу "сообщенiя".
Forth - программы являются наборами "словъ" стековой машины.
Языки, разработанные методомъ номеръ 2, не увеличили производительность программистовъ. Программы на этихъ языкахъ было писать не легче, чѣмъ на другихъ, кромѣ какихъ-то узкихъ классовъ задачъ, которыя случайно оказались для этихъ языковъ "декларативными предметными областями".
3. Языки, построенные методомъ встраиванiя какихъ-то (выбранныхъ ad hoc) новыхъ конструкцiй въ уже имѣющiеся языки.
Однимъ изъ одiозныхъ примѣровъ изъ прошлаго является языкъ PL/I, въ которомъ было такое число различныхъ конструкцiй, что было очень трудно сдѣлать полный компиляторъ для этого языка.
Другой примѣръ - С++ и слѣдующiй за нимъ языкъ D.
Наиболѣе одiозный примѣръ изъ современной практики - языкъ ABAP (компанiя SAP), въ которомъ за 40 лѣтъ разработки были добавлены (не какъ библiотеки, а какъ часть языка) средства работы съ очень большимъ числомъ предметныхъ областей.
https://www.cleverism.com/skills-and-tools/abap/
Въ 1990-2000 годы въ индустрiи была распространена идея, что каждая большая корпорацiя должна разрабатывать собственный языкъ программированiя, хорошо приспособленный къ нуждамъ именно этой корпорацiи. Всѣ эти языки были разработаны методомъ номеръ 3. Свои языки создали IBM, Microsoft, Sun, Oracle, Google, Facebook, а также финансовые гиганты - Bloomberg и другiе.
Проблема съ методомъ 3 въ томъ, что новыя конструкцiи добавлялись не въ результатѣ выбора какой-либо декларативной предметной области, а эвристически. Напримѣръ, добавляется спецiальное ключевое слово, означающее, что запросъ къ базѣ данныхъ будетъ выполняться асинхронно, но и только. Добавленная команда никакъ не стыкуется съ уже существующими конструкцiями языка. Средства работы съ асинхронными процессами въ результатѣ получаются совершенно недостаточными. Напримѣръ, невозможно опредѣлить, законченъ ли асинхронный процессъ. Въ языкъ тогда добавляются новыя ключевыя слова для рѣшенiя этой проблемы, но потомъ появляются новыя проблемы и т.д.
Въ результатѣ, имѣющiяся средства языка плохо сочетаются и исчезаетъ декларативность. Становится очень трудно выискивать въ кодѣ ошибки. Поскольку языкъ не слѣдуетъ какимъ-либо формальнымъ принципамъ, работа съ такимъ языкомъ сводится къ гугленiю проблемъ и тестированiю наугадъ выбранныхъ рѣшенiй.
4. Языки, построенные путемъ "упрощенiя" уже имѣющихся языковъ.
Напримѣръ, Java выбросила цѣлый рядъ возможностей C++, а языкъ Go выбросилъ цѣлый рядъ возможностей изъ Java.
Это не рѣшаетъ имѣющихся проблемъ, и въ результатѣ разработчики все равно потомъ добавляютъ одна за другой ранѣе выброшенныя возможности.
Реальный прогрессъ въ языкахъ программированiя пока что происходилъ въ двухъ ситуацiяхъ. Первая ситуацiя - наличiе готовой "декларативной предметной области" съ извѣстнымъ языкомъ спецификацiй. Вторая ситуацiя - ФП, когда оказалось, что можно математически вывести новые design patterns, сформулировать и доказать правильность ихъ работы.
"Декларативная предметная область" это значитъ, что уже есть принятый и понятный людямъ языкъ, на которомъ люди объясняютъ другъ другу спецификацiи задачъ въ этой области, и этотъ языкъ однозначно и адекватно задаетъ и формулировку задачи, и ея рѣшенiе.
Два примѣра "декларативной предметной области":
1. Традицiонная запись ариѳметическихъ выраженiй. Мы пишемъ (x + y) / 2 + 1 и намъ сразу понятно, что и какъ будетъ вычислено. Когда придумали языкъ Фортранъ, гдѣ такiя выраженiя автоматически правильно компилируются, продуктивность программистовъ на порядокъ выросла. Не надо писать тесты, провѣряющiе, что мы правильно распредѣлили память или что второй знакъ "плюсъ" вычисляется послѣ дѣленiя. Мы написали выраженiе, какъ мы его понимаемъ, и все "само работаетъ". Языкъ спецификацiи (инфиксныя выраженiя съ числами и функцiями) является однозначнымъ способомъ записать и формулировку, и рѣшенiе задачи.
2. Языкъ SQL. Мы пишемъ select NAME,SALARY,DEPARTMENT from EMPLOYEES,SALARIES where EMPLOYEES.ID = SALARIES.EMPLOYEE_ID order by NAME limit 10 - и база данныхъ все сама правильно дѣлаетъ. И человѣку тоже сразу понятно, что и какъ будетъ вычислено. Когда изобрѣли реляцiонныя базы данныхъ, продуктивность программистовъ на порядокъ выросла.
Примѣры design patterns ФП -
1. Фильтрованный траверсальный функторъ-монада (filterable traversable monadic functor). Это структура данныхъ, выглядящая какъ массивъ, для котораго опредѣлены операцiи map, filter, reduce, flatMap. Методъ программированiя въ стилѣ map/filter/reduce позволилъ на порядокъ повысить производительность программистовъ. Теоретическiя свойства этой структуры описываются на языкѣ теорiи категорiй, доказываются необходимые законы, и послѣ этого программистъ можетъ быть увѣренъ, что программа, которая правильно выглядитъ ("сначала мы фильтруемъ то-то, потомъ дѣлаемъ map въ то-то и т.д."), будетъ всегда правильно работать.
2. Свободно порожденная аппликативная монада (free monad/free applicative). https://www.youtube.com/watch?v=Qg48XucSvlg Это комбинацiя свободно порожденной монады и свободно порожденнаго моноидальнаго функтора. (Эти слова мало помогаютъ понять, почему эта конструкцiя полезна, но главное, что есть четкая математическая теорiя съ доказательствомъ, что написанный кодъ реализуетъ структуру данныхъ правильно и всѣ необходимые законы выполняются.) Данная конструкцiя интересна тѣмъ, что ее изобрѣли сначала на бумагѣ, выведя правильный конструкторъ типа, и лишь потомъ написали кодъ реализацiи. Такой порядокъ дѣйствiй - сначала мы что-то на бумажкѣ вычисляемъ, и лишь потомъ начинаемъ конструировать рѣшенiе задачи - характеренъ для инженерной дисциплины. До появленiя ФП, это было невозможно - программы дѣлались чисто интуитивно, и лишь потомъ иногда доказывалась ихъ корректность.
До появленiя FP, въ трудѣ программиста не было мѣста для математическихъ концепцiй. Ни теорiя категорiй (съ функторами, монадами и естественными преобразованiями), ни теорiя логическихъ доказательствъ (изъ которой пришло Curry-Howard correspondence), ни "обычная" теорiя типовъ, ни гомотопическая теорiя типовъ не были нужны, потому что они никакъ не облегчали трудъ программиста и даже вообще не относились къ процессу написанiя программъ. Если посмотрѣть на книгу Кнута "Искусство программированiя", то она заполнена угадыванiемъ того, какъ написать программу и потомъ доказательствомъ, что Кнуту удалось угадать правильно.
Только въ FP математика реально используется для построенiя языка программированiя и для написанiя программъ. Только въ FP построенiе языковъ и программъ можно формализовать достаточно содержательнымъ образомъ, чтобы программистъ могъ думать о программѣ въ терминахъ "здѣсь у меня коварiантный функторъ - здѣсь у меня естественное преобразованiе - значитъ, тутъ тоже долженъ быть коварiантный функторъ" и создавать кодъ, пользуясь этими концепцiями.
Примѣры того, какъ не достигался прогрессъ въ языкахъ программированiя:
1. Языки, имитирующiе естественные (англiйскiй, русскiй и т.п.) Были COBOL, AppleTalk, ну и хрестоматiйное "ЕСЛИ нога поднята ТО опустить ногу ИНАЧЕ упадёшь и ВСЁ". Подражанiе естественнымъ языкамъ ничего не дало - всѣ проблемы организацiи и провѣрки правильности кода остались, кодъ сталъ существенно длиннѣе, но читать и писать кодъ проще не стало.
2. Языки, построенные полностью на какомъ-то одномъ простомъ принципѣ, выбранномъ ad hoc.
LISP - программы являются синтаксическими деревьями выраженiй untyped lambda calculus.
PROLOG - программы являются наборами Horn clauses.
Smalltalk - программы являются наборами объектовъ, посылающихъ другъ другу "сообщенiя".
Forth - программы являются наборами "словъ" стековой машины.
Языки, разработанные методомъ номеръ 2, не увеличили производительность программистовъ. Программы на этихъ языкахъ было писать не легче, чѣмъ на другихъ, кромѣ какихъ-то узкихъ классовъ задачъ, которыя случайно оказались для этихъ языковъ "декларативными предметными областями".
3. Языки, построенные методомъ встраиванiя какихъ-то (выбранныхъ ad hoc) новыхъ конструкцiй въ уже имѣющiеся языки.
Однимъ изъ одiозныхъ примѣровъ изъ прошлаго является языкъ PL/I, въ которомъ было такое число различныхъ конструкцiй, что было очень трудно сдѣлать полный компиляторъ для этого языка.
Другой примѣръ - С++ и слѣдующiй за нимъ языкъ D.
Наиболѣе одiозный примѣръ изъ современной практики - языкъ ABAP (компанiя SAP), въ которомъ за 40 лѣтъ разработки были добавлены (не какъ библiотеки, а какъ часть языка) средства работы съ очень большимъ числомъ предметныхъ областей.
https://www.cleverism.com/skills-and-tools/abap/
Въ 1990-2000 годы въ индустрiи была распространена идея, что каждая большая корпорацiя должна разрабатывать собственный языкъ программированiя, хорошо приспособленный къ нуждамъ именно этой корпорацiи. Всѣ эти языки были разработаны методомъ номеръ 3. Свои языки создали IBM, Microsoft, Sun, Oracle, Google, Facebook, а также финансовые гиганты - Bloomberg и другiе.
Проблема съ методомъ 3 въ томъ, что новыя конструкцiи добавлялись не въ результатѣ выбора какой-либо декларативной предметной области, а эвристически. Напримѣръ, добавляется спецiальное ключевое слово, означающее, что запросъ къ базѣ данныхъ будетъ выполняться асинхронно, но и только. Добавленная команда никакъ не стыкуется съ уже существующими конструкцiями языка. Средства работы съ асинхронными процессами въ результатѣ получаются совершенно недостаточными. Напримѣръ, невозможно опредѣлить, законченъ ли асинхронный процессъ. Въ языкъ тогда добавляются новыя ключевыя слова для рѣшенiя этой проблемы, но потомъ появляются новыя проблемы и т.д.
Въ результатѣ, имѣющiяся средства языка плохо сочетаются и исчезаетъ декларативность. Становится очень трудно выискивать въ кодѣ ошибки. Поскольку языкъ не слѣдуетъ какимъ-либо формальнымъ принципамъ, работа съ такимъ языкомъ сводится къ гугленiю проблемъ и тестированiю наугадъ выбранныхъ рѣшенiй.
4. Языки, построенные путемъ "упрощенiя" уже имѣющихся языковъ.
Напримѣръ, Java выбросила цѣлый рядъ возможностей C++, а языкъ Go выбросилъ цѣлый рядъ возможностей изъ Java.
Это не рѣшаетъ имѣющихся проблемъ, и въ результатѣ разработчики все равно потомъ добавляютъ одна за другой ранѣе выброшенныя возможности.