В очень многих областях у программиста нет роскоши «бесконечной» памяти и/или «бесконечного» процессорного времени

Блин. Покажите хоть одну.

Вот для системщиков я бы давал Паскаль.

Он всем хорош как язык, но со всяким ардуино на нем не поработаешь. А демонстрация применения (если препод умеет) очень воодушевляет студентов.

Что мешает реализовать простенькую систему программирования всякого ардуино с более опытными студентами?

http://we.easyelectronics.ru/AVR/mikropascal-for-avr-osobennosti-yazyka.html

https://wiki.lazarus.freepascal.org/AVR_Embedded_Tutorial_-_Entry_Lazarus_and_Arduino

Тем, что Arduino IDE использует Си.

Есть экспериментальный порт фрипаскаля под AVR: https://wiki.freepascal.org/AVR

Но ардуина в первую очередь хороша тонной готовых библиотечек под всякие разные случаи жизни. А они все на c++.

Снимаю шляпу. Я бы не выдержал. Имел дело исключительно с «выпускниками», и то - «тяжко мне было»…

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

Само преподавание не особо сложно, если придерживаться нескольких принципов:

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

2. сложность повышать постепенно, не гнать материал

3. практика прежде теории, т.к. теория помогает осознавать, систематизировать и обобщать практический опыт

4. не все хотят стать программистами, не надо стремиться из всех сделать профессионалов

5. код идеальным не бывает, важно движение в сторону идеала, а остановиться можно где угодно

6. нужно хвалить за прогресс, даже если результат далек от идеала (а чего вы хотите от ребят которые программируют всего 20 часов?!), хвалите за прогресс, показывая как изменился их код с первых занятий

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

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

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

И да, повторение – мать учения! Только повторять должен учитель. Спокойно и методично, без наездов и жестких принуждений.

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

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

Альтернативами на тот момент были Фортран и ПЛ/1 с одной стороны. Которые тоже были предназначены для написания быстрых программ

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

И Лисп с другой стороны, где было всё для написания надёжных программ: сборка мусора, отсутствие неопределённого поведения, невозможность средствами языка влезть в неинициализированную память, но медленный

Паскаль был очень близок к полностью безопасной памяти. Лисп, как и какой-нибудь хаскель, был интересной разработкой для проверки теории, но нужно было сделать последний штрих: закопать лисп полностью и сделать практичный ЯП. Этого не сделали, и лисп продолжал бессмысленно отвлекать на себя ресурсы. В те годы лисп был совсем не тем, чем он является сейчас, тогда это был питон, который точно так же бессмысленно отвлекает ресурсы уже в 21-м веке. Перспектив развития не было ни у лиспа, ни у питона, но фанаты останутся еще лет на 50. Даже CL отошел от каноничной лисповой парадигмы «всё есть s-выражение» — и это правильно, потому что программу пишет человек, а не s-машина.

С момента, когда ассемблерные структуры перестали адекватно соответствовать примитивам Си (MMX?), развитие Си пошло по пути Фортрана

Намного раньше, уже в конце 70-х/начале 80-х.

Которые сплошной сишный массив. То есть, абсолютно любая операция, кроме «изменить ячейку» либо дорогая, как append, либо очень дорогая, как prepend или insert.

Так в Си и Си++ массивы тоже активно используются

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

Э-э-э не, кобол и бейсик тоже примерно такими были (программа отображалась в ассемблер), но это не делало их языками для написания быстрых программ.

Все программы отображаются в ассемблер. Но в случае бейсика одна операция бейсика это много команд ассемблера. А в случае Си команда Си превращалась в команды ассемблера почти как есть.

Которые в случае Си делались на ассемблере, потому что сам Си выдавал медленные программы.

Для PDP Си выдавал программы почти со скоростью ассемблера. Для x86 близкие по скорости. Оптимизации начали требоваться только с появления MMX. До этого всё, что делает компилятор для оптимизации (развёртка циклов, подстановка процедур, вынос вычислений перед циклом, …) можно было сделать на Си вручную.

Паскаль был очень близок к полностью безопасной памяти.

Указатели есть. Со всеми вытекающими последствиями. Даже в Ада есть понятие erroneous execution. Я программой на Think Pascal случайно Mac OS Classic убил (всего-то сделал Dispose на уже освобождённую область памяти, а потом пару раз выбрал «Ignore» на системные ошибки). Пришлось переустанавливать.

