Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
Собственно вот – интервью Андрея Александреску от 29 января 2012: 10 Questions with Facebook Research Engineer – Andrei Alexandrescu.
На английском. Но довольно компактно и понятно. Он рассказывает о том, чем занимается в Facebook, на чем работают, каких кандидатов для себя ищут, немного о C++ и о D.
Язык D, не смотря на то, что никак не может стабилизироваться, имеет несколько интересных особенностей. Самая важная из которых, пожалуй, система шаблонов. Не могу сравнить шаблоны D1/D2 с C++11, но вот то, что D-шные шаблоны да еще в сочетании со static if мощнее тех, которые в C++03 – это точно.
Сегодня узнал о существовании проекта по написанию руководства по использованию D-шных шаблонов: https://github.com/PhilippeSigaud/D-templates-tutorial
Всем интересующихся смело рекомендую. Просмотрел по диагонали тамошнюю PDF-ку – внушаить, даже самому захотелось прочитать (но вряд ли, однако, найду время).
Еще лет пять назад, увидев вот такую тему на форуме – Будущее программирования - обсудим? – я бы с ходу достал шашку и пошел бы рубиться до потери пульса. Но сейчас я стал старый, ленивый. Просмотрел краем глаза оригинал упомянутой в теме статьи и с горечью обнаружил, что уже не цепляет. Не хочется ни спорить, ни опровергать, ни предлагать собственного видения будущего. Годы берут свое, однако :(
Ну а поскольку старческий маразм начинает маячить на горизонте, то уже можно и побрюзжать на молодежь с их оптимистично-фантастическим взглядом в будущее ;)
Во-первых, раздражает вера в то, что что-то можно тщательно спроектировать и хорошо придумать. Мол, код нужно хранить не в тексте, и даже не в (бинарном-)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-е.
Повторюсь еще раз – тот факт, что с каждым днем производится все больше и больше кода (возможно, лавинообразно больше), и именно этот код будет определять ближайшее будущее – сей факт сильно недооценивается предсказателями будущего.
Ну и, в-пятых, мне фиолетово, какое будет будущее у программирования. Изменения в нем происходят не мгновенно, а поступательно. Поэтому в наличии будет достаточно времени, чтобы перестроится.
Когда я увидел доклад с таким названием, то подумал о том, что бы включить ссылку на него в серию “Быть начальником”, особенно в виде дополнения к последней на данный момент заметке “Самомаштабирование”. Но затем я передумал. И вот почему.
На сайте конференции EXPERT Labs доступен сделанный в прошлом году доклад Славы Панкратова “Переключатель: в какой момент инженер начинает думать как менеджер?” Я его увидел только сегодня.
Просмотрел сначала слайды к докладу. Зародилось какое-то неосознанное чувство “Не верю!”
Затем просмотрел видео. И ближе к концу понял, что меня напрягало по ходу всего доклада. Докладчик не знает, что такое инженер, о чем думает инженер, что инженером руководит. Те образцы поведения “тонкой натуры”, которые приводит в своем докладе Панкратов, лично мне кажутся специально надуманными и притянутыми за уши.
Такое впечатление, что Панкратов воспринимает инженеров как неких безынициативных существ. Тогда как обязанность инженера – это принятие решений. Принятие решений связано с ответственностью и инициативой. А это уже несовместимо с той лузерской позицией, которую Панкратов приписывает инженерам (точнее говоря, неменеджерам). Вопросом “За что мне такое?” озадачиваются вовсе не тонкие натуры, и вовсе не инженеры. Такое отношение к жизни вообще, на мой взгляд, перпендикулярно выбранной профессии и занимаемой должности.
Так что доклад могу охарактеризовать всего двумя словами: херня полная. Ну либо я по критериям Панкратова уже не инженер и какой-то переключатель во мне уже щелкнул :)
PS. А первая мысль, когда я начал смотреть слайды и на первых страницах увидел перечень “достижений” докладчика была: “А почему подобные доклады читают специалисты по тренингам, а не менеджеры, отвечавшие за разработку, скажем IDEA или Visual Studio? Нет ли здесь повторения принципа: кто не может делать, тот учит?”
Наткнулся недавно на интересный ресурс – рубрику Rubies in the Rough, которая пополняется (по словам ее автора) три раза в месяц. Доступ к содержимому, как я понял, платный – вроде бы $6 в месяц. Но есть парочка статей в открытом доступе. Одну из них, The Wrong Tool for the Job, я с удовольствием прочитал. И смело рекомендую как действующим Ruby-разработчикам, так и тем, кто хочет этот язык освоить. Очень познавательно.
Продолжаем сегодняшнюю тему человеколюбия.
Нормальные почтовые программы (по крайней мере раньше) при ответе на письмо специальным образом помечали цитируемый из старого письма текст. Например, добавляя символы > в начало каждой строки, или помечая цитируемые строки инициалами отправителя.
Это было и наглядно, и удобно. Хоть с экрана ты читаешь, хоть с распечатки, хоть в продвинутом графическом интерфейсе, хоть в маргинально-аскетичном текстовом.
Но сейчас выросло новое поколение пользователей. Взращенное, полагаю, мелкомягким аутлуком. Старые добрые > в начале строк, видимо, сильно оскорбляют их тонкое чувство прекрасного. Оформление переписки так, чтобы она легко читалась даже в plain-text – это ниже их достоинства. Поэтому для разделения процитированного и собственного текста используются высокохудожественные средства – чуть-чуть отличающийся шрифт и, самое важное, цвет: чужой текст черным, собственный – темно фиолетовым. Гламурно выглядит, когда с экрана читаешь. А про то, что письма с важной информацией иногда принято печатать, да еще на черно-белых принтерах… Такое, вероятно, им в голову не может придти.
А уж про существование дальтонизма они и вовсе не знают.
Долбо*бы.
Строителям, которые зашивают внешние радиаторы отопления гипсокартоном, нужно отрезать руки.
А дизайнерам, которые это все придумывают, – головы!
Поскольку речь вновь про дартс, да еще и с фотографиями, то упрятано под кат.
Нашлось время записать некоторые впечатления от поездки. Интересующихся милости прошу под кат.