Всё-таки, выбирая лучший язык для обучения, нужно учитывать цели этого самого обучения. Если учат будущих программистов, то Pascal однозначно лучше, чем Python, но вообще-то стоит подумать про C вместо Паскаля. Если язык программирования учат как дополнительный курс, не с целью стать программистом, просто, как удобный инструмент, то возможно Python будет лучше, потому что он может пригодится практически во многих сферах.
Мне всё-таки кажется, что удел Pascal - это школы, потому что школьники ещё не знают, в какую сторону они пойдут, а этот язык заложит академические основы программирования, при этом сам по себе он в будущем не пригодится.
Как вам уже ответили, масса имеет очень большое значение при вибронагрузках. Которые очень сильно отличаются на самокате/моноколесе и легковом автомобиле. Поэтому в легковых машинах основная масса располагается на подвеске, а сами колёса - чем легче, тем лучше.
И, предугадывая следующий ответ - при одинаковой амплитуде и частоте вибрации, но разной массе - вибронагрузка будет разная.
Ну, а по массу, вы конечно забыли? Речь идёт о мотор-колесах легковых автомобилей весом "пару тонн", которые упоминались в комментарии, на который я отвечал изначально.
Не сравнивайте легковой автомобиль с самокатом/моноколесом. Слишком разная масса, как самого средства, колеса, так и двигателя. И скорость очень разная
Могу ошибаться, но мотор-колесо на гражданском транспорте - скорее исключение, чем правило. В основном электродвигатель как раз на подвеске и стоит, чтобы не делать сами колеса слишком тяжёлыми. Плюс требования к вибро-устойчивости такого двигателя на колесе сделают его слишком дорогим. Повторюсь, что могу ошибаться, так что поправьте, если мои рассуждения не верны.
этап когда читать 2-3 страницы текста стало не напряжно
Очень много зависит от конкретной книги. Я примерно так прочитал всего Гарри Поттера (на русском не читал до этого). А потом я как-то взялся за Dune Фрэнка Херберта, которую люблю с детства - я не вылезал из словаря, и в конце концов бросил это дело. Кстати, Harry Potter and Methods of Rationality читается даже лучше Роулинг. JFYI
Большие числа. «1+1=2» я могу посчитать на английском, но когда начинаешь оперировать с большими числами, то переключаешься на русский язык, затем делаешь математическую операцию, затем результат переводится на английский.
Кроме чисел у меня аналогичная проблема с днями недели и временем. С числами ещё возникает неловкая ситуация, когда для ответа нужно что-то посчитать не слишком сложное, но ты зависаешь на этапе трансляции входных данных, потом результата. А выглядит все это как будто ты считать не умеешь.
Однако вендоры low-code платформ предлагают основной рабочей лошадкой назначить аналитиков, а не разработчиков, оставив последним совсем уж специфичные задачи.
Я понимаю это так: аналитики "возят мышкой по экрану", формируя бизнес логику из кубиков (простите за формулировку), а программисты создают этим самые кубики. Звучит, в принципе, не плохо. Однако на практике может прозвучать "выжпрограмисты - вот и делайте всё. Это же упрощает вашу работу". Работал я как-то с подобной системой автоматизации бизнес-процессов. С тех пор я ненавижу low-code, простите.
Тут опять же проверка на базовое знание языка. Выражения if 55: на самом деле выполняется так: if bool(55): Ну, а оператор сравнения работает со значениями, поэтому 55 == True вернёт False.
Но если честно, то очень часто такие "элементарные" задачки формулируются таким образом, что они вместо теста на знание языка превращаются в тест на внимательность. Поэтому с ними лучше не переборщить.
Да видел я про Технику Молодежи, и ссылку на Википедии посещал, когда уточнял, правильно ли я помню про ЗГГОГи ))) Спасибо за ТМ, с же вам кивал плюсик поставил, но та книга мне очень сильно олдскулы свела, особенно тем, что я наконец-то окончательно убедился, что цифра 2 на ней не просто так. Можно сказать, что одна из величайших тайн моей жизни открыта ))
Нашел в интернете эту книгу. Всё-таки я ошибся, там нет Еггогологии, но зато в конце есть игры для МК-61. Посадка на Луну и прочие. Аж олдскулы свело от воспоминаний.
Если кому-то будет интересно: "Игры и развлечения 2", 1990. Издательство "Молодая гвардия". https://www.koob.ru/firsova_l/
Как правильно готовить Python для энтерпрайз - боюсь, что ответ не вместить в комментарий или даже статью. Если очень коротко, то ответ общий для всех ЯП:
голова на плечах
знание ЯП и предметной области
правильное использование нужного инструментария (линтеры, статические анализаторы, и прочее)
хорошее покрытие тестами (для Python, как и для любого другого динамического ЯП нужно очень хорошее покрытие)
опыт
???
Мой опыт говорит о том, что сложную бизнес логику реализовать на Python можно. Так же, при грамотном подходе, можно легко или относительно легко менять её при изменившихся бизнес-требованиях (иногда при кардинально изменившихся).
Python не идеальный язык, у него куча недостатков, производительность - это явно не его (но есть нюансы), динамическая природа привносит много своих неприятностей, однако сфера его применения очень обширная. В корпоративной среде он распространяется очень широко, нравится это или нет.
Опыт мне подсказывает, что для работы с данными используется очень малая часть возможностей Python, как ЯП, потому что в этой сфере важно знание принципов работы с данными и соответствующих бибилиотек. Нюансы и глубокое понимание языка тут не так важно. С исследованиями скорее та же ситуация, если понимать под этим одноразовые Jupyter ноутбуки или скрипты.
В bloody enterprise всё-таки используется немного другой Python (если это не data, ML или AI. Но и тут есть простор для деятельности) со всеми своими достоинствами и недостатками. Бывают, конечно и исключения, особенно когда опытные разработчики вынуждены писать на новом для них Python после поверхностного изучения основ синтаксиса. Этого часто достаточно, чтобы написанный код работал, но сопровождать его становится больно, динамическая природа языка только ухудшает ситуацию. Обычно в таких случаях формируется мнение, что Python не пригоден ни для чего серъёзного.
В общем, моя основная мысль - в bloody enterprise Python может работать вполне хорошо, просто нужно уметь его приготовить.
Эта ветка комментариев не про новые движки, а про то, что на данный момент мотор-колёса - редкость в легковых автомобилях, и про то, почему это так.
Всё-таки, выбирая лучший язык для обучения, нужно учитывать цели этого самого обучения. Если учат будущих программистов, то Pascal однозначно лучше, чем Python, но вообще-то стоит подумать про C вместо Паскаля. Если язык программирования учат как дополнительный курс, не с целью стать программистом, просто, как удобный инструмент, то возможно Python будет лучше, потому что он может пригодится практически во многих сферах.
Мне всё-таки кажется, что удел Pascal - это школы, потому что школьники ещё не знают, в какую сторону они пойдут, а этот язык заложит академические основы программирования, при этом сам по себе он в будущем не пригодится.
Как вам уже ответили, масса имеет очень большое значение при вибронагрузках. Которые очень сильно отличаются на самокате/моноколесе и легковом автомобиле. Поэтому в легковых машинах основная масса располагается на подвеске, а сами колёса - чем легче, тем лучше.
И, предугадывая следующий ответ - при одинаковой амплитуде и частоте вибрации, но разной массе - вибронагрузка будет разная.
Ну, а по массу, вы конечно забыли? Речь идёт о мотор-колесах легковых автомобилей весом "пару тонн", которые упоминались в комментарии, на который я отвечал изначально.
Не сравнивайте легковой автомобиль с самокатом/моноколесом. Слишком разная масса, как самого средства, колеса, так и двигателя. И скорость очень разная
Могу ошибаться, но мотор-колесо на гражданском транспорте - скорее исключение, чем правило. В основном электродвигатель как раз на подвеске и стоит, чтобы не делать сами колеса слишком тяжёлыми. Плюс требования к вибро-устойчивости такого двигателя на колесе сделают его слишком дорогим.
Повторюсь, что могу ошибаться, так что поправьте, если мои рассуждения не верны.
Очень много зависит от конкретной книги. Я примерно так прочитал всего Гарри Поттера (на русском не читал до этого). А потом я как-то взялся за Dune Фрэнка Херберта, которую люблю с детства - я не вылезал из словаря, и в конце концов бросил это дело.
Кстати, Harry Potter and Methods of Rationality читается даже лучше Роулинг. JFYI
Кроме чисел у меня аналогичная проблема с днями недели и временем.
С числами ещё возникает неловкая ситуация, когда для ответа нужно что-то посчитать не слишком сложное, но ты зависаешь на этапе трансляции входных данных, потом результата. А выглядит все это как будто ты считать не умеешь.
Посмотрите на досуге исходники модуля
this, того самого Дзэна Питона ;-)Я понимаю это так: аналитики "возят мышкой по экрану", формируя бизнес логику из кубиков (простите за формулировку), а программисты создают этим самые кубики. Звучит, в принципе, не плохо. Однако на практике может прозвучать "выжпрограмисты - вот и делайте всё. Это же упрощает вашу работу". Работал я как-то с подобной системой автоматизации бизнес-процессов. С тех пор я ненавижу low-code, простите.
Подушню:
На самом деле их четыре. Есть даже специальная аббревиатура: правило LEGB - local, enclosed, global, built-in
Тут опять же проверка на базовое знание языка. Выражения
if 55:на самом деле выполняется так:if bool(55):Ну, а оператор сравнения работает со значениями, поэтому
55 == Trueвернёт False.Но если честно, то очень часто такие "элементарные" задачки формулируются таким образом, что они вместо теста на знание языка превращаются в тест на внимательность. Поэтому с ними лучше не переборщить.
Да видел я про Технику Молодежи, и ссылку на Википедии посещал, когда уточнял, правильно ли я помню про ЗГГОГи )))
Спасибо за ТМ, с же вам
кивалплюсик поставил, но та книга мне очень сильно олдскулы свела, особенно тем, что я наконец-то окончательно убедился, что цифра 2 на ней не просто так. Можно сказать, что одна из величайших тайн моей жизни открыта ))Нашел в интернете эту книгу. Всё-таки я ошибся, там нет Еггогологии, но зато в конце есть игры для МК-61. Посадка на Луну и прочие. Аж олдскулы свело от воспоминаний.
Если кому-то будет интересно: "Игры и развлечения 2", 1990. Издательство "Молодая гвардия".
https://www.koob.ru/firsova_l/
Помнится, кроме ЕГГОГ там ещё был ЗГГОГ. И вообще - была целая наука Еггогология. По ней в какой-то книжке отдельная статья была.
Как правильно готовить Python для энтерпрайз - боюсь, что ответ не вместить в комментарий или даже статью. Если очень коротко, то ответ общий для всех ЯП:
голова на плечах
знание ЯП и предметной области
правильное использование нужного инструментария (линтеры, статические анализаторы, и прочее)
хорошее покрытие тестами (для Python, как и для любого другого динамического ЯП нужно очень хорошее покрытие)
опыт
???
Мой опыт говорит о том, что сложную бизнес логику реализовать на Python можно. Так же, при грамотном подходе, можно легко или относительно легко менять её при изменившихся бизнес-требованиях (иногда при кардинально изменившихся).
Python не идеальный язык, у него куча недостатков, производительность - это явно не его (но есть нюансы), динамическая природа привносит много своих неприятностей, однако сфера его применения очень обширная. В корпоративной среде он распространяется очень широко, нравится это или нет.
Опыт мне подсказывает, что для работы с данными используется очень малая часть возможностей Python, как ЯП, потому что в этой сфере важно знание принципов работы с данными и соответствующих бибилиотек. Нюансы и глубокое понимание языка тут не так важно. С исследованиями скорее та же ситуация, если понимать под этим одноразовые Jupyter ноутбуки или скрипты.
В bloody enterprise всё-таки используется немного другой Python (если это не data, ML или AI. Но и тут есть простор для деятельности) со всеми своими достоинствами и недостатками. Бывают, конечно и исключения, особенно когда опытные разработчики вынуждены писать на новом для них Python после поверхностного изучения основ синтаксиса. Этого часто достаточно, чтобы написанный код работал, но сопровождать его становится больно, динамическая природа языка только ухудшает ситуацию. Обычно в таких случаях формируется мнение, что Python не пригоден ни для чего серъёзного.
В общем, моя основная мысль - в bloody enterprise Python может работать вполне хорошо, просто нужно уметь его приготовить.
Соглашусь. Экран без выреза - дорогого стоит. Вкусовщина, конечно же, но мне, например, это было принципиально.
Ура, учёные подтвердили мою теорию!!! /joke
Я не специалист. Почему это подается, как достоинство? Типа радуйтесь - а могли сделать, чтобы требовалось?