По Наполеону и папаха...
(непредвзятый взгляд профессионала на технологии программирования) Разговор двух программистов за рюмкой чая: - Моя программа работает в три раза быстрее и требует в два раза меньше ресурсов, чем твоя! - Зато моя работает, а твоя - нет. (старый программистский анекдот)
Во всех компьютерных изданиях есть несколько вечно популярных тем, которые с большей или меньшей частотой появляются снова и снова. Например, рекомендации, как покупать компьютер для новичков в компьютерах, или ценные указания по выбору самого-лучшего-на-все-случаи-жизни языка для новичков в программировании.
Точка зрения на то, какой язык программирования лучше, на моей памяти менялась неоднократно.
В школе меня учили ФОРТРАНу (а это было - страшно сказать - в 1980 году), в институте - PL/1 и Ассемблеру. Насколько я помню, эти языки преподносились нам как незыблемые ценности.
После появления первых персональных компьютеров коллективного пользования (ЕС1840, если кто помнит это легендарное детище минской Silicon Valley), стали учить Бэйсику. Учили всех, включая главных бухгалтеров и секретарш. Толку от такого обучения было... К счастью, очень быстро пришло понимание истины, что обычные языки программирования предназначены для обученных специалистов, а для непрофессионалов больше подходят пакеты типа SuperCalc или Excel.
На программистов же свалилось превеликое множество невиданных языков: Basic, Pascal, Prolog, C, dBase, Clipper, Clarion - в различных версиях и вариантах локализации (или, как говорили, русификации). Все изучать - не хватит ни времени, ни сил. Пришлось определяться со специализацией. Кто-то полез в дебри ДОСа (где властвовали ассемблер и С), кто-то занялся базами данных в виде разнообразных экономических и бухгалтерских программ (где хитом надолго стал Clipper). В принципе, подобрать инструмент под конкретную задачу никогда не было проблемой - давние пиратские традиции этому очень даже способствовали.
Единственное, что омрачало светлые дали - сравнительно низкое быстродействие тогдашних компьютеров. Это заставляло очень серьезно заниматься оптимизацией алгоритма либо идти на непопулярные меры вроде вставки модулей на языке более низкого уровня (типа ассемблера), которые позволяли работать с оборудованием быстрее, чем это позволяли стандартные средства основного языка (например, Clipper). Естественно, что скорость разработки программ это отнюдь не повышало.
Таким образом, мне пришлось перепробовать достаточно большое число языков программирования различного уровня и назначения. На каком-то этапе в голову пришла крамольная (на первый взгляд) мысль: а ведь все языки-то почти одинаковые! Действительно, общие принципы реализации алгоритма во всех языках одинаковы: циклы, условия, процедуры, функции... Отличия только на уровне синтаксиса. И те знания, которые вложили в голову в школе и институте, не потеряли свою ценность, несмотря на то, что они давались на базе достаточно древних языков. Более значительную роль играла способность понять суть поставленной задачи и представить ее в виде формального алгоритма.
Даже появление объектно-ориентированных средств разработки (таких, как С++, Visual Basic, Delphi) не изменило ситуацию. Если программист мог хорошо представить себе задачу, он ее решал быстро, красиво и качественно. Если не мог, то, соответственно, программа получалось кривой и ущербной.
Кстати, за последние годы сместились приоритеты требований к программе. Если во времена 286-х машин основным требованием была высокая скорость работы программы, то с появлением Windows более существенной стала скорость разработки. Это стало следствием роста вычислительной мощности машин, с одной стороны, и появления RAD (rapid application development tools) - средств скоростной разработки приложений - с другой. Дело в том, что побочным эффектом внедрения объектно-ориентированных языков стал рост требований к ресурсам компьютера. Особенно это было заметно при переносе приложений с процедурных языков на объектно-ориентированные (например, с С на С++). Размер ЕХЕ-файла вырастал раз в десять, а работа приложения замедлялась (особенно на какой-нибудь слабой машине) до совершенно неприличного уровня. Заказчики - в шоке, программисты - в ауте. Это сейчас можно без проблем и сравнительно недорого нарастить память, поменять процессор, если не хватает имеющихся. Но ведь были времена, когда компьютеры на базе процессора 80386 были запрещены к ввозу в СССР как стратегически важные изделия, а лишний мегабайт памяти стоил полугодовой зарплаты программиста.
Таким образом, реальное применение объектно-ориентированные средства получили только с появлением компьютеров класса Pentium. Однако, проблема выбора инструмента для изучения и последующей работы по-прежнему имеется.
С одной стороны, хочется использовать инструмент достаточно универсальный, с другой - поскорее начать его использовать, чтобы зашибать длинный программистский рубль (о его реальной "длине" распространяться не буду). Вот тут-то мнения специалистов и начинают кардинально расходиться.
В частности, Павел Горбунов настоятельно рекомендует изучать С++. Такого же мнения придерживаются многие эксперты. Во многом эта точка зрения верна: С++ - это основной язык разработок системного уровня во всех ведущих странах мира, он абсолютно гибок и практически незаменим при работе с оборудованием на низком уровне (для создания драйверов, например). Зная С++, программист элементарно переходит к Java - на сегодняшний день лучшему мультиплатформенному средству разработки (в первую очередь для Internet). А Java-программисты - товар повышенного спроса во всем мире (за исключением некоторых отдельно взятых стран).
Однако, столь любимый многими язык имеет один серьезный (на мой взгляд) недостаток: необходим достаточно большой стартовый запас знаний, чтобы начать разрабатывать что-то серьезнее, чем "Hello, world!". На том же Visual Basic или Delphi можно создать нечто работоспособное и сравнительно полезное, не написав "руками" ни одной строки кода. Я не буду утверждать, что подобное творение вызовет у кого-то бурю восторга своим изысканным стилем, но как заготовка для последующей ручной отделки "это" вполне подойдет.
С другой стороны, эти инструменты имеют все атрибуты полноценного объектно-ориентированного языка: свои классы хотите создать - пожалуйста, СОМ-компоненты разрабатывать - проще некуда, доступ к Windows API - сколько угодно. Только надо четко представлять, чего хочешь.
По моему мнению, главная проблема в изучении программирования лежит несколько в другой плоскости. Нужно не столько знать какой-то язык программирования, сколько разбираться в конкретной предметной области, будь то e-commerce, бухгалтерский учет или моделирование ядерного взрыва в реальном времени. Как справедливо отметил уважаемый Павел, за рубежом (да и у нас в серьезных программистских фирмах) не нужны просто специалисты по какому-то языку. Там нужны специалисты, способные применять конкретный язык в определенной предметной области. Причем, опыт разработки именно таких, как надо работодателю (или похожих), приложений, ценится выше, чем знание языка.
Кроме этого, существует такое понятие, как технологии программирования. Они не имеют ничего общего с MMX или 3D Now!, т.к. это всего лишь наборы команд процессора, которые интересны достаточно узкому кругу разработчиков вполне определенных классов программного обеспечения. Они называются по-другому: COM, OOP, клиент/сервер и так далее. Это краеугольные камни современной технологии разработки software. Если специалист разобрался, как обращаться с объектами в VB, он не заблудится в них в Java или С++, а выучить новые команды - дело времени.
У "проклятых буржуинов" почему-то выработалась привычка выбирать инструмент для разработки программного обеспечения, исходя не из его крутости или универсальности, а из соответствия поставленной задаче. То есть, если задача может быть решена средствами Excel, никто не будет использовать Visual C++. Кстати, за рубежом давным-давно сложился солидный рынок разработок (и разработчиков, естественно) на макроязыках. Сначала это были Supercalc и Lotus 1-2-3, теперь, естественно, MS Office или аналогичные продукты-конкуренты. И народ там как-то не комплексует по поводу недостаточной крутизны используемого языка программирования.
Профессия программиста - не самый легкий способ зарабатывать на кусок хлеба. Поэтому за рубежом (да и у нас) молодежь не очень стремится на соответствующие факультеты вузов и колледжей. Врач или юрист в США получает не хуже, чем программист, а напряжение для мозгов куда как меньше. Для сведения: программист в США или Канаде зарабатывает в среднем в полтора раза больше, чем инженер строительной или общетехнической специальности. Поэтому и приходится американцам искать желающих "вывихивать мозги" в тех странах, где умственный труд не очень ценится. Например, в Индии, Китае и, естественно, на просторах бывшего Советского Союза. А в последнее время в стройные ряды "охотников за мозгами" влились Германия и Южная Корея. Тенденция, однако... Как только правительство страны понимает, что без информационных технологий начинается отставание всех остальных отраслей, сразу же начинается поиск соответствующих специалистов за рубежом (на время, пока не будут подготовлены свои кадры). А пока самой главной проблемой правительства какой-либо страны является ежегодная битва с урожаем, высокие технологии там будут в загоне, а соответствующие специалисты искать места, где они смогут получать "по труду", а не вести постоянную борьбу за выживание.
К тому же профессия программиста, даже полученная в отечественном учебном заведении, - одна из немногих "свободно конвертируемых" в мире. Это я смог увидеть на многочисленных примерах моих друзей и соучеников, которые уехали в США, Израиль, Канаду и другие страны мира. Те, кто каким-то образом научился писать программы, имели (и имеют) минимум проблем с работой. Некоторые пошли в программисты, а остальные используют компьютеры как "очень крутые юзеры". Уделом обладателей других профессий поначалу стало разгребание навоза в киббуце на Голландских Высотах или вождение такси в Нью-Йорке.
Подведем итог. Моя точка зрения такова: не важно, какой именно язык изучать, гораздо важнее освоить современную технологию разработки программ. А по своему многолетнему опыту я могу утверждать, что программирование лучше всего изучается на конкретной задаче, а не на учебных примерах. Каждый должен выбрать тот инструмент, который ему больше подходит "по руке". Программисты нужны, и любой толковый специалист неизбежно будет востребован.
Вадим Винокур
Во всех компьютерных изданиях есть несколько вечно популярных тем, которые с большей или меньшей частотой появляются снова и снова. Например, рекомендации, как покупать компьютер для новичков в компьютерах, или ценные указания по выбору самого-лучшего-на-все-случаи-жизни языка для новичков в программировании.
Точка зрения на то, какой язык программирования лучше, на моей памяти менялась неоднократно.
В школе меня учили ФОРТРАНу (а это было - страшно сказать - в 1980 году), в институте - PL/1 и Ассемблеру. Насколько я помню, эти языки преподносились нам как незыблемые ценности.
После появления первых персональных компьютеров коллективного пользования (ЕС1840, если кто помнит это легендарное детище минской Silicon Valley), стали учить Бэйсику. Учили всех, включая главных бухгалтеров и секретарш. Толку от такого обучения было... К счастью, очень быстро пришло понимание истины, что обычные языки программирования предназначены для обученных специалистов, а для непрофессионалов больше подходят пакеты типа SuperCalc или Excel.
На программистов же свалилось превеликое множество невиданных языков: Basic, Pascal, Prolog, C, dBase, Clipper, Clarion - в различных версиях и вариантах локализации (или, как говорили, русификации). Все изучать - не хватит ни времени, ни сил. Пришлось определяться со специализацией. Кто-то полез в дебри ДОСа (где властвовали ассемблер и С), кто-то занялся базами данных в виде разнообразных экономических и бухгалтерских программ (где хитом надолго стал Clipper). В принципе, подобрать инструмент под конкретную задачу никогда не было проблемой - давние пиратские традиции этому очень даже способствовали.
Единственное, что омрачало светлые дали - сравнительно низкое быстродействие тогдашних компьютеров. Это заставляло очень серьезно заниматься оптимизацией алгоритма либо идти на непопулярные меры вроде вставки модулей на языке более низкого уровня (типа ассемблера), которые позволяли работать с оборудованием быстрее, чем это позволяли стандартные средства основного языка (например, Clipper). Естественно, что скорость разработки программ это отнюдь не повышало.
Таким образом, мне пришлось перепробовать достаточно большое число языков программирования различного уровня и назначения. На каком-то этапе в голову пришла крамольная (на первый взгляд) мысль: а ведь все языки-то почти одинаковые! Действительно, общие принципы реализации алгоритма во всех языках одинаковы: циклы, условия, процедуры, функции... Отличия только на уровне синтаксиса. И те знания, которые вложили в голову в школе и институте, не потеряли свою ценность, несмотря на то, что они давались на базе достаточно древних языков. Более значительную роль играла способность понять суть поставленной задачи и представить ее в виде формального алгоритма.
Даже появление объектно-ориентированных средств разработки (таких, как С++, Visual Basic, Delphi) не изменило ситуацию. Если программист мог хорошо представить себе задачу, он ее решал быстро, красиво и качественно. Если не мог, то, соответственно, программа получалось кривой и ущербной.
Кстати, за последние годы сместились приоритеты требований к программе. Если во времена 286-х машин основным требованием была высокая скорость работы программы, то с появлением Windows более существенной стала скорость разработки. Это стало следствием роста вычислительной мощности машин, с одной стороны, и появления RAD (rapid application development tools) - средств скоростной разработки приложений - с другой. Дело в том, что побочным эффектом внедрения объектно-ориентированных языков стал рост требований к ресурсам компьютера. Особенно это было заметно при переносе приложений с процедурных языков на объектно-ориентированные (например, с С на С++). Размер ЕХЕ-файла вырастал раз в десять, а работа приложения замедлялась (особенно на какой-нибудь слабой машине) до совершенно неприличного уровня. Заказчики - в шоке, программисты - в ауте. Это сейчас можно без проблем и сравнительно недорого нарастить память, поменять процессор, если не хватает имеющихся. Но ведь были времена, когда компьютеры на базе процессора 80386 были запрещены к ввозу в СССР как стратегически важные изделия, а лишний мегабайт памяти стоил полугодовой зарплаты программиста.
Таким образом, реальное применение объектно-ориентированные средства получили только с появлением компьютеров класса Pentium. Однако, проблема выбора инструмента для изучения и последующей работы по-прежнему имеется.
С одной стороны, хочется использовать инструмент достаточно универсальный, с другой - поскорее начать его использовать, чтобы зашибать длинный программистский рубль (о его реальной "длине" распространяться не буду). Вот тут-то мнения специалистов и начинают кардинально расходиться.
В частности, Павел Горбунов настоятельно рекомендует изучать С++. Такого же мнения придерживаются многие эксперты. Во многом эта точка зрения верна: С++ - это основной язык разработок системного уровня во всех ведущих странах мира, он абсолютно гибок и практически незаменим при работе с оборудованием на низком уровне (для создания драйверов, например). Зная С++, программист элементарно переходит к Java - на сегодняшний день лучшему мультиплатформенному средству разработки (в первую очередь для Internet). А Java-программисты - товар повышенного спроса во всем мире (за исключением некоторых отдельно взятых стран).
Однако, столь любимый многими язык имеет один серьезный (на мой взгляд) недостаток: необходим достаточно большой стартовый запас знаний, чтобы начать разрабатывать что-то серьезнее, чем "Hello, world!". На том же Visual Basic или Delphi можно создать нечто работоспособное и сравнительно полезное, не написав "руками" ни одной строки кода. Я не буду утверждать, что подобное творение вызовет у кого-то бурю восторга своим изысканным стилем, но как заготовка для последующей ручной отделки "это" вполне подойдет.
С другой стороны, эти инструменты имеют все атрибуты полноценного объектно-ориентированного языка: свои классы хотите создать - пожалуйста, СОМ-компоненты разрабатывать - проще некуда, доступ к Windows API - сколько угодно. Только надо четко представлять, чего хочешь.
По моему мнению, главная проблема в изучении программирования лежит несколько в другой плоскости. Нужно не столько знать какой-то язык программирования, сколько разбираться в конкретной предметной области, будь то e-commerce, бухгалтерский учет или моделирование ядерного взрыва в реальном времени. Как справедливо отметил уважаемый Павел, за рубежом (да и у нас в серьезных программистских фирмах) не нужны просто специалисты по какому-то языку. Там нужны специалисты, способные применять конкретный язык в определенной предметной области. Причем, опыт разработки именно таких, как надо работодателю (или похожих), приложений, ценится выше, чем знание языка.
Кроме этого, существует такое понятие, как технологии программирования. Они не имеют ничего общего с MMX или 3D Now!, т.к. это всего лишь наборы команд процессора, которые интересны достаточно узкому кругу разработчиков вполне определенных классов программного обеспечения. Они называются по-другому: COM, OOP, клиент/сервер и так далее. Это краеугольные камни современной технологии разработки software. Если специалист разобрался, как обращаться с объектами в VB, он не заблудится в них в Java или С++, а выучить новые команды - дело времени.
У "проклятых буржуинов" почему-то выработалась привычка выбирать инструмент для разработки программного обеспечения, исходя не из его крутости или универсальности, а из соответствия поставленной задаче. То есть, если задача может быть решена средствами Excel, никто не будет использовать Visual C++. Кстати, за рубежом давным-давно сложился солидный рынок разработок (и разработчиков, естественно) на макроязыках. Сначала это были Supercalc и Lotus 1-2-3, теперь, естественно, MS Office или аналогичные продукты-конкуренты. И народ там как-то не комплексует по поводу недостаточной крутизны используемого языка программирования.
Профессия программиста - не самый легкий способ зарабатывать на кусок хлеба. Поэтому за рубежом (да и у нас) молодежь не очень стремится на соответствующие факультеты вузов и колледжей. Врач или юрист в США получает не хуже, чем программист, а напряжение для мозгов куда как меньше. Для сведения: программист в США или Канаде зарабатывает в среднем в полтора раза больше, чем инженер строительной или общетехнической специальности. Поэтому и приходится американцам искать желающих "вывихивать мозги" в тех странах, где умственный труд не очень ценится. Например, в Индии, Китае и, естественно, на просторах бывшего Советского Союза. А в последнее время в стройные ряды "охотников за мозгами" влились Германия и Южная Корея. Тенденция, однако... Как только правительство страны понимает, что без информационных технологий начинается отставание всех остальных отраслей, сразу же начинается поиск соответствующих специалистов за рубежом (на время, пока не будут подготовлены свои кадры). А пока самой главной проблемой правительства какой-либо страны является ежегодная битва с урожаем, высокие технологии там будут в загоне, а соответствующие специалисты искать места, где они смогут получать "по труду", а не вести постоянную борьбу за выживание.
К тому же профессия программиста, даже полученная в отечественном учебном заведении, - одна из немногих "свободно конвертируемых" в мире. Это я смог увидеть на многочисленных примерах моих друзей и соучеников, которые уехали в США, Израиль, Канаду и другие страны мира. Те, кто каким-то образом научился писать программы, имели (и имеют) минимум проблем с работой. Некоторые пошли в программисты, а остальные используют компьютеры как "очень крутые юзеры". Уделом обладателей других профессий поначалу стало разгребание навоза в киббуце на Голландских Высотах или вождение такси в Нью-Йорке.
Подведем итог. Моя точка зрения такова: не важно, какой именно язык изучать, гораздо важнее освоить современную технологию разработки программ. А по своему многолетнему опыту я могу утверждать, что программирование лучше всего изучается на конкретной задаче, а не на учебных примерах. Каждый должен выбрать тот инструмент, который ему больше подходит "по руке". Программисты нужны, и любой толковый специалист неизбежно будет востребован.
Вадим Винокур
Компьютерная газета. Статья была опубликована в номере 20 за 2000 год в рубрике разное :: мелочи жизни
