Много ли ученику языков программирования надо?

[beldmit]

 

Саша Соболев тут написал большой текст в контексте обсуждения пользы обучения программированию на примере C++. Текст правильный, но содержит много тезисов, и поэтому отвечать я буду на него примерно потезисно.

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

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

Если ты хочешь стать программистом, ты должен понимать в том, как устроен дивайс, который ты программируешь. Не потому, что ты будешь потом на ассемблере собирать SQL-запросы и не потому, что придется самому ваять менеджер памяти. А что бы понимать что происходит. 

Я в принципе согласен, но адекватный уровень понимания для каждого языка и предметной области разный. Если ты пишешь на JavaScript/CSS, то до железа ты не доберёшься близко к совсем, и тебе не актуальны процессорные кеши, но крайне актуально знание размеров экрана и то, как в какой системе отображаются твои виджеты. А на C, да ещё выжимая каждую операцию досуха ради быстродействия, тебе надо знать, например, про векторные инструкции процессоров.

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

Я тут понял, что единственное, для чего C++ хорош в образовательных целях — это для объяснения про классы, темплейты, контейнеры и алгоритмы. Что у нас бывают разные способы хранить кучу плюс-минус однородных данных, и где-то мы за это заплатим неудобством поиска, где-то проблемами со вставкой, где-то чем-то ещё. Но это примерно C++ 2003. Ну то есть это не C++, это C с классами и немного STL. И я не уверен, что C++ — методически самый лучший для этого язык.

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

Вот тут и согласен, и не согласен. Не компетентен судить про Erlang, но по другим языкам — часть граблей программист не заметит, но ими прилетит. 

 Течет память - либа тухлая, другую возьмем! Медленно работает - надо апгрейдиться! Ну а чего вы хотите - оно вот так работает! Скомпилить шаред библиотеку и подключить к своему проекту на Erlang/R/Python? Не ко мне 🙂 Ну хоть понять, что это можно реализовать как полагается на низкоуровневом языке и попросить того, кто умеет! Но это уже детали даже.

Это вполне релевантные детали в целом. А в частности всё сложно. Утечки памяти в современном языке с garbage collector надо очень стараться, чтобы организовать. Критичные по времени места уже реализованы на низкоуровневом языке и оптимизированы. Другой вопрос, что их можно неправильно использовать и править надо именно алгоритм. А для этого ещё и профайлить, о чём и профессионалы не всегда думают. А когда думают, часто получают неожиданный результат в том, где на самом деле находится узкое по времени место.

Самое серьёзное ускорение, которое мне довелось привнести, было в проекте на C++. Там товарищ делал обрезал начальные пробелы в строке, проходя с начала, и для каждого пробела двигал всю строку (довольно большую) на этот пробел влево.

С/С++/Pascal - отличные языки для изучения в школе. А над программерами, которые не считают нужным их знать, позволь мне посмеяться. Я не со зла, просто это действительно смешно.

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

Comments

[vitus_wagner]

Попался мне недавно случай, когда уже в момент предрелизного тестирования был пойман такой баг, глядя на который я долго удивлялся

1. Как это можно было написать
2. Как это ревьюер пропустил (при том что ревьюер там один был один из лучших программистов нашей конторы).

Вот человеку который учился на Pascal или на Algol-60 как я, в общем на языке, где параметры можно переменовать и по значению и по ссылке, и на этой разнице обязательно заосторяют внимание, должно быть попросту очевидно, что в языке C, где параметр всегда передается по значению, значение переменной p в результате передачи ее значения параметром в функцию free измениться не может.

А тут вот было написано что-то вроде

if (malloced) {
   free(keyword)
}

Это было в исходном варианте. Потом в порядке борьбы с якобы утечкой найденной каким-то новомодным статическим анализатором добавили

if (keyword) {
  free(keyword)
}

Причем теста, который покрывал этот код, и который вообще-то в том же дереве исходников лежат (и который честно сегфолтился по double free), ухитрились не запустить, ни автор "фикса", ни ревьюер, ни я при мердже в релизную ветку. И только при интеграционном тестирование этот тест запустился (это вообще-то уже к апстриму вопрос - почему в стандартный комплект, запускаемый при make check этот тест не входит).

[beldmit]

Да запросто, не приходя в сознание и не такое можно сотворить, затыкая какой-нибудь Coverity.

[vitus_wagner]

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

[ufm]

