Здравствуй, будущее. Прямо так и вижу, как программист, размахивая руками перед каким-нибудь кинектом, таскает подобные блоки, собирая их и составляя их в программы, а непосвященные замирают с открытыми ртами при виде такого таинства программирования.
мечты о действительно визуальном программировании («программировании мышкой») витают давно. И в частных случаях эта задача решается, с разным успехом.
У вас заход с другой стороны — при наличии программы отобразить. Но суть задачи общая — как визуальные образы использовать для каких конструкций — на мой взгляд есть смысл познакомиться с опытом «визуальных программистов», наверняка найдете интересные решения, или может быть даже просто подходы с другой стороны поможет :)
а непосвященные замирают с открытыми ртами при виде такого таинства программирования.
Ага, щас. Точно так же будет подходить начальство и спрашивать «когда». А при знакомстве, узнав что ты программист все будут точно так же с покерфейсом говорить «понятно».
Да, я с удовольствием читал, как вы учите свое дитя программированию. Удивительно, что он многое понимает. После этого ему в будущем, скорее всего, императивное программирование станет неудобным и вообще жутким.
Это не скучность, это униформность. К тому же, программа остаётся выглядеть читаемой как и была. В тех же визуализациях придётся ещё думать как будет выглядеть код.
Безусловно, униморфность — это такое большое достоинство. Но оно же и недостаток. Все равно, что играть в тысячный клон Тетриса: суть кардинально не меняется, пространство для размышлений есть, но оно всегда одно и то же.
Я вижу, что со мной не согласны, но всё же считаю неправильным всюду писать один и тот же некорректный код в качестве примера функциональщины. Зачем экономить одну строчку в ущерб корректности алгоритма?
Безусловно. В статьях о ФП и о самом языке я такого не допустил бы (да и не допустил, читайте Haskell Quest Tutorial). И в преподавании Хаскелля тоже этого не допускаю. А здесь как бы это не столь важно…
Haskell — Дизайн