Який вплив мають мови написання сценаріїв на молодших програмістів? [зачинено]

Днями я мав дискусію з одним зі своїх викладачів.

Ми обговорювали вплив, який мають більш прості мови сценаріїв (наприклад, Python чи Ruby) на молодших програмістів.

Він стверджував, що мови написання породжують неохайні методи кодування, оскільки початківці не розуміють, що відбувається "під капотом". Він також наводив інші приклади того, як мови сценаріїв часто змушують програміста нехтувати занепокоєнням щодо ефективності, управління пам'яттю, операційної складності тощо.

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

Клас закінчувався до того, як будь-яка сторона була повністю досліджена.

До цього моменту я проповідував, що початківці повинні починати з мов скриптів, а потім копати глибоко; але після цього обговорення я почав цікавитись, чи це помилкове мислення.

Отже, який вплив мають мови сценаріїв на молодших програмістів?

Я не погоджуюсь. По-перше, мови сценаріїв знаходяться на більш високому рівні абстракції, і в цьому немає нічого поганого. На початку потрібно просто вивчити принципи. Насправді я б сказав, що вибір мови нижчого рівня може сприяти поганому кодуванню, оскільки доводиться стикатися з деякими деталями, перш ніж мати можливість їх зрозуміти. Замість простої мови можна починати писати чистий і стислий код з самого початку.

По-друге, є багато чого навчитися на цих мовах. Щодо вивчення мови, я б сказав, що C легше, ніж Python. Доводиться мати справу з покажчиками або піклуватися про рядки, але в Python можна дізнатися ще багато понять. Поняття, орієнтація на об'єкт, рефлексія, магічні методи, першокласні функції, лямбда, ітератори та генератори, метакласи: все це є частиною мови.

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

Не має значення, з чого ви починаєте. Важливо, куди ви йдете після початку.

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

Я почав з BASIC. Я там не залишався .

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

Якщо ви дивитесь на вивчення мов як на суто академічну діяльність, щоб дізнатися, як працюють комп'ютери, то він правильний. Якщо ви дивитесь на них як на спосіб зробити справи, то ви маєте рацію.

Я думаю, що "мова сценаріїв" - це жахливе слово, яке є надзвичайно застарілим або в кращому випадку відповідає класу мов, що належать до домену. Ваш вчитель просто вирівнює все, що йому, очевидно, не вистачає розуміння щодо осі зла.

Доцільне розмежування полягає в тому, що між мовами високого рівня та мовами низького рівня або між типово типовими та динамічно типізованими, які є справді ортогональними.

Assembler є динамічно типізованим низьким рівнем (якщо мова про типи взагалі має сенс), C статично набраний низьким рівнем, динамічно набраний Ruby високого рівня, статичний набір Haskell - високий. Java не є ні статичним, ні високим, ні низьким рівнем, а C ++ - статичним і типовим. І так далі.

Обговорення може бути лише тим, які парадигми більше підходять програмісту початкового рівня.
Я впевнений, що програмування на низькому рівні, ймовірно, не так. Це могло бути, колись на початку 90-х, коли ви могли насправді отримати цікаві результати в розумний час.
Але програмування живиться пристрастю. Пристрасть живиться нагородами. Тому програмістам початкового рівня слід починати з інструментів нагородження. Інструменти низького рівня вже не приносять користі, оскільки існує величезне море інструментів високого рівня, які за частину часу отримують такий же результат.

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

Саме так ми думаємо. Людський мозок може обробляти лише обмежену кількість інформаційних "одиниць", але ступінь абстрактності мало має значення в квантуванні інформації. Наприклад: прочитати нам вираз '34 * 75 'простіше для нас, ніж обчислити його, тоді як для комп'ютерів - навпаки. Розпізнати (і тим самим абстрактно) купу чорних пікселів у чітко викладеній лінії, яку потім можна розпізнати (і тим самим ще раз абстрагувати) окремою цифрою - велика робота.
Бабуся розуміє ідею відкриття файлу. Однак вона не має розуміння під цим рівнем. І відверто кажучи, якби їй довелося це навчитися, спочатку вивчивши внутрішню роботу апаратури та операційної системи, а що ні, вона ніколи б не потрапила туди.

