Код [программы] — компьютерная программа или часть программы: последовательность команд, данных и описаний данных, из которых она состоит.
У меня есть подозрение, что данное определение несколько устарело. Лет так на тридцать. 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 по причине необходимости переселения на другую планету.
— Все имена и совпадения в тексте случайны.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Но так ли всё плохо? Есть ли надежда на просветление? Конечно, есть. Имя этому просветлению – (кто бы мог подумать) functional programming.
Ну, ёптыть. Более забористой травы, чем FP в области программирования я пока не встречал. Кто ни попробует -- у всех бошку сносит напрочь.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Ну, ёптыть. Более забористой травы, чем FP в области программирования я пока не встречал. Кто ни попробует -- у всех бошку сносит напрочь.
Этот топик как раз о том, что не у всех и я долго не мог понять почему
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
IT>Что же изменилось внутри метода? Да почти ничего. Как и 30 лет назад мы имеем if/else/switch, несколько циклов, команды выхода из цикла и метода, операции, присваивание и ещё немного по мелочёвке.
"Мясо" все равно сейчас писать намного проще, чем раньше. Появились фреймворки и это главное. Если раньше надо было все писать самому, то сейчас можно использовать готовое.
IT>Фактически, 30 лет развитие шло только снаружи метода и сегодня мы имеем полный мыслимый набор инструментов для организации кода и управления им. По развитию снаружи метода мы уже давно вышли в космос и осваиваем другие планеты. А внутри метода? Внутри мы всё ещё в той же пещере, с тем же каменным топором в руках, что и 30 лет назад. Ни письменности, ни колеса, ни железа.
Взять например web-программирование. Тогда каменный топор — это когда html код надо формировать плюсованием строк. От этого очевидно очень далеко ушли.
IT>Много ли у нас обсуждений на тему жизни внутри метода?
Загляните в форум по .NET'у, там только такие вопросы и есть.
Здравствуйте, IT, Вы писали:
IT>Казалось бы, причём тут Немерле? А вы думали я о чём? Не дождётесь!
Почему то после прочтения первой строчки я уже в этом не сомневался.
IT> Попробуйте ответить для себя на вопрос кто вы. Представьте, что вы пишите небольшое консольное приложение строчек на 300.
Не смог. Ответить, в смысле . Пишу и то и другое одновременно.
Я так понимаю, это обещаное объяснение, почему мне не нравится Немерле? Тогда мимо. Я как раз таки очень положительно отношусь к ФП, и даже первый готов воткнуть Хейлсбергу вилку в глаз за то, что в шарпе до сих пор нет паттерн матчинга . Скептическое отношение у меня как раз таки к МП, а точнее к его реализации в Немерле.
Ну и еще, хоть я и стараюсь с собой бороться, местный неуемный немерлевый пиар, приправленный изрядной порцией демагогии, периодически переходящей в хамство, вызывает чисто инстинктивное раздражение и отторжение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, russian_bear, Вы писали:
IT>>Много ли у нас обсуждений на тему жизни внутри метода?
_>Загляните в форум по .NET'у, там только такие вопросы и есть.
Ты, ИМХО, не правильно IT понял. Он о форме, а ты о содержании.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, russian_bear, Вы писали:
_>"Мясо" все равно сейчас писать намного проще, чем раньше.
Мясо как писалось раньше на if/else/while, так и сейчас пишется на if/else/while.
_>Появились фреймворки и это главное. Если раньше надо было все писать самому, то сейчас можно использовать готовое.
Если бы фреймворки решали всё, то всё уже было бы давно написано и мы были бы без работы. Тем не менее мне почему-то приходится каждый день писать код не покладая рук.
_>Взять например web-программирование. Тогда каменный топор — это когда html код надо формировать плюсованием строк. От этого очевидно очень далеко ушли.
В ASP.NET эта проблема решается средствами метапрограммирования, конкретно precompile time генерацией. А дальше практически как ты сказал, правда не конкатенация, а вывод в stream. Но сути дела это не меняет. Придумали парни из MS DSL для типовой задачи, очень хорошо. Но как мы уже выяснили типовыми задачами жизнь не ограничивается. Почему-то работодатели когда ищут ASP.NET программиста включают в графу skills C#. А значит придётся писать ifs & whiles.
IT>>Много ли у нас обсуждений на тему жизни внутри метода?
_>Загляните в форум по .NET'у, там только такие вопросы и есть.
Дай ссылку хатя бы на один.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Фактически, 30 лет развитие шло только снаружи метода и сегодня мы имеем полный мыслимый набор инструментов для организации кода и управления им. По развитию снаружи метода мы уже давно вышли в космос и осваиваем другие планеты. А внутри метода? Внутри мы всё ещё в той же пещере, с тем же каменным топором в руках, что и 30 лет назад. Ни письменности, ни колеса, ни железа.
Внутри метода — алгоритмы. Те самые сортировки и поиски, о которых книжки пишут. А снаружи — клей и упаковка.
Граждан, способных нагородить иерархую классов, из которой, если ее нарисовать на бумажке разноцветными карандашами, можно обои сделать — пруд пруди. А много вы знаете граждан, способных написать самостоятельно RB-дерево? Или сделать недостающий в системе примитив синхронизации из того, что в системе есть? Много ли вы вообще знаете граждан, которые знают, что в системе может недоставать каких-то примитивов синхронизации?
Дело в том, что проектировать клей и упаковку фундаментально проще, чем проектировать структуры данных и алгоритмы. Кроме того, не все понимают, зачем вообще нужно проектировать алгоритмы, когда полно готовых компонент. А без клея и упаковки 30 человек не посадишь колупать одну большую программу, это же понятно. А без 30 человек ну никак невозможно наваять в срок все эти красивые всплывающие полупрозрачные окна. А без них кто же купит такую программу, только разве лохи безденежные?
Так что совершенно понятно, что архитектор, вооруженный иерархией классов, гораздо более важный для бизнеса человек, чем 30 кодеров, вместе взятые — ведь именно он соединяет их труд воедино, делая одновременно их всех взаимозаменяемыми, а себя — единым и неповторимым (это пройдет, когда изобретут метод, позволяющий засадить за один проект 30 архитекторов).
И получается печальная картина: все мечтают наслаивать классы, слой за слоем, а простую сортировку, если что, и написать-то некому.
IT>Думаю, именно в этом заключается природа предпочтений многих разработчиков. Все хотят быть архитекторами, никто не хочет быть кодером. Ведь кто такой архитектор? Это стратег, командир космической эскадры, бороздящей просторы вселенной. А кто такой кодер? Пещерный человек с каменным топором в руке, пусть даже его пещера и
Осталось еще небольшое количество просто программистов — людей, способных и разрабатывать архитектуру, и наполнять ее кодом. Но увы, это вымирающий вид...
IT>- Я знаю про F# и другие функциональные языки. Моё мнение – у них нет будущего в мэйнстриме даже на платформе .NET по причине необходимости переселения на другую планету.
Обратите внимание, что тот дикий язык, на котором в C++ пишут темплейты, тоже является функциональным языком. Причем чисто функциональным, с ленивыми вычислениями и выводом типов.
В целом совсем неплохо, но я не согласен с основным пойнтом того, что нужно скрещивать ООП + ФП и получится всемирное счастье. Попробую пояснить. Раньше я сам тоже был такого же мнения, увидев OCaml и позже Nemerle, думал как же это круто. На первый взгляд все вроде бы отлично, на внешнем более высоком уровне мы используем ООП, а внутри методов ФП. Но чем больше я стал углубляться в ФП, дошел до изучения языка Haskell. Пришел так называемый enlightment! Нет вру, он пришел позже, я все продолжал писать микс ООП и ФП, но уже начали влиять последствия изучения Haskell'а. Внутри методов я все активнее начал применять функциональную декомпозицию, создавать на месте функции, передавать их как аргумент, возвращать их как результат из функции. Таким образом я избавился от многократного дублирования кода (который я хотел кстати убрать макросами), весь объем кода уменьшился в 6-7 раз! Это все я рефакторил одну из моих подсистем. В итоге от ООП остались только описание класса и внешние интерфейсы. Все. Далее, остальные подсистемы подверглись такому же процессу рефакторинга, ну кроме мордочек.
Из всего этого вывод я делаю такой, что ООП в принципе и не нужен, ФП более чем достаточно. Ну разве, что если ООП будет средством модульности. Т.е. от ООП в классическом понимании останется совсем мало.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Много ли у нас обсуждений на тему жизни внутри метода? А чему у нас учат в вузах? Есть ли у нас хотя бы один предмет, рассказывающий как правильно писать код внутри метода? Скорее всего нет. А о чём там рассказывать? Вот и получается на уровне кода бескультурье, самопал и дурь. Но ведь это просто чудовищная несправедливость. Без кода внутри метода, без кодера программа работать не будет, точнее её просто не будет. Без внешней обвязки и архитектора хоть как-то, но можно обойтись.
Вопрос не столько в том — есть именно такой предмет или нет. Вопрос в системе подготовки программистов. В вузах элементарно отсутствуют преподаватели. Те, кто действительно что-то знает, работают в других местах. Ибо решиться получать 7..10 тыс.руб. за эту весьма тяжкую и нервную работу способны далеко не все, а альтруистов как обычно на всех не хватает.
А старые кадры (еще советских времен) — в подавляющем большинстве так и остались на уровне "времен Очаковских и покоренья Крыма". Научить ассемблеру ЕС-ЭВМ они еще могут. Те, кто продвинутей, вспомнят PDP-11. От практики такие "учителя" оторвались безнадежно (да, наверное, никогда ею и не занимались).
Отдельные вузы (наверное, штук 5-7 на всю Расею) не в счет: по большому счету они, к сожалению, погоды не делают. Вот вам и бескультурье. Добро, если начинающему программисту встретится на пути добрый человек и посоветует почитать, к примеру "Практику программирования" (Б.Керниган и Р.Пайк), "Дисциплину программирования" (Э.Дейкстра) или "Жемчужины программирования" (Дж.Бентли).
Только, боюсь, подавляющее большинство неофитов сие премудрые книжки "ни асилит" — проще ваять псевдомудреный код с кучей абсолютно лишних наворотов
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, IT, Вы писали:
IT>Этот топик как раз о том, что не у всех и я долго не мог понять почему
Наверное потому-что пару десятков лет "бошку" пытались снести на объектно-ориентированный лад. Хотя классики предупреждали:
"Object-oriented programming is an exceptionally bad idea" (Edsger Dijkstra)
"I find OOP technically unsound" (Alex Stepanov, здесь)
IMHO ФП и ООП несовместимы.
PS. Похоже в математике нет ничего, на чем могло бы основываться ООП, в то время как функциональное программирование просто пропитано идеями из математики. А ведь давно известно, что
"В каждой естественной науке заключено столько истины, сколько в ней математики" (Иммануил Кант)
Здравствуйте, Pzz, Вы писали:
Pzz>Внутри метода — алгоритмы. Те самые сортировки и поиски, о которых книжки пишут. А снаружи — клей и упаковка.
Тут надо не книжки читать. Тут надо прежде всего инструмент соответствующий. А то на while/if реализация даже простых алгритмов превращается в кошмар. А чтение того, что получилось — ещё ужаснее.
Pzz>Обратите внимание, что тот дикий язык, на котором в C++ пишут темплейты, тоже является функциональным языком. Причем чисто функциональным, с ленивыми вычислениями и выводом типов.
Здравствуйте, IT, Вы писали:
IT>Сразу хочу обозначить несколько моментов для предотвращения ненужного флейма.
IT>- Я умышленно не стал трогать МП, так эта вещь идёт в параллель с обсуждаемой темой.
Если ты имеешь в виду метапрограммировние — то очень зря его "умышленно не трогаешь".
Сила декларативного программирования (и ФП в частности) — как раз в том, что внутренности метода могут являться метапрограммой, подвергать и подвергаться разнообразным трансформациям.
Паттерн-матчинг — это очень красивый if, всё-таки.
А вот трансформирующийся код — это реально круто.
Причём необязательно прибегать к мощи языков С++, Haskell и тем более Template Haskell.
Старые добрые паттерны ООП делают немножко чудес.
Например, банальная сериализация объекта
void serialize(Archive& ar)
{
ar & m_foo;
ar & m_bar;
ar & m_buz;
}
Здесь, благодаря полиморфизму всех участников соревнования (сам объект-подлежащее, его члены, и посетитель) мы написали метапрограмму, порождающую разные способы записи и чтения (смотря какой посетитель туда придёт), а то и генерирования кода для дальнейшей записи и чтения.
Что же касается фуриков-бариков, то для кодирования прямо в методе нужен достаточно богатый и выразительный фреймворк.
Не обязательно "супер-богатый и супер-выразительный", но всё-таки достаточный.
Почему так популярен Tk во всех его портах — там уже есть все классы окон с кучей точек кастомизации (причём колбеки там на функциях, а не на интерфейсах).
Здравствуйте, konsoletyper, Вы писали:
K>Тут надо не книжки читать. Тут надо прежде всего инструмент соответствующий. А то на while/if реализация даже простых алгритмов превращается в кошмар. А чтение того, что получилось — ещё ужаснее.
Никак не могу согласиться. Одному дай топор — он комплекс в Кижах сделает, а другой — замочит кучу народа. Так же и с инструментами.
Инструмент у программиста — прежде всего голова. Когда в голове бардак, то реализация даже простейшего алгоритма будет нечитаемой. Когда голова в порядке — реализация даже сложных алгоритмов весьма хорошо читается.
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Здравствуйте, igna, Вы писали:
I>PS. Похоже в математике нет ничего, на чем могло бы основываться ООП, в то время как функциональное программирование просто пропитано идеями из математики. A Theory of Objects как теоретический фундамент не прокатит?
На citeseer есть прорва статей в которых OO выражают средствами FP.
И у небезывестного Олега что-то видел на эту тему.
Здравствуйте, IT, Вы писали:
E>>Ну, ёптыть. Более забористой травы, чем FP в области программирования я пока не встречал. Кто ни попробует -- у всех бошку сносит напрочь.
IT>Этот топик как раз о том, что не у всех и я долго не мог понять почему
В стартовом сообщении темы ты как раз и не ответил на вопрос "почему же бошку сносит не у всех".
PS. В начале 90-х в Союзе у многих крышу срывало Прологом. С тех пор я думал, что именно Пролог самая крутая трава. Но, видимо, FP еще круче.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, IT, Вы писали:
IT>Казалось бы, причём тут Немерле? А вы думали я о чём?
Если это такой чудесный и суперпродуктивный язык, то почему единственные условно известные проекты на нем — компилятор и интеграция — никак не могут дойти до версии 1.0?
Здравствуйте, IT, Вы писали:
IT>Но так ли всё плохо? Есть ли надежда на просветление? Конечно, есть. Имя этому просветлению – (кто бы мог подумать) functional programming.
Понимаете, есть один очень серьёзный камень преткновения и его имя -- деструктивные присваивания. Не знаю как вам а лично мне очень сложно обойтись без деструктивных присваиваний. Основной рабочий инструмент для меня C, но я много изучал Haskell и много пытался на нём писать. Вы когда-нибудь пробовали написать на этом языке двусвязный список например? А вы попробуйте... А потом слить два отсортированных двусвязных списка с сохранением сортировки... верёвка и мыло в магазине за углом кстати. Диссер Окасаки по чисто функциональным структурам данных на мой взгляд просто хоронит эти структуры с точки зрения практики.
Так вот любая попытка смешать снотворное со слабительным неизбежно заканчивается тем, что обычный человек в своей жизни мыслит императивно, деструктивными ходами. Типа взять ложку положить в ящик. Потом вынуть ложку положить вилку. Вам мама в детстве записки на столе наверняка оставляла. Типа возьми крупу, свари кашу, съешь её и иди в школу. Чисто императивный алгоритм. А функциональные фичи в языке требуют функциональной чистоты и высокой математической культуры (я месяц въезжал в монады и до сих пор не уверен, что въехал). Что до метапрограммирования, то напишите этот марсианский кошмар и вы увидите что его некому поддерживать.
В то же время у меня есть опыт редукции офигительной объектно-ориентированной иерархии на C++ из десятка шаблонных классов и активным использованием STL и Boost на полсотни килобайт кода в одну (!) функцию на C из сорока строчек, *не использующую даже CRT*. И я совершенно уверен из всего своего опыта -- любая "сложность" программирования на простых языках без лишних фич во многом надумана. C is really enough.
Сейчас все эти сишарпы и немерле выплывают только на растущей производительности компов, которая пока растёт быстрее чем все их сборщики мусора тормозят. Надолго ли?
Здравствуйте, igna, Вы писали:
IT>>Этот топик как раз о том, что не у всех и я долго не мог понять почему I>Наверное потому-что пару десятков лет "бошку" пытались снести на объектно-ориентированный лад. Хотя классики предупреждали:
За цитаты — респект
А вот как из процетированно следует, что I>IMHO ФП и ООП несовместимы.
неясно Или это только IMHO?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Непонятно.
Если нам не помогут, то мы тоже никого не пощадим.
Перекуём баги на фичи!
