[prog] О сложности ООП

В продолжение вчерашних тем (#1, #2).

Когда-то давно мне попадались статьи, в которых ООП рассматривалось с научной точки зрения. Какая-то теория навешивалась на ООП, какая-то формализация. Поскольку с теориями дело у меня всегда обстояли неважнецки, то такие статьи просто проходили мимо меня.

А вот одна из них, на которую дали ссылку в той же дискуссии, просмотренная сегодня утром, позволила мне четко осознать, что я всегда рассматривал ООП не как проявление какой-то теории, а как набор инженерных приемов, облегчающих выполнение конкретных действий. Не более того.

Чтобы проиллюстрировать, что такое удачные инженерные решения, я приведу пару цитат из книги Руала Амундсена “Южный полюс”.

Цитата первая:

     Патентованная дверь палатки была обычной модели -  мешком;  теперь  она считается единственно применимой в полярных областях.
     Патент этот чрезвычайно прост, как  и  вообще  все  патенты,  годные  к чему-нибудь. В палатке вырезывается отверстие нужных размеров.  Затем  берут мешок, открытый с обоих концов, и один конец его плотно пришивается к  краям отверстия в палатке. Ход через второе отверстие мешка и  будет  единственным входом в палатку. Когда влезают в палатку, то собирают открытый конец  мешка и завязывают его как всякий мешок, В палатку со сплошным дном и таким входом не попадет ни единой порошинки снега даже в самый сильный буран.

Цитата вторая:

…Устройство двери тоже  заслуживает  упоминания.  Есть  много  людей, которые, невидимому, никогда не могут научиться закрывать  за  собой  дверь. Где соберутся двое или трое, там найдется по меньшей мере  один,  страдающий таким недостатком. Тем более здесь, где нас было девять человек.  Бесполезно просить человека, страдающего этой "болезнью", закрывать за собою дверь.  Он все равно не сможет этого выполнить. Я еще недостаточно хорошо был знаком со своими спутниками, чтобы знать, как у них обстоит дело по этой части, но для большей верности мы, на всякий случай, сделали самозакрывающуюся дверь.
     Эту работу выполнил Стубберуд, укрепив дверную раму в стене в наклонном положении. Совершенно так, как устраивается у нас в Норвегии вход в  погреб. В  таком  положении  дверь  не  может  стоять  открытой,   Она   обязательно захлопывается сама собой. Я очень обрадовался, когда ее навесили.

В общем, мне удобнее считать, что основные принципы ООП – инкапсуляция, наследование и полиморфизм – в языках программирования появились сначала именно как подобного рода инженерные приемы. А уже потом их попытались впихнуть в какую-то стройную научную теорию (да, я представитель воинствующего невежества ;)

Поэтому не случайно, что Modula-3 у автора упомянутой выше статьи, Луки Карделли, таки не взлетела. В отличии от SmallTalk-а у Кея, C++ у Страуструпа и Java у Гослинга.

PS. Кстати говоря, книга Амундсена мне в свое время очень понравилась. Из нее хорошо видно, что покорение полюса было очень тщательно проработанной операцией, а вовсе не авантюрным приключением.

[prog.idiotic] В ненависти к ООП можно дойти до маразма

Свежий, совершенно фееричный комментарий к уже упомянутому мной обсуждению. Читать его можно и целиком, но я выделю самый яркий фрагмент:

я могу понять привлекательность желания вместо одного модуля нагородить гору "стандартных" паттернов, реализующую тот-же функционал. но всеж стоит по-моему четко говорить что это делается из-за денег а не из-за какой-то особенной "правильности" ООП подхода? нету ее. просто менеджерам удобнее властвовать над толпой индусов. не надо говорить что эта куча будет более безошибочна чем один модуль. просто ошибки будут лучше скрыты от глаз в структуре зависимостей. неконтролируемой кстати ничем.

Долбоебизм на марше, одним словом.

Похоже, нужно вводить какой-то отфильтровывающий барьер. Например, если человек не прочел первую треть книги “Объектно-ориентированное конструирование программ” Бертранда Мейера, то с ним об ООП можно даже не разговаривать.

[prog.work.flame] Следуя правилам чужого блога

выношу продолжение дискуссии к себе, чтобы иметь возможность ответить на заданные мне вопросы.

Первая ветка обсуждения, начатая здесь, пришла к такому итогу:

• thesz: Я думаю, что на Cobol нет интересной работы. Как её скоро не будет и на ООП.
• eao197: На примере недавней вашей вакансии в ПроСофте видно, что интересная с вашей точки зрения работа не способна заинтересовать толковых разработчиков материально. Более того, сам факт вашего ухода из ПроСофта демонстрирует, что инересная работа вне ООП не интересна даже вам самим.
  
  Поэтому ваши фантазии не тему будущих перспектив ООП, полагаю, имеют мало общего с действительностью.
• thesz: Как вы думаете, сколько я получаю сейчас? Как выдумаете, насколько интерена работа, которой я сейчас занимаюсь?
  
  Вообще, создаётся впечатление, что вы принимаете возможности конкретного работодателя за неотъемлемые свойства определённого рода работ. То есть, путаете существенные и несущественные свойства.

Отвечаю следующее:

Не суть важно, сколько вы сейчас получаете и насколько вам интересна ваша нынешняя работа. Я не находил интересным ни то, чем вы занимались в ПроСофте, ни размер зарплат, который там предлагался. Я не нахожу интересным то, чем вы занимаетесь сейчас. Это означает, что отношение к работе у нас с вами совершенно разное. И тот факт, что ПроСофт не смог быстро закрыть вакансию Хаскель/C# разработчика дает мне основание полагать, что мое отношение к работе, несколько ближе к “среднему по больнице”, чем ваше. Посему и к вашим прогнозам на будущее я отношусь более чем скептически.

Вторая ветка, начатая здесь, пришла к такому итогу:

• eao197: Тот, кто поносит ООП не сможет применять ООП успешно. Тем самым, он будет работать хуже, чем тот, кто относится к ООП спокойно. Чем больше будет тех, кто работает хуже, тем более востребованны будут те, кто работает лучше.
• thesz: Это очередной логический скачок.
• eao197: Это не скачок, это наблюдение. Не доводилось видеть, чтобы люди достигали успеха используя инструменты, которые им не нравятся до такой степени, что они называют их говном.
• thesz: Вот именно. Успеха добиваются, используя полезные и приятные инструменты. Это не отменяет способности применять инструменты, который применяющий считает... удобрением.
  
  Так что у вас налицо скачок в рассуждениях. Это не может быть закрыто "наблюдением".

Отвечаю следующее:

Мои наблюдения не отрицают возможности/способности успешно применять инструменты, которые очень сильно не нравятся. Мои наблюдения говорят лишь о том, что если это и происходит, то настолько редко, что можно не принимать этого всерьез.

Ну и еще раз, чтобы дважды не вставать, объясню свою фразу “Радует число людей, которые считают ООП говном. Чем больше вас будет, тем сложнее будет остаться без работы.” (хотя считаю, что лучше всего она объясняется байкой с bash-а). Для этого отошлю читателей к своей же заметке, ко второй ее половине, начинающейся с абзаца:

В-четвертых, раздражает непонимание того факта, что завтрашнее будущее программирования определяется вовсе не тем, что сегодня выдумывают ученые в области computer science. Т.е. то, чем обычный разработчик будет заниматься, зависит не от сегодняшнего state of the art, а от того, на чем начали писать очередную промышленную систему вчера, если не позавчера.

ООП стало тем подходом, который позволил существенно снизить сложность разработки ПО в 80-х и 90-х годах прошлого века. И свою актуальность ООП сохраняет до сих пор.

Если какие-то горячие головы сегодня отрицают ООП, обзывая его говном, или переписывают работающие куски кода “без ООП”, то это мне напоминает попытки поссать против очень сильного ветра. Пусть пытаются. Пусть и дальше отрицают. Пусть не учатся использовать ООП и пусть не пробуют делать большие системы с использованием ООП. Чем больше таких разработчиков будет, тем ценнее окажутся те, кто способен будет сопровождать и развивать то, что уже сделано вчера и то, что делается сегодня. И даже если это не кажется интересной работой, то это все равно работа, которую нужно делать. И которая оплачивается вовсе не из соображений “интересна/не интересна”.

[work.book.humour] Прочитал “Повадки обезьян”

К сожалению, не читал эту книгу раньше, но лучше поздно, чем никогда.

Очень понравилось. Местами весьма характерное поведение.

PS. Я не нарочно такой лаконичный отзыв написал, чесслово ;)

