Текст книги "Редкая профессия"
Автор книги: Евгений Зуев
сообщить о нарушении
Текущая страница: 1 (всего у книги 5 страниц) [доступный отрывок для чтения: 2 страниц]
Редкая профессия
Сокращенный вариант статьи был опубликован в виде отдельной статьи в декабрьском номере журнала PC Magazine/Russian Edition за 1997 год. Статья до недавнего времени находилась в online-архиве журнала, однако была удалена (очевидно, в связи с истечением срока давности ☺).
Комментарий 2008 года
Недавно поздно вечером к нам в комнату зашел коллега, хороший знакомый, глава маленькой фирмы, «широко известной в узких кругах», устало опустился на стул и, очумело покрутив головой, проговорил:
– От заказчиков отбоя нет!..
Он поднял голову, и мы увидели в его усталых глазах удивление, смешанное с восторгом и воодушевлением.
– Работы полно, только успевай! computers Его фирма в принципе ничем не отличается от других московских компьютерных фирм, ориентирующихся на программно-аппаратные разработки, – несколько постоянных сотрудников, десяток толковых студентов, три комнаты в умирающем академическом институте и минимальный, мягко говоря, набор оборудования.
Я вспомнил этот случай, чтобы показать безосновательность сетований на упадок индустрии, невостребованность специалистов и повсеместную ориентацию на продажу готовых западных решений. Сегодня можно уверенно говорить, что неглупый инициативный компьютерщик – от студента до сорокалетнего программиста со стажем – имеет все возможности найти себе работу, соответствующую его квалификации, за вполне адекватные деньги.
Речь, однако, о другом. Разработка программного обеспечения – настолько широкая область деятельности, что человек, который действительно хорошо программирует, скажем, драйверы устройств и зарабатывает этим себе на жизнь, вряд ли сможет в приемлемый срок научиться профессионально проектировать базы данных. Исключения крайне редки. (Я не беру в расчет одержимых молодых людей, которые имеют свое мнение решительно обо всех аспектах разработки и использования ПО и пишут в своих резюме невообразимо длинный список программных систем самого разного калибра и назначения, в которых они как бы умеют работать. Речь идет прежде всего о настоящих профессионалах.) В то же время, и драйверы, и базы данных определенно относятся к программному обеспечению.
Жизнь сложилась так, что автор любит проектировать и разрабатывать компиляторы, и у него это, в общем, получается. То, что вы прочтете ниже, надеемся, подтвердит мои слова. Однако чем серьезнее относишься к тому делу, которое любишь, тем меньше времени и возможностей остается постичь что-то другое, пусть даже важное. Боюсь, ни за какие деньги я не возьмусь сейчас, скажем, за графику или разработку бухгалтерских программ – не только потому, что мне это не интересно, но прежде всего из-за невозможности достаточно быстро стать профессионалом в этих сферах.
А теперь скажите, какая софтверная специализация пользуется сейчас на рынке большим спросом: разработка компиляторов или компьютеризация бухгалтерий? Ответ очевиден. Более того, возможно, такая же картина наблюдается и на Западе. В самом деле, даже если там существует несколько сотен аттестованных компиляторов языка Ада (а это именно так), количество специалистов, их программировавших, все равно значительно меньше числа тех, кто разрабатывает всевозможные прикладные программы по заказам фирм и организаций.
На Западе, с его несоизмеримо большим разнообразием потребностей в сфере программирования, ситуация все-таки иная. Когда происходили описываемые ниже события (середина 90-х), я, скажем, не знал о существовании web-сайта http://www.compilerjobs.com/, в котором публикуется и регулярно обновляется поразительный в своем разнообразии список вакансий, связанных с разработкой компиляторов…
Комментарий 2002 года
Так что заголовок этой части имеет вовсе не хвастливый, а грустный оттенок. Разработка компиляторов – редкая профессия, но не в смысле ее дефицитности и, следовательно, высокой цены на нее. Напротив, она редкая прежде всего потому, что редко требуется и, соответственно, найти себе применение крайне трудно. Поэтому, когда все-таки появляется работодатель, предлагающий такую работу, психологически трудно еще и педантично уточнять условия вроде денег и прочего: спасибо и на том, что работа, по-настоящему интересная и приносящая радость, нужна кому-то еще!
Летает или не летает?
Я хочу рассказать о том, как мы делали компилятор Си++. Вообще-то, об этом стоило бы написать книгу – настолько эта история кажется захватывающей и поучительной, однако… будет ли это кому-нибудь интересно? Даже если коротко рассказать о наиболее существенных проблемах, с которыми мы столкнулись, трудно избавиться от мысли о, скажем, неактуальности нашего опыта в сегодняшней российской ситуации в программировании. В самом деле, посмотрите хотя бы на полки отделов книжных магазинов, торгующих компьютерной литературой. Невероятное (по сравнению с картиной 5-6-летней давности) разнообразие книг! Практически по любому программному продукту, мало-мальски используемому у нас, можно гарантированно найти по крайней мере две-три книги. Однако работ, посвященных современным архитектурам, проблемам разработки программного обеспечения, принципам построения сложных систем, таких, как компиляторы, СУБД, операционные системы, – нет. Только описания конкретных инструментов, пакетов и систем. Ситуация в некотором смысле обратная той, которая складывалась в доперестроечное время: тогда очень многие серьезные работы известных западных авторов, пусть с опозданием на пару лет, но выходили у нас. Печатались и очень неплохие отечественные книги. (И между прочим, находили спрос, и многие мгновенно становились библиографической редкостью!)
Все это определенно говорит о том, что спрос на подобного рода публикации практически отсутствует. Кому сейчас интересна проблематика разработки компиляторов, когда у любого программиста на выбор имеются три-четыре превосходных западных продукта, а наша промышленность уже давно не производит собственных компьютеров, для которых могли бы понадобиться подобные разработки?
У этих опасений есть еще один аспект. Опыт общения с западными специалистами по ПО, как достаточно известными и уважаемыми, так и рядовыми программистами, убедил в одной простой вещи: практически никому не интересны те проблемы и трудности, с которыми ты сталкиваешься в процессе реализации того или иного проекта; мало кого интересуют пути и способы их преодоления. Важен и интересен прежде всего результат! Об этом образно сказал нам один коллега, эмигрировавший в Швейцарию лет пятнадцать назад.
– Вот ваш «Буран», – сказал он (дело было больше двух лет назад), удобно расположившись в кресле на открытой террасе Политехнического института в Лозанне с видом на Женевское озеро.– Программа вроде бы завершилась единственным полетом в беспилотном режиме. Наверняка в процессе его разработки конструкторы продемонстрировали высокую квалификацию, нашли какие-то интересные нестандартные решения, придумали и отработали технологию, решили уйму проблем и т.д. и т.д. Но… – заключил он с ехидцей в голосе,– не летает! Не делает то, для чего был предназначен! А значит, и говорить о нем бессмысленно. Его нет, и это главное.
Светило ласковое солнце. Сквозь большие окна факультета информатики был виден просторный студенческий компьютерный класс, уставленный огромными цветными мониторами Sparc’ов. В сырой и холодной Москве слетавший в космос «Буран» сиротливо пристроился в парке Горького среди аттракционов. Возразить было нечего.
С тех пор в наших разговорах метафора "летает – не летает" приобрела в применении к нашему проекту почти ритуальный характер. Она не потеряла свою актуальность даже и сейчас, когда вроде бы по результатам тестирования на соответствие стандарту Си++ наш компилятор стабильно обгоняет все последние версии Watcom и транслирует сам себя почти так же быстро, как это делает Visual C++.
Компилятор "не летает". То есть не распространяется, не используется, не применяется в конкретных разработках. Почему – отдельная история.
Что нам стоит дом построить?
Однажды (около четырех лет назад) в НИИ при Московском университете, где мы тогда работали, появился высокий представительный мужчина с вальяжными манерами, окладистой бородой, большой лысиной и выразительными глазами навыкате.
Ничего удивительного в этом не было. Иностранцы посещали нашу "контору" через день, а то и чаще; каждая лаборатория либо выполняла какие-нибудь работы по западным заказам, либо изо всех сил старалась их получить. Это было тяжелое время: реальная зарплата истончалась с каждым месяцем, работы и каких-либо перспектив совершенно не было, немногочисленные предложения от государственных организаций носили отчетливый оттенок идиотизма и сиюминутности и подкреплялись безумно мизерным финансированием. Большие ЭВМ, когда-то работавшие круглосуточно и обслуживавшие весь университет, стояли; некоторым уже был подписан смертный приговор – золотосодержащие детали оказались более привлекательными, чем машинное время… НИИ медленно умирал и потихоньку пустел.
Каждому приходилось самому искать дополнительный приработок. Правда, возможности были. Преподавали в многочисленных тогда учебных центрах совместных предприятий, писали для них учебные пособия, а то и книги, подрабатывали в коммерческих фирмах. Иностранные представители, которым наш директор с гордостью показывал "компьютерный класс" с десятком тайваньских XT, вежливо выслушивали его объяснения, сдержанно кивали и фотографировали со вспышкой, словно доисторическое чудовище, карточный перфоратор Juki, стыдливо задвинутый в дальний угол. Их предложения о совместных проектах (по крайней мере, доходившие до нашего отдела) либо носили несколько авантюрный и несолидный характер, либо были откровенно неинтересны. Несмотря на трудности и безвременье, мы все-таки ощущали себя системными программистами, и как-то не очень хотелось заниматься рисованием окон и конструированием экранных форм или переводом математических библиотек с одного языка программирования на другой. К тому же деньги предлагались оскорбительно скромные.
Однако то, что говорил высокий солидный бородач (назовем его Вальтер Деккер), звучало как откровение. Предлагалось разработать (не адаптировать, не доделать, не участвовать в разработке, а самим сделать from scratch – с нуля!) компилятор (компилятор!) с языка Си++ (!) для одной европейской (для определенности пусть для бельгийской) софтверной компании! Причем не какой-нибудь препроцессор в Си, как известный cfront, а честный прямой компилятор переднего плана, генерирующий низкоуровневый промежуточный код, используемый фирмой в системе программирования, в составе которой компиляторы Си, Модула-2 и Фортран.
Следует объяснить, что автор со студенческих лет питает к проблематике компиляции языков программирования особую страсть и имел к тому времени некоторый опыт как в проектировании языков (в частности, языков дискретного моделирования), так и в реализации различных языковых систем, включая (страшно сказать) системы построения компиляторов. Этот опыт целиком относился к прежним временам, а проекты, за немногими исключениями, носили полуинициативный характер, будучи поддержанными только непосредственным начальством. Проекты не мешали текущей работе в "ящике" (правильнее сказать, текущая работа не слишком препятствовала этим проектам). Поэтому предложения бельгийца казались невероятной удачей и в то же время справедливой наградой за долгие годы верности избранному направлению.
Фирма хотя и не обладала именем, звучащим в мировом масштабе, но казалась вполне респектабельной: она существовала уже более 25 лет, что для софтверной фирмы, согласитесь, немало, участвовала в нескольких общеевропейских проектах; ее продукты (в том числе, собственная коммерческая реализация UNIX) имели не одну тысячу пользователей. Так что желание дополнить свою систему программирования новым мощным языком выглядело вполне логичным.
Любителям разгадывать псевдонимы и умолчания сказанного вполне достаточно, чтобы узнать страну, компанию, да и ее представителя.
Первый настораживающий момент (хотя то, что нам следовало тогда насторожиться, мы поняли гораздо позже) прозвучал вскоре после начала переговоров. Когда речь зашла о составе команды и предполагаемых сроках, то шеф, профессор Владимир Александрович Сухомлин, сам имеющий высокую квалификацию и немалый опыт подобных работ, не менее нашего опьяненный перспективой настоящего дела, немедленно ответил: три разработчика за один год. Сейчас мы понимаем, что здесь насторожиться следовало бельгийцам, уж конечно, прекрасно знающим, каковы реальные трудозатраты подобных разработок: не имеют ли они дело с неопытными авантюристами? Однако они просто спросили: не очень мало? Тогда шеф, сделав для солидности паузу, сказал: ну ладно, год и четыре месяца.
Однажды в эхо-конференции по языку Ада – comp.lang.ada – прозвучал вопрос от некоего молодого человека по имени Mайк Уайт. Этот замечательный парень из Массачусетса написал примерно следующее: вот на Макинтошах нет приличного компилятора для новой редакции Ады, так, может, я бы его сделал? Сколько примерно это заняло бы времени? Вопрос звучал слишком наивно, да и имя сильно смахивало на псевдоним, так что это вполне можно было бы принять за провокацию. Правда, говорят, американцы вообще довольно простодушный народ…
Что тут поднялось! Крупнейшие специалисты по языку Ада, мировые знаменитости вроде Роберта Девара всем своим весом (кто его видел, тот поймет мою иронию) обрушились на бедного Майка. "Вы сумасшедший! Вы не представляете, что такое сделать компилятор! Вы плохо изучали в университете курс по компиляции языков! Вы никогда не доведете этот проект до конца! На это требуется минимум 25-30 человеко-лет!" Тот, кажется, несколько ошарашенный этим тайфуном, растерянно отписывался: "Да… теперь я понимаю… это невозможно… лучше портировать GNAT на Макинтош… А может, мы с кем-нибудь скооперируемся и вместе все-таки попробуем?.."
Как знать, если бы этот американский Миша Белов не наткнулся тогда на столь суровую и дружную отповедь, быть может, он сейчас с парой приятелей уже заканчивал бы свой компилятор? Хорошо известно, что очень многие достойные проекты (примеры известны всем) выполнялись предельно малыми силами. И если бы мы, подобно Майку, перед тем как начать работу, спросили бы в comp.lang.cpp: друзья, а получится у нас компилятор – втроем за год?– почти наверняка получили бы аналогичный шквал критики.
Тогда мы об этом не думали. Конечно, мы знали Си++ только как пользователи, сам язык еще не приобрел своей теперешней монструозности, да и работа казалась настолько заманчиво-интересной и в то же время ясной, что инстинктивно хотелось заинтересовать собой фирмачей, не оттолкнув их слишком большими сроками. Но они-то, они – сделавшие и UNIX, и серию компиляторов, замахивающиеся на еще более амбициозные проекты, казалось, собаку съевшие на управлении программными разработками,– как они могли не насторожиться?
Они не удивились. Они сказали: "Хорошо, пишите план на полтора года".
По рукам!
У кого-то из классиков есть забавная шутка (за точность цитаты не ручаюсь, но смысл передан верно): «Системные программисты не вполне понимают, за что им платят большую зарплату: ведь они выполняли бы свою работу и бесплатно. Правда, у них хватает ума не говорить об этом своему начальству». Это очень точное наблюдение – прямо про нас, только без «большой зарплаты».
Характер условий, предлагаемых бельгийцами, был, видимо, типичен для тогдашних отношений с иностранными фирмами: они передавали нам несколько рабочих станций Sun 3/60 на процессоре Motorola 68020 (которые к тому времени уже морально устарели и самой фирмой попросту списывались) и обещали платить… не скажу сколько, но, поверьте, очень и очень небольшие деньги – даже по тогдашним российским меркам.
Вообще-то, это не очень вязалось с обликом солидной фирмы, но осознание пришло гораздо позже. Да, еще: те станции, на которых мы должны были работать, передавались нам не просто так – они шли в счет оплаты за нашу работу! Мы оказались как бы должны им, еще не приступив к делу… Впоследствии то же произошло со SparcClassic. Когда на 3/60 стало совсем невозможно работать (примерно как если на XT пытаться редактировать графические изображения), нам перевели деньги на покупку этой самой младшей модели семейства Sparc с минимальной комплектацией, внеся ее стоимость в оплату проекта.
Естественно, результат работы становился собственностью фирмы, а с нас взяли подписку о неразглашении, согласно которой в течение всего срока действия контракта мы не имели права не только говорить об условиях работы и названии фирмы, но и вообще рассказывать о том, что мы делаем. Говорят, некоторые компании оговаривают и более суровые условия: скажем, после окончания действия контракта разработчик в течение некоторого времени не имеет права работать над аналогичными проектами. Какое счастье, что бельгийцы до этого не додумались – мы бы подмахнули и такое…
Можно сколько угодно смеяться над нашей наивностью и недальновидностью, но когда вот сейчас, наяву, предлагается в точности та работа, о которой (простите за высокопарность) мечтал всю жизнь…
Кажется, мы и сейчас приняли бы подобные условия (шутка).
Глаза боятся, а руки делают
Не знаю, решились бы мы на этот проект, если бы сразу представляли (так, как знаем сейчас) его истинную трудоемкость. Тогда язык Си++, судя по учебным пособиям, казался нам… да, непростым для компиляции, с корявым и неоднозначным синтаксисом, сильно усложненной семантикой традиционных конструкций, но вполне сравнимым, например, с объектной версией Паскаля фирмы Borland. Так что срок, названный шефом, поначалу не вызвал у нас протеста. Однако чтение первой же действительно серьезной и подробной книги – перевода авторского определения языка[1]1
Эллис М., Строуструп Б. Справочное руководство по языку программирования C++ с комментариями: Пер. с англ.– М.: Мир, 1992 – 445 с., илл. ISBN 5-03-002868-4.
[Закрыть], предложенного в качестве начальной версии для его стандартизации, повергло нас в ужас и панику. Казалось, это безумие невозможно реализовать вообще! Тогда мы поняли настоящую цену учебникам типа «Язык XXX за двадцать один день» или «YYY – это просто!». Подобные тексты (сами по себе, быть может, и неплохо написанные) оставляют за своими рамками настолько обширные области языка, избегают касаться стольких его тонкостей и особенностей, что в голове у читателя-программиста формируется зачастую усеченный и выхолощенный образ инструмента, который он собирается использовать.
Вообще, у автора вызывает некоторую настороженность, когда о сложных вещах пытаются говорить упрощенно (это касается не только программирования). Задачи, решаемые современными программными системами, очень и очень сложны. Для их создания приходится использовать адекватные инструменты, которые не могут не соответствовать сложности и ответственности задач и потому объективно не могут быть простыми. Поэтому писать о Си++ в стиле "Откройте файл myprog1.cpp с компакт-диска, прилагаемого к книге, и нажмите Ctrl-F9. Поздравляем! Вы выполнили вашу первую программу на Си++!" – недопустимая профанация предмета.
С тех пор мы считаем, что настоящее пособие по сложному современному языку программирования общего назначения (уровня Си++ или Ada95) должно иметь форму, близкую упоминавшейся выше книге Эллис и Страуструпа,– комментированный стандарт. Только такая книга может дать читателю настоящее понимание языка. Да, читать и пытаться понять строгий, сложно построенный, местами даже занудный текст будет весьма непросто – но кто сказал, что профессия программиста проста? Мы обязательно сделаем такую книгу по Си++, когда его Стандарт, наконец, будет принят.
Стандарт принят в 1998 году – уже почти три года назад, а обещанных комментариев до сих пор нет… Собственно текст Стандарта я практически полностью перевел, надо бы засесть и за комментарии. Однако одному мне не справиться… Саша Кротов, где ты!?..
Комментарий 2001 года
Мы подошли к делу серьезно. Три или четыре месяца мы практически не программировали. Мы изучали Эллис и Страуструпа («Зеленую книгу») вдоль и поперек и во всех мыслимых направлениях, продумывали общую конфигурацию компилятора, выбирали построение основных структур данных и важнейших алгоритмов, предлагали и обсуждали проектные и технические решения и писали проект.
Прекрасно помню чувство гордости, которое мы испытали, увидев наглядное свидетельство наших трудов – увесистый том, привезенный Вальтером, красиво отформатированный, распечатанный на лазерном принтере (у нас их тогда и в помине не было) и даже, кажется, переплетенный. Сейчас, когда прошло уже около трех лет, очень многие наши проектные решения кажутся прямолинейными, наивными и даже неверными; некоторые пришлось менять уже в процессе реализации, но, тем не менее, проект дал необходимую основу для работы.
Этот текст, кажется, произвел достаточное впечатление на бельгийцев; они вполне убедились в уровне нашей квалификации. Тогда показалось удивительным, но некоторых простых вещей они просто не знали: например, что typedef-объявление не вводит новый тип, конструкции extern "С" могут быть вложенными и т.д. Не говоря уже о более специфических аспектах. Когда мы описывали в проекте технику компиляции вызовов, мы употребили термин «thunk» (короткий код для вычисления фактического параметра). Оказывается, они, сделавшие несколько коммерческих компиляторов, не знали, что это такое! С удовольствием и тайным злорадством я выписал из классической книги Гриса[2]2
Грис Д. Проектирование компиляторов для цифровых вычислительных машин: – Пер. с англ.– М.: Мир, 1969.
[Закрыть] и послал им большую цитату, объясняющую этот термин…
