Мир разработчиков программного обеспечения разделен на два лагеря. Знатоки языков поют дифирамбы мощи высокоуровневого программирования — функциям высшего порядка, метапрограммированию, аспектно-ориентированному программированию, рефлексии и т.д. Знатоки инструментов имеют хорошие навыки использования утилит для сборки и отладки, документирования и автодополнения, рефакторинга и тестирования. Знатоки языков склоняются к использованию для разработки текстовых редакторов типа emacs, vim или подобных — они хорошо подходят для почти любых языков, включая новые. Знатоки инструментов выбирают IDE, такие как Visual Studio, Eclipse, или IntelliJ, включающих в себя целые наборы специализированных средств разработки.
Новые языки программирования, такие, к примеру, как Laszlo или Groovy, и новые расширения языков, такие как AOP, обычно доступны только для использования средствами универсального текстового редактора, пока не получат полноценную поддержку в какой-нибудь IDE. Спустя какое-то время, если язык действительно «выстрелил», эта поддержка, несомненно, появится. Это происходит не потому, что сделать нужный инструментарий слишком сложно. Это происходит потому, что вложение усилий в разработку языка и вложение усилий в разработку средств для него находятся в несколько ортогональных плоскостях и порой даже вытесняют друг друга. И вот почему.
Языки программирования
Если вы проводите большинство своего времени изучая непосредственно язык и способы его использования, ваша картина мира выглядит примерно так:
На этой диаграмме первоначальный выбор языка программирования и уровень владения им может грандиозно повлиять на вашу продуктивность. Выбор IDE при этом не слишком важен — в основном вы будете использовать IDE как просто текстовый редактор, возможно с редкими исключениями. При этом вы не будете пользоваться всеми теми инструментами, что предлагают современные IDE.
Инструменты
С другой стороны, если вы проводите большинство своего времени за изучением инструментов разработки, вы знаете, каково это — использовать всю мощь интегрированных редактора и отладчика, средств автодополнения, рефакторинга, моделирования, дизайна, тестирования, профилирования и т.д. Ваша картина мира выглядит примерно так:
Наличие IDE даёт вам серьёзные преимущества по сравнению с голым текстовым редактором. Выбор же языка программирования, с другой стороны, не столь уж важен — вы по большому счёту будете работать со всё теми же классами и методами, переменными и выражениями, условиями и циклами. А вот реальная сила вашего стиля — в скорости разработки, которую даст вам знание IDE.
Два лагеря
А куда же мне пойти, если я хочу быть как та обезьяна в анекдоте — и умным и красивым? Можно ли быть одновременно знатоком и используемого языка программирования и инструментов? Это трудно. В сутках по-прежнему 24 часа, а в году всего 365 дней. Каждую свободную минуту можно посвятить либо изучению языка, либо инструментария. Каждый из этих вариантов в итоге положительно отразится на вашем мастерстве, но по-разному. Эти пути развития во многом конкурируют — за ваше внимание, за ваше время, за ваш стиль программирования. И в итоге вы попадаете в один из двух лагерей.
Вложение своего времени в изучение возможностей языка заставляют вас ценить интересные аспекты новых языков. Вы сразу можете позволить себе начать использовать новый язык, если в нём есть что-то, что может вам сильно помочь. Для этого у вас уже есть ваш любимый текстовый редактор, а у языка — его компиляторинтерпретатор — больше, собственно говоря, ничего и не нужно.
Инвестирование времени в развитие навыков владения инструментами, с другой стороны, не поощряет вас к использованию новых языков. Ведь инструменты ещё не поддерживают самые ценные идеи этих языков, а коль уж писать на них в стиле классического ООП — так не проще ли делать это на ранее используемом языке, с его хорошо знакомой спецификой? Тем более это даст вроде бы неплохую скорость разработки и предсказуемый результат.
Таким образом, уделяя больше внимания языку, вы так или иначе уделяете меньше внимания инструментам (и наоборот). И каждая из этих двух тропинок приведёт вас рано или поздно в один из двух лагерей, со всеми его плюсами и минусами.
В каждый момент времени программист, который выбрал текстовый редактор в качестве основного инструмента, имеет более широкий выбор языка программирования. Все новые языки имеют компиляторинтерпретатор, но далеко не все также имеют поддержку в какой-нибудь IDE. Диаграмма ниже показывает, как это выглядит для разных языков в разные моменты их эволюции.
Для каждого языка линия в конце «бело-красной» фазы показывает момент, когда язык уже пригоден не только для академических исследования, но и для какого-то реального использования. Линия в конце «красно-фиолетовой» фазы означает, что и все инструменты для данного языка стали полностью пригодны к реальному, полезному использованию. В каждый момент времени языков, прошедших «бело-красную» фазу больше, чем закончивших «красно-фиолетовую».
Одно из следствий этого большего выбора — факт того, что этот выбор даёт доступ к более мощным языкам. Таким образом, на программиста, сделавшего ставку на текстовый редактор + знание языка играют сразу два фактора: и углубление собственных знаний, и преимущества от мощных новых возможностей языка.
Дилемма разработчиков языков программирования
Самые мощные языки программирования часто имеют самый слабый инструментарий. Причина этого всё та же — ограниченность ресурсов. Разработчик нового языка — не волшебник и не миллиардер. Ему каждую свободную минуту приходится думать о том, куда её лучше потратить — на улучшение языка, или на улучшение инструментов для работы с ним.
Взгляните на следующую диаграмму. Она показывает три гипотетических языка программирования, чьи разработчики решили сосредоточиться, соответственно на развитии самого языка (верхняя стрелка), на развитии инструментов (левая стрелка) и на поиске баланса (средняя стрелка). Стрелки примерно одинаковой длины (что означает одинаковое вложение ресурсов) и поэтому они заканчиваются в совсем разных местах диаграммы. «Языковая» стрелка даёт нам супер-мощный язык с голым компилятороминтерпретатором. «Инструментальная» даёт нам хорошую IDE при средненьком банальном языке. «Балансная» теряется где-то по середине.
И вот в чём факт: хороший язык всегда рано или поздно сможет пройти по этой диаграмме из точки «много хороших фич» до точки «много хороших фич и инструментов». Так что в конце концов и приверженцы языка, и сторонники инструментов будут пользоваться хорошим языком с помощью достойных инструментов. Я надеюсь, что разрабатываемый нами язык Laszlo тоже к этому когда-нибудь придёт.
Трудности первопроходцев
Всё вышеуказанное, казалось бы, приводит к выводу о том, что «языковой» подход однозначно лучше. Действительно — использовать мощь нового языка можно раньше, изучать глубже, а инструменты потом подтянутся — и от них получим профит тоже. Так? Не совсем, есть нюансы.
Вложение своего времени в изучение инструмента фактически гарантированно даст вам результат. Популярность инструментов известна, их возможности — тоже. Выучили продвинутый дебаггер — получите сокращение времени разработки продукта на 5%. Насобачились пользоваться рефакторингом? +5 в карму. Настроили Continous integration — гора с плеч!
С языками всё не так. Новые языки имеют теоретическую мощь, но её еще нужно оправдать. Можно потратить месяц на изучение нового языка и столкнуться с тем, что он, оказывается, не подходит для вашей предметной области. Или не имеет крайне нужных библиотек. Или его сообщество крайне мало. Или с его знаниями не найти работы.
С другой стороны, если вы изучаете языки быстро, применяете их в небольших проектах и они решают стоящие перед вами задачи — для вас нет разницы, будет ли успешным дальнейшее развитие этого языка. Он помог вам здесь и сейчас — отлично. Вам не нужны толстые монографии по нему — достаточно небольших кусочков работающего кода, вам не нужна большая команда специалистов, которых нужно где-то искать и нанимать — достаточно лично вас (ну и может быть пары коллег-энтузиастов).
Ещё одно отличие подходов — вовлеченность команды. Вполне может быть, что кто-то в вашей команде Java-проекта будет использовать Eclipse, кто-то кодить в IntelliJ IDEA, а кто-то в текстовом редакторе. Это нормально, пока созданный код компилируется и выполняется одинаково. Однако, если в вашей Java-команде кто-то один вдруг самолично решить писать на Haskell — что-то определенно идёт не так.
Заключение
Конечно, есть и контрпримеры идеи «дилеммы языка и инструмента». Например Lisp и Smalltalk: оба являются мощными языками с хорошим инструментарием. Исключения возможны — как для языков, гармонично сочетающих мощь внутренних конструкций с применяемым инструментарием, так и для программистов, одинаково хорошо знающих и то, и другое. Но это примерно как встретить прославленного пианиста, являющегося одновременно и международным шахматным гроссмейстером.
Автор: tangro
