Pull to refresh

Программисты: вчера и сегодня

Здравствуй, уважаемый хаброчеловек. Если ты программист, ты никогда не задумавался о том, как программировали лет 30 назад и как программируют сегодня? Под катом некоторые размышления по этому поводу.

Первый компьютер под названием ENIAC был изобретен аж в 1946 Джоном Уильямом Мокли (John William Mauchly). С тех пор прошло немало времени — компьютеры развивались, соответственно развивались и языки программирования, с развитием которых неуклонно начало расти число программистов. Первым программистам было действительно тяжело, 1 и 0 — все, что у них было. Естественно писать большие программы на машинных кодах тяжело, а поддерживать — практически невозможно, хотя в то время больших программ не было, да они и не требовались.

Неудивительно, что программистам надоело программировать в машинных кодах, вследствие чего появился языка ассемблера, а затем и первый язык высокого уровня – Фортран. Кто-то скажет, что первым был Планкалкюль, разработанный Конрадом Цузе, однако для этого языка не было транслятора. Да, был еще ПП (Программирующая программа), однако широкое применение высокоуровневые языки получили именно благодаря Фортрану.

Ладно, думаю, что стоит закончить с историческим экскурсом, ведь история развития языков программирования – тема для отдельной статьи. Ближе к делу. Если Вы еще не забыли, то топик называется «Программисты: вчера и сегодня», предлагаю начать рассуждение о программистах «вчерашнего» дня, или лучше сказать «позавчерашнего» дня.

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

Все, что было сказано в предыдущем абзаце, имеет отношение, скорее, к программистам на ассемблере. Хочется поговорить и о языках высокого уровня, которыми уже пользовались программисты «вчера». Эти языки имели строгую статическую типизацию, то есть все типы данных, которыми оперировал программист, имели под собой машинную основу. Например, int в 16ти-битном компиляторе языка C представлялся машинным словом (2 байта), соответственно все операции, выполняемые с переменными данного типа, выполнялись именно процессором. К чему я все это говорю? К тому, что программист, опять же, отвечал за работу своей программы, мог предсказать ее поведение в зависимости от входных данных.

Однако ошибка в программу могла закрасться не только по вине непосредственного разработчика, но и по вине разработчиков библиотек, которые использовались для разработки данной программы. Никто ведь не гарантирует, что, например, Win32 API функции, которыми мы пользуемся, всегда работают во всех случаях правильно. Несмотря на это, у программистов появилась возможность писать достаточно большие программы сравнительно быстро и просто (ведь не надо думать на какую дорожку ставить считывающую головку жесткого диска).

Снова напрашивается вывод: чем выше уровень языка программирования, тем больше программист зависит от того, что лежит уровнем ниже. Поясню. Первые программисты целиком и полностью зависели от железа. Потом программисты стали зависеть от операционных систем и библиотек, которые они используют для разработки. От чего же программисты зависят «сегодня»? Тут все намного сложнее.

Многие современные языки обладают динамической типизацией, то есть программист оперирует объектами, которые не имеют под собой непосредственной машинной подоплеки. Таким образом, в выполнении операций над такими объектами процессор не участвует напрямую. Все сделает, например, виртуальная машина (JVM, .NET), которую тоже писали люди, а ведь любому свойственно ошибаться.

«Сегодняшние» языки программирования сильно абстрагируют разработчика от оборудования. Это позволяет создавать платформо-независимое программное обеспечение, но, в то же время, программист уже не всегда может предсказать поведение своей программы.

Давайте сравним программиста со строителем. Что лучше, строить дом из простых кирпичей, устройство которых строитель прекрасно знает или же строить дом из готовых квартир, подъездов, а может и целых этажей. Поломка одного кирпичика вряд ли приведет к краху всего здания, а вот поломка целого подъезда, внутреннее устройство которого строителю, скорее всего, не известно может привести к непредсказуемым последствиям.

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

Какой из этого всего следует вывод? Рассмотри плюсы и минусы «сегодняшних» языков программирования по сравнения с «вчерашними».

Плюсы:
  • Возможность создания больших программных комплексов
  • Высокая скорость разработки
  • Кросс-платформенное ПО
  • Довольные заказчики и начальники, получающие требуемое ПО за относительно короткие сроки

Минусы:
  • Сравнительно низкая надежность программ (так как может ошибиться любой, от разработчика библиотек до разработчика ОС, Framework’ов и даже компиляторов)
  • Сложный синтаксис
  • Дорогие компиляторы и средства разработки (опять же из-за сложного синтаксиса)

На самом деле, этой статьей я не хотел сказать, что в современном программировании все плохо и что всем срочно надо пересаживаться на ассемблер. Я, например, на работе программирую именно на C# и тот проект, который мы делаем, на С++ делали бы в 10 раз дольше. Для каждой задачи существует свой язык, который лучше других подходит для ее решения, и «сегодня» нужно уметь грамотно его выбрать. Я хочу сказать, что не стоит целиком посвящать себя высокоуровневым языкам, ведь существуют задачи, которые лучше решать с использованием менее высокоуровневых языков. К тому же никто не запрещает использовать разные языки для разработки одного проекта.

Жду Ваше мнение по поводу программирования «вчера» и «сегодня».
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.