Какое влияние оказывают языки сценариев на начинающих программистов? [закрыто]

У меня была беседа с одним из моих учителей на днях.

Мы обсудили влияние, которое простые языки сценариев (такие как Python или Ruby) оказывают на начинающих программистов.

Он утверждал, что языки сценариев порождают неаккуратные методы кодирования, потому что новички не понимают, что происходит "под капотом". Он также привел другие примеры того, как языки сценариев часто заставляют программиста пренебрегать заботами об эффективности, управлении памятью, сложности операций и т. Д.

Я утверждал, что языки более низкого уровня могут быть слишком сложными для некоторых людей, и они могут сдаться, прежде чем у них появится страсть к программированию. Когда я начал изучать свой первый язык программирования (C), я пришел к указателям и сдался, потому что понятия были слишком сложными (в мою защиту мне было всего 14 лет). Если бы не Java, я бы не стал программистом! Если бы я начал с более простого языка, а потом углубился, я бы не сдался и выучил бы столько же, сколько начал с C.

Класс закончился прежде, чем любая сторона была полностью исследована.

К этому моменту я проповедовал, что начинающие должны начинать с языков сценариев, а затем копать глубже; но после этого обсуждения я начал задаваться вопросом, было ли это ошибочным мышлением.

Итак, какое влияние оказывают языки сценариев на начинающих программистов?

Я не согласен. Во-первых, языки сценариев находятся на более высоком уровне абстракции, и в этом нет ничего плохого. В начале каждый просто пытается изучить принципы. На самом деле, я бы сказал, что выбор языка более низкого уровня может привести к плохому кодированию, поскольку нужно разобраться с некоторыми деталями, прежде чем понять их. Вместо этого с более простым языком можно начать писать чистый и лаконичный код с самого начала.

Во-вторых, на этих языках есть чему поучиться. Что касается изучения языка, я бы сказал, что C легче, чем Python. Нужно иметь дело с указателями или заботиться о строках, но есть много других понятий, которые нужно изучить в Python. Понимания, объектная ориентация, отражение, магические методы, первоклассные функции, лямбды, итераторы и генераторы, метаклассы - все это является частью языка.

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

Неважно, с чего начать. Это имеет значение, куда вы идете после начала.

BASIC, возможно, не самый элегантный язык на планете, но он охватывает основы процедурного программирования, и этого достаточно, чтобы начать.

Я начал с Бейсика. Я не остался там.

Ваш учитель прав, за исключением того, что он предполагает, что его последствия - плохие вещи.

Если вы рассматриваете изучение языков как чисто академическую деятельность для изучения работы компьютеров, то он прав. Если вы смотрите на них как на способ добиться цели, то вы правы.

Я думаю, что «язык сценариев» - ужасное слово, которое чрезвычайно устарело или в лучшем случае подходит для класса предметно-ориентированных языков. Ваш учитель просто выравнивает все, что ему явно не хватает понимания, в ось зла.

Разумное различие заключается в том, что между языками высокого уровня и языками низкого уровня или между статически и динамически типизированными языками, которые действительно ортогональны.

Ассемблер имеет низкоуровневую динамическую типизацию (если говорить о типах вообще имеет смысл), C - низкоуровневая статически типизированная, Ruby - высокоуровневая динамически типизированная, Haskell статически типизированная. Java не имеет ни высокого, ни низкого уровня, статически типизированного, C ++ - и высокого, и низкого уровня, статически типизированного. И так далее.

Можно только обсудить, какие парадигмы больше подходят программисту начального уровня.
Я совершенно уверен, что программирование на низком уровне, вероятно, не таково. Возможно, это было когда-то в начале 90-х годов, когда с его помощью можно было получить интересные результаты в разумные сроки.
Но программирование подогревается страстью. Страсть питается наградами. Поэтому программисты начального уровня должны начинать с полезных инструментов. Низкоуровневые инструменты больше не приносят пользы, потому что есть огромное множество высокоуровневых инструментов, которые дают вам тот же результат за короткое время.

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

Вот как мы думаем. Человеческий мозг может обрабатывать только ограниченное количество информационных «единиц», но степень абстрактности не имеет большого значения при квантовании информации. Например: чтение выражения «34 * 75» для нас проще, чем его вычисление, тогда как для компьютеров все наоборот. Распознать (и тем самым абстрагировать) группу черных пикселей в волнистую линию, которую затем можно распознать (и тем самым еще раз абстрагировать) как отдельную цифру, - это огромный труд.
Моя бабушка понимает идею открытия файла. Однако у нее нет понимания ниже этого уровня. И, честно говоря, если бы ей пришлось изучить это, сначала изучив внутреннюю работу аппаратного обеспечения и операционной системы, а что нет, она бы никогда туда не добралась.

Есть много людей, которые слишком усложняют вещи, потому что их никогда не учили думать с точки зрения ясных, лаконичных и, тем самым, элегантных решений, но они слишком много времени удосужились обмениваться деталями низкого уровня и решать возникающие проблемы. Обучение людей мыслить как компьютеры - худший из возможных подходов к программированию.
Ценность программирования заключается в поиске решения проблемы. Выражение его в виде кода на самом деле является более скучной, механической задачей, и ее следует просто выполнять с использованием любых подходящих инструментов.

