четверг, 9 февраля 2012 г.

[prog] 10 Questions with Facebook Research Engineer – Andrei Alexandrescu

Собственно вот – интервью Андрея Александреску от 29 января 2012: 10 Questions with Facebook Research Engineer – Andrei Alexandrescu.

На английском. Но довольно компактно и понятно. Он рассказывает о том, чем занимается в Facebook, на чем работают, каких кандидатов для себя ищут, немного о C++ и о D.

[prog] Интересный документ: A tutorial on D templates

Язык D, не смотря на то, что никак не может стабилизироваться, имеет несколько интересных особенностей. Самая важная из которых, пожалуй, система шаблонов. Не могу сравнить шаблоны D1/D2 с C++11, но вот то, что D-шные шаблоны да еще в сочетании со static if мощнее тех, которые в C++03 – это точно.

Сегодня узнал о существовании проекта по написанию руководства по использованию D-шных шаблонов: https://github.com/PhilippeSigaud/D-templates-tutorial

Всем интересующихся смело рекомендую. Просмотрел по диагонали тамошнюю PDF-ку – внушаить, даже самому захотелось прочитать (но вряд ли, однако, найду время).

среда, 8 февраля 2012 г.

[prog.flame] Старческое (брюзжание на тему будущего программирования)

Еще лет пять назад, увидев вот такую тему на форуме – Будущее программирования - обсудим? – я бы с ходу достал шашку и пошел бы рубиться до потери пульса. Но сейчас я стал старый, ленивый. Просмотрел краем глаза оригинал упомянутой в теме статьи и с горечью обнаружил, что уже не цепляет. Не хочется ни спорить, ни опровергать, ни предлагать собственного видения будущего. Годы берут свое, однако :(

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

Во-первых, раздражает вера в то, что что-то можно тщательно спроектировать и хорошо придумать. Мол, код нужно хранить не в тексте, и даже не в (бинарном-)XML, а в реляционной СУБД. И если тщательно разработать соответствующий язык запросов… Откуда возьмется это “тщательно”, кто это сделает? Производство ПО – это производство, это не наука, в которой доказательство гипотезы Пуанкаре можно искать десятилетиями. В производстве любое работающее решение – это компромисс между желаемым и возможным, да еще и найденный в жестких временных рамках. И таки да, промышленно используемые языки программирования (Cobol, Fortran, C, C++, Java, C#, Perl, Ruby и пр.), страдающие целыми кучами болезней, – это как раз иллюстрация данного факта.

Во-вторых, раздражает нежелание адекватно воспринимать окружающий мир и отталкиваться от объективной реальности. История показала, что текстовое представление программ оказалось самым живучим. Не смотря на многочисленные попытки перейти от этого представления к какому-нибудь другому. По мне, так это объективный факт. Такой же, как восход Солнца на Востоке, а не на Юге. Тем не менее, не переводятся горячие головы, которые думают, что если “тщательно” подумать, то можно создать новую объективную реальность и заставить весь мир отказаться от хранения кода программ в текстовых файлах. Собственно, такое нежелание воспринимать реальность объективно проявляется не только по отношению к текстовым файлам, но и в других вопросах. Просто текстовые файлы – это очень яркий и показательный пример.

В-третьих, раздражает недооценка временности временных решений. Мол, сейчас временно есть зоопарк Web-программирования: сервер-сайд (JSP, ASP, etc) + клиент-сайд (JavaScript) + презентация (HTML, CSS). И это плохо. Но это временно, потом все будет хорошо. Или вот C++ – это плохо, это ужасный язык, он должен исчезнуть. Но временно пусть будет, а потом придет Java и все будет хорошо.

Не будет. Нет ничего более долговременного, чем временное ;)

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

Каждый день пишется все больше и больше кода. Но пишется на языках, которые применяются уже не один год – на Java, на C#, на JavaScript, на C++ и даже на Cobol. И именно это определяет ближайшее будущее. По двум простым причинам:

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

2. Программируя на конкретном языке разработчик получает опыт и наработки, которые он не захочет просто так взять и выбросить. Поэтому, если Вася Пупкин писал на JavaScript сегодня, то он продолжит писать на JavaScript и завтра. Потому что умеет, потому, что у него есть багаж знаний. Этот же принцип работает и по отношению к компаниям, которые производят ПО. Если у конторы есть N миллионов строк на Java, которые можно переиспользовать в новых продуктах, то контора завтра будет писать на Java, переиспользуя эти N миллионов строк, а не переписывая их на каком-нибудь Haskell-е.

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

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

вторник, 7 февраля 2012 г.

[work] Ознакомился с докладом “Переключатель: в какой момент инженер начинает думать как менеджер?”

Когда я увидел доклад с таким названием, то подумал о том, что бы включить ссылку на него в серию “Быть начальником”, особенно в виде дополнения к последней на данный момент заметке “Самомаштабирование”. Но затем я передумал. И вот почему.

На сайте конференции EXPERT Labs доступен сделанный в прошлом году доклад Славы Панкратова “Переключатель: в какой момент инженер начинает думать как менеджер?” Я его увидел только сегодня.

Просмотрел сначала слайды к докладу. Зародилось какое-то неосознанное чувство “Не верю!”

Затем просмотрел видео. И ближе к концу понял, что меня напрягало по ходу всего доклада. Докладчик не знает, что такое инженер, о чем думает инженер, что инженером руководит. Те образцы поведения “тонкой натуры”, которые приводит в своем докладе Панкратов, лично мне кажутся специально надуманными и притянутыми за уши.

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

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

PS. А первая мысль, когда я начал смотреть слайды и на первых страницах увидел перечень “достижений” докладчика была: “А почему подобные доклады читают специалисты по тренингам, а не менеджеры, отвечавшие за разработку, скажем IDEA или Visual Studio? Нет ли здесь повторения принципа: кто не может делать, тот учит?”

[prog] Ruby-истам на заметку: Rubies in the Rough

Наткнулся недавно на интересный ресурс – рубрику Rubies in the Rough, которая пополняется (по словам ее автора) три раза в месяц. Доступ к содержимому, как я понял, платный – вроде бы $6 в месяц. Но есть парочка статей в открытом доступе. Одну из них, The Wrong Tool for the Job, я с удовольствием прочитал. И смело рекомендую как действующим Ruby-разработчикам, так и тем, кто хочет этот язык освоить. Очень познавательно.

понедельник, 6 февраля 2012 г.

[life] Почтовое, человеколюбивое…

Продолжаем сегодняшнюю тему человеколюбия.

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

Это было и наглядно, и удобно. Хоть с экрана ты читаешь, хоть с распечатки, хоть в продвинутом графическом интерфейсе, хоть в маргинально-аскетичном текстовом.

Но сейчас выросло новое поколение пользователей. Взращенное, полагаю, мелкомягким аутлуком. Старые добрые > в начале строк, видимо, сильно оскорбляют их тонкое чувство прекрасного. Оформление переписки так, чтобы она легко читалась даже в plain-text – это ниже их достоинства. Поэтому для разделения процитированного и собственного текста используются высокохудожественные средства – чуть-чуть отличающийся шрифт и, самое важное, цвет: чужой текст черным, собственный – темно фиолетовым. Гламурно выглядит, когда с экрана читаешь. А про то, что письма с важной информацией иногда принято печатать, да еще на черно-белых принтерах… Такое, вероятно, им в голову не может придти.

А уж про существование дальтонизма они и вовсе не знают.

Долбо*бы.

[life] Морозное, человеколюбивое…

Строителям, которые зашивают внешние радиаторы отопления гипсокартоном, нужно отрезать руки.

А дизайнерам, которые это все придумывают, – головы!

[life.sport.darts] И такие робингудовские выстрелы бывают ;)

Поскольку речь вновь про дартс, да еще и с фотографиями, то упрятано под кат.