Как-же это надоело, госссподи.
Друзья, когда вам в голову придёт банальная мысль, что "обучение программированию", и "обучение языку программирования" вещи между собой связанные очень опосредованно - вот только тогда начинайте что-то вещать с умным видом. А пока - не надо, ладно?

[vitus_wagner]

Это как? Учить программированию путем рисования блоксхем на бумаже? Еще в первой половине 80-х годов у нас в школе по этому поводу говорили "Програмизьма без механизьма - разновидность онанизма".

Учить программированию можно ТОЛЬКО давая ученику возможность выполнять написанные им программы на каком-нибдуь вычислительном устройстве. Так что без языка¸ причем языка имеющего реальный компилятор или интерпретатор на имеющемся в наличии железе, в процессе обучения не обойтись.

А любой языка как инструмент обучения обладает теми или иными достоинствами или недостатками.

Учить же на десятке языков сразу можно далеко не всех. Это слишком продвинутый уровень. Хотя в ходе обучения будущего профессионального программиста такой период когда к каждому практикуму нужно освоить новый язык, необходим.

[ufm]

"- Почему у вас так много свободного времени, вы такой добродушный и веселый? Как вам это удаётся?
- Я никогда ни с кем не спорю, особенно в интернете.
- Но это-же невозможно!
- Да, вы совершенно правы.
"

[beldmit]

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

[vit_r]

С древних времён известно, что учить надо сразу двум языкам программирования. Не важно каким, главное чтобы из разных групп.

[vitus_wagner]

Почему так мало? По идее оптимальным количеством в подобных ситуациях является число e. Следовательно лучше трем, чем двум - три ближе к e.

[permeakra]

>Саша Соболев тут написал большой текст в контексте обсуждения пользы обучения программированию на примере C++.

Можно ссылку?

[beldmit]

Он весь процитирован здесь, курсивом.

[juan_gandhi]

А... я вижу явные приметы маразма "опытного разработчика". Видел это неоднократно. Когда триггеры и ФФЯ были важнее кода. Когда машинные коды были надежней ассемблера (ближе к железу). Когда ассемблер был лучше фортрана и си (ближе к железу).

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

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

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

[beldmit]

Важность Раста из той половины Rust Book, которую я просмотрел, я оценил. Он закрывает существенное подмножество способов выстрелить себе в ногу. Но он, небось, в этом плане не единственный такой.

[vitus_wagner]

А мнет тут тем временем дружно пытаются доказать, что Go круче Rust.

А ECMAScript к сожалению, сам по себе ни для чего не пригоден. Чтобы учить детей на нем программировать, мало иметь сам языка, надо еще какую-нибудь объектную модель чего-нибудь к нему приложить.

Причем все сколько-нибудь распространенные - что браузерная модель документа, что WindowsScriptingHost-овская модель системы, что предлагаемая NodeJS - отнюдь не образец простоты и логичности.

Я б если ставить задачу учить детей программированию посредством какого-нибудь извода JavaScript, сначала бы разработал исполнителя. Какого-нибудь робота, желательно чтобы его можно было не только в виртуальной среде гонять, но и собрать физического, из Ардуино с RaspberryPi в черепушке, с простой и понятной объектной моделью, и вот на нем бы учил.

[filin]

C++ для обучения программированию плох тем, что в нём за деревьями не видно леса. Про классы, контейнеры и алгоритмы лучше взять scala. И, кстати, важно помнить, что классы в С++ — это не концепция, и даже не прямое отражение концепции, а особенность реализации. А темплейты — это либо оптимизация алгоритмов, либо работа с алгоритмами «для бедных». В смысле, для тех, у кого язык не умеет переменных типов по-человечески. В первом варианте они нужны уже для профессиональных программистов, оптимизирующих узкие места, найденные профайлингом, как правило, под конкретную архитектуру. При обучении программированию эту тему затрагивать вообще вредно. Ну а во втором — лучше сначала освоить алгоритмы на языках достаточно высокого уровня, а потом уже, если понадобилось оптимизировать, реализовывать освоенное с помощью темплейтов.

[beldmit]

Темплейты - это внедрение Duck Typing туда, куда его не клали.

[nataraj]

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

Думаю, что для понимания работы компилируемых в машинный код языков лучше всего взять Си. Там можно показать все возможные грабли.

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

C++ он по моим ощущениям несколько франкенштейно образный, чтобы начинать обучение с него. Там с этими шаблонами сломит ногу сам Страуструп...
Понятно что можно выбрать какое-то удобоворимое подмножество, из серии писать на Qt, которое в принципе С++ и удобоваримое... Но это далеко не весь СиПиПи...