закопать лисп полностью и сделать практичный ЯП

А какой практичный ЯП не хуже лиспа?

Даже CL отошел от каноничной лисповой парадигмы «всё есть s-выражение» — и это правильно, потому что программу пишет человек, а не s-машина.

Так CL и есть «практичный лисп». Там и синтаксис произвольный через настройку читателя (reader) и куча наворотов типа сохранения образа с текущим состоянием или динамических переменных. И CLOS сверху.

Намного раньше, уже в конце 70-х/начале 80-х.

Приведёшь пример программы с ассемблерными вставками ради скорости из тех времён? Даже Doom обошёлся обычным Си.

Если ты будешь делать prepend большому списку в питоне, то твоя программа будет медленно работать даже по меркам питона.

std::vector::insert будет работать не быстрее.

а в том, что низкоуровневый, не универсальный

Чем предлагаешь заменить? Списком как в лиспах? Так там доступ к элементу O(n).

Или не потратишь, потому что ООП там не упал, а копипаста «в N местах» автоматизирована шаблониумом :)

SaaS/PaaS с ограничением на транзакцию N секунд(не Nцать), пара метров памяти и встроенная БД, которая не может поменяться (соответственно рефлексы жабистов намутить слой абстрагирования от базы или «смартфабрику» не работают). Алсо в эмбеде торадиционно фыркают на фреймворки от вендора как на жырное ненужно :)

потому что ООП там не упал, а копипаста «в N местах» автоматизирована шаблониумом

Шаблон писать вместо нормального кода тоже больше времени требует. Я не про ООП, а про обобщения целиком. Хоть в виде ООП, хоть в виде STL, хоть в виде мегаабстрактных функций Хаскеля.

Вообще говоря, я про примеры где она «бесконечна» спрашивал :)

Все программы отображаются в ассемблер. Но в случае бейсика одна операция бейсика это много команд ассемблера. А в случае Си команда Си превращалась в команды ассемблера почти как есть

Она превращалась в несколько команд ассемблера. Как делалось в фортране, бейсике, коболе. Что этих «несколько» было меньше в Си — да, не спорю.

Для PDP Си выдавал программы почти со скоростью ассемблера. Для x86 близкие по скорости

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

Оптимизации начали требоваться только с появления MMX

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

Указатели есть. Со всеми вытекающими последствиями

И в жаве есть указатели. Дальше что? При попытке доступа получаешь NullPointerException, но программа не скатывается в UB — и это решающее отличие промышленного языка от наколенной поделки.

Я программой на Think Pascal случайно Mac OS Classic убил (всего-то сделал Dispose на уже освобождённую область памяти, а потом пару раз выбрал «Ignore» на системные ошибки)

Сорян, я вообще не знаю, что это за звери. Я убивал дос из турбопаскаля, но лечилось простым ребутом. Что, впрочем, не обязывает делать dispose/release таким опасным.

А какой практичный ЯП не хуже лиспа?

Да хотя бы производные ML. Другое дело, что с таким же успехом я могу спросить «какой практичный ЯП лучше питона?» — их овердофига, но они не применяются массово и слабо развиваются, потому что питон всех сожрал. Точно так же тупиковый лисп тогда сожрал все ресурсы разработки, которые не были затрачены на развитие тех же ML-производных.

Так CL и есть «практичный лисп». Там и синтаксис произвольный через настройку читателя (reader) и куча наворотов типа сохранения образа с текущим состоянием или динамических переменных. И CLOS сверху

То, что ты привел, не является практичностью, потому что сильно затрудняет реализацию интерпретатора-компилятора-стандартной либы, а динамические переменные и DSL — поддержку софта, в котором разрабы решили поиграть в архитектуру. В свое время разрабы жавы думали о том, чтобы ввести возобновляемые исключения, но их вовремя остановили. 99% задач можно решить без возобновляемых исключений, а ради оставшегося процента прогибать всех не имеет смысла. Индустрия сказала свое слово, и на данный момент все или почти все массовые ЯП не имеют возобновляемых исключений (разве что Clojure, и то я не в курсе как там).

