2020-11-19 20:55:06
[3. Зачем учить "старые" языки программирования?]
Для того, чтобы дать ответ на этот вопрос, мы должны понять, где проходит граница между "старыми" и "новыми" языками программирования. Разумеется, четкого раздела здесь нет и эти два термина условны. Как мы узнали выше, никто не создает языки с учетом "новизны". Процитирую еще раз основную мысль из предыдущего ответа: "Со временем разработчики понимают сильные и слабые стороны используемых языков, пытаются их улучшить, либо создать новые, которые больше соответствуют их требованиям и лучше подходят для решения поставленных задач". Думаю, с этим мы разобрались.
Условным водоразделом для "старых" и "новых" языков можем считать район 2000-х годов. При создании таких языков как Java (1995) и C# (2000) учитывали слабые и сильные стороны языков-предшественников (о слабых и сильных сторонах мы еще поговорим). Тот же подход, только в разных вариациях, применялся при разработке языков следующего поколения. Появление языков "новой школы" (Java, C#) и бум объектно-ориентированного подхода (ООП) был обусловлен растущими вычислительными мощностями компьютеров. Подумайте над следующими вопросами (для тех, у кого уже есть опыт работы): почему ООП так активно не использовали ранее (хотя парадигма такая уже была)? Какую проблему решал объектно-ориентированный подход в программировании? Свои ответы я дам позже (в будущем мы детально рассмотрим парадигму ООП и ее применение), а пока вернемся к текущему вопросу.
Рассмотрев два языка из "новой школы", мы должны обратить внимание на дату их появления — это границы 2000-х годов. Что же это значит? Это значит то, что софт на языках "новой школы" только-только начинали создавать. В свою очередь, это говорит нам о том, что весь софт до "новой эры" был написан на языках "старой школы". Это и есть первая часть ответа на наш вопрос, а именно: бОльшая часть софта, на данный момент, написана на языках "старой школы". Как следствие этого существует спрос на специалистов, которые могут поддерживать и развивать уже написанное программное обеспечение. Ведь поддержка существующих продуктов обходится гораздо дешевле, чем создание новых. Особенно когда речь идет о проектах, которые разрабатывались десятилетиями.
Следующий важный момент — это работа с низкоуровневыми абстракциями. Причем не просто работа, а очень быстрая работа. Языки, "исповедующие" ООП, обладают ощутимыми недостатками в части потребления ресурсов (overhead) и скорости работы. Более того, такие языки как Java и C# вам просто не дадут работать с низкоуровневыми сущностями напрямую. Например, пытаясь выйти за границы массива, Вы получите ошибку на этапе компиляции (Compilation Error / Build Error). В лучшем случае компилятор не пропустит эту операцию, в худшем — Вы получите ошибку времени выполнения (Runtime Error), что может привести к нарушению сегментации памяти (Segmentation Fault), краху рабочей системы и ее аварийному завершению. Стоит ли упоминать указатели? Стоит. Для справедливости нужно сказать, что C# позволяет работать с указателями, но это идет вразрез с концепцией языка. Такие языки как C# и Java позиционируются как строго типизированные "безопасные" языки программирования. Строгая типизация (в отличие от Си, где она слабая) позволяет избежать огромного кол-ва ошибок на этапе компиляции (когда мы делаем сборку) и во время выполнения программ.
В отличие от Java и C#, язык Си не ограничивает программиста. Суть авторской задумки заключалась в том, чтобы "не мешать" программисту, так как он лучше знает, что делает. В такой ситуации нам остается лишь доверять компетенции абстрактного "Цукерберга". С помощью языка Си и его политики "не ограничивать программиста", мы можем писать сверхэффективный, кроссплатформенный, малогабаритный код. Но трудность заключается в том, что неограниченные возможности — это большая ответственность. Если Вы не разобрались на 100% в языке Си, это гарантирует 100%-е проблемы в работе вашего софта и его окружения.
2.1K viewsedited 17:55
G
