суббота, 29 января 2011 г.

[life.sport.darts] Дэйв Chizzy Чизнэйл перешел в PDC

Бывший игрок BDO, Дэйв Chizzy Чизнэйл, в этом сезоне перешел в PDC. В первый раз я его увидел на Чемпионате Мира по версии BDO 2010, где он вышел в финал и проиграл Мартину Адамсу. Во второй раз его игру я посмотрел на Grand Slam Of Darts 2010, где он в первой же игре разгромил Саймона Витлока 5:1.

Сегодня Чизнэйл принял участие в первом PDC-шном турнире из серии Players Championship. Правда, во втором раунде он в упорной борьбе проиграл Винсенту ван дер Вурту 5:6, но зато сделал лег в девять дротиков!

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

PS. Кстати, на этом турнире Фил Тейлор проиграл в четвертом туре Энди Смиту. Да, не может Тейлор пока вернуть себе форму :(

PPS. Еще кстати: ван дер Вурт вышел в финал турнира, где был разгромлен Мэрвином Кингом со счетом 1:6.

[prog.thoughs] Некоторое послесловие к затянувшемуся LOR-овскому спору

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


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

Кстати говоря, уже можно наблюдать, как потихоньку императивные языки обзаводятся элементами из функциональных языков: лямбда функции в C# и C++0x, паттерн-матчинг и case-классы в гибридной Scala. Обобщенное программирование в C++, которое давным-давно существует и активно используется, так же давно переносит элементы функционального программирования в насквозь императивный, да еще и низкоуровневый язык.

C++, к тому же, является хорошим примером самого что ни есть мейнстримового и промышленного языка программирования, в котором хоть какое-то внимание уделено иммутабельности и средствам контроля за побочными эффектами – это я сейчас о const-ах и const-методах. По крайней мере, по сравнению с теми же Java, C#, Python, Ruby и даже Scala, в языке есть хоть какие-то средства контроля за модификацией состояния. А на примере D можно увидеть, как эти средства получают дальнейшее развитие – вплоть до чистых функций без побочных эффектов.

Так что я надеюсь, что в дальнейшем мейнстримовые языки (в первую очередь, наверное, C#, а так же молодые конкуренты C++, вроде Go и D) будут обзаводиться поддержкой паттерн-матчинга и каких-то более-менее мощных (по сравнению с Паскалевскими записями с вариантами) форм АлгТД. И эти средства найдут такое же широкое применение в обычных императивных языках, как теперешние switch/case (которые, надо заметить, тоже не сразу появились).

Не знаю, правда, как быстро до мейнстрима дойдут более хардкорные штуки вроде теории типов. Дойдут, наверное, в какой-то упрощенной форме лет через -надцать.


Во-вторых, проникновение ФП в широкие массы очень сильно напоминает мне аналогичное проникновение ООП, которое в своей деревне мне довелось наблюдать где-то начиная с 1994-го года, а на Западе он начался намного раньше.

По началу ООП применяло очень небольшой количество продвинутых и “рубивших фишку” программистов. Они более-менее успешно справлялись со сложными задачами и умудрялись применять ООП грамотно и по делу. Может быть потому, что у многих тогда был большой опыт обычного процедурного/структурного программирования (а у некоторых и логического, поскольку в те годы Пролог был сильно популярен на просторах СНГ). А так же чувство меры, чтобы не плести ОО-иерархии классов там, где можно было написать несколько подпрограмм.

Но потом к этому делу подключились более широкие массы. В основном, молодежь, вроде меня. У нас не было опыта в прошлом, и мы нисколько не задумывались о том, насколько новой или не новой вещью является ООП. Багаж знаний был нулевым, поэтому нам было без разницы, изучать ли ООП, или структурное/модульное программирование.

Как следствие, с ООП случился явный over-use. Наследование и полиморфизм пихали направо и налево. Если что-то нужно было написать, то писали это сразу на объектах, чтобы затем расхлебывать последствия. Даже лозунг тогда ходил – “В мире нет ничего, кроме объектов!” :) Как апупеоз этого лозунга – языки программирования Eiffel и Java, в которых даже невозможно было сделать простую свободную функцию – ее нужно было обязательно запихнуть в какой-нибудь класс.

Что случилось потом? Толстенные толмуды о том, что такое ООП и как его готовить. Паттерны проектирования. Огромное количество статей на тему ООП. Специализированные конференции и сайты. Километровые флеймы на профильных ресурсах о том, кто правильнее понимает и применяет ООП, православно ли множественное наследование и еретичны ли ромбовидные иерархии классов. После чего изрядное количество публикаций о провалах при использовании ООП, а так же серьезная критика в перемешку с жестокими личными разочарованиями. Даже ярлык начал ходить -- “ООП головного мозга” :) В итоге закономерное понимание того, что OO is not silver bullet :)

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