О, и не волнуйтесь о том, что не поняли указатели. У меня была примерно такая же проблема в том же возрасте. Проблема здесь также заключается в отсутствии абстракции. Классически вы узнаете об указателях из какой-то книги на C, и пока вы изо всех сил пытаетесь их понять, это идет рука об руку с распределением памяти и, следовательно, со стеком, кучей памяти и так далее. Абстрактная концепция указателей - косвенное. Переменная, которая содержит индекс в конкретном массиве, является именно этим (на самом деле это действительно то же самое в C, где конкретный массив - это ваше адресное пространство), и вам не нужна арифметика указателей для этого.
Это просто для иллюстрации того, что выбор высокого уровня абстракций делает вещи намного проще для понимания.

РЕДАКТИРОВАТЬ: и когда дело доходит до набора текста, я предпочитаю статически типизированные языки. И я думаю, что программисты начального уровня должны четко понимать концепцию типов (которая является абстрактной).

Нет ничего простого в Python. Взгляните на Юникод и метапрограммирование.

Я вижу другую, гораздо более глубокую проблему.

Unityped языки не заставляют обращать внимание на типы, думать на типах. Это хорошо, пока у меня есть небольшие скрипты с некоторыми строками и числами, которые конвертируются друг в друга, не замечая этого. Но придет день, когда это сломается. Внезапно программа сломается, и каждое быстрое исправление приведет к ее поломке.

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

Я по-прежнему утверждаю, что формальное обучение и наставничество являются гораздо более важным фактором, чем выбор языка для качества кода для начинающих. Однако, если бы мне пришлось выбирать первый язык для начинающих, я бы выбрал python для программистов-самоучек и C ++ для обучения в колледже.

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

Некоторые из этих основ просто очень трудно освоить, если вы самоучка, пока вы не получите некоторый опыт за пояс. Кроме того, вам обычно нужно как можно скорее сделать что-то полезное, и вы можете получить теоретическую поддержку по мере необходимости, хотя вы рискуете никогда не узнать больше, чем минимум при таком подходе. Вот почему я рекомендую такой язык, как python.

Мы видели это с другой стороны в колледже, и я думаю, что это полезно. * Мы начали на низком уровне. Указатели, управление памятью, массивы символов ... Так что да, мы начали с C. То же самое с алгоритмами: сначала реализуем связанный список, хеш-таблицу, дерево ... И только потом используем стандартные библиотеки.

После этого мы подошли к более мощным языкам, таким как Java, C # или Perl. Но с преимуществом знать, что происходит под поясом.

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

Языки сценариев не делают программистов небрежными. Отсутствие ясности в понимании проблемной области (например, бизнес, который обслуживает программа) - вот что является причиной небрежности.

Как гласит старая поговорка: «Вы можете писать на языке COBOL на любом языке», хотя я подозреваю, что когда все типы данных выглядят одинаково , становится все труднее понять, каковы основные аспекты вашей программы, что является основной особенностью COBOL. зации.

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

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

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

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

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

Просто помните, что ни один инструмент не подходит для каждой работы. Выберите инструмент, наиболее подходящий для ситуации. Это относится к языкам программирования так же, как к любому инструменту.

Я с вашим учителем, но также с @Singletoned, когда он говорит, что ваш учитель полагает, что последствия (например, отсутствие знаний о производительности) плохие.

Я думаю, что начинать с C лучше, чем начинать с языков сценариев. Как учитель, я бы сконцентрировался на всей этой вещи архитектуры фон Неймана (ALU, регистры, память, порты ввода / вывода, ...), перешел прямо к указателям (извините, это действительно ключевая концепция [не выпускать ссылки (т. е. указатели) в языках ВМ являются основным источником утечек памяти]), попадаются в некоторые структуры данных (дерево, связанный список, хэш-таблица ¹ ), а затем ... поднимают уровень абстракции до чего-то другого (ОО, функциональное программирование, что-то - строгие правила статической типизации , yo \ m /, так что никаких «языков сценариев»> :().

¹ Хм, может быть, я согласен с вашим учителем в отношении производительности, в конце концов.

Я думаю, что лучше всего начать с модульного языка, а затем перейти к более сложным вещам, в мои дни мы начинали с Pascal и COBOL и пытались понять, что означают подпрограммы, переменные потока управления и т. Д. Только после того, как я освоился с Pascal, у меня даже возникло желание переключиться на такие языки, как C / C ++, и освоить все другие приемы, которые являются дополнительным дополнением для младшего программиста.

Вы оба правы.

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

С другой стороны, вещь номер один, которую я ищу в интервью, не является идеальным пониманием, это то, что они любят делать вещи. Когда я только начинал, компьютер, который делал что-то, был довольно впечатляющим, поэтому мои маленькие Apple Basic и 6502 ассемблерные штуки казались мне действительно потрясающими. Но в наши дни компьютеры делают много удивительных вещей, так что я думаю, что это хорошо для людей, чтобы начать с довольно высокого уровня, если это то, что им нужно, чтобы зацепить.

В принципе, я думаю, что начинать с мелкого конца бассейна можно только до тех пор, пока вы в конце концов не пойдете в глубокие воды.

Во-первых, я определенно начинаю с языка более высокого уровня абстракции. В настоящее время я бы порекомендовал Python. Наиболее важной причиной выбора языка сценариев в качестве первого языка является то, что вы можете легко собрать что-то, что работает. Как Джо упоминает в своем вопросе, номер один, становясь программистом, заключается в том, что у вас есть мотивация идти дальше и копать глубже. Эта мотивация достигается, когда вы можете создавать работающее и полезное программное обеспечение.

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

С самого начала должно быть ясно, что языки программирования - это всего лишь инструменты для выполнения работы. Очень важно правильно выбрать инструмент для конкретной задачи. Я думаю, что для начинающего программиста язык сценариев высокого уровня поможет подчеркнуть этот момент. Язык более высокого уровня даст более широкую перспективу и мотивирует программиста копаться глубже.