Пять самых сложных языков программирования на свете
У всех нас только и разговоров, что о C, C+, Java, Python и так далее, а между тем, в природе существуют языки, который можно назвать не просто сложными, а недоступными для понимания большинства программистов. Они называются эзотерическими языками программирования (или эзолэнгами, от скоращенного esolang).
Эзотерические языки служат не для того, чтобы выполнять обычные задачи программирования. Они создаются, чтобы провести проверку концепции или просто в развлекательных целях.
Ниже я привожу список из пяти самых головоломных языков программирования (примечание переводчиков: если у вас есть более достойные претенденты, которые не упоминаются у автора, будем рады услышать о них в комментариях). Я попытался написать программу ‘Hello World!’ на каждом из них – было весело.
Malbolge
Этот язык был придуман в 1998 году Беном Олмстедом. Его принято считать самым сложным из всех существующих. Говорят, что сам автор не написал ни единой программы на своём детище. Код, выводящий на экран слова Hello World!, появился спустя целых два года после того, как Олмстед завершил работу над языком.
Вот фрагмент кода для выведения на экран текста Hello World! на Malbolge:
И вот что он выдаёт:
Этот и все следующие отрывки кода написаны автором и запущены на tio.run
INTERCAL
Джим Лайон и Джон Вудс разработали INTERCAL в 1972 году в качестве пародии на целый ряд языков программирования. Изначально он назывался «компилируемый язык, у которого нет произносимых сокращений».
В INTERCAL специально внедрялись особенности, рассчитанные на то, чтобы усложнять жизнь программисту. Например, в нём применяется модификатор PLEASE и подобные. Компилятор может забраковать код, если PLEASE встречается в нём без должной регулярности. Объяснение? «Недостаточно вежливо». Если же модификатор PLEASE появляется в коде чересчур часто, компилятор отклоняет код как «слишком вежливый».
Вот фрагмент кода для выведения на экран текста Hello World! на INTERCAL:
И вот что он выдаёт:
Brainfuck
Brainfuck появился в 1993 году стараниями Урбана Мюллера, который замышлял его как развлечение для других программистов. Уже из названия понятно, что язык ставит своей целью максимально затруднить понимание происходящего для того, кто с ним работает.
Весь язык состоит из восьми отдельных символов, которые и используются для реализации любых операций. Первый компилятор, который Мюллер разработал сам, тянул всего на 296 байт.
Вот фрагмент кода для выведения на экран текста Hello World! на Brainfuck:
А вот что он выдаёт:
COW был создан Шоном Гебером в 2003 году. Смысл названия этого языка станет вам ясен, когда вы увидите код. По уровню сложности COW сопоставим с Brainfuck. Если сравнивать количественно, в COW представлено на четыре команды больше – в общей сложности их двенадцать на целый язык.
Вот фрагмент кода для выведения на экран текста Hello World! на COW:
А вот что он выдаёт:
Whitespace
Whitespace увидел свет Даремском университете, его авторы – Крис Моррис и Эдвин Брейди. Широкой публике он был представлен на первое апреля в 2003 году.
Базовая идея в том, что для написания программ в языке комбинируются пробелы, табуляции и переводы строки. Все прочие символы интерпретатор игнорирует, рассматривая их как комментарии к коду.
Вот фрагмент кода для выведения на экран текста Hello World! на Whitespace. В нижеприведённом отрывке каждый пробел, табуляция и перевод строки предваряются символами S, T и L соответственно:
Простое сложное программирование
В очередной раз увидел на Хабре статью про сложное дело под названием «программирование». И то, что программирование действительно является делом не простым воспринимается как факт и обычно не требует какого либо подтверждения.
Но понятие «сложность» сродни термину «куча». Для кого-то и пять кокосов это не куча, а кого-то съел один и раз «больше не хочется» — значит для него и единственного кокоса будет много.
Обычно разговоры о «сложности» включают в себя только оценочные суждения без какой либо численной оценки. А так как лично меня интересует вопрос сложности языков программировании, то я решил посчитать сложность реализации компилятора gcc в каких нибудь условных попугаях. Вдруг можно будет увидеть какие нибудь закономерности?
Выбор «попугаев» для измерения
Я не стал придумывать свои или вычислять эмпирические метрики программного кода, и в качестве «попугая» решил взять самую простую метрику SLOC (англ. Source Lines of Code) — количество строк исходного текста компилятора, которая очень легко вычисляется.
Правда, с её помощью можно будет оценивать сложность языка только при следующем допущении — сложность языка должна находится в прямой зависимости от сложности его реализации, если простых синтаксических конструкций будет требовать меньше кода, чем для более сложных.
Конечно, использование метрики «количество строк исходного кода» имеет и свои недостатки, т.к. она сильно зависит от используемого языка программирования, стиля оформления исходного кода и в общем случае не позволяет сравнивать несколько разных проектов между собой.
Но для численной оценки сложности кода в рамках одного проекта, метрика SLOC подходит хорошо.
Методика подсчета SLOC
Поэтому решил взять уже готовый. После быстрого поиска остановился на утилите SLOCCount, которая умеет анализировать почти три десятка типов исходников.
Причем, считает не просто количество строк исходного текста, но и умеет игнорировать комментарии, исключает из подсчета дубли файлов (сравнивает их хеш суммы), а так же выводит расчетную трудоемкость, примерную оценку стоимости разработки анализируемого проекта и другие характеристики.
Меня изначально интересовал объем исходников на С/С++ и может быть еще на Ассемблере, если таких файлов окажется достаточно для много. Но после начала работы очень обрадовался, что не стал изобретать велосипед, а взял готовую тулзу, т.к. она отдельно считала статистику исходных файлов синтаксического анализатора Yacc/Bison (.y), который и определяет фактическую сложность парсера (читай сложность синтаксиса языка программирования).
Старые исходники gcc брал с gcc.gnu.org/mirrors.html, но перед запуском анализатора удалили каталоги других компиляторов (ada, fortran, java и т.д.), чтобы они не попадали в итоговую статистику.
Результаты в попугаях.
Объем кода синтаксического анализатора Yacc/Bison
Объем общей которой базы GCC (только для языков C и C++)
Выводы
К сожалению синтаксический анализатор Yacc/Bison использовался только до 3 версии, а после его использование свелось на нет. Поэтому оценить сложность синтаксиса С/С++ с помощью объема кода парсера можно лишь примерно до 1996-98 года, после чего его стали постепенно выпиливать, т.е. чуть менее, чем за десять лет. Но даже за этот период объем кодовой базы синтаксического анализатора вырос двукратно, что примерно соответствует по времени реализации стандарта C99.
Но даже если не учитывать код синтаксического анализатора, то объем общей кодовой базы так же коррелирует с внедрением новых стандартов C++: C99, С11 и C14.
На графике не видно выраженного пика для С+17 и следующих версий, но предполагаю, что при текущем объеме кодой базы (более 4 миллионов строк только С и С++ кода), несколько тысяч строк, необходимых для поддержки синтаксических конструкций новых стандартов просто незаметно.
Вывод первый — очевидный. Рост сложности инструментов разработки
Фактически на примере проекта GCC можно видеть постоянный и неотвратимый рост сложности рабочих инструментов программистов.
И как бы не говорили о деградации разработки Хорошие времена рождают слабаков, о системном кризисе программного обеспечения, который носит поколенческом характер, но мне кажется тут дело немного в другом.
Обновление персонала и как следствие — необходимость обучения новых сотрудников старым наработкам, тут дело не сколько в передаче знаний, сколько в возможности эти знания усваивать.
Причем возможность усвоения знаний для разных поколений будет разная, но не из-за того, что предыдущее поколение было умнее, а у нового поколения не хватает толку в этом разобрать. Просто изменяется окружение и усложняются рабочие инструменты, по сравнению с теми, которые были в ходу у предыдущего поколения.
Вывод второй — порог входа
Представьте, что нужно «сделать свой сайт». Естественно нужно определить, какую CMS для него использовать и какой брать хостинг. И если с хостингом вопрос решается очень просто, конечно же в TimeWeb, да еще и с бонусом по ссылке, то при выборе CMS приходится подумать.
И если для простых сайтов существуют и простые решения, то для тех, кто не ищет легких путей существует CMS Drupal, который примечателен тем, что имеет фантастически высокий порог входа для начала использования.
Это я к чему? При использовании любого инструмента, как и языка программирования, существует некий минимальный уровень комфортного использования. Причем этот уровень прямо пропорционально связан с размером той целевой аудитории, для которой он предназначен. Точнее, размер возможной аудитории определяется в том числе и требованиями к уровню начальных знаний и квалификации потенциального пользователя.
Итоговый вывод — не утешительный
Если рассматривать увеличение сложности только самого ПО, то это одно дело. Вот к примеру:
А что делать, если сложность программного обеспечения накладывается на тенденцию постоянного усложнения самих рабочих инструментов? Ведь постоянное развитие языков программирования неизбежно повышает порог входа для всех начинающих и только усугубляет проблему сложности разработки ПО.
Другими словами, не зависимо от того, как хорошо документирован код и как полно он покрыт тестами, через некоторое время устаревают используемые инструменты, завершаются жизненные циклы внешних зависимостей, и самое главное, приходят новые люди взамен тех, кто разработал или сумел разобраться в системе.
И у новых людей возникает необходимость разбираться в системе с самого начала, но в других начальных условиях. И из-за этого, сложность изучения системы для всех новых людей будет выше просто по факту того, что изменились внешние условия и усложнились рабочие инструменты, которыми приходится использовать новым сотрудникам.
Понятно, что чем дальше, тем проще уже не будет. Ведь область IT, это среда с самой высокой конкуренцией. И как уж тут не вспомнить Льюиса Кэррола, что его крылатое выражение
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
Какой самый сложный навык в программировании?
Какому навыку в программировании обучить сложнее всего? На этот вопрос постарались ответить пользователи сайта Quora. Самые интересные ответы перевел и опубликовал сайт KV.BY.
Стив Гэринг, технический директор Easil (2017-н.в.)
Есть пара вещей, которые кажутся мне особенно сложными и по-моему именно они отличают разработчика от программиста. Недостаточно сделать, необходимо проверить.
Нередко можно услышать: «Задача X выполнена, осталось только протестировать программу и можно переходить к задаче Y». Однако на следующий же день можно услышать от разработчика: «Я все еще работаю над задачей X, в ней обнаружилось несколько багов и мне придется исправлять их весь день».
Большинство разработчиков не считает тестирование частью своей работы. Для них это обременительная обязанность, которой должны заниматься тестировщики. То, что выполнено с точки зрения разработчика, как правило проваливается на стадии тестирования. Однако если задачу выполнял программист, проблем на стадии тестирования возникнуть не должно.
Один мой бывший коллега ненавидел тестирование, но я настаивал на том, чтобы он проводил более тщательную проверку продукта на стадии разработки. В конце концов коллега ушел и стал руководителем собственной команды и проекта. Несколько месяцев спустя он сказал мне: «Теперь я понимаю, почему ты заставлял меня заниматься тестированием, ведь оно действительно полезно и приносит значительные плоды». Ваш код должен читаться легко, как книга.
Код не должен выглядеть, как сложное алгебраическое уравнение, он должен легко читаться. Каждый его отрывок должен быть понятен без необходимости обращаться к ссылкам и подсказкам. Переменные и идентификаторы метода должны быть наглядными, а операторы – лаконичными.
Я видел функции с именем `codeToRun (id)`. Можете ли вы догадаться, что делала эта функция? Блокировала 60 строк кода, ожидая загрузки изображений в документе. Поэтому, когда я столкнулся с этим, мне пришлось залезть в код, найти эту функцию и прочитать те 60 строк кода, чтобы понять, какого черта происходит. Если бы функция называлась `blockForImages`, я мог бы избежать этих манипуляций.
Жаль, что у меня не сохранился пример этого кода, но просто скажу, что самое худшее, что я когда-либо видел, это одна строка JavaScript, на которую у меня ушло примерно 15 минут, просто чтобы ее понять. Это была одна строка, 7 одиночных символьных переменных и 3 функции. Имя функции не дало мне никаких указаний на ее цель, код внутри был невероятно запутанным, и когда я посмотрел ссылки на функцию, входы и выходы также были одиночными символьными переменными. Я должен был прочитать примерно 50 строк кода, чтобы понять эту единственную строчку.
Причесанный, читабельный код сэкономит вашей команде и всей компании сотни часов в год, а также серьезную денежную сумму, если придется заниматься отладкой уже функционирующего продукта.
Райан Гедвилл, сооснователь компании (2016-н.в.)
Умению абстрактно мыслить. В конце концов все ПО выражено в двоичном коде. А сам по себе двоичный код – эта абстракция, созданная людьми для моделирования схем. Языки программирования, которые вы используете, являются частью программного обеспечения с багами, написанные на языках программирования, состоящих из ПО и багов.
Некоторые языки программирования написаны сами на себе – например, Smalltalk. Это приложение рекурсии, которая является результатом чистого объектно-ориентированного программирования.
Объектно-ориентированное программирование – это абстракция, и программные языки изо всех сил стараются вплести эту абстракцию в свою структуру.
Мой опыт показывает: если в долгосрочной перспективе ориентироваться на эти абстракции, довольно быстро можно стать хорошим программистом. В действительности написание кода подобно складыванию мозаики у себя в голове с последующим внедрением синтаксиса. Если язык вам знаком, уложить его в рамки синтаксиса довольно просто.
Переписывайте программное обеспечение на разных языках. Попробуйте функциональное программирование, попробуйте C, попробуйте распространять свое программное обеспечение через сеть серверов. Одна и та же задача выполняется с помощью кода, но мыслительные процессы при этом сильно различаются.
Это позволит вам улавливать связи и постепенно развиваться как инженеру, и это одна из самых трудных вещей для изучения, которую к тому же очень трудно объяснить. В любом случае, чем больше вы пишете кодов, тем лучшим специалистом становитесь. Но всегда думайте о том, насколько это будет полезно для решения задач в будущем.
Джонас Меллин, преподаю программирование с 1990
Работать как настоящая команда, то быть частью команды, оставаясь при этом личностью со своей позицией и ценностями. Это подразумевает действовать сообща, помогая друг другу и принимая совместные решения по выполнению задач.
Создавать достаточно комфортную среду для стимулирования творчества. В этом каждый должен вносить свой вклад.
Расставлять приоритеты. Особенно важно принимать взвешенные решения, принимая во внимание все аспекты, что особенно успешно удается делать в команде.
Анализировать влияние тех или иных изменений на существующее положение дел.
Джейсон Русс, программист, сертифицированный педагог, начинающий писатель
Любому навыку, подразумевающему использование естественного языка, включая умение правильно называть абстракции и грамотное составление встроенной документации.
Очень часто комментарии к коду и идентификаторы, с которыми я сталкиваюсь, избыточны, неопределенны, неоднозначны, чрезмерно конкретны (например, излишние данные о внедрении или ориентация только на одного клиента) или просто семантически неточны.
К сожалению, последний пункт в этом списке является не только самым опасным и вопиющим нарушением, но и самой частотной ошибкой, которую к тому же нелегко исправить. Не считая варианта отправить разработчиков обратно на школьную скамью, чтобы они подтянули английский, я не знаю, как еще справиться со всеми недопониманиями и потерей времени, связанными с банальной безграмотностью.
Имейте в виду, это не проблема конкретной организации, занимающейся программированием, это проблема всей отрасли. Вероятнее всего она возникает в следствие естественной дихотомии между правым и левым полушариями мозга и между учебными планами инженерных и гуманитарных учебных заведений.
И действительно, разработчики, способные создать идеальный алгоритм, идеальное регулярное выражение или идеальную структуру данных, кажутся неконкурентоспособными по сравнению с теми немногими, способными подобрать слово или составить предложение, которое идеально передавало бы весь объем информации.
Программирование — это сложно
Большинство новичков в программировании рано или поздно сталкивается с такой чарующей фразой: «Программирование — это просто, ему может научиться любой». Эта фраза сопровождается угрожающим сообщением о том, что людям, занимающимся гейткипингом, надо прекратить. Этой статьёй я хочу сказать, что это неправда. Программирование — это сложно, оно не для каждого, и хотя сейчас им может заняться каждый, большинству определённо не стоит писать код.
Программирование легкодоступно
Когда глупые люди говорят, что программировать просто, что им может заниматься каждый, они на самом деле имеют ввиду доступность сферы программирования. Если у вас есть простейшее средство доступа к Интернету, то достаточно легко получить доступ к ресурсам для изучения. Ни одна из наук не доступна настолько, как компьютерная наука, и большинство работ по ней выложено в открытый доступ — компьютерная наука процветает в Интернете, и хотя отдельные её ветви закрыты, большинство контента доступно свободно и процветает благодаря этой доступности. Вы можете скачивать компиляторы, редакторы, IDE, даже получить доступ к документации, обсуждать с другими людьми свои проблемы, и так далее. Это огромное сообщество, уровень гостеприимности и открытости которого несравним с любой другой наукой в истории человечества.
И в самом деле, вам не нужно знать много, некоторые программы можно написать буквально через полчаса знакомства с программированием. Программирование доступно настолько, насколько не доступна ни одна другая наука.
Но легкодоступность не означает простоту изучения. Если я могу смешать три ингредиента и сделать омлет, то это не делает меня шеф-поваром. Я могу готовить несколько блюд, но никогда не скажу, что готовка — это просто. Приготовление пищи — это сложная задача, требующая терпения и внимания к деталям, много знаний и опыта.
Программирование — это любопытное сочетание творчества и точных наук; но никто и никогда не говорил, что творчество — это «просто». Некоторые вещи легко осваиваются некоторыми людьми, другие сложны для понимания.
Некоторые аспекты программирования просты
Да, в этом можно не сомневаться: отдельные аспекты просты. Существуют вещи, которые вы можете сделать, в конечном итоге получив, например, скелет приложения для блога. Любой (под опытным руководством) может сделать профессионально выглядящую веб-страницу за первые часы изучения HTML. Можно легко задать вопрос и найти решение на StackOverflow, можно запросто скопипастить решение на свои веб-страницы.
Существует множество туториалов для начинающих, даже для абсолютных новичков, и некоторые из них созданы новичками. Программирование — в высшей степени гостеприимная к новичкам область.
Однако для разных людей простыми бывают разные вещи. То, что мне кажется невероятно сложным, другим кажется невероятно простым. То, что кажется простым, становится проблемой для других. Нет консенсуса о том, что для кого легко, но для всех есть простые вещи, зависящие от того, по какому пути обучения они шли. Тем не менее…
Большинство аспектов программирования сложно
Такова правда: если человек начинает делать нечто более сложное, чем простая веб-страница или простая демо-программа, всё становится сложным, и чем больше вещей соединяется воедино, тем более сложной и утомительной становится задача. И именно этого вам не скажет лжец, уверяющий, что «программирование — это просто». Решать программные головоломки сложно, особенно, когда они не задумывались как головоломки.
На самом деле, при правильном подходе большинство аспектов программирования сложно, даже если поначалу и кажется простым. Причина в том, что у вас есть сложные фрагменты, которые нужно объединить и заставить их работать. И сложнее всего, когда человеку приходится писать эти сложные фрагменты с нуля. Всё кажется простым, потому что мы видим людей с пяти-, десяти- и двадцатилетним опытом, делающих вещи, которые просты для них, потому что в процессе их создания они совершили все возможные мыслительные ошибки, обеспечив таким образом себе защиту от этих ловушек.
Самозванство и мошенническое позитивное мышление
Как часто вы слышали о синдроме самозванца? Если вы слушаете выступление на тему «программирование — это просто», то, вероятно, слышали о нём, и часто на эти темы говорят одни и те же люди. Синдром самозванца — это когда человек чувствует себя недостаточно компетентным для работы, за которую ему платят, и ощущает, что он не заслужил свой успех; но слышали ли вы о случаях, когда люди на самом деле сталкивались с кажущимся непродуктивным топтанием на месте, при котором им приходится исправлять или совершенствовать результаты собственной работы, или когда они не могут быстро найти ответ на Stack Overflow. Чаще всего я слышу о самозванцах в программировании, когда их терпение лопается, когда они больше не могут соответствовать нереалистичным стандартам, которые они создали для себя, когда они не могут двигаться вперёд со скоростью, к которой привыкли. (У меня есть собственные претензии к синдрому самозванца, но об этом в другой раз.)
Угар позитивности, мифологии «всё просто» не говорит вам ни слова о тех моментах, когда всё становится невероятно сложным, когда требуется прилежная работа и постоянные усилия. Когда вам не могут дать ответа другие люди, то остаётесь только вы и код других людей или, что хуже всего, ваш код. В такие моменты иногда приходится переосмысливать целые архитектуры, потому что некоторые аспекты не прошли проверку реальностью.
Я сказал, что сфера программирования плодородна для новичков, и это правда. Но то, что плодородно для злаков, плодородно и для сорняков, и для них особенно. Нам нужно говорить о таких людях, пользующихся преимуществами плодородной почвы. А поскольку в этой сфере множество новичков, то там есть множество людей, пользующихся ими.
Это происходит множеством различных способов; некоторые из таких людей даже не осознают, что делают это, они просто инстинктивные деляги, продающие свои навыки по слишком большой цене. Обычно они выглядят так: двухлетний опыт работы в сфере разработки ПО, пишут книги и раздают советы, иногда за приличную цену. Мы встречаем их на конференциях, их рекламируют в статьях или в других медиа, иногда они разыгрывают карту «культурного разнообразия» (diversity), иногда — карту успешного новичка, продвигая себя и пользуясь доверчивостью толп начинающих.
И чтобы создавать ложный имидж в этой сфере, даже не нужно быть абсолютным лжецом. Достаточно играть с чувствами людей. Например, говорить им нечто ошибочное, что люди хотят слышать. Нужно подобрать ключевые слова, которые будут льстить большинству аудитории; «программирование» — это одно из них, потому что программирование — крайне размытое понятие, а получить звание «программист» желают многие, так же, как и звание «сениор», к которому стремятся люди, мечтающие стать сениорами в свои двадцать с небольшим лет. Нужно найти ярлык, лестный вашей аудитории, и применить его к ней. Именно так мы получаем лозунг «программирование — это просто» (это не так), или «HTML — это язык программирования» (это не так), или «программирование — это мастерское пользование поиском в Google/StackOverflow».
Чтобы подчеркнуть своё утверждение, затем вы демонстрируете врага. «Не позволяйте никому говорить, что это неправда» — простой, но эффективный способ внушить аудитории образ мышления «вы против враждебного мира». Неплохо также использовать словечко «гейткиперы», ведь рассуждения о привилегиях и людях, охраняющих их от аудитории, привлекательны. Они не дают вам подняться, они несправедливы, они лгут о трудностях, они заставляют вас заниматься сложной, скучной работой. Такая методика применима не только к программированию, это простая техника манипуляции толпой — если есть враги, то это простой способ сплотить аудиторию против них. Но какой бы ни была эта методика, основная задача манипулятора — размытость содержимого сообщения, чтобы было сложно его опровергнуть.
Давайте обсудим мои примеры. На объяснение лозунга «программирование — это просто» мне уже понадобилось 1385 слов, а статья ещё не закончена. Объяснить «HTML — это язык программирования» в чём-то сложнее из-за нечёткого значения термина «программирование». Строго говоря, HTML не является реальным программированием, это язык представления разметки. Он является неполным описанием того, как выглядит и что содержит веб-страница. HTML — обязательный для любого связанного с вебом проекта инструмент, но он не используется изолированно, программирование происходит не на нём. Но если кто-то говорит вам, что HTML — это язык программирования, то обычно защищает своё заявление тем, что гейткиперы ограничивают значение слова «программирование». При этом говорящие это редко заинтересованы в изучении истинного значения собственных слов. Как я говорил, «программист» — это звание, и подобно другим почётным званиям, оно заставляет людей, особенно некомпетентных, защищать его.
Иллюзия «я могу сделать то же, что и ты»
С заявлением «программирование — это мастерское пользование поиском в Google/StackOverflow» всё сложнее. Потому что это и правда, и ложь одновременно. Мастерское владение поиском в вебе — очень важный навык современного разработчика. Я учился в мире, где этого ещё не было, где не существовало Google, где человеку нужно было изучать документацию и иногда читать сотни страниц, чтобы понять, как всё работает. И это если документация была; в противном случае приходилось только пробовать, терпеть неудачу и пробовать снова. Однако сегодня пробовать не нужно, существуют готовые тулкиты, библиотеки или языки программирования (и даже их коммерческие версии), чётко заточенные на поиск ответа. Документация теперь предназначается не для чтения пользователями, а для индексации поисковыми движками и для того, чтобы люди работали с ней при помощи поисковых движков. Однако больше всего современные инструменты полагаются на сайт ответов Stack Overflow.
На самом деле, зависимость людей от Stack Overflow — это, вероятно, самое пугающее, что произошло с сообществом программистов за последние 10 лет. Stack Overflow — это мощный костыль, мешающий вам двигаться самостоятельно, потому что слишком легко искать ответы на нём. А когда люди перестают мыслить самостоятельно, то начинают писать неразумные вещи.
Если вы, как новичок, смотрите, что делают опытные разработчики, то это выглядит простым. Кажется, то, что делают они, может сделать каждый. Это выглядит совершенно посредственно. Существует миф о суперпрограммистах, делающих всё по-своему. Голливуд представляет их как людей, вводящих код со скоростью света, потому что единственный способ продемонстрировать высокий навык персонажа в своём деле — показать, что он справляется с работой быстрее, чем кто-либо другой (Голливуд показал бы человека, лучше всего отсчитывающего десять секунд, как того, кто справляется за пять). Смысл в том, что это выглядит просто, но на самом деле это не так. Потому что опыту новичка не хватает кругозора, сосредоточенности на действительно важном. Новичку научиться считать до десяти мешает только незнание синтаксиса цикла, для опытного разработчика синтаксис — это то, что замедляет его реализацию выполнения операций с коллекцией отфильтрованных данных.
Утверждение «программирование — это просто» не даёт людям развиваться
Этот пост возник благодаря представленному ниже твиту (и этой статье на румынском, но я остановлюсь на англоязычном твите.
— Когда я говорю кому-то, что я программист, то меня сразу начинают считать суперумной. Ребята, можем ли мы как-то вместе попробовать объяснить людям, что кодить не так сложно. В первую очередь, это в буквальном смысле гугление и устранение сделанных нами ошибок. Писать код может каждый.
— Я понимаю задачу этого поста и знаю, что он был написан не из злого умысла, однако учиться кодить сложно и это утверждение «писать код может каждый»/«кодинг — это не так уж сложно» заставляло меня чувствовать себя тупой, когда я была новичком.
Люди чувствуют себя глупыми, когда им приходится разбираться с собственным творением и пытаться его исправить, заставить работать на сценариях реального мира, которые они не всегда предусматривают, когда впервые пишут код. Позитивность не поможет тебе, когда помощь нужна на самом деле. Единственное, что ты можешь использовать — свою смелость, но что делать с необоснованной смелостью? Как быстро положительный настрой и необоснованные запросы падут перед мрачными реалиями работы программистом?
Автор первого твита сказала что-то в духе «люди считают меня умной, потому что я программист» и «главное в гуглении и исправлении своих ошибок». Но на самом деле программирование не об этом, и такой преувеличенный, ограниченный взгляд говорит мне, что её опыт в разработке ПО достаточно мал. И знаете, что пугает? Она работает над сайтом под названием «thecodinginterview.com», то есть является популярным источником советов для начинающих. И я даже не хочу начинать тему того, насколько аморально это мошенничество с «coding interview».
Позитивное мышление безотказно, потому что позитивность никогда не подвергают проверкам; и она полностью пропадает, когда ситуация действительно становится серьёзной. Все ошибки — ваша вина, потому что «кодить может каждый» и «кодинг не так сложен». Когда ты вынужден столкнуться со своими ошибками, ты остаёшься в одиночестве, потому что никакая чушь о позитивном мышлении не может их устранить.
Установка «программирование — это сложно» не должна быть пугающей
Кое-кто утверждает, что если врать новичкам о том, насколько на самом деле сложно программирование, то это их отпугнёт. Не уверен, что людей когда-нибудь останавливал тот факт, что выбранное ими занятие сложно. В конце концов, бОльшая часть нашей поп-культуры посвящена героям, выполняющим сложные задачи. Мне кажется, что именно эта культура изнежила мозги людей, считающих, что если результат не будет мгновенным, то он не стоит усилий. Но когда я начинал программировать, никто не говорил мне, что программировать легко. Я ожидал, что оно будет сложным.
Я знаю, что у многих есть одержимость «достигаторством», они хотят овладеть программированием, стать сениором в 22 года. Я удержался от преследования столь глупой затеи. Я знал, что программирование сложно и что достижение моей цели может быть невозможным. В каком-то смысле, так и есть: я изучал программирование, чтобы уметь писать собственные игры, и спустя более полувека я так и не создал ни одной. Но это дало мне чёткое понимание масштаба моего дела.
Я говорю это не для того, чтобы демотивировать начинающих. Статья всего лишь должна подготовить их к тому, что ждёт их впереди. Так что если вы хотите сказать что-то новичку, то скажите следующее: «В программировании есть простые и сложные вещи. Если ты будешь достаточно терпелив, то со временем сложные вещи станут интересными, а простые станут сложнее».
Но не говорите ему, что программирование — это просто. Это не так.
На правах рекламы
Заказать у нас сервер очень просто! Воплощайте любые идеи и проекты с помощью наших VDS с мгновенной активацией на Linux или Windows. Сервер готов к работе через минуту после оплаты!