Но потом к этому делу подключились более широкие массы. В основном, молодежь, у которой нет большого опыта в прошлом, и которая нисколько не задумывается о том, насколько новой или не новой вещью является ФП… Далее по тексту :)

Так что лично я начинаю готовиться к эпохе FP over use, с появлением толстенных толмудов, паттернов проектирования, публикаций и многокилометровых флеймов между неофитами о православности монад и еретичности побочных эффектов :)

[life] SourceForge затеял глобальную смену паролей своих пользователей

После обнаружения атаки на SourceForge, этот ресурс организовал глобальную смену паролей для своих пользователей.

Как-то не по себе. До сих пор читал новости о взломах сайта как о пожарах где-то на другом конце Земли. А тут бах! Оказывается, что горело-то в соседнем подъезде. Неприятно.

И, главное, нафига кому-то понадобилось SourceForge взламывать? Чтобы подменить дистрибутивы каких-то проектов и, тем самым, организовать распространение какого-то вредоносного ПО? Или же просто взять и все поломать, чтобы сервисом было невозможно пользоваться?

[prog] Вышла версия 6.0.1 библиотеки ACE

Обновилась библиотека ACE – вышла версия 6.0.1, в которой исправлено несколько ошибок и добавлена поддержка MinGW с GCC 4.5.

Скачать новую версию ACE (а так же обновленные версии TAO, CIAO и DAnCE) можно отсюда: http://download.dre.vanderbilt.edu/previous_versions/

вторник, 25 января 2011 г.

[prog; work] В продолжение и вчерашней темы, и темы тестовых заданий до собеседования

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

Когда я описывал причины, побуждающие меня давать тестовые задания, то среди прочих я указывал такую: умеет ли человек критически относиться к написанному им коду. И вот последовавшее на LOR-е обсуждение моего рефакторинга отлично продемонстрировало, зачем я это делаю.

Если вы предъявляете претензии к чужому коду (речь идет об обсуждении тестовых заданий на собеседованиях), то вам необходимо указать, что именно вам не нравится и почему. Еще лучше, если вы сможете показать свой, исправленный вариант. Но, в любом случае, реакция собеседника будет либо адекватной (при этом не обязательно лояльной к вам), либо нет.

В состоявшемся флейме на LOR-е можно найти примеры и того, и другого.

Вот пример нормальной реакции, которая, однако, вам может и не понравится:

Знаешь, мне совершенно не нравится твой код. Я и сам люблю писать длинные паттерн-матчинги с большим количеством гардов и всегда предпочитаю локальные функции отдельным методам. А количество методов стараюсь всегда минимизировать. Так получается лаконичнее, декларативнее и понятнее на мой частный взгляд. И мне кажется, что Ф.П. провоцирует писать код именно в таком стиле.

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

Еще один пример нормальной реакции. Хотя этот случай сложнее, но и перспективнее предыдущего. Часть первая:

а по-моему ты сильно перебрал с количеством функций

я бы максимум согласился на дополнительные функции doAncientLogin (альтернативное название doPetrivkaLogin) и doModernLogin; опять же вполне нормальным были бы не эти функции, а просто строки комментариев перед их началом

Часть вторая:

твой стиль напоминает канцелярский слог, которых прокатывает в простых случаях, но невыносим в сложных

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

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

А перспективнее данный случай тем, что в процессе могут быть сформированы более менее четкие правила, вроде вот таких (предупреждаю, что это только пример, с которым я далеко не согласен):

1. комментарии в виде названий переменных -- нормально, хотя и малость говорливо

2. комментарии в виде названий функций -- неприемлемо

3. функция должна выделяться тогда, когда цель (или инвариант) функции достаточно далека от средства ее достижения

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

