AT
Это краткий пересказ содержания основных статей и писем Э. В. Дейкстры -- для тех, кто не читал. 😉
Size: a a a
2020 April 10
AT
а ведь так было совсем недавно
Ага, всего-то 30-40 лет назад. 😊
p
Ага, всего-то 30-40 лет назад. 😊
15-20
AT
15-20
20 лет назад был 2000 год - персоналки и компьютерные классы были уже в каждой школе каждого райцентра...
VM
15-20
Нет. В 1990 учили на PC XT, СМ ЭВМ
PS
Но в компиляторах Дейкстра был не так уж хорош — что играет определяющую роль в нашем чате ;) Его компилятор Algol 60 проиграл другому компилятору (очень знаменитому!) — оказался медленнее по крайней мере на 2 порядка, и устроен был гораздо сложнее :)
"You may know that arrogance in computer science is measured in Nano-Dijkstras" (c) Alan Kay :)
"You may know that arrogance in computer science is measured in Nano-Dijkstras" (c) Alan Kay :)
p
20 лет назад был 2000 год - персоналки и компьютерные классы были уже в каждой школе каждого райцентра...
в моей вроде не было, насколько я помню
VM
А
И ещё троллил чтобы первый год к компьютеру студентов не подпускали, чтобы на бумажке всё программировали. 😄
тогда б никто до программистов и не дошел бы :)
KR
При всём уважении к опыту предыдущих ораторов и при всей моей любви к ФП, да и к железу тоже, остаюсь при своём мнении.
Моё мнение таково: основой всего и любого программирования является так называемое "алгоритмическое мышление", иначе известное как "моделирование" и "абстрагирование". Именно ему и следует обучать, поскольку именно с этим пунктом возникают самые серьёзные проблемы, при этом не только у начинающих программистов, но и у многих продолжающих.
А для того чтобы промоделировать вычислительные процессы, и, соответственно, построить алгоритмы решения каких-то "прикладных" задач, необходима модель вычислений. И именно ей необходимо обучать начинающих. Не так уж важно, что именно это за модель. Я лично считаю, что лямбда-исчисление наиболее доступно именно для непосвящённых в программирование благодаря ссылочной прозрачности и семантике переписывания, которую реально можно проводить руками на бумажке. Но машина Тьюринга тоже подойдёт, как и её вариации в виде разных упрощённых учебных процессоров. А вот реальные процессоры "замусорены" слишком большим количеством усложнений связанных с соображениями производительности и историческими причинами.
Опять же, при наличии чётко определённой вычислительной модели можно предметно говорить о корректности алгоритмов и программ. А при желании и возможности — преподавать средства доказательства корректности.
Моё мнение таково: основой всего и любого программирования является так называемое "алгоритмическое мышление", иначе известное как "моделирование" и "абстрагирование". Именно ему и следует обучать, поскольку именно с этим пунктом возникают самые серьёзные проблемы, при этом не только у начинающих программистов, но и у многих продолжающих.
А для того чтобы промоделировать вычислительные процессы, и, соответственно, построить алгоритмы решения каких-то "прикладных" задач, необходима модель вычислений. И именно ей необходимо обучать начинающих. Не так уж важно, что именно это за модель. Я лично считаю, что лямбда-исчисление наиболее доступно именно для непосвящённых в программирование благодаря ссылочной прозрачности и семантике переписывания, которую реально можно проводить руками на бумажке. Но машина Тьюринга тоже подойдёт, как и её вариации в виде разных упрощённых учебных процессоров. А вот реальные процессоры "замусорены" слишком большим количеством усложнений связанных с соображениями производительности и историческими причинами.
Опять же, при наличии чётко определённой вычислительной модели можно предметно говорить о корректности алгоритмов и программ. А при желании и возможности — преподавать средства доказательства корректности.
В таком обобщённом виде это просто расширенная функциональная грамотность - умение читать строгие тексты и непротиворечиво и строго излагать свои мысли.
К
На мой взгляд, первичен, все-таки, комбинаторный подход. Если разработчик понимает преимущества комбинаторного программирования, то, при необходимости, конкретные шаблоны проектирования (в духе монадной bind) он, походя, переизобретет, не отвлекаясь от прикладной задачи.
Для меня хорошим примером является вот эта реализация синт. анализатора Оберона: https://github.com/vladfolts/oberonjs/blob/master/src/grammar.js
Ее автор ничего не знал ни о монадах, ни о PEG, когда писал этот код. Обычный рядовой разработчик на JS. И результат он получил, исходя из собственного чувства прекрасного :)
Для меня хорошим примером является вот эта реализация синт. анализатора Оберона: https://github.com/vladfolts/oberonjs/blob/master/src/grammar.js
Ее автор ничего не знал ни о монадах, ни о PEG, когда писал этот код. Обычный рядовой разработчик на JS. И результат он получил, исходя из собственного чувства прекрасного :)
На самом деле автор терпеть не может Javascript, зато любит Haskell и использовать его подходы, программируя на С++. То есть, и о монадах он знал, когда писал транслятор, и рядовым разработчиком на Js не являлся
M
это уж точно что не рядовой разработчик JS, потому как там чисто фунциональный подход, так обычно пишут люди под долгим впечатлением от closure или haskell.
Вот как выглядит код именно JS разработчика (но в то же время знакомого с Хаскелем)
https://github.com/JSMonk/hegel/blob/master/packages/core/src/checking/index.js
Вот как выглядит код именно JS разработчика (но в то же время знакомого с Хаскелем)
https://github.com/JSMonk/hegel/blob/master/packages/core/src/checking/index.js
PS
На самом деле автор терпеть не может Javascript, зато любит Haskell и использовать его подходы, программируя на С++. То есть, и о монадах он знал, когда писал транслятор, и рядовым разработчиком на Js не являлся
Я с автором достаточно давно общался на эту тему, но хорошо помню его слова, что он этот подход для себя изобрел, о комбинаторах и PEG в тот момент не думал. Насколько я помню по Фидо, он был активен в обсуждениях Delphi :) А монад тоже в коде и близко не видно :)
К
Вполне возможно, что подход он переизобрёл, но подготовка у него была серьёзная
PS
MaxGraey
это уж точно что не рядовой разработчик JS, потому как там чисто фунциональный подход, так обычно пишут люди под долгим впечатлением от closure или haskell.
Вот как выглядит код именно JS разработчика (но в то же время знакомого с Хаскелем)
https://github.com/JSMonk/hegel/blob/master/packages/core/src/checking/index.js
Вот как выглядит код именно JS разработчика (но в то же время знакомого с Хаскелем)
https://github.com/JSMonk/hegel/blob/master/packages/core/src/checking/index.js
Ой, вот такого рода "знакомство с Haskell" бы только повредило, на мой взгляд. Ведь все очень просто, автору хорошо бы идти от существа задачи. Есть очень мощный подход: представьте, что уже имеется подходящая нотация для описания решения задачи, далее просто опишите решение. А затем реализуйте и нотацию. В данном случае выразительным описанием, очевидно, выступает грамматика в БНФ. И в дело вступают технические моменты, как грамматику выразить прямо на JS, что для этого нужно. Гораздо хуже, когда человек начинает думать в терминах шаблонов проектирования изначально. В этом смысле неважно, речь ли об ООП, или о ФП.
PS
Вполне возможно, что подход он переизобрёл, но подготовка у него была серьёзная
Я не спорю. С ним было общаться одно удовольствие. В этом смысле он как как раз отличный пример для подражания в среде оберонщиков :)
К
Верно, но роль шаблонов в данном случае в том, что если о них знать, они начинают подворачиваться под руку, пусть даже не осознанно
К
Я не спорю. С ним было общаться одно удовольствие. В этом смысле он как как раз отличный пример для подражания в среде оберонщиков :)
Он не считает себя оберонщиком, как не считают его таким те, кого он считает оберонщиками
PS
Он не считает себя оберонщиком, как не считают его таким те, кого он считает оберонщиками
Если есть возможность, просто пригласите его сюда. И, думаю, на этом его заочное обсуждение давайте прекратим :)
К
Я уже закинул Ваше сообщение в чатик, где он появляется. Если захочет - зайдёт