…якобы просто «функция» чем-то отличается от «бизнес-функции».
Но ведь отличается. Бизнес-функции (деловые функции) – это подмножество функций, а именно те функции, ради которых вся система затеяна. В отличие от инструментальных функций, которые нужны не сами по себе, а чтобы обеспечить выполнение бизнес-функций.
Вдобавок, варианты реализаций через запоминание дифтонгов плохо масштабируются, если кому-либо когда-либо захочется расширить домен римских чисел сверх 5000.
Вот тут не понял. Почему они плохо масштабируются, если всё, что для этого надо сделать, – добавить числа из расширения (вместе с новыми дифтонгами) в рабочий массив?
Не имеет смысла спорить о терминах, когда проблема обозначена по существу.
Спорить о терминах не имеет смысла потому, что любое определение -- лишь способ упростить высказывание, заменив длинную формулировку коротким термином. Само по себе определение не содержит новой информации, это чисто технический приём.
Поэтому вместо спора о том, каково "истинное" содержание используемого термина, следует просто явно декларировать: "В контексте последующего высказывания (читай: обозначения проблемы по существу) я буду использовать термин <термин> в значении <формулировка>". И дальше строго придерживаться этой декларации.
В таком случае не будет иметь значения, что ваш оппонент привык называть этим термином что-то другое; не будет иметь значения даже, что есть какая-то общепринятая формулировка, отличная от вашей, -- фактически, вы просто при каждом упоминании термина неявно добавляете к нему "в том значении, которое я определил выше".
Само собой разумеется, что и ваш оппонент может сделать то же самое -- дать определение термину в контексте своего высказывания. В том числе, тому же самому термину -- здесь важно только чётко отделять, в каком именно (в чьем именно) значении термин употребляется в каждом конкретном случае. (Ясно, что таких проблем можно избежать, не используя один и тот же термин в разных смыслах, но тут уже дело вкуса).
Формально, его, наверное, можно отнести к функциональным, но выглядит он не как реализация лямбда-исчисления, а как реализация подстановок формальных арифметик
Вообще-то, он выглядит как реализация нормальных алгорифмов Маркова, что эквивалентно лямбда-исчислению.
Я тоже про это подумал, но ведь если произведение можно получить несколькими способами, то отработать надо их все. (То есть нас должно интересовать распределение не произведения, а пары множителей).
На самом деле, сама идея правильная. Напомнило "Притчу" Дейкстры. Но, конечно, в такой подаче это не уровень Хабра. (Я, признаться, в начале статьи подумал, что очевидное решение – это как раз взять произведение и один из множителей, а подвох кроется где-то в неравномерности распределения произведений).
На уровне бизнес-требований разделение на функциональные и нефункциональные не столь критично, как на уровне требований к решению. Поэтому сложилась практика, говоря о функциональных/нефункциональных требованиях, неявно подразумевать именно требования к решению.
Хотя в рамках классификации уместнее, конечно, прописать это явно.
Но ведь отличается. Бизнес-функции (деловые функции) – это подмножество функций, а именно те функции, ради которых вся система затеяна. В отличие от инструментальных функций, которые нужны не сами по себе, а чтобы обеспечить выполнение бизнес-функций.
Вот тут не понял. Почему они плохо масштабируются, если всё, что для этого надо сделать, – добавить числа из расширения (вместе с новыми дифтонгами) в рабочий массив?
Мне в этом контексте больше нравится такое:
Ага, взять под залог в долг на 10 минут, а потом не вернуть :)
Спорить о терминах не имеет смысла потому, что любое определение -- лишь способ упростить высказывание, заменив длинную формулировку коротким термином. Само по себе определение не содержит новой информации, это чисто технический приём.
Поэтому вместо спора о том, каково "истинное" содержание используемого термина, следует просто явно декларировать: "В контексте последующего высказывания (читай: обозначения проблемы по существу) я буду использовать термин <термин> в значении <формулировка>". И дальше строго придерживаться этой декларации.
В таком случае не будет иметь значения, что ваш оппонент привык называть этим термином что-то другое; не будет иметь значения даже, что есть какая-то общепринятая формулировка, отличная от вашей, -- фактически, вы просто при каждом упоминании термина неявно добавляете к нему "в том значении, которое я определил выше".
Само собой разумеется, что и ваш оппонент может сделать то же самое -- дать определение термину в контексте своего высказывания. В том числе, тому же самому термину -- здесь важно только чётко отделять, в каком именно (в чьем именно) значении термин употребляется в каждом конкретном случае. (Ясно, что таких проблем можно избежать, не используя один и тот же термин в разных смыслах, но тут уже дело вкуса).
А любые две кириллические (в верхнем регистре)?
Это цитата. Довольно известная, из "Законов Мерфи".
А в чём подвох?
Условие X
Условие Y
Условие Z.
Возможно, лучше было бы использовать в таком контексте пару "неправильно/правильно". Не дословно, зато по смыслу.
Вообще-то, он выглядит как реализация нормальных алгорифмов Маркова, что эквивалентно лямбда-исчислению.
Забыли спонсорскую ссылку вставить (шутка)
Ошибка игрока.
Согласен, с явными ветками лучше. (FizzBuzz, кстати, на мой взгляд, для этого и нужен: проверка на склонность к избыточной оптимизации).
Но всё-таки, без бинарных операций было бы, пожалуй, в рамках приемлемости.
То есть, получается, выпендрёжность здесь сводится к использованию
~nвместо-n-1Можно даже в качестве этой картинки использовать заставку самой игры. Будет ещё нагляднее.
Я тоже про это подумал, но ведь если произведение можно получить несколькими способами, то отработать надо их все. (То есть нас должно интересовать распределение не произведения, а пары множителей).
Истинно так, только, выходит, тильда там по ошибке, должен быть минус.
На самом деле, сама идея правильная. Напомнило "Притчу" Дейкстры. Но, конечно, в такой подаче это не уровень Хабра. (Я, признаться, в начале статьи подумал, что очевидное решение – это как раз взять произведение и один из множителей, а подвох кроется где-то в неравномерности распределения произведений).
Вероятно, дело в следующем.
На уровне бизнес-требований разделение на функциональные и нефункциональные не столь критично, как на уровне требований к решению. Поэтому сложилась практика, говоря о функциональных/нефункциональных требованиях, неявно подразумевать именно требования к решению.
Хотя в рамках классификации уместнее, конечно, прописать это явно.