А могут (и обязательно будут) и неадекватные реакции. Вроде вот такой. За которой последует многочасовый бесплодный спор о том, что такое сайд-эффекты, откуда они взялись и куда пропали.

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

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

Однако, только в форумном флейме каждый собеседник может считать себя правым и до бесконечности отстаивать собственную точку зрения. На собеседовании ситуация чуть иная. Поскольку there are many ways to skin a cat, то встает вопрос о том, какой из ways будет считаться более предпочтительным в данной конкретной организации. И здесь ситуация как в спорте – судья может и ошибаться, но он судья и его решения неоспоримы на поле. Если соискатель не понимает этого и все равно будет защищать собственное решение не смотря на ваши доводы, то это просто показатель того, что правила игры он не будет соблюдать и в будущем.

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

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

понедельник, 24 января 2011 г.

[prog.flame] Попробую отрефакторить чужой Scala-код

На LOR-е прошло обсуждение присуждения гранта команде разработчиков Scala (об этом я уже писал). Свою лопату дерьма на вентилятор в этом обсуждении я мастерски вбросил и запасся попкорном. В процессе споров один из защитников Scala поделился с общественностью примером своего кода. Который, по мнению автора, демонстрирует преимущества лаконичности Scala вообще и повышения надежности за счет Option[T] и паттерн-матчинга.

Лично же мне кажется, что это обычный говнокод. Который я в данной заметке попробую отрефакторить. Чтобы получилось так, как привык писать я сам. И как я требую поступать от своих подчиненных. Т.е. не факт, что получится что-то принципиально иное. Но, будет оформлено более привычно для меня :)

Кроме того, в процессе упомянутого LOR-овского флейма мне стало более очевидно, почему на платформе JVM языку Scala не суждено стать мейнстримом. Надеюсь, что в конце заметки я смогу это продемонстрировать.

Букв будет много, поэтому продолжение под катом.

воскресенье, 23 января 2011 г.

[prog] Несколько ссылок на тему Real-Time Java

Началось все с того, что Алёна Сагалаева (aka Alena C++) сообщила в своем блоге об участи в подкасте некоего Радио Т. Прослушал я этот подкаст. Подивился ущербности наездов на C++ со стороны ведущих – обсуждение C++ там велось в стиле “Алёна, всем давно известно, что C++ унылое говно. Что вы можете сказать по этому поводу?” Отдаю должное Алёне, она держала себя в руках. Я бы на ее месте быстро бы перешел к ответам вроде “Уже давно очевидно, что вы дятел. Что вы можете сказать по этому поводу?”

Среди потоков феерического бреда в подкасте так же прозвучала фраза о том, что в Java есть ручное управление памятью. Из того, что я знаю про Java, ручное управление памятью там было только в Java-расширении под названием Real-Time Specification for Java (RTSJ). Помню, что на глаза попадались какие-то статьи с рассказом о том, что же RTSJ добавляет в Java в плане управления памятью. Но, как назло, ничего конкретного не вспомнил. Поэтому немного погуглил и нашел несколько ссылок. В общем, ничего серьезного, но в качестве отправной точки для заинтересовавшихся данной темой подойдет.

Во-первых, это краткий обзор RTSJ на сайте Sun Oracle: An Introduction to Real-Time Java Technology: Part 1, The Real-Time Specification for Java (JSR 1). Это очень краткий ввод читателя в тему. Вторая часть статьи лежит здесь.

Во-вторых, это интересная статья “Real-Time Java Scoped Memory: Design Patterns and Semantics” от 2004 года, в которой вопросы управления памятью в RTSJ рассмотрены более подробно, с небольшими схематическими примерами. Чем эта статья еще подкупает, так это тем, что ее писали не саночники-маркетологи, а люди, которые разрабатывали собственную real-time виртуальную машину для Java под названием Ovm. Кстати говоря, на сайте проекта Ovm достаточно много публикаций, касающихся Real-Time Java и попыток ее применения в авиации.

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

Поэтому, программировать на RTSJ, наверное, можно. Но просить за это нужно совсем другие деньги ;) На C++ может выйти дешевле :)))

Ну а в завершение ссылки на небольшие презентации на тему Real-Time Garbage Collector-ов:

Наверняка знатоку этой темы они ничего нового не скажут, но для профанов вроде меня может быть познавательно.