Комментарии 166
Опять таки, это моё личное мнение, не хочется его навязывать, а хочется просто поделиться мыслями.
Есть разные люди. Кому-то интересно понимание, а кто-то стремится использовать язык программирования как инструмент для решения своих основных задач или просто для быстрого заработка денег. Поэтому от цели человека тоже многое зависит.
К примеру, язык C сможет дать вам больше пользы. Он и не является самым «низким и рутинным», он по-прежнему актуален, он дает лучшее понимание работы компьютера и после него остальные языки учатся лучше. Почему бы не начать с него?
у меня си был, наверное, третьим языком (после бейсика и ассемблера).
если знаешь ассемблер, то классическая книга k&r отлично «заходит», си видится как такой продвинутый супер-ассемблер. а вот на роль первого языка… сомневаюсь.
Я тут пару месяцев назад объяснял неглупым студентам, знающим Java, но не знающим C некоторые моменты из C. Да мне банально стыдно было объяснять, что в C массив не массив, что строки не строки, что "*" надо читать не как часть типа, а как часть объявления переменной, что в C есть разница медлу объявлением и определением. Понимание этого нормально для разработчика ОС, но забивать этой ерундой голову на первом ЯП — абсолютно лишнее.
Python самое то, для начала. Мой сын в неполные 8 лет пишет простые штуки на Python. Потому что я смог объяснить, что такое условие, что такое переменная, что такое цикл, что такое метод, что такое параметр метода, что такое тип. Если бы мне пришлось попытаться объяснить указатели и подобную ересь, он бы не смог.
x = 5Что такое x, если не переменная?
Ну эти ссылки даже в language reference (например тут) и называют переменными (variables).
a = 0
print(f'stage 0, id(a)={id(a)}, a={a}')
for i,x in enumerate([1,2,546,12,-3],1):
a = a + x
print(f'stage {i}, id(a)={id(a)}, a={a}')
##
#stage 0, id(a)=140727764754800, a=0
#stage 1, id(a)=140727764754832, a=1
#stage 2, id(a)=140727764754896, a=3
#stage 3, id(a)=1961160318832, a=549
#stage 4, id(a)=1961160868208, a=561
#stage 5, id(a)=1961160318832, a=558
habr.com/ru/company/mailru/blog/454324
Да, сама ссылка и есть variable. Я же не спорю о том, что понятие переменных немного отличается от С++. Просто там выше было "в python переменных нет" — слегка максималистское утверждение, которое не вполне соответствует документации.
Это замечание также является ответом на ваш комментарий habr.com/ru/post/516070/#comment_21985010
UPD: разовью мысль. В Python есть объекты, изменяемые либо нет, с раз и навсегда заданным типом, но не имеющими имени. В этом смысле они не являются переменными. И есть изменяемые ссылки, которые авторы языка, на правах демиургов окрестили «переменными». Но для этих «переменных» разрешены ровно две операции: переназначение и обращение посредством них. А привычных переменных, которые можно складывать, вычитать, сравнивать, и т.п. присваивать им значение, брать их адрес и привязывать к ним ссылки в Python нет.
Для большинства переменная — изменяемый объект имеющий два неизменных атрибута: имя и тип, и изменяемое значение.
Про большинство — это сильное утверждение, которое следовало бы подкрепить какими-то авторитетными источниками.
Например, в Википедии переменная определяется как область памяти, связанная с некоторым идентификатором. Если Википедия недостаточно авторитетна, то подобное определение можно найти и в классической книге «Компиляторы: построение и анализ» Ахо и др. (раздел 1.6.2).
Давайте оставим споры о том, чьё определение лучше и более общепринято, и на минутку примем то, определение, которой я привёл выше (переменная — область памяти, связанная с идентификатором). Вы согласны, что в Python переменные всё же есть?
Конечно, с формальной точки зрения указатель и переназначаемая ссылка являются переменными. Но когда говорят о них, их так и называют, не используя термин «переменная».
Вот, скажем, открываю я раздел об указателях в C++ и читаю, что «указатель — это тип переменной, который...». Более того, ниже написано, что «pointers… are variables themselves», и используется словосочетание «pointer variable». Выходит, что говорят. Уверен, что можно найти массу других примеров, когда указатель называют переменной.
И если с формальной точки зрения ссылки — это переменные, что вы сами и написали, то почему вообще этот спор возник? Раз формально ссылки — это переменные, то почему вы говорите, что переменных нет? Они есть.
И есть изменяемые ссылки, которые авторы языка, на правах демиургов окрестили «переменными».
Так почему мы должны им отказывать в этом праве? Это общепринятый среди программистов на Python термин, а значит, когда мы говорим о Python, то и называть x нам следует переменной. Разве нет?
переменная — область памяти, связанная с идентификатором
Возьмем файл. Лежит в области памяти? Да, пусть и не оперативной. А может закеширован и именно там и лежит. Идентификатор есть? Есть — его имя. Но файлы переменными почему то не называют.
Далее, рассмотрим UNIX-подобные ос. В них у одного файла может быть несколько имен и файл будет существовать до тех пор, пока с ним будет хотя бы одно имя. Ничего не напоминает? Может объекты в Python файлами назовем? Нет не будем, потому что у файлов есть дополнительные свойства, которых нет у объектов Питон.
И если с формальной точки зрения ссылкиЯ же пишу, вы ударяетесь в начетничество и формалистику. Это же касается и следующего за этой фразой абзаца.
Можно рассмотреть еще «переменные» в Wolfram Language с его двумя формами «присваивания». Там вообще чудеса можно творить. Фактически речь идет о записях, указывающих на связь между литералом и выражением. В одной форме присваивания выражение вычисляется (простите редуцируется), а в другой оставляется как есть.
Так вот результат последовательности операций
x = a+b
y = x
z := x
x = c+d
для кого то результат может оказаться неожиданным. (Хотя проверить не могу, Mathematica у меня нет уже довольно давно).
Это общепринятый среди программистов на Pythonнужно всё-таки разделять программистов на Питоне и пользователей Питона. Кого сейчас больше — вопрос, но это оффтоп.
Так что насчёт определения из книги Ахо, согласны с ним? И как вы прокомментируете то, что указатели всё же называют переменными в документации C++?
Но файлы переменными почему то не называют.
Ха-ха! Так этот пример работает и против вашего определения («изменяемый объект имеющий два неизменных атрибута: имя и тип, и изменяемое значение»). Имя есть, тип есть, содержимое файла может меняться. Вполне можно считать типом тип содержимого, который отражён в расширении. Или, если хотите, можно делить файлы на обычные, символические ссылки, блочные устройства и т.д. :)
Я же пишу, вы ударяетесь в начетничество и формалистику.
По-моему, формалистика — это надуманное разделение переменных на подвиды. Просто приведите ссылки на авторитетные источники, подтверждающие вашу точку зрения.
нужно всё-таки разделять программистов на Питоне и пользователей Питона.
А кто такие пользователи Python и чем они отличаются от программистов? И зачем их разделять?
По поводу файлов и переменных. У переменной есть еще один важный, но не упомянутой мною атрибут — программа, в которой она существует. Файл как таковой существует сам по себе.
По поводу ссылок на авторитетные источники. Ссылаясь на кого-то, ссылающийся берет на себя всю ответственность за написанное другим автором в рамках цитирования и дополнительных оговорок. Авторитет здесь не причем. Авторитет — тот, кого прочитают первым, а не тот, на кого сошлются неглядя. Большинство из тех, кто сейчас на чем либо программирует начинали с чего-то вроде Бейсика или Паскаля. И там с понятием переменной все было четко — именованная ячейка памяти.
Возвращаясь к Питону. Можно дать четкое и понятное описание его грамматики не прибегая к понятию переменной, используя, при этом, термины «ссылка», «объект», «класс», «тип» и т.п. не переопределяя их.
Программист пишет ПО согласно ТЗ для использования автором ТЗ или третьими лицами. Пользователь использует языки программирования для создания собственных инструментов для решения стоящих перед ним задач. Пример — Датасаентист.
Файлы — плохая аналогия. Под файлами чаще всего понимаю что-то похожее на posix-файлы. И в этом случае аналогия становится сильно сложнее. Для переменной возможно обойтись только очень небольшим количеством операций, которые действуют на всю переменную (ну например, это могут быть инициализация, присвоение, получение ссылки), для файла набор операций заметно отличается. На эту тему был неплохой обзорный доклад.
Но в любом случае предлагаю прекратить бессмысленный спор. В первом ЯП мне лично проще описать, как работает Python с его переменными-ссылками, чем С. Есть и другие языки, достаточно простые, которые не требуют таких усилий, как С, но у них у всех есть недостаток — малая кодовая база. А тут я на Minecraft'е могу показать простые приёмы и ребёнку интересно (например, он может быстро делать в Python то, что задолбается делать руками). Если захочет быть программистом, то всё равно освоит не меньше 5-6 ЯП. Если не захочет, то Python хватит по жизни. Ну не с MSX Basic же начинать в 2020 году.
А привычных переменных, которые можно складывать, вычитать, сравнивать, и т.п. присваивать им значение, брать их адрес и привязывать к ним ссылки в Python нет.
Ну вот я пишу:
a = 1
b = 2
c = a + bЭто разве не присваивание значений и не сложение? Да, под капотом там более сложный механизм, чем в C++. Но по-моему, отрицание того, что в приведённом коде есть присваивание и сложение — это уже казуистика.
Пока идет работа с иммутабельными (с точки зрения Python) объектами, «переменные» ведут себя привычным образом, по крайней мере до тех пор, пока не начинаем сравнивать их id. Как только объекты становятся сложнее «переменные» сразу превращаются в ссылки.
Так я ж не спорю, что там ссылки. Мне непонятно, почему ссылку нельзя назвать переменной. Это переменная и есть. И когда вы ссылаетесь на мнение большинства, это вызывает лишь недоумение. Я программирую уже лет 25 в том числе и на Python, и впервые сталкиваюсь с утверждением, что в Python нет переменных (это не аргумент, конечно, просто объясняю своё удивление).
Разделение переменных на собственно переменные и ссылки не только излишне, оно вдобавок всё сильно запутывает. Это разделение просто излишне.
Например, вы приводили C++ в качестве примера языка, в котором переменные определённо есть.
Вот, скажем, такой кусочек кода:
struct Box {
int* p;
int v;
}
Box b;Здесь b — это, очевидно, не указатель и не ссылка. Это видно просто из объявления. Звёздочки нет же. Значит это переменная. Но внутри v содержит указатель, который может меняться. Значит это, по-вашему, не переменная. Что же это?
Если же вы всё же согласитесь, что b — это переменная, то что мешает назвать переменными объекты в Python, ведь там практически такая же ситуация?
Это называется "переменная ссылочного типа".
y = x
x = 'spam'
Что выведет print(y)
Странно. В language reference, во всей документации и PEPах есть, а у вас нет.
Идеальным для обучения является предельно маленький язык (без синтаксического сахара, особых случаев и выполнения работы за программиста) с предельно сильной статической типизацией. Это, прежде всего, языки, созданные Виртом (от Pascal до Oberon-07), и, с оговорками, Go.
А вот после изучения основ алгоритмики на языке высокого уровня (ЯВУ) уже переходить к ассемблеру — чтобы понимать, как написанный код выполняется процессором и сколько «сто́ит» каждый оператор ЯВУ.
P.S. И, да: С намного проще изучать после знакомства с ассемблером.
Haskell ;)
Можно ради обучения сделать это тремя способами:
1) самому написать функцию транспонирования. Её можно спокойно написать на python.
2) как в примере
3) использовать готовую из numpy
Часто становлюсь свидетелем историй, когда молодые люди прочитав разные статьи про могущественный C\C++ начинают с него учиться программировать, а потом остывают. Потому что «сложно» и «непонятно как применить».
Сходу
- В С отвратительная работа с типами. Pascal в этом смысле гораздо дисциплинированей.
- В С — мутабельные строки оканчивающиеся
\0. В Pascal более классичные (с отдельной хранящейся длиной) - В C нет модульности.
- В C нет проверок на допустимость диапазонов.
Pascal не идеален, но С для обучения программированию точно хуже.
Но ведь, получается, школьные задачи тогда оторваны от реальности?
Абстрагированы, чтобы сосредоточиться на главном на тот момент.
Что касается зависимых типов, наверное, хорошо, что их там нет.
Ага. Ну прям ШОК. Срыв покровов. Большинство школьных задач оторваны от реальности. Внезапное открытие. :)
Я не против C. Да и даже за паскаль не топлю (еле синтаксис вспоминаю, если честно). Языков надо знать много. Я только считаю, что С сложнее использовать, как первый язык. Хотя… Кто бы говорил — у меня МК-61 был первым ЯП, ничо, выжил.
Конечно же я не завтипы имел в виду, а простейшие проверки типа такого
const N = 1000;
type Range = 1..1000;
var r: Range = 1;
begin
r := 1000;
r := r + 1; // тут будет "value out of range" (не во всех компиляторах, правда)
writeln(r);
end.Для массивов (заданных при компиляции) тоже есть проверки диапазонов индексов.
Что касается приведенных вами отличий, то существенным из них является является только первое, да и то с оговоркой. Паскаль, с точностью до отдельных конструкций, которые вряд ли кто нибудь будет использовать в крупных проектах, является подмножеством С.
Мой первый язык программирования, если так вообще можно сказать, был редактор карт к варкрафту третьему. А что, базы дает — ветвление, циклы, события, последовательность действий и огромная мотивация, в отличие от бесполезной программы на си.
Хотя конечно в пучины C++ бросаться сразу тоже так себе. Мне лично начать полноценно учиться программированию долго «магия» мешала. Т.е. вот тебе условные операторы, переменные, функции и прочее. Но как работают функции из стандартной библиотеки, что такое системные вызовы и прочее я в упор не понимал и от того фрустрировал. Дело пошло когда сделал две вещи: просто без детального изучения и написания своих программ почитал про ассемблер x86, и прочитал книгу Петцольда «Код. Тайный язык информатики». Правда если асм я читал еще в вузе (учился не на программиста), то Петцольда читал где то через год — полтора работы 1сником. После этого вся «магия» пропала и смог не только на 1с писать. Ну точнее не только на 1с я и тогда мог бы что то написать, но то был манки кодинг, без понимания.
автору можно сказать только одно от всей школоты: «идите в жопу со своими сосями»
крайне важна интерактивность, идеально бы зашла смесь питонячьего синтаксиса и интерактивности Squeak — как язык Smalltalk та еще какашка, но его отладчик и Morphic GUI в котором можно нарисовать прямоугольник мышью (как самостоятельный элемент на экране, не в форме), и тут же привязать на него обработчики, это идеальный школьный инструмент для обучения (+EToys)
www.youtube.com/playlist?list=PL6601A198DF14788D
1) элегантный уанлайнер достаточно продвинутого уровня для транспонирования матрицы — не имеет никакого отношения к изучению программированию с помощью питона, такие вещи люди пишут через пару лет опыта.
2) Си не помогает разобраться с глубиной операционной системы или процессора, он оторван достаточно сильно и от того, и от другого. Он помогает сразу понять что программирование — сложно, это есть. И в этом же он помогает программирование бросить.
2.1) Если вы хотите чтобы человек разбирался как работает стек, то отправьте его спустя год опыта на курс from nand to tetris. Там честно делается весь стек, хотя и на примитивном академическом компьютере — от HDL->машкоды->assembly->os->compiler->OO language->app
3) «зачастую люди используют библиотеки» а зачастую так же пишут велосипеды с ноля. Это относится к методологии разработки, а не обучению программирования и тем более не к языку.
4) «Вы посмотрите, на калькуляторе сажали апполон, а сейчас четыре вкладки тормозят». Вы неправильно расставляете противоречие. Четыре вкладки тормозят не потому что был выбор между медленными и быстрыми. Выбор был между наличием этих четырёх вкладок у __вас__ в браузере, и их отсутствием — в браузере и на рынке. И этот выбор всегда делается в пользу наличия.
Давно я увидел довольно интересный аргумент, почему C не должен быть первым языком программирования в школах. В школе не у всех есть мотивация преодолевать доп. барьеры, которые выставляет язык при его изучении. Но в целом идею можно распространить не только на школьное образование.
Посмотрите на hello-world написаный на С:
#include <stdio.h>
void main()
{
printf("Hello world\n");
}И представьте как преподаватель (или книга для новичков) будет объяснять этот код:
#include <stdio.h>— не смотрите пока на это. Оно просто нужно, но зачем — будет рассказано через 5-6 уроков.void main()— это функция main. С неё начинает выполняться программа. Что такое функция вы узнаете на 3-ем уроке. И не смотрите пока наvoid— расскажу потом про то что это такое.{и}— это начало и конец функции и других блоков.printf("Hello world\n");— это строка выводит на экран указанный текст. Не обращайте внимания на\n— позднее вы узнаете, что это такое и зачем нужно.
В итоге большая часть первого кода, с которым знакомится новичок — это набор каких-то непонятных инструкций и терминов, на которые ему рекомендуют пока не обращать внимания, т.к. сложно объяснить на первом уроке их смысл и назначение без того что бы не углубиться в другие темы.
Так себе аргумент — каждый из перечисленных пунктов можно в достаточном объеме объяснить за пару предложений. Проблемы будут как раз дальше — С не очень дружелюбен по отношению к людям, которые плохо понимают, как правильно работать с указателями, со всеми этими &, ** и явным выделением памяти на куче и в стеке. Чуть ошибся — и всё сломалось, вообще всё. Когда я начал писать на джаве, мой самый большой кайф был именно от того, что можно написать new, создать объект и спокойно его передавать куда хочешь, и всё будет работать.
Да, можно сказать в два предложения зачем нужен #include и что-такое void. Но скорее всего это не добавит ученикам понимания, потому как они ещё не могут понять саму суть проблем, для решения которых нужны эти штуки. И потому это вызовет только больше вопросов (у тех кому интересно, остальные просто забьют):
- Зачем подключать библиотеку стандартных функций (и что это вообще такое)? Я же просто хочу вывести текст на экран. Это ведь элементарно.
- Пустой тип...?! Что?! А есть в С "мутный тип"?
- Эмм… символ перевода строки? Это что-ли "буква" такая? Что за код 10? Нельзя что ли просто нажать "Enter" как в Ворде?
А указатели, ссылки и выделение памяти — это действительно не тема новичков (даже на 10-ый урок). Им бы освоить базовые конструкции (циклы, условия, переменные и функции), и научится ими пользоваться там где надо.
Зачем подключать библиотеку стандартных функций (и что это вообще такое)? Я же просто хочу вывести текст на экран. Это ведь элементарно.
Понятие «функции» или «метода» дается на вводных 15 минутах, где вы объясняете, чему вообще учить будете, что такое программа, что такое алгоритм, пример в виде пошагового рецепта борща, вот это всё. Поверх такого базиса всё прекрасно можно объяснить.
Пустой тип...?! Что?! А есть в С «мутный тип»?
«void означает, что функция не возвращает ничего. Если бы мы написали функцию, которая складывает два числа и возвращает результат — вместо void мы написали бы, что она возвращает int — целое число»
Эмм… символ перевода строки? Это что-ли «буква» такая? Что за код 10? Нельзя что ли просто нажать «Enter» как в Ворде?
«Когда мы пишем \n, мы говорим компьютеру, что здесь нам нужно перейти на новую строчку — как будто мы нажали Enter в Ворде. Текст из двух строчек выглядел бы так: первая строчка/nвторая строчка»
Если для ваших школьников это всё еще слишком сложно — скорее всего, это начальная школа, и тогда, пожалуй, стоит взять Logo с черепашками.
Не библиотеку стандартных функций, а заголовочные файлы стандартных функций ввода-вывода. Причём это имя собственное скорее :)
Даже понимание операции присваивания, требует знания указателей и ссылок. Понимание сути простейшей операции a+b требует сведений о таблицах виртуальных методов и т.п.
for i in range (0, 10):
print (i)или же таким образом
for fruit in ["apple", "apricot", "orange"]:
print (" Could you give me an "+ fruit)Зачем забивать голову человека StopIteration? Когда он будет изучать исключения или писать собственный итерируемый класс вполне можно будет изучить это исключение.
Зачем знать ссылки в самом начале достаточно простых типов вроде int, string, list и тд. Потом нужно будет это изучить, но в начале это вообще не мешает изучению.
def MyJoin(a,b):
for x in b:
a.append(x)
p = [1,2,3]
MyJoin(p,p)
Почему именно в ИТ так упорно стараются снизить планку? Почему другие отрасли этим не страдают? Давайте снижать барьеры в медицине, самолётостроении, инвестиционной деятельности и многом другом.
Давайте снижать барьеры
Давайте
в медицине
На медсестру высшее образование не нужно, курсы оказания первой помощи на многих предприятиях есть.
самолётостроении
Лет 10 назад р/у модель летательного аппарата — это был адъ и израиль в плане освоения управления. Сейчас можно купить квадрокоптер и летать, не приходя в сознание.
инвестиционной деятельности
Мне с каждого банка, где у меня есть карты, звонят раз в месяц с предложением включаться в инвестиционные программы. В 90-е никто и знать не знал, что такое эти инвестиции.
Это нормальный процесс — каждая область деятельности с течением времени всё больше дифференцируется и по возможности снижает порог входа. Ниша для глубоко сведущих профессионалов никуда при этом не девается, просто тупо их труд использовать для простой повседневной работы.
На медсестру высшее образование не нужно, курсы оказания первой помощи на многих предприятиях есть.
На медсестру нужно учиться три года. Курсов хватает только на должность младшей медсестры, имеющей право только ставить уколы и менять утки.
Лет 10 назад р/у модель летательного аппарата — это был адъ и израиль в плане освоения управления. Сейчас можно купить квадрокоптер и летать, не приходя в сознание.
Как это соотносится с обучением инженеров, проектирующих самолёты?
Мне с каждого банка, где у меня есть карты, звонят раз в месяц с предложением включаться в инвестиционные программы. В 90-е никто и знать не знал, что такое эти инвестиции.
Да и с предложениями автоматизировать бизнес звонят не реже, но не надо путать доступность услуги для обывателя и профессиональный уровень оказывающего эту услугу.
Беда в том, что бизнес в попытках заткнуть кадровые дыры хоть кем-нибудь, сформировал профессиональную культуру, в которой забыли, что программирование — это всё-таки инженерная дисциплина, со всем причитающимся уровнем ответственности.
Почему все языки должны быть доступны только для головастых профессионалов?
В школе не у всех есть мотивация преодолевать доп. барьеры, которые выставляет язык при его изучении. Но в целом идею можно распространить не только на школьное образование.
В этом я вижу заманивание. Не может или не хочет человек преодолеть трудности первого шага, не надо тащить его под ручки, снижая сложность этого шага.
Они живут сами по себе.
Очень мало качественных курсов, и даже они — являются частью инфобизнеса, который к профессии никакого отношения не имеет. Я вот никого из знакомых не тащу в профессию.
Я тащу только к себе на работу тех, в ком я вижу рабочий потенциал. Даже не текущие технические навыки.
Курсам платят за то, чтобы они снизили сложность вхождения. В этом вообще смысл обращения к ним. И очень многие ожидают, что именно за ручки будут если не тащить, то вести на протяжении курса и даже после него. А некоторые курсы так и обещают это.
В инвестиционной деятельности барьеры снижаются всю её историю, чтобы инвестор, не будучи профессионалом в объекте инвестиций, дал свои ресурсы.
в 20, в 15, в 10 и в 6 очень разное представление о том, куда тратить свою мотивацию.
Я в 5 классе уже колупал ассемблер.
и мои цифры означали возраст, а не год
ну не знаю, как переходить на удалёнку — практически у всех не-IT сотрудников обнаружился ноутбук/компьютер.
Так же знаю достаточно людей, которые продали пк и оставили только консоль (чаще даже без нее) и телефон.
Как то вот так.
П.С.: у них там одним из аргументов оставить на удаленке был — не тащить оборудование взад на работу.хД
По-моему, очень странная аргументация. Питон простой, но лучше начинать со сложного, чтобы понимать глубину и сложность
Младенцы не должны учиться передвигаться ползком, т.к. это слишком просто. Они должны начать с бега на 100м, это поможет им лучше понять своё тело и механику движения. А в будущем переход на ползание им дастся очень легко.
Разве не вся идея обучения — постепенное движение от простого и понятного к более сложному? Я когда в детстве начинал учить с++, это чуть не стало концом программирования для меня. Это слишком сложно и для достижения результатов нужно пройти большой путь (и боль)
С питоном (или любым другим "простым" языком), уже в первый день можно сделать чтото простое и полезное (например скрипт для автоматизации рутины), что принесёт реальную пользу и самоудовлетворение. И если будет интерес к железу или кишкам ОС, то всегда можно начать познавать более сложные языки, типа ассемблера и С. При этом у многих людей это если вообще может не настать
a = [1,2,3]
b = a
for x in b:
a.append(x)
print(a)
и как, по вашему, условная Марьванна должна будет объяснять 7-классннику почему вместо удвоения списка он получил бесконечный цикл не прибегая к этим кишкам?
Или более элегантное
def MyJoin(a,b):
for x in b:
a.append(x)
#.....
p = [1,2,3]
MyJoin(p, p)
print(p)
и как, по вашему, условная Марьванна должна будет объяснять 7-классннику почему вместо удвоения списка он получил бесконечный цикл не прибегая к этим кишкам?
Да не проблема, как мне кажется, для условной Марьванны. У вас же во второй строке написано «b = a». Изменяя одну из переменных, вы автоматически изменяете другую.
Пример:
a = [1,2,3]
b = a
a.append(4)
print(a)
print(b)Out:
[1, 2, 3, 4]
[1, 2, 3, 4]И всё. Без кишок и углубления в ассемблер.
Как поправить:
Для создания независимой копии используйте «copy» или простое «преобразование»:
a = [1,2,3]
b = list(a)
b.append(4)
print(a)
print(b)Out:
[1, 2, 3]
[1, 2, 3, 4]Изменяя одну из переменных, вы автоматически изменяете другую.
Извините, но ваше утверждение ошибочно. У нас есть один объект (который и следует считать за настоящую переменную) и две ссылки на него.
Я бы использовал метафору «этикеток и коробок». «Переменные» как этикетки, навешиваемые на объекты в языках типа Питона, и коробки, в которые кладутся значения в C и прочих Паскалях.
Только вот не думаю, что условный Вася Пупкин поймет это сразу и правильно.
UPD. Вот только объяснения зацикливания у вас по прежнему нет. Так что в кишки все равно придется лесть, пусть и не употребляя напряму слова «исключение» и «итератор».
У нас есть один объект (который и следует считать за настоящую переменную) и две ссылки на него.
Ваше объяснение ничуть не хуже. Просто ученик уже должен представлять себе, что такое объект. С таким пониманием вообще нет проблемы увидеть и исправить ошибку. И это всё можно объяснять в рамках изучения питона. У каждого языка есть какая-то специфика.
Ради справедливости можно сказать, что в С++ тоже есть указатели и также можно сделать переменные взаимозависимыми. И ещё можно кучу ошибок понаделать при работе с одним объектом из разных мест и утечки памяти существуют в С/С++ и бесконечные циклы можно написать… Это не от языка зависит. Знания можно углублять по мере необходимости. Но всегда проще изучать предмет от простого к сложному.
Обычно, на этапе изучения циклов ещё нет понятия объектов.
в том то и проблема, что в случае с Питоном понятие объекта в том или ином виде нужно для объяснения сути цикла for. Либо нужно держать учеников в неведении относительно истинного синтаксиса цикла.
Ради справедливости можно сказать, что в С++ тоже есть указатели и также можно сделать переменные взаимозависимыми.
Ради справедливости следует заметить, что смысла в С++ без указателей нет, но никто в здравом уме и трезвой памяти не предлагает использовать его для обучения основам программирования.
За последние лет 50 создана уйма учебных языков, позволяющих ученикам практиковаться в конкретных особенностях программирования, в том числе «ошибаться по делу» и легко выяснять причины своих ошибок, без риска «выстрелить себе в коленку», там где это не актуально.
Но вот есть у меня племянник; очень хочет программировать и у него прям глаза загораются, когда он видит какой-то результат. Использует он питон. Я ему пытаюсь сосватать какие-то азы и базовые понятия, но вижу, если он надолго над этим засядет, то весь его запал сойдёт на нет. Он может написать простенькую программку. Но, к моему сожалению, не всегда до конца понимает, как оно работает. Главное, что у него не пропадает интерес. И иногда ему всё-таки приходится разбираться в деталях. Вот как раз в случаях, когда программа не работает или не даёт ожидаемого результата. И вот тогда к нему по крупицам приходят и какие-то базовые понятия.
Питон со своей огромной базой готовых библиотек и современных туториалов позволяет достигать желаемого результата за короткий срок, подогревая интерес.
Так что, я на примере своего племянника вижу, что питон может быть удачным выбором для неусидчивых школьников в качестве первого языка программирования.
Объект — не переменная, а значение, которое может существовать без ссылок на него (пока сборщик мусора не доберётся) Как раз для упрощения на начальных этапах, можно считать объект переменной.
Нам на коробках и этикетка к ним объясняли это 30 лет назад. Переменная — этикетка к коробке. А вы коробку называете переменной, а этикетке в праве называться так отказывете. Странно
Как раз для упрощения на начальных этапах, можно считать объект переменной.
Основной принцип образования — ни на каком из этапов нельзя давать ложную информацию. Единственное упрощение — полнота.
Как в 1-м классе на 0 делить нельзя, так и на первом курсе. Только на первом курсе рассказывают как обходить проблему деления на ноль.
Переменная — этикетка к коробке.
Лет 10 назад в статье про переменные в интерпретируемых языках это объяснялось уже так. Рисовалась двойка лежащая в подписанной коробке в случае С и двойка с повешенными на нее бирками в случае какого-то из интерпретируемых языков. Ссылку дать не могу, не нашел.
А как же "нельзя из 2 вычесть 3"?
Не очень понял противопоставление C и интерпретируемых языков.
Не очень понял противопоставление C и интерпретируемых языков.
Ну примерно в этом ключе
$ cat sample.c
int printf(const char*, ...);
int main() {
int x = 1;
int y = x;
printf("&x=%p\n", &x);
printf("&y=%p\n", &y);
return 0;
}
$ ./sample
&x=0x7fff9c148fac
&y=0x7fff9c148fa8
$ cat sample.py
x = 1
y = x
print(f'id(x)={id(x)}')
print(f'id(y)={id(y)}')
$ python3 sample.py
id(x)=9062624
id(y)=9062624
хотя, конечно, далеко не для всех интерпретируемых языков
$ cat sample1.py
import numpy as np
X = np.array([1,2,3])
Y = X
X[1] = -2
print('X=', X)
print('Y=', Y)
$ python3 sample1.py
X= [ 1 -2 3]
Y= [ 1 -2 3]
$
$ cat sample1.m
X = [1 2 3];
Y = X;
X(2) = -2;
X
Y
$ octave sample1.m
X =
1 -2 3
Y =
1 2 3
$
В смысле как она будет, если она не знает того языка которому учит? Это конечно большая проблема (я бы сказал — наибольшая проблема обучения программированию, когда учителя сами не умеют программировать), но язык-то тут при чем? Это на любом языке такое может возникнуть.
Зачем человеку углубляться в понимание таких кишок?
вспоминая себя в том возрасте, мотивация — мелкое тщеславие: «написать программу не так, как учили, но чтобы она работала правильно». а ещё лучше «написать так, чтобы учительница не поняла».
только вот именно в случае с питоном это скорее всего приведёт не к «углублению в понимание», а к «stackoverflow-driven программированию».
И конечно самая главная проблема в транспонировании матрицы в том, что обычно квадратные скобки говорят о том, что будет создан список. Именно это будет смущать человека, делающего свои первые шаги в программировании
numpy.array(matrix).TВы взяли плохой пример и построили статью на основе плохой пример == плохой язык (для первого изучения). Ну возьмите просто другой пример задачи для обучения.
Начинать надо с основ. А Python очень сильно скрывает низкоуровневые вещи, ведь он именно для этого и был создан. Это всеравно что пилота с первого курса сразу учить управлять авиалайнером, который оборудован автопилотом и кучей вспомогательных средств: может и научиться, но кто захочет с ним летать, если даже у него красный диплом.
В мои годы для обучения использовали Pascal, но в мои годы был жив Delphi. Сейчас учить Pascal ради Pascal смыла наверно нет. Хотя старый добрый Pascal никому ещё вреда не принес.
C/C++ — это по-сути единственный современный выбор. Я конечно не имею ввиду обучение всем возможностям этих языков в школе.
Скорее всего ваш выбор основывается на ваших текущих ощущениях. Но вы слишком переоцениваете знания и навыки новичков в программировании. Вам может и кажется всё элементарно в изучении C. Примерно так же как водитель со стажем может "на автопилоте" ехать домой и параллельно болтать с пассажиром, и делать ещё что-то. А вот новичкам все вещи, о которых вы даже уже не задумываетесь, будут камнем преткновения и тормозом в дальнейшем продвижении.
Когда человек уже не очень молод, тогда и элементарное чтение, и письмо может стать камнем преткновения. Это факт.
А ещё можно отбить у молодого человека всё желание учиться предмету (в данном случае — программировать), если это будет скучно и неинтересно.
Я заинтересовался программированием, потому что начал с qbasic, рисовал в нём картинки и анимации кодом. Для питона есть notebook или pygame, с которыми тоже можно интерактивно и интересно начинать обучение. А что есть у С? Не плюнет ли на программирование юный падаван после пары уроков про ссылки и ручное управление памятью?
Это всеравно что пилота с первого курса сразу учить управлять авиалайнером, который оборудован автопилотом
Ох уж эти аналогии. А я вот другую могу придумать: что если программирование — не управление авиалайнером, а вождение автомобиля? Тогда ты можешь пойти простым путём — сдавать на автомате ( = изучать питон). Конечно, ты будешь лишён части возможностей, но всё равно сможешь ездить (= писать программы) на дорогах наравне с людьми, сдавших на механике (= изучали С).
Начинать надо с основ.
Тогда почему не ассемблер? Или вообще, изучать сперва физику транзисторов, потом устройство цп, а только потом допускать до компа.
А вот если человек в самом начале пути. в юном возрасте, потратил немногим больше усилий и выучился водить механику, пересесть на автомат всегда сможет.
Но, согласен, не всем это нужно.
Ох уж эти аналогии. Представьте ситуацию, человек выучился водить механику и идёт работать на автозавод сборщиком. Думаете, ему легко будет?! Скорее всего, он будет себя чувствовать инвалидом.
А вот если человек в самом начале пути, в юном возрасте, потратил немногим больше усилий и собрал своими руками хотя бы одну машину, ездить-то на ней уж труда ему не составит.
Но, согласен, не всем это нужно.
Представьте ситуацию
Представил. К программированию она отношения не имеет.
Я писал на С++ лет 5. Потом на python и java, сейчас на js.
Пригодились ли мне специфичные для С++ знания (типа работы с указателями, ручному управлению памятью, препроцессору) мне в написании программ на других, отличных от него языках? Нет. Пригодились только общие концепты, которые я мог бы понять при изучении любого другого языка, вместо С++.
Более того, чтобы сейчас вернуться в мир С++, который очень сильно изменился (настолько, что я с трудом могу читать программы на нём написанные), или писать на С, мне придётся с нуля изучать их особенности, потому что они просто забылись.
В итоге, потраченное время на знания тонкостей С и С++ не принесло пользы при смене языка. Так зачем нагружать мозг обучаемого этим тонкостям, вместо того чтобы от них дистанцироваться и сосредоточиться непосредственно на процессе программирования? Учить строить абстракции, учить алгоритмам, парадигмам и всяким шаблонам?
Конечно, в том же питоне тоже есть свои особенности, но они куда меньше отвлекают от решения задач.
Но разговор же был изначально первом языке вообще, с которого начинается обучение. И моё имхо тут состоит в том, что с++ на эту роль слабо подходит из-за его сложности и обилия тонких моментов.
А пересаживаться на него с других языков не сложнее, а даже легче, чем изначально учиться на нём.
Это хороший аргумент, но скажем в моем случае заработать денег помогает скажем скала. А вот попытки понять как оно там на низком уровне — иногда скорее бы помешали, потому что базовый уровень абстракции в работе довольно высок.
В общем, как пример годно, но наверное не универсально.
Меня такое утверждение в такой форме вообще коробит, потому что почти ни для каких задач такого единственного выбора нет, а для многих задач выбор C/C++ просто будет неудачным. Даже если взять все тот же мир HFT, разве на сегодня условный Rust не будет реальной альтернативой, или вот прям никаких-никаких? Даже если низкий уровень важен, варианты для обучения все равно есть. Ассемблер тот же, если взять приличный.
Далеко не факт, что первый изучаемый язык, и язык, на котором человек реально будет работать это одно и тоже. Я даже думаю что почти всегда в карьере у человека будут разные языки.
В общем, как ни странно, я согласен с выводом автора, что питон не лучший язык в качестве первого, но аргументация у меня совершенно другая. Python уже на сегодня имеет длинную историю, и тянет за собой некоторый набор заморочек и странностей. И хоть с какой-то точки зрения он и простой, но можно найти и что-то еще попроще. Как минимум, есть и другие варианты. Скажем, мне близок мир Java — и в этой области есть груви, который мне больше нравится, именно в качестве языка для обучения.
println «Hello World!» // почему бы и нет?
Ну или скала, котлин… причем это вполне практичные языки со своей не узкой и стабильной нишей практического применения.
И как по мне эту книгу стоит давать всем кто думает программированием заняться попробовать.
Тогда почему не ассемблер? Или вообще, изучать сперва физику транзисторов, потом устройство цп, а только потом допускать до компа.
а почему нет?
обучение зачастую цикличное (на следующем круге более детально изучают то, что уже проходили). и на каком-то уровне нужны и ассемблер, и устройство цп, ну а физику транзисторов ЕМНИП в школе и так проходят.
поясню примером из математики: курс алгебры, если мне не изменяет память, начинался всё с тех же натуральных чисел и операций над ними, что и в начальной школе. только уже на несколько ином уровне, с введением аксиоматики и строгими доказательствами.
нужно ли начинать изучение алгебры с введения понятий поля и т. п.? мой ответ — разумеется, да. нужно ли начинать знакомство с алгеброй с этого? разумеется, нет, сначала идёт простой счёт, четыре арифметических действия и т. п.
а почему нет?
Потому что можно вполне успешно программировать без этих знаний. Эти знания полезны, но не необходимы. Изучать их как отдельные предметы хорошо.
А аналогии с математикой тут не уместны, так как питон и с нельзя однозначно сопоставить с числами или полями. Это немного другое, не находите?
а почему нет?
Потому что нормальный человек сначала учится есть кашу, потом её варить, и совсем мало кому надо знать, что там происходит от прорастания из семечка до прилавка магазина. В программировании-то с чего должно быть иначе?
нормальный человек сначала учится есть кашу, потом её варить, и совсем мало кому надо знать, что там происходит от прорастания из семечка до прилавка магазина
ну да, вот эти «совсем мало кто» и становятся программистами
Ну так "становятся", а тут бытует почему-то мнение, что если человек сознательно решил, что ему хочется научиться готовить вкусную гречку, то ему надо не с книги рецептов начинать, а с курсов агронома и мелиоратора.
Да и с гречкой, может, дойдёт до того, чтобы собственную ферму запилить с уникальной технологией выращивания, чтобы вкус был именно тот. Обсуждается же выбор первого языка программирования.
Если говорить про указатели и низкий уровень, то мне кажется, сейчас это вообще лучше осваивать через игры типа Shenzhen I/O, где сложность программируемой системы плавно нарастает, а не сваливается всей массой.
а почему или-или? ИМХО профессиональный программист должен иметь представление и о том, и о другом.
Как я и подумал, прочитав заголовок, статья о том, что питон слишком лёгкий. Но разве задача программиста не в том, чтобы быстро написать эффективный код?
Питон — вполне допустимый язык для старта, чтобы познать процедурное программирование и ООП, а потом уже расширять знания, изучая новые языки.
Для одних это осознанный шаг начать программировать и вот тут выбор ЯП — они топят за пониманием основ и т.п.
Для других это первое знакомство в школе и попытка заинтересовать и дать азы детям — они то как раз и пытаются донести что не важен синтаксис, и чем меньше шагов до результата тем для детей лучше, и им как раз не нужно пытаться что там «под капотом», итераторы или еще что то.
И обе группы как будто не видят того о чем говорит вторая.
Для человека, которому хочется «пощупать», посомтреть, а что же это такое — python как раз очень хороший выбор, и если ему уже будет это интересно, то дальше от основ на уровне логики, до основ на «уровне железа» он пройдет осознанно. Или не станет заморачиваться если ему не нужен будет такой уровень знаний — вполне себе может оказаться что для решения своих прикладных задачек python'а ему будет за глаза (тут часто хватает программирования на уровне синтаксиса и там не особо важно какой язык, а python во многих моментах позволяет быстрее и проще набросать рабочий код).
Для одних это осознанный шаг начать программировать и вот тут выбор ЯП — они топят за пониманием основ и т.п.
понимание основ — в смысле понимание железа? Если в процессе изучения С/С++ не отобъют охоту и не нанесут непоправимую травму, интересно было бы посмотреть, как объясняют многоядерность CPU, многопоточное и асинхронное выполнение, обмен данными по сети (и в разрезе могоядерности, многопоточности, асинхронности), обобщеное (non)blocking IO.
Какие там еще есть важные основы, дополняйте.
На мой взгляд, люди которые «топят за понимание основ», чаще лукавят, недоговаривая, что «основ» на самом деле очень много разных, и при некоторой заинтересованности человека, каждая из них — целы отдельный мир для изучения. Но для того, что бы начать получать первые результаты и радость от них — ничего этого не требуется.
Зато потом, несомненно понимающие основы разработчики одного из крупнейших онлайн магазинов, выкатывают приложение, которое умеет умеет «бибикнуть» телефоном, и собщить «товар доставлен», а когда приходишь забрать, требуется еще 20-30 секунд до того, как считывателю штрихкод с номером заказа, потому, что в том конкретном месте покрытие мобильной сети «так себе».
То, что одновременно с этим «бибиком» и уведомлением, можно всю фигню загрузить в телефон по быстрому домашнему интернету, при обучении основав, видимо не рассказали. А жаль. Мне, как человеку, который пользуется результатами труда «понимающих основы» программистов, хотелось бы, что бы они в первую очередь мои пользовательские задачи понимали лучше, а уж потом «основы».
можно изучать Си в школе, если цель решать олимпиадные задачки. Си очень быстрый и стандартной библиотеки хватает чтобы решать олимпиадное программирование. Плюсы: понимаешь алгоритмы, структуры данных с нуля, можно пробиться в хороший вуз с медалями олимпиад и оттуда в науку/рисерч зарубеж
если же цель — вырастить формошлепа/править ямлы/джейсоны, то питон или яваскрипт это самое то, что надо. Плюсы: понимаешь базовые взять данные с фоомы, засунуть в базу, отобразить хтмл/джейсон и тд, и пробиться на галеру.
Также можно выучить РНР и делать сайты на вордпрессах, я сам РНР обожаю и также с рнр начинал
Питон тогда еще был 1.5.2, ядро линукса вроде уже 2.x, но не суть. Попросили по-изучать задачу, захват изображения с web-камеры в приложение, и какую-то обработку (по теперешним меркам — тривиальную).
Важно то, что для макетирования задачи нужно было какой-то UI сделать, что-то у человека спрашивать, как-то с полученным видео-потоком это всё сочеталось. Начинать реализацию такого рода макета на C/C++ без опыта написания приложений с UI — это сразу неделя-две. Взять что-то скриптовое — один день. Питон был сподручнее, да и другие альтернативы на линуксе тогда сходу давали Tk в качестве UI. Наверное, v4l уже тогда был, но тоже не принципиально — поток байт с устройства получить труда не составило.
А вот для отображения нужно было разобраться какие байты за какими идут и как это всё ожидает виджет.
Думаю, уже многие правильно догадались: каждый полученный с камеры кадр, он же матрица байт, нужно было как-то обработать. Вложенные циклы на питоне, даже для разрешения 320x200 на том железе работали больше секунды на кадр, а хотелось 640x480.
Да, никаких list comprehension тогда не было даже в виде PEP.
Думаю, опять многие догадались: написать одну, даже выделю — ОДНУ — функцию обработки кадра на C и вызывать из питона заняло, тоже примерно один день (в первый раз писал C-расширение). Да-да, ровно те-же вложенные циклы, условного «транспонирования матрицы».
В итоге оно успевало 640x480 24 кадра в секунду (реально камера вроде такое не выдавала) с запасом.
Почему всё это вспомнил и даже решил написать комментарий?
Где-то с начала 2000-ых, лично я считаю ANSI C — это такой «portable assembler», это когда разработчик действительно должен понимать происходящее «в железе». C++ — это когда нужно на малых вычислительных ресурсах делать много полезной работы, с каким-то комфортом.
Сколько (в количестве разработчиков которые их решают) такого рода задач вообще? Семь процентов? Один процент? Пол процента?
С тех пор, больше всего промышленного кода я написал на python, следующий jvm-based (scala, java). Код, который приносил и до сих пор приносит реальную пользу людям. Расширение на C для питона писал может еще пару раз — обертки к уже готовым С/С++ библиотекам, которые по какой-то причине не сделали до меня.
Нужно ли человеку, который хочет отдать рутину железяке, тратить неделю-две, вместо двух дней? Тратить годы, на изучение инструмента, который реально требуется в проценте случаев, вместо пары недель, и применимости в 99% случаев?
Каждый отвечает на эти вопросы для себя и своих друзей/знакомых/коллег сам.
Мой ответ — нет, не нужно.
Для улучшения производительности в узких местах, если это потребуется, всегда можно взять более специализированный инструмент.
«Отраслевой ответ», тоже никто не скрывает — идем смотрим количество вакансий и объемы рынка в людях, в деньгах, в задачах, в зависимости от инструментов.
Гораздо важнее в самом начале хоть в каком-то виде ознакомиться не столько и конкретным языком, сколько с парадигмами: процедурная/структурная (наиболее близкая к железу), функциональная, О/ОО(П), декларативная, что-то забыл? В каких случаях нужна строгая типизация, в каких статическая, в каких не нужны и как это всё вообще между собой соотносится.
И с архитектурой приложений, в каких случаях и почему полезно доступ к данным выделять отдельно, отображение данных отдельно, обработку отдельно, вот это всё.
Всё это принесен несоизмеримо больше пользы, нежели «мы понимаем, как оно там внутри».
p.s. сколько людей понимает электричество? Сколько людей несколько раз каждый день включает и выключает свет, например? Нужно ли рассказывать про электричество до того, как научить человека пользоваться выключателями?
В этой связи вполне себе может оказаться работоспособной связка языков с похожим синтаксисом, например С (для понимания) и JavaScript (для наглядности). Это как одновременное изучение, например, английского и немецкого языков.
Лично у меня первый опыт программирования связан с освоением стекового калькулятора Электроника МК-61. Офигенно интересная штука, хотя для жизни оказалась бесполезной, кроме элементарных вещей. Для понимания изучал С, но лучше зашел Assembler. Для прикладных же вещей 20 лет назад лучше всего оказалась Java, сегодня же это JavaScript.
В результате программируя на Python в качестве первого своего языка, вы надеваете на себя розовые очки и начинаете считать, что программирование — это просто.
Python плохой потому-что слишком просто?
А что плохого в том-что просто? разве не проще идти от простого к сложному? Что же тогда в школах сначала 2+2 учат складывать, а не сразу с теоремы Эйлера не начинают? А то дети в первом классе подумают что математика слишком просто, да расслабятся!
Если раньше нужно было 8-битный процессор, чтобы запустить спутник в космос, то сейчас у нас тормозит несколько вкладок в браузере при 2-4 ядерном 64-битном CPU. Так может быть причина как раз в разработчиках, а не в «слабом» железе?
Это определенно моё любимое! По вашему если на ASM все переписать, ваши вкладки в космос улетят, вместе с браузером, как тот самый спутник в 1979. Да что мелочится прям на RCA 1802 всё можно будет и запустить. И вообще какое то непонятное сравнение микроконтроллера с браузером один решает не сложные задачи типа, если на вводе №1 логическая 1, на вводе №3 логический 0, а на входе АЦП сигнал равен 2 Вольтам значит
Что-то мне подсказывает что проблема всё таки в железе! Ну как вариант захламленная ОС, вирусы. Проверьте ПК антивирусом, а то м.б. хацкеры крипту с помощью вашего браузера майнят, а вы тут на разработчиков наговаривайте) У меня вот например, вкладок 15 открыто, и что-то ничего лагать даже не думает. Хотя железом похвастаться не могу, ноуту 10 лет.
По мне так Python в качестве первого языка вполне хорош! Спустя 1-2 дня обучения уже можно сотворить что то полезное, радуясь маленьким победам, тем самым мотивируя себя идти дальше. Плюс куча всего доступно из коробки: http запрос — вот вам urllib; БД — вот вам SQLite; GUI – пожалуйста Tkinter и т.д.
Время придет и человек поймет, что одних знаний ЯП Python мало и пойдет дальше углубятся в изучения архитектур, алгоритмов, структур и т.д. Но уже с: 1) пониманием зачем ему эти знания; 2) определенным бэкграундом; 3) азартом постигать новые вершины.
По поводу Си как первого языка! Оправдано если есть желание развиваться в embedded или ОС, драйвера. Но тут си малая часть того что нужно знать! В других случаях получится, что — это будет изучение языка ради изучения языка.
— минимум усилий — максимум результата;
— нарастающая сложность (т.е. что сейчас не нужно, то сейчас и не пишется);
— компилятор + среда + редактор — запускаются одним кликом;
и т.д.
Возможно как первый, без лишних «плюшек» типа транспонированной матрицы и нормально. Незаслуженно заминусованный пост! Возможно не явно раскрыты аргументы + конечно же это дело привычки. Меня угнетает популярность Python, так как в моем инструментарии уже есть какие-то языки, не раз пытался перейти на мышление пайтона, но это так объектно-ориентированное и функциональное программирование, нужен опеределенный отдельный стиль мышления и соответсвующая задача для него. Никто не говорит что он не хорош, но количество всевозможных библиотек и слепое доверие им — смахивает на историю с Ардуино, когда есть конечно библиетека, но чтобы она работала в твоем проекте правильно ее надо оптимизировать.
Мне кажется, что важность первого языка сильно преувеличивают. Дескать, если первый язык был неправильный, то всё, у человека всё в голове неправильно и это уже не исправить. Это не так работает. Если первый язык что-то оставил в программировании непонятным, то это исправит второй язык.
Если речь о маленьких детях, то не нужно требовать от первого языка, чтобы он сразу все концепции программирования рассказывал. Вспомните возрастную психологию, у дошкольников ведущий вид деятельности игра. Так и пусть это будет игра, которая вдобавок что-то рассказывает про алгоритмы.
Если это старшие школьники, это вообще может быть что угодно более-менее популярные. Вы же не обезьяну дрессируете. Посмотрите среди знакомых, с какого языка они начинали. Кто-то с BASIC, кто-то с JavaScript, кто-то с C, а кто-то с Pascal. И что, действительно есть связь?
Главное не язык, а тот, кто учит (или учебник/курс, если речь о самообразовании). Если он может при помощи некоторого языка показать концепции программирования, то отлично! Если первым языком будет Haskell, то это не значит, что ученик никогда не сможет программировать на C++.
Это как с первым дистрибутивом Linux. Нужно ставить тот, что у соседа.
Например, если ученик хочет изучить алгоритмы, то он может как Pascal выбрать, так и C. Как по первому множество учебников и пособий (книжки Окулова и Шеня, например), так и по второму полно.
Ну, допустим, школьнику сложнее понять, что такое указатель, а в C нужно сразу в это окунуться. И с Pascal было было проще. Но если его учитель хорошо знает C, но плохо знает Pascal, я бы не был уверен, что стоит выбрать именно Pascal.
TL;DR Роль первого языка завышена, смотреть надо по ситуации, универсального ответа нет.
Почему Python — плохой выбор для первого языка программирования?