Пионеры программирования

Дочитал книгу Федерико Бьянкуцци и Шейна Уордена с двойным названием "Пионеры программирования. Диалоги с создателями наиболее популярных языков программирования".


Книга досталась мне по символической цене в нагрузку с несколькими другими книгами, которые я заказывал в интернет-магазине books.ru. Правда цены на остальные книги и на доставку в этом интернет-магазине взлетели осенью так высоко, что я сомневаюсь, что эта книга действительно обошлась мне дёшево :)

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

1. C++
2. Python
3. APL
4. Форт
5. Бейсик
6. AWK
7. Lua
8. Haskell
9. ML
10. SQL
11. Objective-C
12. Java
13. C#
14. UML
15. Perl
16. PostScript
17. Eiffel

В этом списке меня больше всего удивило отсутствие некоторых весьма важных языков, без которых остальной список кажется неполным. Прежде всего это Lisp и Smalltalk. Кроме того, мне кажется странным, что обойдены стороной такие языки как JavaScript, Ruby, Erlang. Кстати, раз уж в книге есть C++, Objective-C, Java и C#, для комплекта стоило ещё взять интервью у авторов D.

Пожалуй большинство авторов так или иначе не лестно отозвалось о C++. Общие высказывания были в том духе, что он слишком громоздкий.

Автор Форта запомнился как несколько оторванный от жизни человек, увлечённый узким миром микропроцессоров.

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

Авторы AWK - вполне себе современная по подходам к работе команда разработчиков. Мне кажется, что в настоящее время большинство программного обеспечения разрабатывается именно такими небольшими командами, с совместной работой над кодом, подготовкой проекта и документации.

До чтения этой книги не я как-то не задумывался о том, что у языка SQL есть авторы. Почему-то казалось, что его авторы остались безвестными рядовыми сотрудниками какой-то корпорации вроде Oracle или IBM. Впрочем, видимо именно так это и есть. По своему влиянию этот язык оказал, пожалуй, даже большее влияние на отрасль прикладного программного обеспечения, чем все остальные языки. Потому что почти любой прикладной проект, сделанный для нужд бизнеса, вне зависимости от того, на каком языке он написан, использует одну из СУБД и один из диалектов SQL.

Авторы Objective-C высказали интересную мысль, которая давно вертится у меня в голове, о том, что наследование - чуть ли не лишняя концепция ООП, без которой можно обойтись в большинстве проектов, делая акцент на инкапсуляции. В этом, они, похоже вступают в спор с автором Eiffel, который кроме важности контрактного программирования заявляет о важности наследования, при чём множественного.

Автор Perl, при всём моём уважительном отношении к Perl как инструменту для быстрого решения практических задач системного администрирования, меня разочаровал. Он произвёл впечатление человека, случайно попавшего в отрасль. Часто говорил о важности контекста, так что сложилось впечатление, что он намеренно делал язык Perl как можно более запутанным. Кроме того, время от времени он переходил на тему Perl 6. Сложилось впечатление, что в Perl 6 он решил сделать разворот на 180 градусов по некоторым, чуть ли не основным концепциям.

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

Автор Eiffel рассказал о том, что использует оригинальный подход к тестированию программ. Поскольку язык концентрируется на ООП и принципах контрактного программирования, оказывается возможным создавать случайные объекты и вызывать их методы со случайными аргументами, отлавливая исключения. При этом, если исключение произошло в предусловии, значит всё нормально, т.к. в этом случае объектом или методом не правильно воспользовались. Если же исключение произошло в постусловии, значит ошибка содержится именно в вызываемом методе или объекте. Становится возможным оставить программу на тестирование на несколько часов, не занимаясь специально написанием тестов. В процессе тестирования все последовательности вызовов и их аргументы, приводящие к ошибкам, записываются, так что на их основе можно не только продиагностировать и исправить ошибку, но и добавить к программе регрессионный тест на будущее.

Большинство остальных интервью не оставило в памяти сколь-нибудь заметного следа. APL, Haskell, ML я воспринимаю как языки, оторванные от практики. UML вообще не считаю языком, а остальные языки, на мой взгляд, вполне обычные и, не обладают какой-то изюминкой, которая позволила бы отложиться им в памяти.

P.S. Кроме того, на этой неделе я дочитал, наконец "Таис Афинскую" Ивана Ефремова. Книгу я начал читать ещё в 2010 году, потом надолго отложил и дочитал лишь в течение последнего месяца.

Чед Фаулер. Программист-фанатик

Фанатизм мной воспринимается как-то отрицательно. Фанатик - это человек, который не воспринимает аргументов и слепо отстаивает предмет, фанатиком которого он является. Вряд ли я купил бы эту книгу, зная о ней только её название. Однако, я - большой любитель почитать комментарии и скорее всего я просто почитал отзывы об этой книге в каком-то онлайн-магазине и они меня убедили в том, что эта книга достойна того, чтобы её прочитать. На самом деле книга называется Passionate Programmer - страстный или пылкий программист. Впрочем, если перевести название книги именно так, многие бы решили, что книга представляет собой какой-то любовный роман о программисте :)

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

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



В среде программистов на таких людей часто навешивают ярлык "ковбой". Однако люди часто останавливают дальнейшие размышления над темой, когда они нашли подходящее слово. Если слово найдено, значит дальше думать не нужно - всё понятно. О чём-то похожем писал Фейнман в книге "Вы, конечно, шутите, мистер Фейнман!", когда рассказывал о своём отце. Люди думают, что если они знают название птицы, значит они знают эту птицу, но на самом деле они могут не знать об этой птице ничего, кроме её названия всего на одном языке. Если задуматься и попытаться осмыслить "ковбоев" как явление, то окажется, что именно "ковбои" придумали экстремальное программирование, гибкие методики разработки, скрам и непрерывную интеграцию. Это те методики, которые заявляют: "Будь мужиком, просто напиши этот код!" или, как гласит девиз Nike, "Just do it!"



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

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

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

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