Не есть. Excel вообще больше на другую парадигму похож: dataflow programming. Интересно, что бы сделал пользователь Excel, если бы ему предложили использовать, например, свёртку. «Горы — это горы, а воды — это воды».
ДРАКОН — те же блок-схемы, вид сбоку. Я про него слышал краем уха, но он предназначен, насколько я понял, для такого традиционного структурного программирования. И он сам вроде бы язык, только визуальный :)
У меня был опыт работы с Max/MSP — тоже визуальный язык, но объектный и для работы с аудио и MIDI. С тех пор если есть выбор, писать или рисовать, я предпочитаю писать :)
DFD и ERD — это совсем другая история, они да, нужные и полезные :)
Для конкретной задачи практически всегда можно создать некую структуру из классов, которая будет отражать тот или иной аспект применения функций высших порядков — и изобразить её на UML-диаграмме. Но сам концепт представить сложно в таком виде, разве что нарисовать компилятор для функционального языка :) UML, всё же, язык объектного моделирования :)
Были попытки разработать графический язык для функционального программирования, например, тут, но, на мой взгляд, неудачные и не имеющие смысла. Тут ситуация аналогичная блок-схемам — с появлением структурного программирования они потеряли смысл, ибо сами языки были нагляднее, чем представление алгоритма в блок-схеме.
И ещё, процедурное программирование и функциональное — две большие разницы. Функциональное представляет функции как значения, за счёт этого Вы можете представить списки функций, композицию функций и прочие подобные вещи. И вообще говоря, Вы представляете решение задачи как последовательное применение функций, по сути — Вы описываете, что хотите получить.
В процедурном программировании Вы как раз представляете решение задачи как последовательность шагов, вся идея заключается в изменении состояний памяти, значений переменных и прочее.
UML же отражает сущности из другой области — он представляет классы, интерфейсы, отношения между ними — в чистом функциональном или в обычном процедурном (хотя ООП является потомком процедурного программирования) программировании этого всего нет. ООП изображает программу как передачу сообщений между объектами — это просто другая точка зрения, взгляд с другого угла на проблему.
Поэтому использовать UML и для процедурного, и для функционального программирования бессмысленно :)
«Большие дяди и здесь бывает ведут себя непонятно. Как, например, Microsoft, который внезапно, с февраля месяца этого года перестал удалять с рутрекера раздачи своих операционных систем, которые до того момента сносились с завидной регулярностью и упорством.»
До них наконец-то дошло, что если они добьются того, что их ОС можно будет купить только у аккредитованных поставщиков, их рыночная доля резко упадёт, и тогда белый пушистый зверь придёт к ним в гости. Я уверен, что лет через 5 на всех сайтах в интернете будут висеть баннеры с ссылками на бесплатную скачку последней Windows с оф. сайта этого самого Microsoft. И это будет очень хорошо, я считаю.
А вообще, идея интересная, только вот с реализацией, чувствую, возникнут проблемы…
Отличная статья! Написано с юмором и понятно.
Я бы ещё начинающим порекомендовал отличный сайт Hoogle. Здесь вы всегда можете получить справку по библиотечным функциям, очень удобно :)
Вообще говоря, некоторые подобные идеи проскальзывали у Joel'а:
«Introduction
Question about recent project candidate worked on
Impossible Question
C Function
Are you satisfied?
Design Question
The Challenge Do you have any questions?»
Я думаю, что хорошо, если кандидата попросят задавать вопросы. Но это не должно быть в начале (люди практически всегда напряжены перед собеседованием, поэтому такие сюрпризы можно делать, когда человек уже «вошёл в ритм») и собеседование не должно исчерпываться этим.
Ситуация аналогичная :) Тут ещё всё от устройства мозгов зависит. Кому-то удобно представлять задачу как набор чётко определённых для себя паттернов, кому-то — как набор процессов, кому-то — как потоки данных, ну и т.д. :)
«ведь программа хоть на Си, хоть на Хаскеле в итоге сводится даже не к ассемблеру, а к машинному коду.» — безусловно. Но мы на уровень выше этого :)
Я приведу контрпример: фраза хоть на китайском, хоть на русском в итоге сводится к одному и тому же смыслу, который понимает и китаец, и русский. Тем не менее, хотя языки позволяют выражать одно и то же, в китайской грамматике есть такие вещи, как, например, счётные слова, которые не имеют аналога в русском. А в русском есть падежи, которых, очевидно, нет в китайском. У нас та же ситуация :) Мы говорим про правильные грамматические конструкции для выражения смысла: и т.к. языки разные, грамматические конструкции меняются :)
Дело в том, что мы по разному определяем исходные понятия :) Я подразумеваю под функцией нечто оторванное от физической реализации в принципе. Когда Вам говорят о функции синуса, вы же не представляете это как ряд шагов, которые реализуют, например, подсчёт суммы соответствующего разложения в ряд? Точно так же паттерны говорят о том, как организовать объекты так, чтобы достичь некоторых свойств системы. Т.е. в случае функции в ФП мы абстрагируемся от её реализации, а в случае паттернов в ООП — мы абстрагируемся от, скажем, конкретной реализации объектов в языке или системы наследования (ну в js, например), но всё же от самого понятия объекта мы абстрагироваться не можем.
Поэтому я всё же, если говорить строго, показываю, что один из приёмов ФП можно использовать для того, чтобы достичь тех свойств системы, которые обычно достигаются путём использования паттерна.
Паттерн — это метод достижения определённой цели, ФВП — тоже метод достижения определённой цели, цели иногда отличаются, иногда совпадают, но это просто параллельные миры на одном уровне абстракции :)
Вот как можно кратко сформулировать всё то, о чём мы спорили с mokus :)
Собственно для того, чтобы избежать этого, я и привёл исследование, рассказывающее, почему же я так смело утверждаю, что к чему относится и кто кого реализует :) Но, похоже, никто не удосужился…
Короче говоря, мне надоело спорить на эту тему. Если Вы так хотите воспринимать это как реализацию паттерна — пожалуйста :) Кому-то моя статья сэкономит пару строк кода, а кого-то познакомит с весьма важными понятиями. Это уже очень много.
и использовать кортежи со строками, отражающими значения. Или даже:
Тогда можно без кортежей.
А так весьма неплохое решение.
У меня был опыт работы с Max/MSP — тоже визуальный язык, но объектный и для работы с аудио и MIDI. С тех пор если есть выбор, писать или рисовать, я предпочитаю писать :)
DFD и ERD — это совсем другая история, они да, нужные и полезные :)
Были попытки разработать графический язык для функционального программирования, например, тут, но, на мой взгляд, неудачные и не имеющие смысла. Тут ситуация аналогичная блок-схемам — с появлением структурного программирования они потеряли смысл, ибо сами языки были нагляднее, чем представление алгоритма в блок-схеме.
И ещё, процедурное программирование и функциональное — две большие разницы. Функциональное представляет функции как значения, за счёт этого Вы можете представить списки функций, композицию функций и прочие подобные вещи. И вообще говоря, Вы представляете решение задачи как последовательное применение функций, по сути — Вы описываете, что хотите получить.
В процедурном программировании Вы как раз представляете решение задачи как последовательность шагов, вся идея заключается в изменении состояний памяти, значений переменных и прочее.
UML же отражает сущности из другой области — он представляет классы, интерфейсы, отношения между ними — в чистом функциональном или в обычном процедурном (хотя ООП является потомком процедурного программирования) программировании этого всего нет. ООП изображает программу как передачу сообщений между объектами — это просто другая точка зрения, взгляд с другого угла на проблему.
Поэтому использовать UML и для процедурного, и для функционального программирования бессмысленно :)
До них наконец-то дошло, что если они добьются того, что их ОС можно будет купить только у аккредитованных поставщиков, их рыночная доля резко упадёт, и тогда белый пушистый зверь придёт к ним в гости. Я уверен, что лет через 5 на всех сайтах в интернете будут висеть баннеры с ссылками на бесплатную скачку последней Windows с оф. сайта этого самого Microsoft. И это будет очень хорошо, я считаю.
А вообще, идея интересная, только вот с реализацией, чувствую, возникнут проблемы…
Я бы ещё начинающим порекомендовал отличный сайт Hoogle. Здесь вы всегда можете получить справку по библиотечным функциям, очень удобно :)
1. Если не возводить в квадрат, а удваивать, как на Scala, то можно так:
5. Можно без map'a:
А так — круто! :)
«Introduction
Question about recent project candidate worked on
Impossible Question
C Function
Are you satisfied?
Design Question
The Challenge
Do you have any questions?»
Я думаю, что хорошо, если кандидата попросят задавать вопросы. Но это не должно быть в начале (люди практически всегда напряжены перед собеседованием, поэтому такие сюрпризы можно делать, когда человек уже «вошёл в ритм») и собеседование не должно исчерпываться этим.
Я приведу контрпример: фраза хоть на китайском, хоть на русском в итоге сводится к одному и тому же смыслу, который понимает и китаец, и русский. Тем не менее, хотя языки позволяют выражать одно и то же, в китайской грамматике есть такие вещи, как, например, счётные слова, которые не имеют аналога в русском. А в русском есть падежи, которых, очевидно, нет в китайском. У нас та же ситуация :) Мы говорим про правильные грамматические конструкции для выражения смысла: и т.к. языки разные, грамматические конструкции меняются :)
Поэтому я всё же, если говорить строго, показываю, что один из приёмов ФП можно использовать для того, чтобы достичь тех свойств системы, которые обычно достигаются путём использования паттерна.
Паттерн — это метод достижения определённой цели, ФВП — тоже метод достижения определённой цели, цели иногда отличаются, иногда совпадают, но это просто параллельные миры на одном уровне абстракции :)
Вот как можно кратко сформулировать всё то, о чём мы спорили с mokus :)
Короче говоря, мне надоело спорить на эту тему. Если Вы так хотите воспринимать это как реализацию паттерна — пожалуйста :) Кому-то моя статья сэкономит пару строк кода, а кого-то познакомит с весьма важными понятиями. Это уже очень много.