Данное сообщение навеяно очередной "войной" на rsdn.ru о выборе между С++ и C#.
Мне кажется, что языки, используемые нами для выражения своих идей, становятся частью нас самих, поэтому, если вы знаете только один язык, может показаться, будто сторонники других языков представляют опасность лично для вас. Мне представляется, что выход из этой ситуации – освоение других языков. Сомневаюсь, что можно быть профессионалом в области ПО и знать лишь один язык программирования. Может быть и экономическая причина: фундаментальные знания выходят за границы языка программирования в отличие от многих практических навыков. Поэтому, если я знаю только язык X и его наборы инструментов, а вы являетесь сторонником языка Y и его наборов инструментов, вы представляете угрозу для источника моего заработка. И вновь решение, как мне кажется, - в знании нескольких языков и наборов инструментов (а также твердое понимание фундаментальных концепций).
Интервью++: Бьерн Страуструп об эволюции языков
Портфелем знаний мы предпочитаем называть все факты, известные программистам об информатике, области приложений, в которых они работают, и накопленный ими опыт. Управление портфелем знаний очень похоже на управление финансовыми портфелем. Предложения по поддержке портфеля знаний:
- Учите (как минимум) по одному языку программирования каждый год.
- Читайте по одной технической книге ежеквартально.
- Читайте книги, не относящиеся к технической литературе.
- Экспериментируйте с различными операционными средами.
Важно продолжать инвестирование. Как только вы почувствуете, что освоили новый язык или фрагмент технологии, двигайтесь дальше. Изучайте другой. Неважно, будете ли вы когда-либо использовать одну из этих технологий в проекте или даже не упомянете о них в своем резюме. Процесс обучения расширит ваше мышление, открывая вас для новых возможностей и новых путей в творчестве. "Перекрестное опыление" идей важно; попытайтесь применить выученные уроки к проекту, над которым вы работаете в настоящее время. Даже если в вашем проекте не используется некая технология, вы наверняка сможете позаимствовать некоторые идеи.
Эндрю Хант и Дэвид Томас. Программист-прагматик. Путь от подмастерья к мастеру
Как сказал Дэвид Грайс (Gries) подход к программированию не должен определяться используемыми инструментами. В связи с этим он проводит различие между программированием на языке (programming in lanuage) и программирование с использованием языка (programming into language).
Разработчики, программирующие «на» языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемых языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными. Разработчики, программирующие «с использованием» языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка.
Стив Макконнелл. Совершенный код.
Я привел три цитаты, каждая из которых говорит о второстепенной роли языка программирования в жизни разработчика. Причем автор одной из них имеет непосредственное отношение к одному из языков программирования!
Конечно же, я не придерживаюсь мысли, что язык программирования не играет никакой роли. Нет, это не так.
Я не считаю, что не нужно углублять свои знания в конкретном языке или технологии; не считаю, что нужно выбросить книги Герба Саттера и Андея Александреску, Джошуа Блоха и Билла Вагнера, и не зачитываться этюдами nikov-а на rsdn-е. Все это очень полезно. Но польза не только в том, что эти знания вы можете использовать сейчас на текущем проекте с текущим языком и технологией, а в том, что эти знания позволят перейти вам на следующий уровень своего развития и решать более сложные задачи в следующих проектах, уже на совершенно других языках программирования и совершенно других технологиях.
Продолжая рассуждение о языках программирования в жизни разработчика, достаточно вспомнить, что пишет Брукс и Буч о сложности программных систем:
Эйнштейн неоднократно утверждал, что природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы. а затем: Сложность программного обеспечения – отнюдь не случайное его свойство. Сложность вызывается четырьмя основными причинами: сложностью реальной предметной области, из которой исходит заказ на разработку; турдностью управления процессом разработки; необходимостью обеспечить достаточную гибкость программы; неудовлетворительными способами описания поведения больших дискретных систем.
Как вы можете заметить, не один из этих пунктов не содержит фразы: «сложность программного обеспечения обусловлена неверным выбором языка программирования». Кроме того, вам будет довольно сложно найти цитату авторитетного автора, который бы сказал что-то вроде этого: «Изучение языка программирования А – это ваш путь к успеху. Благодаря ему уже через полгода его изучения вас ждет почет и уважение в среде разработчиков по всему миру, вы будете президентом корпорации и будете ездить на Bentley, а вот если ваш выбор остановится на языке программирования Б – вас ждет позор, забвение и жизнь на помойке».
На закуску, хочется привести еще одну цитату Ханта и Томаса:
Программирование – это прикладное искусство. Простейший его смысл заключается в следующем: заставить компьютер делать то, что вам нужно (или то, что нужно пользователю, работающему с вашей программой). Программист – он и слушатель, он и советник, он и переводчик и даже диктатор. Вы пытаетесь ухватить суть не совсем ясных требований и найти такой способ их выражения, что только машина сможет оценить их по достоинству. Вы пытаетесь задокументировать работу так, чтобы она была понятна другим, спроектировать ее так, чтобы другие могли на нее положиться. Кроме того, вы пытаетесь сделать все это вопреки безжалостному ходу стрелки часов, отсчитывающих время, отпущенное на проект. Каждый день вы совершаете по маленькому чуду. Это непростая работа.
Многие предлагают вам помощь. Фирмы-поставщики инструментальных средств настойчиво говорят о чудесах, которые творят их программы. Мудрецы от методологии заверяют в том, что их средства гарантируют результаты. Каждый считает свой язык программирования лучшим из лучших, а операционную систему – панацеей. Разумеется, эти утверждения неверны. Простых ответов не существует. Не существует такого понятия, как наилучшее решение, будь то инструментальное средство, язык или операционная система. Существует лишь некие системы, которые являются более приемлемыми при конкретном стечении обстоятельств. И в этот момент на сцену выходит прагматизм.
Стоит избегать обряда венчания с конкретной технологией, но при этом необходимо обладать подготовкой и опытом, настолько обширными, что это позволит выбрать верные решения в конкретных ситуациях. Ваша подготовка происходит из понимания основных принципов информатики, а опыт основывается на разнообразных практических проектах. Теория и практика сочетаются, придавая вам силу.
P.S. Если вы хотите стать хорошим программистом, то нужно решать сложные задачи в интересном коллективе. При этом язык программирования играет лишь второстепенную роль.
Мне кажется, что языки, используемые нами для выражения своих идей, становятся частью нас самих, поэтому, если вы знаете только один язык, может показаться, будто сторонники других языков представляют опасность лично для вас. Мне представляется, что выход из этой ситуации – освоение других языков. Сомневаюсь, что можно быть профессионалом в области ПО и знать лишь один язык программирования. Может быть и экономическая причина: фундаментальные знания выходят за границы языка программирования в отличие от многих практических навыков. Поэтому, если я знаю только язык X и его наборы инструментов, а вы являетесь сторонником языка Y и его наборов инструментов, вы представляете угрозу для источника моего заработка. И вновь решение, как мне кажется, - в знании нескольких языков и наборов инструментов (а также твердое понимание фундаментальных концепций).
Интервью++: Бьерн Страуструп об эволюции языков
Портфелем знаний мы предпочитаем называть все факты, известные программистам об информатике, области приложений, в которых они работают, и накопленный ими опыт. Управление портфелем знаний очень похоже на управление финансовыми портфелем. Предложения по поддержке портфеля знаний:
- Учите (как минимум) по одному языку программирования каждый год.
- Читайте по одной технической книге ежеквартально.
- Читайте книги, не относящиеся к технической литературе.
- Экспериментируйте с различными операционными средами.
Важно продолжать инвестирование. Как только вы почувствуете, что освоили новый язык или фрагмент технологии, двигайтесь дальше. Изучайте другой. Неважно, будете ли вы когда-либо использовать одну из этих технологий в проекте или даже не упомянете о них в своем резюме. Процесс обучения расширит ваше мышление, открывая вас для новых возможностей и новых путей в творчестве. "Перекрестное опыление" идей важно; попытайтесь применить выученные уроки к проекту, над которым вы работаете в настоящее время. Даже если в вашем проекте не используется некая технология, вы наверняка сможете позаимствовать некоторые идеи.
Эндрю Хант и Дэвид Томас. Программист-прагматик. Путь от подмастерья к мастеру
Как сказал Дэвид Грайс (Gries) подход к программированию не должен определяться используемыми инструментами. В связи с этим он проводит различие между программированием на языке (programming in lanuage) и программирование с использованием языка (programming into language).
Разработчики, программирующие «на» языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемых языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными. Разработчики, программирующие «с использованием» языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка.
Стив Макконнелл. Совершенный код.
Я привел три цитаты, каждая из которых говорит о второстепенной роли языка программирования в жизни разработчика. Причем автор одной из них имеет непосредственное отношение к одному из языков программирования!
Конечно же, я не придерживаюсь мысли, что язык программирования не играет никакой роли. Нет, это не так.
Я не считаю, что не нужно углублять свои знания в конкретном языке или технологии; не считаю, что нужно выбросить книги Герба Саттера и Андея Александреску, Джошуа Блоха и Билла Вагнера, и не зачитываться этюдами nikov-а на rsdn-е. Все это очень полезно. Но польза не только в том, что эти знания вы можете использовать сейчас на текущем проекте с текущим языком и технологией, а в том, что эти знания позволят перейти вам на следующий уровень своего развития и решать более сложные задачи в следующих проектах, уже на совершенно других языках программирования и совершенно других технологиях.
Продолжая рассуждение о языках программирования в жизни разработчика, достаточно вспомнить, что пишет Брукс и Буч о сложности программных систем:
Эйнштейн неоднократно утверждал, что природа должна иметь простые объяснения, поскольку Богу не свойственны капризность и произвол. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы. а затем: Сложность программного обеспечения – отнюдь не случайное его свойство. Сложность вызывается четырьмя основными причинами: сложностью реальной предметной области, из которой исходит заказ на разработку; турдностью управления процессом разработки; необходимостью обеспечить достаточную гибкость программы; неудовлетворительными способами описания поведения больших дискретных систем.
Как вы можете заметить, не один из этих пунктов не содержит фразы: «сложность программного обеспечения обусловлена неверным выбором языка программирования». Кроме того, вам будет довольно сложно найти цитату авторитетного автора, который бы сказал что-то вроде этого: «Изучение языка программирования А – это ваш путь к успеху. Благодаря ему уже через полгода его изучения вас ждет почет и уважение в среде разработчиков по всему миру, вы будете президентом корпорации и будете ездить на Bentley, а вот если ваш выбор остановится на языке программирования Б – вас ждет позор, забвение и жизнь на помойке».
На закуску, хочется привести еще одну цитату Ханта и Томаса:
Программирование – это прикладное искусство. Простейший его смысл заключается в следующем: заставить компьютер делать то, что вам нужно (или то, что нужно пользователю, работающему с вашей программой). Программист – он и слушатель, он и советник, он и переводчик и даже диктатор. Вы пытаетесь ухватить суть не совсем ясных требований и найти такой способ их выражения, что только машина сможет оценить их по достоинству. Вы пытаетесь задокументировать работу так, чтобы она была понятна другим, спроектировать ее так, чтобы другие могли на нее положиться. Кроме того, вы пытаетесь сделать все это вопреки безжалостному ходу стрелки часов, отсчитывающих время, отпущенное на проект. Каждый день вы совершаете по маленькому чуду. Это непростая работа.
Многие предлагают вам помощь. Фирмы-поставщики инструментальных средств настойчиво говорят о чудесах, которые творят их программы. Мудрецы от методологии заверяют в том, что их средства гарантируют результаты. Каждый считает свой язык программирования лучшим из лучших, а операционную систему – панацеей. Разумеется, эти утверждения неверны. Простых ответов не существует. Не существует такого понятия, как наилучшее решение, будь то инструментальное средство, язык или операционная система. Существует лишь некие системы, которые являются более приемлемыми при конкретном стечении обстоятельств. И в этот момент на сцену выходит прагматизм.
Стоит избегать обряда венчания с конкретной технологией, но при этом необходимо обладать подготовкой и опытом, настолько обширными, что это позволит выбрать верные решения в конкретных ситуациях. Ваша подготовка происходит из понимания основных принципов информатики, а опыт основывается на разнообразных практических проектах. Теория и практика сочетаются, придавая вам силу.
P.S. Если вы хотите стать хорошим программистом, то нужно решать сложные задачи в интересном коллективе. При этом язык программирования играет лишь второстепенную роль.
Мне стыдно, что я знаю только 1 язык программирования. :-(
ОтветитьУдалитьТо, что я совсем немного помню с++ я не считаю.
Интересно, но я даже не знал о существовании священных войн между адептами разных языков. И узнав об этом я очень удивился, потому что, как по мне, этой проблемы не должно существовать в принципе и ввязываться в такие дискуссии могут только довольно ограниченные люди.
Вообще, такое чувство, что люди рассматривают расхождение во мнениях по поводу языков программирования или операционных систем, как личную обиду, настолько эмоциональны такие дискуссии получаются.
ОтветитьУдалитьЯ тоже обычно не ввязываюсь в такие дискуссии, т.к. переубедить людей в подобных вещах практически невозможно.
Это здорово конечно "учить по одному языку в год". Интересно что является критерием "выученности". Прочитать много книг, написать "Hello World". Изучение языка подразумевает продуктивную работу с ним. Нет проекта/задачи с использованием языка - язык не знаком. Это как учить китайский по самоучителю и не разу не поговорить с китайцем.
ОтветитьУдалитьК тому же язык как замечено в статье не так важен. Так сложилось что язык подразумевает некую экоситему (фрэймворк). Если пишем в резюме например c# подразумевается знание АСП.НЕТ и/или ВинФормс и/или ВПФ.
2vitaly.maslevskiy:
ОтветитьУдалитьЕсли присмотреться к цитате внимательнее, то можно заметить, что авторы не используют завершенную форму глагола "учить", они не говорят о том, что нужно "выучить" язык программирования, они говорят о том, что его нужно "изучать". "Выучить" язык программирования, действительно, нельзя, но познакомиться с ним, даже не на реальной задаче, а на простой, придуманной самостоятельно и выполняемой в свободное время - можно.
Мнение у "прагматиков" (как и большинства серьезных авторов и зрелых специалистов) сводится к тому, что не нужно раз и навсегда "венчаться" с каким бы то ни было языком или технологией. Расширение кругозора позволит уменьшить барьер, который есть у каждого человека, когда он сталкивается с чем-то новым. Кроме того, знания других языков, методов, технологий, позволяет более здраво смотреть на решаемые проблемы и мыслить не в терминах решения, а в терминах задачи.
2Сергей Тепляков
ОтветитьУдалитьДа я согласен "многостаночники" не настолько зашорены как "гуру". Да я полностью согласен со стариком Страуструпом, что изучение языков расширяет кругозор повышает мыслительную гибкость программиста.
Суровая реальность несколько иная. Язык/технология в 99.99% проектов бежит впереди анализа. Наивно полагать, что изучив предметную область комманда примет решение "сьехать" с c# на c++. Сроки разработки сокращаются, заказчики хотят результатов здесь и сейчас, "горячие" методы разработки SCRUM, Agile затуманивают головы менеджерам по продажам/заказчикам. Результат команда начинает писать на том что у нее есть в руках. Возможно во времена мэйнфрэймов/перфокарт и суровых программистов в джемперах с гитарами можно было заявить, "проект займет 12 человеко лет, причем нам придется переучить наш личный состав, на использование языка Б ибо используемый нами язык А не подходит для решения задач в вашей предметной области" сейчас это просто не реальный вариант. Озвучевшего такое решение с почестями свезут в Кащенко. Да всего 15-20 лет назад, выбор языка программирования был следствием тщательного анализа, сейчас как мне кажется это исключительно эго/политика/профит.
При таком раскладе, знание нескольких языков становится для программиста не средством выбора правильной стратегии и/или архитектуры приложения, а волшебным помелом, на котором можне передвигаться между конкурирующими лагерями (проектами), для мэнеджемента со стороны разработчика "многостаночник" волшебная палка которой можно загнать в счастье клиента который начал (по тем же политическим/эгоситическим соображениям) гундосить на тему "Ой все хорошо, но у нас в компании применяется язык Б ,а апологетов языка А мы режем по пятницам".
Еще один момент, язык программирования перестал быть субстанцией на которой излагают проблемы предметной области. Скорее язык стал маркетинговым инструментом. Программирую почти 20 лет (полный стаж включаю не проффесиональный) и с периодичностью 3-5 лет изобретается "серебрянная пуля" с помощю которой "Приложения разрабатываются на Х процентов быстрей при этом становятся стабильней на Y процентов и т. д."
Факт (ИМХО) сроки разработка за последние 12 лет сократились минимально.
Возможно откомментировал не совсем в тему поста.
2vitaly.maslevskiy
ОтветитьУдалитьМожет и не сильно в тему поста, но зато верно. Спорить с вашими заявлениями сложно.
Промышленное программирование особенно в крупных проектах процесс весьма инерционный, любые изменения - это болезненный процесс, а выбор языка программирования - так и подавно.
Простой пример, в Майкрософт только недавно начали появляться продукты, написанных на .net framework, а крупных продуктов, которые были _полностью_ написаны на .net нет совсем (наиболее близко к этому подошла Visual Studio 2010).
А если вернуться к моему изначальному посту, то суть в нем в том, что не нужно слишком серьезно подходить к какому бы то ни было инструменту или технологии. Да и процесс постоянного изучения - это же здорово:) масса удовольствия (во всяком случае у меня).