Из Лингвы:

Код [программы] — компьютерная программа или часть программы: последовательность команд, данных и описаний данных, из которых она состоит.

У меня есть подозрение, что данное определение несколько устарело. Лет так на тридцать. 30 лет назад такое определение было совершенно верным и отражало существующий тогда порядок вещей. Код программы действительно состоял из последовательности команд и данных, всё было предельно просто:

int Foo()
{
    return 2 * 2;
}

Что же изменилось с тех пор? Давайте посмотрим:

class Bar
{
    int Foo()
    {
        return 2 * 2;
    }
}

За 30 лет развития традиционных языков программирования (Fortran, PL/1, COBOL, Pascal, C/C++, Java, C#) принципиально изменился только мир вокруг метода. Мы получили наследование, инкапсуляцию и полиморфизм, компонентность и контрактность, шаблоны/дженерики и атрибуты, массу паттернов проектирования, подходов и отходов, методологий и прочих вещей, призванных организовать код в нечто более менее управляемое.

Что же изменилось внутри метода? Да почти ничего. Как и 30 лет назад мы имеем if/else/switch, несколько циклов, команды выхода из цикла и метода, операции, присваивание и ещё немного по мелочёвке. Было только одно существенное новшество – замыкания в C# 2.0 в 2005-м году, и те приобрели человеческое лицо только в 2008-м в C# 3.0 с введением лямбд. Может быть ещё с натяжкой вывод типов из инициализации. И это всё! Всё! За 30, блин (в грубой форме), лет!

Фактически, 30 лет развитие шло только снаружи метода и сегодня мы имеем полный мыслимый набор инструментов для организации кода и управления им. По развитию снаружи метода мы уже давно вышли в космос и осваиваем другие планеты. А внутри метода? Внутри мы всё ещё в той же пещере, с тем же каменным топором в руках, что и 30 лет назад. Ни письменности, ни колеса, ни железа.

Думаю, именно в этом заключается природа предпочтений многих разработчиков. Все хотят быть архитекторами, никто не хочет быть кодером. Ведь кто такой архитектор? Это стратег, командир космической эскадры, бороздящей просторы вселенной. А кто такой кодер? Пещерный человек с каменным топором в руке, пусть даже его пещера и находится внутри одного из кораблей эскадры. Жуткий дисбаланс. Иметь такой дисбаланс в стратегических и тактических средствах не просто глупо, а уже даже не смешно. Только представьте себе ситуацию – космический десант в виде волосатого безграмотного сброда в шкурах с каменными топорами и костяными ножами. А ведь это и есть истинный портрет современных коммандос от IT. Мы сильно преуспели в стратегии, но при этом являемся абсолютными ламерами в тактике.

В результате часто следствием такого дисбаланса становится смена приоритетов – архитектура всё, код ничто. Много ли у нас обсуждений на тему жизни внутри метода? А чему у нас учат в вузах? Есть ли у нас хотя бы один предмет, рассказывающий как правильно писать код внутри метода? Скорее всего нет. А о чём там рассказывать? Вот и получается на уровне кода бескультурье, самопал и дурь. Но ведь это просто чудовищная несправедливость. Без кода внутри метода, без кодера программа работать не будет, точнее её просто не будет. Без внешней обвязки и архитектора хоть как-то, но можно обойтись.

Но так ли всё плохо? Есть ли надежда на просветление? Конечно, есть. Имя этому просветлению – (кто бы мог подумать) functional programming.

Как это ни странно, но всё это время, в отличии от традиционных языков программирования, развитие на планете FP шло по пути наращивания возможностей внутри функции и манипуляции функциями. В результате было наработано множество техник и паттернов не относящихся напрямую к FP: pattern matching, algebraic types, tuples, type inference, immutability. Всё это спокойно можно использовать вообще без знания, что такое функция высшего порядка. Более того, если попытаться применить FP в традиционном программировании, то окажется, что и ФВП и любые другие возможности FP вообще никак не конфликтуют ни с ООП, ни с АОП, ни с компонентностью, вообще ни с чем. Причина в том, что они применимы и улучшают жизнь внутри метода, практически никак не проявляя себя и не влияя на то, что происходит снаружи, что отлично демонстрируется новыми возможностями C# 3.0.

Казалось бы, причём тут Немерле? А вы думали я о чём? Не дождётесь!

Немерле – это удачная попытка совмещения традиционного программирования и FP. Практически все, что наработано в FP поддерживается в Немерле и уже сейчас готово к использованию. Можно отложить в сторону каменный топор (if/else) и взять в руки охринительной мощности базуку (match). Кривизну out/ref параметров можно заменить на tuples, а зоопарк из приватных методов на удобные локальные функции. Много чего. И главное больше нет необходимости компенсировать скудность тактических средств стратегией.

Это путь в другой мир, в другую жизнь внутри всё того же метода. Примерно как разница между структурным C и современным C# с точки зрения организации архитектуры приложения. Вспомните, как вы изучали ООП или COM/компонентность, точно так же и здесь напрочь рушатся устоявшиеся представления о существующем порядке вещей. Код, получив стероиды от FP, становится мощнее, выразительнее, компактнее, понятнее и интереснее одновременно. Здесь есть куда приложить мозги и есть от чего получить эффект. Кодер здесь уже не троглодит в поеденной молью шкуре, а боец спецназа в нано-костюме из Crysis , способный в одиночку выполнять самые сложные задания.

Впрочем, это всё лирика. На практике получается, что код внутри и снаружи – это два разных кода, два мира, внешний и внутренний. Это хорошо видно при рефакторинге, когда код алгоритма не трогается, но его компоновка полностью меняется. Из этого, кстати, напрашивается ещё один вывод.

Людей принято делить по темпераменту на сангвиников, холериков, флегматиков и меланхоликов. Программистов можно условно поделить на (в примере выше я назвал метод Foo, а класс Bar) фуриков и бариков, на тех, чей код растёт из методов и тех, кто проектирует приложение от иерархий классов. Попробуйте ответить для себя на вопрос кто вы. Представьте, что вы пишите небольшое консольное приложение строчек на 300. Я – однозначно фурик. Я сразу начну писать код прямо в методе Main и только когда почувствую дискомфорт, озабочусь иерархией классов. Делать это сразу я не стану, т.к. считаю это бесполезной тратой времени, потому что не знаю, что меня ждёт впереди. Потом, если понадобится, будет всё, и иерархии, и паттерны, и компоненты. Но это потом, а пока главное – код, главное – функционал.

Смею предположить, что именно поэтому Немерле произвёл на меня столь сильное впечатление. И, наоборот, для бариков все эти фенечки вторичны. А мега-архитекторам так вообще глубоко до лампочки. Представим себе такого условного мега-архитектора. Вот взял он Немерле, покопался в нём и ничего интересного для себя не обнаружил. И правильно. Ведь с точки зрения архитектуры приложения в целом Немерле не привносит ничего нового. Вообще ничего. Все фичи на уровне методов, а методы у нас удел кодеров, затупятся каменные топоры, настругают ещё. В общем, нафига такой козе такой баян? Непонятно.

Собственно, всё. Теперь можно и пофлеймить

Сразу хочу обозначить несколько моментов для предотвращения ненужного флейма.

— Я умышленно не стал трогать МП, так эта вещь идёт в параллель с обсуждаемой темой.
— Я знаю про F# и другие функциональные языки. Моё мнение – у них нет будущего в мэйнстриме даже на платформе .NET по причине необходимости переселения на другую планету.
— Все имена и совпадения в тексте случайны.