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

18

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

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

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

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

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


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

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

joe_coolish
источник
8
Я не хочу быть задницей, но grammar.quickanddirtytips.com/affect-versus-effect.aspx
Singletoned,
4
Я научился водить машину с автоматической коробкой передач. Позже я получил один с механической коробкой передач. Это заняло некоторое время, и мне повезло, что мне не пришлось изучать сцепление и переключаться вместе со всем остальным.
Дэвид Торнли
2
@Singletoned: правда. Каким-то образом мне пришлось подумать о xkcd.com/326, хотя ...
2
Заставил
P.Brian.Mackey
4
Лично я считаю неестественным учиться программировать на низких, а затем высоких. Мы учимся ползать, потом ходить, бегать, разговаривать, писать. Не уверен, что логика для изменения естественного порядка в колледже. Я обычно просто слышу, как люди приходят к выводу, «потому что, если мне было трудно учиться, тогда это должно оставаться для вас трудным». Даже Джоэл сказал это. Я думаю, что цикл никогда не закончится.
P.Brian.Mackey

Ответы:

26

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

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

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

Andrea
источник
1
+1, хотя я не думаю, что C легче изучать, чем Python в любом смысле. Возможно, в целом будет меньше понятий, но вы узнаете больше за то же время с Python. И, конечно, если C слишком прост, всегда есть C ++, обучающий вас сложностям языков высокого и низкого уровня. ;)
Мартин
+1, это было мое мышление! Я хотел бы прочитать это перед классом :)
joe_coolish
22

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

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

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

Стивен А. Лоу
источник
+1 за идеальный ответ - показывать кратко, как неуместен исходный вопрос! (По стечению обстоятельств я тоже начал с Бейсика ;-)
Петер Тёрёк
5
Меня удивляет, как много людей остаются там ..: o /
Гари Уиллоуби
1
Excellect ответ. Кратко, точно и точно. Я начал с Бейсика.
Майкл Райли - AKA Gunny
11

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

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

Singletoned
источник
6
Должен не согласиться с вами. Последствия - плохие вещи, потому что следствием является невежество. Это означает, что в конечном итоге что-то сломается, и проблема окажется на более низком уровне абстракции, чем вы понимаете, и поэтому вы не будете знать, как это исправить. Это всегда плохо.
Мейсон Уилер
6
Должен согласиться с вами. Последствия незнания того, что происходит под капотом, - глубокая простота и прямолинейность выражения, не беспокоясь об аппаратных нюансах. Более низкие уровни абстракции предназначены для разработчиков языков, а не разработчиков приложений.
S.Lott
1
@ Мейсон: Абсолютно. Однажды я заработал очень значительную сумму денег, спасая ослов команды программистов, которые не имели ни малейшего представления о том, что на самом деле происходит под капотом, и поэтому не могли заставить свою производственную систему работать хорошо или работать надежно. (Однажды, потому что такая работа - отстой. Жизнь слишком коротка!)
Уильям Пьетри,
1
@ Мейсон - я согласен с тем, что вы сказали, что важно иметь эти знания, если вы собираетесь программировать профессионально. Я нашел свои знания указателей, дискретных структур и лямбда-исчисления чрезвычайно ценными. Я застрял в командах, где члены моей команды не обладали этими навыками, и в итоге они создавали слишком сложный или очень глючный код. только потому, что они не знали лучше. Кажется, что иногда колледжи дают студентам CS слишком много молока и не хватает мяса, но, с другой стороны, если они кормят начинающих программистов мясом, они рискуют выпасть.
joe_coolish
1
@Joe: По словам Джоэла, отстранение тех, кто не может справиться с этим, - вот и весь смысл. И поскольку не только компьютерный программист, но и пользователь компьютера , тот, кто регулярно работает с ужасными программами, которые, как я могу только предположить, были созданы некомпетентными программистами, я действительно хотел бы, чтобы бит «заставить их выпадать» был более успешным!
Мейсон Уилер
5

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

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

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

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

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

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

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

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

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

back2dos
источник
3

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