Та же история с никсовыми сигналами и fork — никому не нужно делать весь софт сигнало и форкобезопасным только для того, чтобы 1% софта захотел сделать снимок данных или сложный обработчик сигнала. Это называется «модульность» — способность одного софта разрабатываться безразлично от другого софта, и при этом обе итоговые софтины прекрасно уживаются друг с другом. И эта модульность невозможна, если одна софтина постоянно накладывает на другую какие-то требования.

Приведёшь пример программы с ассемблерными вставками ради скорости из тех времён? Даже Doom обошёлся обычным Си

Oh rly?
https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/README.asm

а в том, что низкоуровневый, не универсальный

Чем предлагаешь заменить? Списком как в лиспах? Так там доступ к элементу O(n).

Дерево или skip list.

Из за этого на ряде платформ эта программа будет недоступна

Это на каких, например?

Пиши нормальный шаблон :) что за отмазоны

Написание шаблона требует времени. Тестирование шаблона намного сложнее тестирования нешаблонного кода. И может оказаться, что всё это время потрачено зря, так как шаблон используется только в одном месте и больше нигде.

Это майндсет «добавим памяти в системные требования» :) я еще в 2005м угорал с чувака с СПб, который приехал тайга устанавливать сметный софт в строительную контору, где раньше были поделия на FoxPro («Смета-Баира»), но ключевые дискеты постепенно протухали и надо было куда-то мигрировать. Контора повелась на минимальные требования на новый сметный софт про Вынь 95 и «нимношк RAM». Все аццки свопилось и машинки жрали лицензии HASP-ключа. Паренек был фшоке, отпаивали пивом: «У нас везде Win2K и меньше двух гигов нигде нету!»

Ах-ах, какие ужосы :) а может не оказаться.

Ах-ах, какие ужосы :) а может не оказаться.

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

Хорошо написанный и оттестированный простой код можно очень легко модифицировать до шаблонов и пр., когда будет нужно, причем тогда же можно и учесть новые требования. В итоге win-win, и первый результат получаем быстро, и корректировку делаем быстро. А если писать сразу шаблоны и пр, то результат получаем медленно, нужен квалифицированный программист, а корректировать код под новые задачи еще медленней. Простые вещи делаются просто. Если просят сложить два целых двузначных числа, то не надо делать шаблоны, заводить bigint’ы и строить прочие космолеты.

x86 оптимизирован под Си, в том числе под медленные сишные строки.

Не понял. А где они были быстрые? Или какой процессор оптимизирван не под них?

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

Там ещё register был. volatile можно рассматривать как его антоним. Иначе из памяти в регистр данные загрузятся, а обратно выгрузятся только после полного окончания работы с ней. А с volatile на каждое чтение должна быть работа с памятью.

И в жаве есть указатели.

Где? Там только переменные с объектами. Или как сделать int **a?

NullPointerException

Это в случае доступа к методу или полю объекта null.

но программа не скатывается в UB — и это решающее отличие промышленного языка от наколенной поделки.

Я и привёл в пример Лисп. В нём было также. А в Паскале и Аде есть UB.

Да хотя бы производные ML.

Сейчас есть эффективные компиляторы с SML и Ocaml. Как-то популярностью всё равно не пользуются.

их овердофига, но они не применяются массово и слабо развиваются, потому что питон всех сожрал

Так питон их сожрал тем, что лучше. Или почему выбирают его?

https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/README.asm

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

Индустрия сказала свое слово, и на данный момент все или почти все массовые ЯП не имеют возобновляемых исключений (разве что Clojure, и то я не в курсе как там).

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

В 4 раза в одном тесте. там вызов функции рекурсивный. Остальное похоже на си. Слово «иногда» здесь ключевое.

Хорошо написанный и оттестированный простой код

К этому приходишь далеко не сразу. Многие (все?) проходят стадию выпендрежа «а смотрите как я ещё умею!». Со временем начинаешь ценить минимализм. Причём на всех уровнях - от архитектуры / дизайна, до собственно кода и конкретного функционала. Имхо - настоящая элегантность именно в этом, прям как у японцев с их понятиями об эстетике.

К сожалению, многие к этому вообще не приходят.

В этом плане меня сильно удручает развитие С++ в сторону метапрограмирования. Лучше бы развивались в сторону оттачивания базовых инструментов, тестирование, количество UB бы уменьшали бы и т.д.

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