Там багато людей, які надмірно ускладнюють речі, оскільки їх ніколи не вчили мислити чітко, лаконічно і, отже, елегантно вирішуючи, але витрачали занадто багато часу на роздуми з обмінними деталями низького рівня та вирішення проблем проти них. Навчити людей мислити як комп'ютери - це найгірший підхід до програмування.
Значення програмування полягає в пошуку рішення проблеми. Виявлення цього коду справді є більш тупою, механічною задачею, і його слід просто виконувати за допомогою будь-яких інструментів.

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

EDIT: і коли мова заходить про введення тексту, я віддаю перевагу мовам, які мають статичний тип. І я думаю, що програмісти початкового рівня повинні чітко розуміти поняття типів (яке є абстрактним).

У Python нічого простого. Погляньте на Unicode та метапрограмування.

Я бачу ще одну, набагато глибшу проблему.

Неодноманітні мови не примушують звертати увагу на типи, думати про типи. Це добре і добре, якщо у мене є невеликі сценарії з деякими рядками та номерами, які перетворюються один на одного, не помічаючи. Але настане день, коли це зламається. Раптом програма зламається, і кожне швидке виправлення призведе до її знов.

Або початківець програміст хоче зрозуміти, що йому буде потрібна ціла списка замість списку кортежів, але не матиме ні найменшого уявлення "як це зробити", і він буде задавати питання про stackoverflow, що показує абсолютну безпорадність.

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

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

Деякі з цих основ просто зрозуміти, якщо ви самоучки, поки ви не отримаєте певного досвіду. Крім того, зазвичай потрібно зробити що-небудь корисне якнайшвидше, і ви можете отримати теоретичні основи за необхідності, хоча ви ризикуєте ніколи не навчитися більше, ніж голий мінімум за допомогою цього підходу. Ось чому я рекомендую таку мову, як python.

Ми бачили це навпаки в коледжі, і я думаю, що це корисно. * Ми почали на низькому важелі. Покажчики, управління пам’яттю, масиви символів… Так, так, ми почали з C. Те саме з алгоритмами: спочатку реалізуйте зв’язаний список, хештел, дерево… І тільки потім використовуйте стандартні бібліотеки.

Після цього ми перейшли до більш потужних мов, таких як Java, C # або perl. Але з перевагою знати, що відбувається під поясом.

Хоча це працює, я вважаю, що перехід від мов скриптів до мови нижчого рівня теж добре. Знання мови високого та низького рівнів гарантує вам легкість у користуванні мовою високого рівня, а ще розумієте, що відбувається. Порядок, в якому ви їх вивчаєте, є менш важливим.

Мови сценаріїв не роблять програмістів неохайними. Відсутність ясності розуміння проблемної галузі (наприклад, бізнес, який обслуговує програма) - це те, що викликає неохайність.

Як свідчить стара приказка: "Ви можете писати COBOL будь-якою мовою". Хоча я підозрюю, що коли кожен тип даних виглядає однаково , то стає важче зрозуміти, які основні аспекти вашої програми є головною особливістю COBOL- ізація.

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

Я думаю, що для використання будь-якої мови програмісту необхідно мати базове розуміння програмування в цілому. Вони ніде не будуть ефективними, якщо не розуміють понять, таких як вектори, дерева та хеш-таблиці. Їм не обов'язково потрібно вміти реалізовувати ці речі, але вони повинні знати їх характеристики.

Де я думаю, що неохайність грає не в навичках програмування, а тоді, коли потрібно створити компоненти, що повторно використовуються. Ці мови не вимагають, щоб ви визначали хороші інтерфейси між кодовими блоками або механізми, щоб бібліотеки застосовували обмеження для своїх клієнтів. Зробити хороші компоненти для повторного використання такими мовами не неможливо, це просто набагато складніше.