[life.humour] И что же гласит закон?

Или он просто гласит? Ну гласит себе и гласит ;)

[prog] Нашел баг в OTL

Некоторые 32-битовые ODBC-драйвера (например, производства Oracle) не поддерживают 64-битовых целых чисел (т.е. не могут работать с bigint-ами). В библиотеке OTL для таких случаев есть обходной маневр: группа макросов OTL_BIGINT, OTL_BIGINT_TO_STR и OTL_STR_TO_BIGINT. Если их должным образом определить, то OTL автоматически заменяет работу с 64-битовыми числами на работу с их строковыми представлениями. И приложение даже не замечает, что ему приходится работать с ущербным ODBC-шным драйвером.

К сожалению, в версиях OTL до 4.0.257 включительно, комбинация из OTL_BIGINT/OTL_BIGINT_TO_STR/OTL_STR_TO_BIGINT и OTL_ODBC/OTL_ODBC_MULTI_MODE не обрабатывалась должным образом. Не производилось преобразования чисел в строку и обратно.

К счастью, OTL – это OpenSource-библиотека. И хотя там достаточно своеобразный подход к организации кода (вся библиотека – это один большой h-файл), но удалось весьма быстро найти как причину проблемы, так и способ ее устранения.

Сразу же после этого описание найденной ошибки были отправлены автору библиотеки, Сергею Кучину, который уже опубликовал версию 4.0.258 с исправлениями. За что ему респект и уважуха!