(крупными буквами):

учителя Питон, не умеют ни в программирование ни в преподавание.

КОНЕЧНО, это беда не Питона, а преподавателей более всего. У них самих нет систематического образования в отличии от.

Это да. Но к счастью никто не заставляет этим пользоваться.

С методологической точки зрения мне кажется очень полезно и нужно апеллировать к asm’у. По крайней мере это то что я делаю когда вижу на ревью безосновательно переусложнённый код, весь такой «модный / молодёжный», с кучей лямбд итд. Просто предлагаю «а теперь давайте посмотрим на asm, сравним с более простым решением и померяем производительность обоих». Обычно вопросы отпадают.

Мне вот совершенно непонятно, как учить питону. Нет, конечно, я семестр мог бы введение какое-то сделать, и научить паре тем, но систематически преподавать программирование на вырост – не понимаю.

Базово можно дать процедурный подход к организации кода. Но написание программ с организации данных, т.е. с ООП уже будет сложно, т.к. там нет организации данных, там полная свобода. Вот класс, поля? какие поля? ну в init задайте, а потом их можно будет еще добавить или удалить… DataClass (или как он там) помогает лучше организовывать код, но это такая прослойка, которая тянет за собой кучу логики…

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

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

PS: непрограммистам, от программирования достаточно процедурного подхода, имхо, поэтому питон для них этим и должен ограничиваться, при массовом обучении.

Трудно всерьез воспринимать не-кроссплатформенные библиотеки в 2020+ годах, будь они хоть трижды замечательные

Delphi 11.2 Alexandria

Выпущена 07 сентября 2022 года.

Основные нововведения среды разработки:

• Поддержка iOS Simulator для языка Delphi с возможностью создания двоичных файлов iOS Simulator для устройств macOS, работающих на ARM-64 (процессоры M1 или M2). Это позволяет разработчикам тестировать свои приложения Delphi на разных устройствах Apple и в различных форм-факторах с помощью симулятора iOS без необходимости покупать специальное оборудование.
• IDE нацелена на 32 версию API Android (по сравнению с 30-ой версией API в версии 11.1), которая потребуется Google Play в ноябре 2022 года. Установщик также был обновлен, чтобы предложить установить Eclipse Temurin JDK 11, необходимый для новейших инструментов Android SDK.
• Набор инструментов Delphi для Linux ранее использовал GDB для отладки. 11.2 переключается на LLDB, что обеспечивает значительное улучшение качества как в функциональности, так и в поддержке синтаксиса языка Delphi. LLDB был обновлен до версии 12 и используется для симулятора iOS, наряду с существующим использованием LLDB для платформ C++ Win64 и Delphi macOS, iOS и Android 64.
• Добавлена поддержка Markdown. Рендеринг Markdown (.md) включает поддержку таблиц и других специальных тегов. Аналогичным образом, HTML-файлы отображаются в формате HTML в среде IDE с помощью нового встроенного средства просмотра на основе VCL. Диалоговое окно «Параметры проекта» теперь позволяет пользователям указывать файл Markdown в качестве альтернативы HTML-файлу в качестве “страницы проекта” или readme.
• Представлено множество улучшений инструментария, IDE и библиотек, в том числе: подсветка неактивного кода в редакторе кода, восстановленные преобразования XLST для получения справочной информации, улучшения библиотек Delphi, VCL, FireMonkey и FireDAC, расширенные вкладки редактора, языковой фильтр для менеджера пакетов GetIt, обновление C++ Builder Code Insight и улучшения страницы приветствия.

Мне вот совершенно непонятно, как учить питону.

отвлекаясь на актуальное : мне вот тоже не понятно как :-) ну вот свежий пример range(x) - он в начальных школьных примерах про циклы ведёт себя ровно я-ля [1 2 3 4].

То есть вроде как «выглядит как утка и крякает как утка». Ну вот на самом деле херушки :-) И с точки зрения чад попавших под обучение питону, я полностью согласен - это лютый бешеный пиз-ц.

Паренек был фшоке

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