[vitus_wagner]

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

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

[yurikhan]

Я тоже прошёл через BASIC и Паскаль. И они оба полезны. (И вредны тоже, разумеется; не буду спорить с Дейкстрой и Постом.)

BASIC (особенно прошитый в ПЗУ) полезен тем, что в нём нет бойлерплейта. 10 PRINT "Hello World" и поехали. Это очень понятно для начинающего программиста: программа — это список действий, которые можно было бы делать руками по очереди, но удобнее же, когда они все сразу. (Управляющие конструкции — IF, FOR, WHILE, GOSUB — появляются чуть позже.) В Паскале уже требуется минимум begin … end., в Си — int main() { … } (а для хеллоу-ворлда ещё и #include <stdio>, который на этом этапе обучения кроме как магическим заклинанием не объяснишь). В принципе, в современном реальном мире тем же свойством обладает шелл. (Кроме концепции шебанга, которая, впрочем, для шелл-скриптов опциональна.)

Паскаль полезен как язык со строгой статической типизацией. Boolean, Char и Integer — три разных типа, конвертирующихся друг в друга только явным приведением. В Си же мы сразу сталкиваемся с суровой реальностью, что в машине все данные — это целые числа и что выхлоп printf(fmt, 42) существенно зависит от того, что там в рантайме окажется в fmt: %d или %c.

[pashap]

Ну, мне, кстати, паскаль до сих пор полезен.

[bowhill]

Мало кто, обучая С++ в частности и ООП вообще, объясняет (и понимает) три существенных тезиса.

1. Объектные модели — иерархические, а модели реальной жизни — графы (которые представляются эквивалентными реляционными/сетевыми моделями). Графы не могут быть представлены иерархией, ни практически, ни теоретически. Поэтому ООП-модели, по определению и по дизайну — неисправимо ложные (кривые).

2. Для компенсации п.1 и создания иерархического дерева, как-то реализующего связи в графе, создаётся иерархия наполненная химерами: несуществующими, вымышленными сущностями. И на поддержание этих химер уходит весьма существенное, а часто и основное количество труда (что всё равно не приводит модель к норме).

3. Иерархические модели статичны, то есть гораздо тяжелее поддаются изменению, тем более постоянной, динамической модификации. А реальная жизнь и её модели как раз динамичны.

Всё это известно довольно давно, к примеру, всё это было существенными причинами, по которым ещё в давние времена развитые инженеры на смену IMS сделали System R (DB2).

Существуют ли области для статических иерархических моделей? Да, но это весьма ограниченная и частная область. Даже банальный библиотечный справочник не является иерархической моделью.

[stas]

Все модели ложны, но некоторые - полезны. Иерархические, как раз, бывают полезны довольно часто.

На комментарий выше

[bowhill]

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

К тому же динамически её изменять весьма сложно (не в смысле перестроения дерева, конечно). Ну и отдельная очень плохо решаемая задача — одновременное совмещение или использование нескольких иерархических моделей.

[stas]

Если ты хочешь стать программистом, ты должен понимать в том, как устроен дивайс, который ты программируешь.

Для меня это звучит как "чтобы водить автомобиль, надо понимать физику двигателя внутреннего сгорания". Когда-то, наверняка, так оно и было. Но эти времена были лет сто назад, и теперь это тривиально не так. То же самое и с программистами. Конечно, хороший механик тоже в хозяйстве вещь полезная, а механик с теоретической базой - ещё круче. Но насчёт "должен" - это чересчур.

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

Ну и 90% оптимизации, конечно, алгоритмы. Из остальных опять же 90% - опять же алгоритмы, но после очистки шелухи, привносимой высокоуровневыми языками. И лишь оставшаяся небольшая часть нуждается в C++. Ну, когда надо, тогда надо. Но это бывает редко, а у значительной части людей, именующих себя программистами - так прямо и никогда.

"для каждого пробела двигал всю строку" -- теперь везде

[bakaneko]

> для каждого пробела двигал всю строку"
Теперь везде так пишут. ¯\_(ツ)_/¯

Тот самый "left-pad, сломавший интернет" (дополнить строку слева пробелами (или заданным символом) до заданной длины):
в цикле добавляется по одному пробелу слева (создаются всё новые копии исходной строки с увеличивающимся количеством пробелов).
Видимо, с длинными строками никто не тестировал?