PS. Все-таки библиотеки с полными исходниками есть рулез! :)

PPS. А по поводу качества Oracle-вских продукт пердело поделок я еще скажу пару ласковых.

[prog] ICU 49 Released

Вышла версия 49 (или 4.9, если следовать старой системе нумерации версий) большой библиотеки ICU – инструмента для работы с Unicode и другими связанными с интернализацией (i18n) вещами (числами, датами, текстами, регулярными выражениями и пр.).

Загрузить можно отсюда: http://site.icu-project.org/download/49

Тем, кто не знаком с ICU, можно заглянуть сюда: http://userguide.icu-project.org/

Список изменений весьма большой:

Common Changes

• Unicode 6.1: New scripts & blocks; changes to grapheme break & line break property values; some characters change from symbol to Po or No; etc.
• CLDR 21.0.1: Changes in segmentation data to match Unicode 6.1; new structures for support of Chinese calendar, for context-dependent capitalization, for gender of lists of people, for ordinal categories, and for multiple number systems per locale; deprecation of "commonlyUsed" element in timezone names; removal of "whole-locale" aliases; major cleanups of timezone names, delimiter data, abbreviated number data.
• Normalizer2 API additions
  • Easier-to-use getInstance() variants; e.g., getNFDInstance() (#8246)
  • Getter for the combining-class value for a code point (#8606)
  • Getter for the raw Decomposition_Mapping (#8804)
  • Pairwise composition (#8804)
• TimeZone class: (C++) Getter for unknown time zone, (Java) fields for GMT & unknown zone (#8779)
• Support for deprecation of the "commonlyUsed" element for CLDR metazones (#8811)
• DateTimePatternGenerator can now use separate patterns for skeletons that differ only in MMM vs MMMM or EEE vs EEEE,  etc. (#7930)
• Support for custom DecimalFormatSymbols in RuleBasedNumberFormat (#8940)
• Format and parse Chinese calendar dates including support for intercalary months (#8958, #8959, #8977)
• Context Transforms for context-dependent capitalization behavior (#9110)
• APIs for TimeZoneNames and TimeZoneFormat (#8512, #8513)
• Support for new date format pattern "ZZZZZ" for ISO 8601 zone format (#9045)
• Options for ambiguous local time resolution in Calendar (#8916)
• Support for ISO 4217 numeric currency code (#7964)
  

ICU4C Specific Changes

• One platform.h file used on all platforms now (#8452)
• Smaller binaries with static-linked ICU (#8453)
• Explicit constructors in UnicodeString (#7877)
• Option for not including utf headers (#8575)
• Added function u_printf (#8579)
• C++ namespace support (#8680)
• DateFormat/SimpleDateFormat format/parse const methods are really const now (#8844)
• Service Provider: link against multiple ICUs, access using just locale ID for collation and date formating services (#8157)

PS. Сам я ICU не использую, но за развитием подсматриваю :)

[prog.crypto] Склерозник: godzilla crypto tutorial

Когда-то давным-давно, когда пришлось познакомиться с SSL и основами криптографии, наткнулся на интересный ресурс: домашнюю страничку Питера Гатманна (Peter Gutmann).

Помимо прочего он написал и выложил в сеть большой набор PDF-ок со слайдами на тему информационной безопасности и криптографии: godzilla crypto tutorial. Помнится, я почерпнул оттуда много полезного. Так что с удовольствием рекомендую.

Кроме того, Питер разработчик большой C++ной библиотеки cryptlib. Сам я ее не применял, но в свое время смотрел. Мне она тогда понравилась больше, чем OpenSSL. (Интересующиеся так же могут глянуть на Crypto++ и Botan).

PS. Давно уже не занимался ничем, связанным с криптографией. А тут вдруг случайно наткнулся на собственный текст с упоминанием этих ресурсов и решил занести их в склерозник, на всякий случай.

[prog.work.idiotic] Решение кадрового кризиса в РБ: перекуем бухгалтеров на программистов!

Ув.тов.Сергей Галичанин поделился ссылкой на статью: Силиконовая Белоруссия. Один фрагмент оттуда особенно доставил:

Остроумную идею решения кадровой проблемы предложил глава компании Бел-Хард Игорь Мамоненко: он считает, что бухгалтеры могли бы переучиться на программистов - как когда в перестройку инженеры переучивались на бухгалтеров. А для этого надо всего-навсего упростить налоговое законодательство и систему бухгалтерского учета - не только для программистов, но и для всех:

"Если мы возьмем любого бухгалтера, то, во-первых, он уже умеет работать на компьютере, - говорит Мамоненко в интервью изданию "Компьютерные вести". - Второе: ему свойственны, так сказать, качества прецизионности. То есть он не делает ошибок в цифрах. Он умеет работать с программным обеспечением. Сейчас, по данным Всемирного банка, в Беларуси у фирмы на бухгалтерский учет уходит в среднем 900 часов в год. Средняя цифра по миру - 160 часов. А в Объединенных Арабских Эмиратах вообще уходит 12 часов. Поэтому если мы время на бухгалтерию сократим хотя бы в пять раз, то от 400 тысяч бухгалтеров мы оставим 80 тысяч.  А 320 тысяч человек у нас высвободятся. Конечно, это не должно произойти одномоментно - мы рассчитываем примерно на пять лет. То есть специалисты будут постепенно высвобождаться из бухгалтерской сферы, сфера образования их будет "подхватывать". Также никто не спорит с тем, что предоставление льгот привлечет в Беларусь всех мировых лидеров в области IT-образования".

Мамоненко считает, что, если этот проект удастся, переученные бухгалтеры смогут приносить в страну около 7 миллиардов долларов в год:  "Если 150 тысяч индусов в одной компании зарабатывают 10 миллиардов долларов, то почему 300 тысяч белорусов не могут заработать 7 млрд? Мы просто умножили 300 тысяч человек на 15 долларов за человеко-час и отняли 20 процентов, традиционно приходящиеся на время отпусков и учебы".

Ну просто неисчерпаемый источник ресурсов для подготовки программистов – целая армия бухгалтеров. И правда: на компьютере работать уже умеют, остальному быстренько доучим :)

Почему я прикалываюсь. Потому, что, по моему мнению, успешно переучится на программистов сможет только некоторый процент бухгалтеров. И, вполне возможно, что этот процент будет таким же, как если в программистов начнут переучивать маркетологов, логистов, экономистов и т.д. Поскольку для программиста нужен определенный склад ума*, а не умение не делать ошибок в цифрах.

* Тема эта провокационная и я о ней зачастую думал в прошлом. В результате для себя пришел к выводу, что для успеха в программировании человек должен уметь разбивать операции на (почти бесконечную) последовательность элементарных шагов (алгоритм). Например, “открыть дверь” – для обычного человека это простая операция: взялся за ручку и потянул. Тогда как программист вынужден разбивать ее на большее число действий, которые “подразумеваются” – подойти к двери, поднять правую руку, взяться правой рукой за дверную ручку, потянуть на такое-то расстояние, переместить правую руку, потянуть дверь еще на какое-то растояние… В общем, как музыкантам нужен слух для того, чтобы обучаться музыке, так и программистам нужна вот такая вот врожденная способность, чтобы учиться разрабатывать ПО. И, как в случае с музыкальным слухом, эта способность есть не у всех. Хотя она, в какой-то степени, может быть развита. Причем, в отличии от слуха, довольно сильно развита. Особенно если у человека есть способность четко ставить цели, ранжировать их по приоритетам и обеспечивать их достижение… Но это уже разговор зашел о менеджменте ;)

[life.work] Когда читаю такие поучения…

Вот такие (тема уже древняя, но такие персонажи на профильных форумах раньше появлялись регулярно, не исключено, что и сейчас где-то кого-то “лечат”):

Нет у меня ни времени ни желания писать полноценную статью, поучать кого-то. Не люблю учить людей жить. Предпочитаю смотреть, как они наступают на грабли, а потом с умным видом критиковать с безопасного расстояния за очевидные ошибки.

Кроме того, я далеко не уверен, что молодёжи есть смысл идти вообще в IT. Есть гораздо более перспективные для карьеры направления. Но если уж решено идти в IT — то потребуется очень многое. В ближайшее же время потребность в низкоквалифицированных кадрах может резко упасть — технологии на месте не стоят, и подай-принесиев очень эффективно заменяет автоматика. Тот, кто хочет оказаться на вершине пирамиды, кто хочет быть мастером, тому потребуется:

— фундаментальное математическое образование, включая все теоретические основы computer science.

— широкий кругозор и неплохая гуманитарная база, ведь работать ему предстоит с людьми. Подай-принесий может уткнуться в компьютер и кодить, предоставив право принимать решения и управлять более умному, опытному и социально приспособленному, находящемуся повыше него на социальной лестнице. Но мастер ближайшего будущего себе такое позволить уже не сможет. Так что учите дети психологию, учите языки запоем, классическую и современную литературу и живопись, и конечно же историю и социологию. Пригодится ВСЁ.

— умение работать руками. Кто в детстве не играл фанатично с конструкторами — может заранее сам себя отсеять. Модульные встраиваемые архитектуры будут доминировать, и приличная инженерная смекалка и хотя бы минимальное отсутвие криворукости — обязательное требование. Так что, в перерывах между штудированием Цицерона и Сенеки и решением задач по комбинаторики и теорверу, надо браться за паяльник, и творить. Для души.

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

— как это ни банально, но требуется хорошее здоровье. Да и бессонные ночи даром не проходят. В общем — спорт, и ещё раз спорт. Только не тяжелая атлетика и не бокс, конечно же.

Всё это — лет 7-8 после школы. Минимум. Да вы, детки, не пугайтесь — врачи — так те и вовсе, пока не начнут собственно карьеру, учатся более 10 лет. И не жалуются. Радуйтесь, что они так долго учатся — иначе на кладбищах место быстрее кончалось бы. А ведь ответственность компьютерщика часто не меньше чем у врача. Только оплачивается, бывает, существенно лучше.

Итак, отучились мы, сверкаем эрудицией, за плечами не один десяток самостоятельно выполненных учебных проектов во всех отраслях индустрии — можно теперь и о карьере подумать. Все дороги открыты. Такой специалист может делать всё, что хочет, и там, где ему будет угодно. И когда подай-принеси сядут на свой разнесчастный велфер, с тоской вспоминая времена, когда за примитивную работёнку можно было до $6k в месяц взять — они, мастера, будут тащить цивилизацию вперёд, поднимаясь всё выше и по социальной лестнице.

И вот еще оттуда же, феерическое:

К 30 в IT надо бы получать дивиденды, а не зарплату.

Так вот, когда читаешь такое, то очень хочется набить автору сих поучений морду. Тупо и незамысловато, но качественно и основательно, до стертых в кровь кулаков. Ибо уровень высокомерной спеси и самодовольства+самолюбования в таких высказываниях просто зашкаливает.