Бабки были нужны, чуваком оказался директор фирмы. Он вкратце обрисовал задачу. Ну, думаю, задача средней сложности, по времени норм. В общем, согласился. О, если б я знал, на что подписываюсь! :-D
Короче, с тех пор я люто возненавидел как сам FoxPro, так и поделки на его основе.

отпаивали пивом

Пивом отпаивал я себя сам. Сочувствующих поблизости не оказалось, тут мне не свезло.

Признаю, что ошибался. Список возможностей впечатляет

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

И range() это хороший пример, это дает экземпляр класса, генератор с отложенным вычислением и кучу еще других непонятных слов. Хотя нужно то всего-то список цифр иметь (на первом этапе), но print(range(4)) не напечатает [0, 1, 2, 3].

там вот так надо:

print([x for x in range(4)])

почему и как это называется - без понятия.

Это понятно. Формируешь список вытаскивая элементы из генератора.

По сути, range(4) это функциональщина, ты не имеешь значения, ты их получаешь вычислением.

print([x for x in range(4)])

картинка из серии «что бы значило ?» :-)

дословно на английский приведённое выше непереводимо.Надо привлекать тибетских буддистов .. а перевод на русский не пропустит модерация :-)

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

Не понял вопроса, поэтому отвечу наугад: весь питон это дикая смесь функциональщины и ооп, да еще и с кучей костылей, чтобы программистам было удобнее.

Так навскидку скажу что меня лично питон НЕ мотивирует писать что-то именно оптимизировано. Изза тормознутости. Поэтому там у меня дикий винигрет. Но у других иногда просто непонятно винигрет это или некое уно-квази-фантазио, гениальная идея.

Оптимизация оптимизации рознь. Вот тот же пример с range(4) это не [0, 1, 2, 3], а куча прослоек, как-то неоптимально.

Есть три стадии написания кода:

1. чтобы работало

2. чтобы было написано правильно

3. чтобы работало быстро

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

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

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

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

    count = range(4)
    for k in count:
        count = [0]
        print(k in count)
        print(k)

True
0
False
1
False
2
False
3

4-ре раза! А все потому что count внутри цикла это новая переменная.

range(4) это не [0, 1, 2, 3]

>>> list(range(4))
[0, 1, 2, 3]
>>>

for в Python'е просто перебирает элементы. Если список элементов пустой, то цикл не выполняется вообще. Ни одного раза.

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

Впрочем, могу, если count будет изменяемой, например, count = [0, 1, 2, 3], а потом делать count.pop() в цикле.

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

Ладно, я уже тупить начал, значит пора спать.

Проблема в том, что он совсем не просто перебирает элементы

проблема не в этом. Трабл в том что range(4) и [0 1 2 3] ведут себя по разному в одних и тех-же кейсах. Их можно невозбранно однообразно использовать в циклах, но a=range(4) это совсем не то что a=[0,1,2,3]

Да. Это два совершенно разных типа «объектов», и как пример выше, их даже в циклах нельзя однообразно использовать.

count = [0,1,2,3] можно в цикле менять и это влияет на исполнение цикла, а count = range(4) изменить в цикле сильно сложнее.

Да. Это два совершенно разных типа «объектов».

вот от подобной разницы и проистекают все проблемы.

две фигни смотрятся и читаются одинаково, но работают сильно отлично друг от друга. Без объяснения внутреннего устройства применение невозможно. Внутреннее устройство без алг.основ тоже никак.

«это нельзя объяснить, это надо запомнить» :-) про вилЬка, торлЪко

две фигни смотрятся и читаются одинаково, но работают сильно отлично друг от друга.

Так в Си++ такое сплошь. Начиная от char* и std::string и заканчивая россыпью умных указателей.

А если считать, что если list(range(4)) == [1,2,3,4], то range(4) == [1,2,3,4], так тогда список равен массиву и целое число вещественному.

Вот класс, поля? какие поля? ну в init задайте, а потом их можно будет еще добавить или удалить…

Не знаю, я всегда рассказывал как «особенность синтаксиса». То есть если в Си++:

class A
{
  int x, y;
  A(_x,_y):x(_x),y(_y) {}
}

то в Питоне

class A:
  def __init__(self, _x, _y):
     self.x = _x
     self.y = _y

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

а перевод на русский не пропустит модерация

вывести
  список, собранный из
    x для каждого x, полученного из последовательности range(4)