Мови сценаріїв звертаються до програміста-початківця, оскільки це дозволяє їм робити більше "разових" дій за менший час, але коли ті самі програмісти починають займатися програмуванням технічного обслуговування, вони часто швидко мають проблеми з цими мовами.

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

Просто пам’ятайте, що жоден інструмент не найкращий для кожної роботи. Виберіть інструмент, найбільш відповідний ситуації. Це стосується мов програмування так само, як і для будь-яких інструментів.

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

Я думаю, що починати з C краще, ніж починати з мов сценаріїв. Як викладач, я зосередився б на всій цій архітектурній справі фон Неймана (ALU, регістри, пам'ять, порти вводу / виводу, ...), перейшов безпосередньо до покажчиків (вибачте, це дійсно ключова концепція [не випускаючи посилання (тобто покажчики) в мовах VM є основним джерелом витоків пам'яті]), потрапляйте на деякі структури даних (дерево, пов'язаний список, хештел ¹ ), а потім ... піднімайте його на рівень абстракції на щось інше (OO, функціональне програмування, щось - сильні правила статичного введення , yo \ m /, так що ніяких "мов скриптів"> :().

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

Я думаю, що найкраще - починати з модульної мови, а потім переходити до складніших матеріалів: в мої дні ми починали з Pascal і COBOL і намагалися зрозуміти, що означає підпрограми, контрольні змінні потоку тощо. Тільки після того, як мені було комфортно з Паскалем, у мене навіть виникло бажання перейти на такі мови, як C / C ++, і вивчити всі інші методи, які більше доповнюють молодшого програміста.

Ви обоє праві.

Мови сценаріїв, безумовно, ускладнюють початківцям розробникам зрозуміти, що відбувається насправді. (Так роблять бази даних, фреймворки та бібліотеки. О, і браузери, сервери, мережі та файлові системи.) Коли я опитуюсь у молодих розробників, мене часто глузують, як мало вони знають про те, як комп’ютери насправді працюють, і наскільки вони схильні до завантаження -культурне програмування.

З іншого боку, річ номер один, яку я шукаю в інтерв'ю, не є ідеальним розумінням, це те, що вони люблять робити речі. Коли я почав працювати, комп'ютер, що робив що-небудь, був дуже вражаючим, тому мої маленькі речі Apple Basic і 6502 з асемблером здалися мені дуже приголомшливими. Але в наші дні комп’ютери роблять багато дивовижних речей, тому я думаю, що це нормально для людей, щоб почати на досить високому рівні, якщо це те, що потрібно, щоб вони зачепилися.

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

По-перше, я б нескінченно почав з мови більш високого рівня абстракції. В даний час я б рекомендував Python. Найважливіша причина вибору мови сценарію як першої мови полягає в тому, що ви можете легко скласти щось, що працює. Як згадує Джо у своєму питанні, річ номер один, перетворюючись на програміста, полягає в тому, що у вас є мотивація продовжувати та копати глибше. Ця мотивація здобувається, коли ви можете створити робоче і корисне програмне забезпечення.

Окрім пунктів з розумінням абстракції (високий рівень) та розумінням основної реалізації (низький рівень) є третій пункт, який пропускають. Для того, щоб бути хорошим програмістом в наші дні, ви обов'язково повинні оволодіти обома вищезазначеними пунктами. Крім того, для вашої компетенції дуже важливо постійно дивитися на нові технології та точки зору. Незалежно від того, з якого рівня абстракції ви починаєте, ви повинні постійно вдосконалюватися та ставити під сумнів свої існуючі методи.

З самого початку слід зрозуміти, що мови програмування - це лише інструменти для виконання завдання. Дуже важливо вибрати правильний інструмент для певного завдання. Я думаю, що для початківця програміста мова сценаріїв високого рівня допоможе підкреслити цю точку. Мова вищого рівня дасть більш широку перспективу та мотивує програміста копатися глибше.