Кристофер Махан
источник
Я согласен, что Python может быть очень сложным и ОЧЕНЬ мощным. Но основы (манипуляции со строками, манипуляции с массивами и т. Д.) В Python намного проще, чем в C.
joe_coolish
1
С Python очень просто начинать, и многие повседневные задачи на порядок проще, чем, например, в системных языках. Нет, язык в целом, его кровавые детали и расширенные возможности не просты (это относится ко всем не игрушечным языкам). Но это был не вопрос.
1
Тогда почему мой if searchstring.lower () в filecontent.lower (): не работает? из-за bom в UTF-16LE sql файле в tfs на windows с Python2.7. Не было весело получил это работает. заняло несколько часов. string.find () тоже не работал ... Аааааа!
Кристофер Махан
1
Как Unicode проще в C?
Ден04
3

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

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

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

Инго
источник
6
Но Python и Ruby строго типизированы. Это ортогонально тому, чтобы быть динамически набранным. Строки и числа не неявно преобразовать друг к другу.
dsimcha
3
@dsimcha: Да - И как это опровергает сказанное @Ingo?
Джим Г.
1
Потому что этот вопрос в основном о Ruby и Python. Я думал, что он подразумевает, что он думает, что Ruby и Python слабо напечатаны, что является распространенным недоразумением.
Дсимча
1
@ davidk01 - это моя точка зрения: значения имеют типы, хотим мы этого или нет. Но в динамически типизированных (если вам больше нравится этот термин) языках переменные не имеют. Вместо этого проверка типа выполняется во время выполнения, чтобы различать множество вариантов Unitype.
Инго
2
@Ingo: я, по крайней мере, имел обыкновение находить пользователей Common Lisp, которые думали, что отсутствие статической типизации является преимуществом (фактически, необязательная статическая типизация, используемая либо для проверки ошибок, либо в целях повышения производительности), поскольку она ускоряет разработку и что ошибок, которых можно было бы избежать при статической типизации, на практике оказалось не так сложно найти и исправить. Я не видел ничего, кроме мнения, так или иначе.
Дэвид Торнли
2

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

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

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

Карл Билефельдт
источник
2

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

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

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

Карра
источник
1

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

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

Фарли Найт
источник
1
Попробуйте, прежде чем подозревать. Основное отличие состоит в том, что вам наплевать на то, где это Fooили Barчто-то совершенно другое, если вы можете .frobnicate()это сделать в любом случае. Без явных интерфейсов.
Я довольно хорошо знаком с динамическими языками, так как моя повседневная работа связана с Ruby on Rails. И да, это главное соглашение в динамичном языковом сообществе. В общем, это называется «утки». В исследовательской литературе они называются структурными типами, и есть некоторые синтаксические соглашения, которые могут показать вам, как выглядит «крякаемый тип». Мало того, есть системы типов, которые могут их распознавать и проверять, что ваша программа относится к уткам с добротой.
Фарли Найт
Я знаю о структурных типах и считаю их довольно изящной идеей. Но поскольку нет ни одного зрелого, удаленно широко используемого языка (база пользователей уровня O'Caml была бы хорошим началом), который бы использовал их, я не считаю их практической альтернативой динамической типизации. Печально, но факт.
Широко используемые языки этого не делают, но это не мешает вам загружать свою собственную систему типов в широко используемую. Я уверен, что вы видели статьи на такие вещи, как вывод типов для динамических языков.
Фарли Найт
Опять же, я не считаю что-то используемое мной и парнем по соседству практической альтернативой. Программисту нужны такие вещи, как библиотеки, стабильный синтаксис, инструментарий и т. Д.
1

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

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

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

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

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

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

Билли ОНил
источник
0

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

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

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

JohnL4
источник
Неаккуратное программирование является источником утечек памяти, и не нужно много учить людей следить за ресурсами, такими как файловые дескрипторы. Существует бесчисленное множество программ на Си с утечками памяти, поэтому я не уверен, что вы делаете, обучая людей указателям как можно скорее.
davidk01
Это правда, но ... (а) непонимание основ приводит к некоторому плохому коду (посредством взлома, пока это правильно или небрежное программирование), и (б) я пытался объяснить, почему указатели по-прежнему актуальны, а не Утверждая, что C лучше, чем мусорные языки с точки зрения утечек памяти. Цель получения указателей как можно скорее состоит в том, чтобы мы могли затем получить чертовски C.
JohnL4
0

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

Гаурав Сегал
источник
0

Вы оба правы.

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

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

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

Уильям Пьетри
источник
0

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

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

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


источник