Комментарии 148
У новичков обычно не с языком проблема, а с базой, как и в любой другой сфере... язык это просто лопата инструмент
Если выбирать между Python и Go как первым языком для начинающего программиста, то я очевидно предпочту посоветовать Golang!
На рекламу похоже. Если про новичка, то тогда Паскаль. :) После уже без разницы какой.
Соглашусь про рекламу, не соглашусь про Паскаль.
не соглашусь про Паскаль.
Почему?
Закопайте уже дедушку пожалуйста. Он давно умер и не дает для новичков никакого особенного опыта, который нельзя получить с другими современными языками.
Как я понял, вы за Скратч для новичков?
Обучающий Паскаль, это PascalABC.Net, который написан на C# и имеет в своём арсенале почти все фишки и языка C# (включая LINQ и лямбды). Этот язык и среда постоянно обновляются.
Не говоря о том, что есть современный Delphi (наследник Паскаля).
Я сам изучал Pascal и Delphi и считаю их отличными языками для обучения программированию... если вы живёте в 90-ых, начале нулевых.
Сейчас бы я не стал их рекомендовать для обучения новичков, потому что синтаксис этих языков не похож ни на один современный востребованный в коммерческой разработке язык. А значит вся эта история чисто на период обучения, затем придётся переучиваться.
Да-да, я знаю что изучение синтаксиса занимает малую долю в освоении языка и это делается относительно легко и быстро, но всё же. Говорить ученику "сейчас мы будем изучать что-то полезное, но временное" - отличный способ сбить ему мотивацию. "А почему бы сразу не учить что-то постоянное?" спросит он и будет прав. Мир поменялся, стал более глобализованным, и в IT среде тоже. Появились всякие гитхабы. Обучать человека сразу актуальному языку - значит дать ему возможность изучать огромный массив чужого кода, предлагать свои МРы, вместо того чтобы окукливать его в академическом мирке.
Поэтому можно учить алгоритмам и структурам данных сразу на C#. Это отличный язык, актуальный, с кучей библиотек и довольно простой. Си-подобный синтаксис позволит легко перейти на целую пачку других востребованных языков. Также имеет быстрое время компиляции, что тоже полезно при освоении и проведении множества экспериментов. Или, как вариант, Java, чтобы ученик мог написать приложение под свой телефон.
Очевидный минус C#, как и подавляющего большинства современных языков, это то, что они не учат низкоуровневой работе с памятью. Но опять же, мир поменялся и сейчас процесс разработки на 95% вакансий программистов не требует ручного управления памятью. Поэтому в обязательном порядке грузить ученика этим не надо. И только если появится такой интерес - можно пощупать какие-нибудь Rust и C.
Pascal, опять же, и тут не нужен.
Delphi актуальный язык с кучей библиотек и довольно простой. А Си-подобные языки это лишь наличие там операторных скобок в виде фигурных скобок? Серьезно?
Также имеет быстрое время компиляции, что тоже полезно при освоении и проведении множества экспериментов. Или, как вариант, чтобы ученик мог написать приложение под свой телефон. Достаточно принести с собой USB провод, подключить к компу и через adb разрешить к нему доступ. А дальше прямо из среды пиши и собирай программы на телефон.
Я сам дельфист, он меня кормил и поил долгие годы, и продолжает кормить на пенсии (масса старого кода). Но - вот такая беда: есть масса отличных открытых библиотек на С/С++ аналогов которых нет на Delphi. Пишу, стало быть, "обертки" к сишным dll. Ручками, с тестами. А потом библиотека обновляется, и я должен делать все то же самое, скрупулёзно перепроверяя сигнатуры всех методов. А если библиотека для использования предполагает наследование - тут вообще труба, Дельфи идёт лесом. Отсутсвие нормальных шаблонов и лямбд - после того, как поработал с с++, очень хочется тоже. Приходится ручками вызывать деструкиоры после использования: весь дельфийский код прошит try-finally. Да можно классы реализовывать от интерфейсов, дабы избежать ручного освобождения, но практически все библиотеки реализованы без интерфейсов.
И т.д. и т.п.
Да, в Делфи есть уникальные библиотеки (отчёты, визуальные компоненты), но гораздо большего в них нет.
Да, личный состав на новые проекты на Дельфях уже очень трудно найти.
У современного Делфи проблем с отсутствием каких-то библиотек почти нет. Более того, сишные либы использует не только Делфи, если реализации нет, Питоновские библиотеки - это в 70% обертки над сишными, и проблем там особых в этом не видят.
В Делфи есть обобщенные типы и анонимные функции, которые не менее удобны, чем шаблоны и лямбды.
И вызывать деструкторы - это вообще не проблем и реализовать можно что угодно и как угодно. Например, я реализовал функционал метода defer из языка Zig в Delphi (в 10 строк) и теперь мне try/finally (или даже except) вообще не нужен.
Я и многие из сообщества Делфистов занимаются разработкой на Делфи современных программ, с решением современных проблем и каких-то особых затруднений, которые бы не решались этим инструментом не видят.
Сейчас бы я не стал их рекомендовать для обучения новичков, потому что синтаксис этих языков не похож ни на один современный востребованный в коммерческой разработке язык. А значит вся эта история чисто на период обучения, затем придётся переучиваться.
99% изучавших программирование в школе - никогда не станут программистами...
Сам когда учился нас учили на паскале потом делфи, после того как устроился на работу очень жалел что обучали именно на паскале так как несколько лет опыта на языке и изученных библиотек и тонкостей ВСЁ ЭТО НА СВАЛКУ работодателям он нафиг не нужен был, 1,5 вакансии. Понятно что учили не языку а алгоритмам и в общем принципам, но я 2,2-3 года изучал язык, его конструкции и мне бы пригодилось это все, но нет. Всем нужен был С++,Java,PHP,Ruby и в итоге программировать мы умеем, алгоритмы и структуры данных знаем но идем покупать книжку по PHP и изучать новый язык
Всем нужен был С++,Java,PHP,Ruby и в итоге программировать мы умеем, алгоритмы и структуры данных знаем но идем покупать книжку по PHP и изучать новый язык
Абсолютно верно. С хорошей базой одного языка нужные изучить уже не проблема, и эта книжка успешно заканчивается за пару месяцев вместо учебного года.
У меня в школе был турбопаскаль и там был весь спектр применений от низкого до высокого уровня, от ассемблера до ООП. На нем и олимпиады решали и графические демо пилили с музыкой и даже игры простенькие. После паскаля сесть за С было вообще легко, только синтаксис подсматривай в мануале.
Значит, все должны пройти через те же сложности, что и вы?
для программиста нужны и важны только три вещи:
1. Упорство - ибо только со временем мы поймем что все мы учили не тот язык
2. Упорство - ибо только со временем мы поймем что важнее всего НАД-штуки которые определяют то как и что ты пишешь(методы, алгоритмы, etc.)
3. Упорство - ибо только со временем ты начинаешь понимать что программирование это непрерывное Обучение...
Сложности? Да вы шутите?! Это было увлекательно. Мы начинали с 3х аудиторий, преподы по информатике были из военного училища, на территории которого находилась школа, строгие и профи. Классы часто были открыты вне учебного графика для желающих и свободных мест там не особо наблюдалось. Интернетов тогда небыло, игры считались контрабандой. Но можно написать свою ;)
Хотя, нет, было какое-то время отведено для игр совсем после занятий, на доп классах. Винчестеров в компах небыло, загрузка по сети, сеть коаксиал.
да какие там сложности-то?
Очень жаль что мне не заплатили.
Про паскаль согласен, но Delphi сейчас не пользуется популярностью у работодателей, в отличии от Go, .NET и остальных
Совершенно согласен про Паскаль :)
Я так и сделала. Вначале год учила близкого родственника Паскалю, с большим удовольствием. Паскаль ему еще пригодится, алгоритмы в академическом стиле записывают на паскалеподобном псевдокоде. Собственно, я и сама их так записываю. К счастью, изучение Паскаля соответствовало школьной программе, т.к. информатичка не знала питон. Изучили все основные алгоритмические конструкции и массивы, сдали ОГЭ. Ну а сейчас мы (внук, информатичка и я) учим питон. Нужно сказать, что я иду с большим отрывом)) сейчас учу на степике ООП Артёма Егорова и Питон для профессионалов Поколения Пайтон. Что касается впечатлений от питона. Вначале меня несколько шокировала манера передачи аргументов в функцию, но сейчас уже привыкла. Радует большое количество библиотек: только собралась делать мемоизацию - а мне уже готовый декоратор дают. Хороший язык питон, и завершает триаду известных мне языков: пролог, паскаль, питон - все на "п"))
Количество букв в коде неважно. Половина этих ужасных ключевых слов генерирует полуавтоматически IDE. Быстродействие программы, если она 99% времени все равно ждет пользовательской команды - тоже
Да, но большинство апеллирует тем, что у Python быстрее скорость разработки из-за как раз таки малого количества слов
Про быстродействие не согласен, пользователю будет лучше ждать в два, а то и в три раза меньше загрузки ответа, например, от сервера
При чем тут скорость разработки и заявленная вами тема про ЯП для новичков? Какая связь? Вы сами много людей учили или как-то помогали в обучении?
Я сам не сильно преподаватель и через меня прошли 3 человека, каждому нужен был очень разный уровень навыков программирования, такой, что они могли на работе автоматизировать какие-то рутинные вещи или просто разобраться в чем-то уже существующем и маленьком.
Я сам начинал с python, сейчас полностью перешел на golang и JS. И советовать эти языки как первые я бы стал только в том случае, если человек четко ставит себе цель. Например вкатиться во фронтэнд, бэкэнд, а может человек игры хочет делать, тогда тем более с C# вероятно начинать и стоит.
Но по моему опыту работы в разных местах (удивительно, но кодят не только в IT компаниях), чаще всего люди учатся писать что-то супер маленькое и простое, что помогает им в работе - спарсить файлики клиентов/заказчиков, собрать из БД в эксельку какой-то отчет и отправить куда-то и т.п. вещи.
Так вот в случае python людям сильно проще воспринимать его синтаксис. У меня на много больше сил и времени уходило, чтобы объяснить людям что такое стрелочные функции, асинхронность, как вообще жить со статической типизаций и о том как душно расписывать типы (вы кстати забыли об этом упомянуть, приведя в пример крайне нелепый print).
И да, часто новичкам не нужно вот это вот ХАЙЛОАД, СЕРВЕРЛЕСС, да даже линукса у 99% нет и их пугает это слово.
Вообще это правда бред сравнивать какой язык для новичка лучше.
Некоторые вообще C++ первый раз пощупали в универе, зато это им дало в последствии такую жирную базу, которую сложно переоценить.
Дядя Гвидо никогда не продвигал питон как язык быстрой разработки. Всегда этот язык был про удобство чтения и восприятия другими программистами.
у Python быстрее скорость разработки из-за
большого комьюнити, сотен, если не тысяч книг и миллионов примеров в сети. И этим он хорош и для новичка. Особенно для новичка без профильного образования, который изучает язык самостоятельно.
Про быстродействие не согласен, пользователю будет лучше ждать в два, а то и в три раза меньше загрузки ответа, например, от сервера
Вот это крайне спорная тема. Для вебни есть тысячи других вещей которые могут тормознуть запрос, самые простые - отсутствие cdn и большое расстояние, ну и просто хреновое соединение. Плюс всякие облачные базы тоже докинут тормозов уже на бэке. Вполне обычная ситуация когда на крестах нужно будет 10мс машинного времени, на пистоне 100мс, а пинг от юзера до бэка 500мс
Количество букв в коде неважно. Половина этих ужасных ключевых слов генерирует полуавтоматически IDE.
А читать потом тоже IDE будет?
Обычно есть ненагруженный фронт (js, например) и вечно перегруженный бэк (go, java, python и тп)
Количество букв в коде неважно... енерирует полуавтоматически IDE.
"Чукча не читатель, чукча писатель". Питон очень легко читать, иначе бы он не вытеснил бы perl.
Вы ещё Lua не видели. Нестрогая типизация не всегда плохо.
Змеиный язык тоже позволяет организовывать иерархию: как через классы, так и с помощью папок с отдельными файлами-модулями в них. Существует и неявный импорт, и псевдонимы позволяющие укорачивать очереди вызовов. Есть и необязательная типизация, которая не выдает ошибок но позволяет лучше ориентироваться в коде. Да, использование данных нюансов требует углубленного изучения. Но это наоборот подчеркивает, что именно новичкам разбираться в этом необязательно.
Единственная объективная претензия к Python это скорость выполнения. Но здесь достаточно просто не использовать его в критичных ко времени выполнения областях, и все будет замечательно.
Так вроде ж в Go подобие ООП.
Как раз питон и хорош для первого языка. Мне самому нравится писать и на питоне, и на го, но... новичок, когда дойдет до указателей, например, без посторонней помощи просто утонет....это отобьёт желание программировать на долгое время
Ну конечно он утонет, если учился писать код на Python. Новичок будет дополнительно шокирован, когда узнает, что у int есть ограничение максимального значения, что присутствует uint и обычный , что есть long и остальные. А указатели, да, прикол не удобный, но в C# сделали отличный оператор out для таких действий
Новичок будет дополнительно шокирован, когда узнает, что у int есть
ограничение максимального значения, что присутствует uint и обычный ,
что есть long и остальные.
Не, в Питоне драконы живут не совсем там. Они живут в семантике изменяемых данных — она крайне неочевидна. В результате и очень опытные энтузиасты Питона не могут вручную уверенно проинтерпретировать программу — всё время опасаются подвоха.
Классические:
def f( x = []):
x.append(1)
return x
l1 = [1, 2, 3]
l2 = l1 # Тут надо рассуждать в терминах указателей!
l1.append(4)
print(l2)
l1 += [5]
print(l2)Ну и недавний шедевр (спасибо тут кому-то) — что выдадут две программы
a = 1
b = 2
def f():
print(b)
a = b
f()и
a = 1
b = 2
def f():
print(b)
b = a
f()Хочу отметить, что если я все эти программы переведу на OCaml, практически кто угодно без труда их проинтерпретирует.
Тем не менее, народ пишет на Питоне много чего, причём достаточно развесистого. Отсюда мораль:
Код на Питоне обязательно надо запускать после написания. Если код на Питоне ни разу не запускался, скорее всего, правильно он работать не будет.
Желательно писать программы, которые при любом запуске полностью проходят по всем ветвям исполнения. Классический пример — ML.
Ну и для остальных приходится писать чудовищное кол-во тестов.
>Ну и недавний шедевр
Так это не про изменяемость/неизменяемость, а про область видимости и локальные переменные. Вроде бы для большинства ЯП актуальная тема
Если покопаться то в любом языка можно найти непривычные вещи.
Let's talk about javascript https://www.destroyallsoftware.com/talks/wat
Вроде бы для большинства ЯП актуальная тема
Нет, там про синтаксическое совпадение объявления+инициализации переменной и переприсваивание переменной. Эффект получается как от hoisting.
В том же C++ они сделаны так, что не перепутаешь. В OCaml'е, который я упоминал, аналогично.
out в C# это не про указатели.
Их несколько: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/out
В случае параметров, как раз про указатели
В случае параметров оно про передачу по ссылке.
Проблем понимания указателей много, и передача по ссылке в их число не входит, она как раз понятна.
Можно бесконечно спорить о терминах, но в C# указатели (и то только на значимые типы) работают только в области unsafe. Если так уж рассуждать, то любая работа с классами это работа с указателями, потому что передаётся ссылка на область в куче.
a = "Hello, World" // > Hello, World, ему все равно на такие манипуляции
Это еще что. Вот например, если в Python написать
variable = 42а затем
varibale = "Hello world"то язык тоже все проглотит, но переменная variable останется равной 42! Потому что во второй строчке опечатка:) В Go оператор := предназначен специально для объявления переменной (введения нового имени), и такой ситуации просто не может возникнуть. В Python, как ни странно, оператор := тоже ввели, но у него другая семантика, причем на мой взгляд совершенно невразумительная. В этом месте питонисты наверняка скажут - ну и что, каждый язык уникален, художники авторы языка так видят и т.п. Но я не соглашусь: все-же во всем должен быть смысл. В Python := используется для создания и изменения переменных внутри выражений. Т.е. с одной стороны хорошо - в некоторых случаях код становится компактнее, удается избежать дублирования вычислений, но с другой, а что мешает использовать := не внутри, а просто для создания переменной? Ведь очевидно что это просто частный случай. А нельзя! Точно так же нельзя использовать обычное присваивание внутри выражений - оно может быть только на "верхнем уровне".
Таким образом, я считаю что применение = и для объявления новых имен, и для присваивания - ошибка дизайна языка, но исправлять ее поздно в силу огромного количества написанного кода. И какой смысл в отличии контекста "внутри выражений" от контекста "верхнего уровня" тоже непонятно.
Спасибо, поправил.
По поводу := не совсем понятно зачем это надо, читабельность кода может из-за этого упасть, как по мне, если брать Python, поэтому я данную конструкцию при разработке особо не использовал
В Go оператор := предназначен специально для объявления переменной (введения нового имени)
И создания большого количества шума при рефакторинге. Когда добавляешь удаляешь вызов функции присваивающей значение в переменную с именем err .
Таким образом, я считаю что применение = и для объявления новых имен, и для присваивания - ошибка дизайна языка,
Я нормально живу с этим. Я использую инструменты для анализа кода и ошибка из вашего примера далёко не пройдёт.
Сравнивать языки на примере "Hello world" это эпично
Скорость - это довольно таки условно, так как не всегда, но часто всех по фиг. А где не по фиг, есть другие показатели, такие как скорость разработки, доступность программистов и т.д.
Что касается "новичков" - еще более по фиг. У них настолько мало знаний, что им еще учиться и учиться. На этом этапе почти нет лишнего, что стоит положить в голову.
Загуглил про Golang.
"Нет объектов, классов и наследования, которые усложняют код и его изменения".
Чой-то он очень на Си похож, который без плюс-плюшек.
Серьёзно? Сравнение языков по хелло ворлд?
Я думал конце стати будет реклама Ит школы :), Питан медленный и есть проблемы оптимизаций но в начале изучение будущему программисту нас***ть на эти проблемы новичок пишет код чтобы понимать логику программирование, он не будет писать энтерпрайз программы
А отсутствие статической типизации делает ваш код кашей.
Сразу видно новичка, который не в курсе про аннотации типов
Python довольно медленный язык
В тех областях, где питон обычно используется, это не имеет почти никакого значения
Весь текст, который написан здесь на русском языке, представляет собой абсолютно нечитаемую кашу. А теперь вопрос. Кто в этом виноват: русский язык, или автор текста?
К вашему сведению, минмальная программа на C# выглядит примерно так же, как и на Python:
Console.WriteLine("Hello, World!");Возможность писать программу таким образом, без лишней обвязки, называется "top-level statements", появилась она недавно, в .NET 6.0, но она - есть. Более того, она задействована в стандартных шаблонах проектов
Посему за статью, извините - минус.
Рад, что в статью исправление теперь внесено. Но что сделано, то сделано, и минус отменить нельзя.
То есть в остальном статья замечательная, да? :D
Вряд ли, ничего замечательного в ней не заметил. Но поощрение в виде снятия ранее наложенного взыскания за исправление фактической ошибки автор заслужил IMHO.
А по теме статьи я высказываться не хочу. Ибо обучением программированию я не занимаюсь, а своего релевантного опыта у меня уже давно нет.
Изучение языков программирования я начал с Алгол-60, продолжил Фортраном IV, PL/1 и немного Бейсиком (тем, старым, с обязательними номерами строк). Си изучил уже заметно потом - и вообще по справочнику (80 страничек формата A6), где-то за неделю. И так далее. Вся эта история теперь вряд ли кому-нибудь интересна - разве что, как @saipr, мемуары начать писать...
слабо
считаю, что срач "какой ЯП выбрать первым" надо закрыть
и так известно, что это паскаль
сарказм мод офф
Могу добавить очевидную вещь.
Для новичка в первую очередь важна доступность информации по языку, наличие библиотек и примеров кода и технический бэкграунд. Вне сомнений, питон тут в легкую побеждает Go. По питону на порядки больше информации, и, в том числе, на русском языке. Кроме того, новичку надо выбирать направление разработки и уже исходя из этого выбирать нужные технологии и, в частности, языки. И, конечно, работать над собственной дисциплиной. Если с дисциплиной всё хорошо и изучаемый предмет интересный, то можно выучить что угодно
Я уже написал на довольно много информации, поэтому давайте подведем итоги
Много информации - это сравнение скорости на одном тесте, с упоминанием в тексте как было плохо в более старых версиях, и сравнение удобства синтаксиса на основе Hello World? С единственным аргументом в пользу статической типизации, что в динамической можно ошибиться?
Что ж, звучит как действительно весомая аргументационная база для новичка, чтобы определиться с выбором языка по этой статье!
PS. Я не спорю, что python медленнее чем другие упомянутые языки, и динамическая типизация это не всегда хорошо, но кажется что для определения "какой язык лучше" подобных аргументов (изучаемых примерно в первый час знакомства с языком) несколько маловато..
Какая тема стоит в VSCode? Скажите точное название, pls...
Какой то грустный рассказ. Каждый язык создаётся под какие то задачи. А тут реклама go. И извините, имея три года разработки, так авторитетно рассуждать какой язык круче, как то не солидно.
Раньше были радиолюбители, первым творением которых был, как правило, радиоприёмник в мыльнице. Наверное что то такое подразумевается и в этой статье под "новичком". Иначе о чём вообще идёт речь, если этот "программист" в институтике минимум 4 года что то должен был изучать.
Начну с очевидного - первым должен быть язык со строгой не динамической типизацией, потому что после наработанного опыта под чрезмерно гибкий язык - человеку будет сильно сложнее перестроиться в сторону усложнения. А вот после Java пересесть на TypeScript/JS/Python/PHP/Perl будет проще (но зачем? :)
Вот интересно, по задаче: "Здесь мы будем делать относительно базовую программу, которая перебирает все числа от 99 до 999, т.е. трехзначные, а потом проверяет, делятся ли они без остатка на 12 и 11. " - где Вы перебираете трехзначные в реализации, если перебор от 0 до 1000? Зачем искать остаток от деления на 11, чисел которые нацело не делятся на 12? В чем смысл ставить задачу и так глупо ее реализовывать? Выводили бы просто, например, остаток от деления всех чисел от 0 до 10 000 на 7 и замеряли время работы программы на разных ЯП.
После такого, как то не очень понятно рассуждение о выборе первого ЯП.
Краткая выжимка из статьи: возможность писать любые типы данных в одну переменную затруднит отладку. Языки не отличающиеся высокой производительностью кода априори плохие.
Очень узкий обзор в плане применения языков. Контраргументы не рассмотрены вообще. Зачем я вообще это читал...
А насчёт языка для новичков. Я бы порекомендовал, например, встроенные скриптовые языки в любимых компьютерных играх, или например язык любимого опенсорс софта, куда можно законтрибутить какие-то полезные изменения (или другими словами то, что изначально кажется интересным). Прекрасно прокачивает базовые навыки, так как мотивация как правило и так хлещет через край. А дальше и на что-то более практичное можно будет переключиться.
Я, например, в детстве начал с Бейсика (встроен в zx spectrum) и довольно быстро переключился на ассемблер (на спектруме других классных альтернатив не было). Меня сильно забавляло делать разные графические и звуковые эффекты и менять/изучать код игр (благо встроенный в ПЗУ дизассемблер позволял творить чудеса). Так что в университете были моменты, когда не преподаватели учили меня а я их. Также как и была вполне приличная работа начиная где-то с 3го курса.
Любимый опенсорсный софт до сих пор в значительной степени пишется на C/C++, ибо легаси с длинной историей. А это уж точно не те языки, которые зайдут новичкам. Пока новички разберутся, как заставить скачанное с Github'а хотя бы собраться на их машине (нигде нет такого ада со сборкой и зависимостями и столь же бессмысленных и невразумительных сообщений об ошибках, как в тулчейнах C/C++), у них уже пропадёт всякое желание программировать.
я Full-stack программист с опытом командной разработки около полугода
То есть махровый джун, но мнение уже имеет.
Заголовок правильный, но суждения почему... ну так себе.
Там другие сюрпризы немного с моей точки зрения.
В питоне по факту нет приватных данных (и не говорите мне о префиксе _varname, все равно компилятор этого не проверяет). И как уже говорилось нету проверки статик типизации данных (сувай строку в int и питону сойдет), да тут твоя мысль была верной.
Из этих условий с моей точки зрения, усложняется построение кастомных структур кода. Сложней связывать множество классов, функций и тд в коде когда нету никаких проверок автоматических то что ты пользуешся верными интерфейсами каждой из компонент. Сложно рефакторизовывать код упрощая его, через складывание в микробиблиотечки/папки скрывающие сложность своего кода за более простым интерфейсом. Ибо нам сложно изменять код, ибо он нафиг весь сломается на рантайме и ничего не подсказывается компилятором об этом.
Эти проблемы классически в питонячьих проектах фиксяться очень плотным юнит тестированием. И ловлей ошибок в Staging на рантайме. Однако юнит тесты долговато вызываются и имеют все таки долгий фидбэк и уровень точности для быстрого фикса проблем решаемых на уровне статик типизации. Ловля ошибок в Staging еще дольше по фидбэку. Альтернативно еще эти проблемы решаются очень плотно используемым супер бойлерплетерным фреймворком где мы абузим правильность работы фреймворка на большую часть кода (жить в таких условиях грустновато, но можно)
В свою очередь в питоне есть возможность включить Mypy на максимальных настройках или Pyright, и тогда есть это наша статик типизация и ничего не мешает с большим удобством структурировать кастомный код.
Но чтобы mypy работал, надо чтобы весь код следовал ему :/ И было по меньше Any. Gradual Typing отличается впрочем от полной настоящий типизации и имеет подводные камни.
(P.S. в питоне есть дружелюбные фреймворки к такому подходу, FastAPI и Django Ninja. В сочетании с использованием Pydantic везде где можно, выходит весьма приятно)
И вот тут то и кроется главный дьявол с моей точки зрения. Очень малое количество питон программистов умеет в Mypy/Pyright писать питонячьий код, и я в общем то разочаровался когда либо встретить команду где с такими питонистами я бы был работал. Проще изучить язык Голанг или Джава или C#, и работать с людьми у которых нет выбора в этом плане ^_^.
Короче совет из моего потока мыслей: Изучать другие языки типа Golang, Java и тд полезно. Будет проще понять Mypy/Pyright (from typing import typing официальные доки прочитай досконально), и оперировать этим в питоне при желании. А так же исполнить желания/метания души и работать не только с питоном.
Совет номер два. Динамик типизированная натура питона на самом деле прекрасна для написания юнит тестируемого кода. Почитайте "Принципы юнит-тестирования Хориков Владимир" и "разработка через тестирование | Бек Кент", весьма полезно для выживание в питоне и не только в нем ^_^. Опыт юнит тестирования в питоне пригодиться при переходе в Golang, Java, C#, где этот процесс более затруднителен.
Дьявол кроется в том, что статик тайп-чекеры (mypy/pyright) - это сторонние тулы, которые:
Опциональны к использованию
Можно сконфигурировать так, дабы они были "лояльны" к проверяемому коду
Их можно "обмануть" - задизэйблить ту или иную failed проверку на уровне строчки кода/всего модуля
Писать везде Any
Отключить disallow_generics и писать аннотации для контейнерных типов в духе list/dict
Много всяких false-positive проверок (особенно в mypy)
И так далее, и тому подобное
Такое должно безжалостно зарезаться на code review. А у автора потом спрашивать все ли у него хорошо в жизни....
Так то в C тоже можно кастить все указатели в (void*) и потом в требуемый тип, а в какой-нибудь Java - в Object и обратно.
Знаете, сколько раз я на код-ревью получал ответ (от инициатора код-ревью) в духе "ну дык этож петон! Какие дженерики??"
Мало того, что питонисты (не все, но с большего) не умеют писать нормальные тайп-анотации, так они еще и умудряются оправдывать свое неумение тем, что мол Пайтон был разработан как dynamic-typing язык, а все эти ваши type-hints - попытка сделать из Пайтона ту же Джаву и вообще, фу.
Благо дело, на текущем проекте я как раз ответственное лицо за настройку/прикуручивание всяческих линтеров. Пускай неумехи страдают :))
Знаете, сколько раз я на код-ревью получал ответ (от инициатора код-ревью) в духе "ну дык этож петон! Какие дженерики??"
Ну дык, автор отправляется читать книжку, PR откладывается пока автор занимается самопросвещением.
Конечно, мне наверное просто говорить, потому что я еще и мейнтейню бОльшую часть проектов где делаю код-ревью. Так что последнее слово в основном остается за мной.
Благо дело, на текущем проекте я как раз ответственное лицо за настройку/прикуручивание всяческих линтеров. Пускай неумехи страдают :))
О да, линтеры спасают жизнь.
Мало того, что питонисты (не все, но с большего) не умеют писать нормальные тайп-анотации,
Я вроде научился, но не скажу, что это просто. И дело не в Питоне а в самом концепте. Может потому их и выбросили из Go?
Каким инструментом линтите типы?
Может потому их и выбросили из Go?
Что значит выбросили, вот они сразу же в хелловорлде торчат https://go.dev/tour/basics/4
Это простые аннотации, а вот дженерики в Го не влючили изначально, потому что сложно это, а язык должен быть простым.
Потом добавили.
К счастью, до создателей Go дошло, что писать тонны бойлерплейта на каждый тип это на самом деле сложнее чем дженерики)
(осталось только с убогим if err != nil что-нибудь сделать, и получится нормальный язык)
К счастью, до создателей Go дошло, что писать тонны бойлерплейта на каждый тип это на самом деле сложнее чем дженерики)
А в Rust с этим как? (кажется, там нет наследования, наверное...)
В нём есть трейты, для многих задач этого хватает
Наследование и дженерики понятия не связанные, они друг с другом не связаны и друг на друга не влияют.
Для дженериков есть трейты, они очень хорошо эту задачу выполняют.
Вместо наследования можно использовать композицию (добавлять "наследуемый" тип в качестве внутреннего поля). Чтобы не было так больно копипастить не изменившиеся методы есть, например, delegate.
Еще для снижения количества копипасты есть макросы, даже 2 вида: Macros By Example и процедурные макросы.
Первый тип не сложный, легко пишется, и неплохо помогает, но все же не настолько могущественны как второй тип.
Чтобы макросы второго типа (я просто не уверен, как нормально это "Macro By Example" перевести, чтобы было понятно что это) писать было проще и веселее можно использовать другие макросы, например quote. Вот мой личный пример его использования.
Да что сложного в дженериках, Господи... Я - питонист до мозга костей, который, чисто баловства ради, изучает Раст на досуге. Разобраться с дженериками в расте, хотя бы на базовом уровне, мне не составило особо труда. Почему это должно быть "сложно" для других ребят-питонистов? Риторический вопрос..
Буквально пару раз в жизни столкнулся с проблемой, когда вывести нужный тип было реально больно. В подавляющем большинстве случаев - все изи. Да, занимает какое-то время "на подумать", но, кмк, этот вопрос желания.
линтим типа через mypy
они еще и умудряются оправдывать свое неумение тем, что мол Пайтон был разработан как dynamic-typing язык, а все эти ваши type-hints - попытка сделать из Пайтона ту же Джаву
Но действительно: если в проекте нужна type safety и т.п, зачем писать его на Python? Выглядит как попытка научить "неумех-питонистов" забивать гвозди отвёрткой
Но действительно: если в проекте нужна type safety и т.п, зачем писать его на Python?
А если очень нужна, но не во всём проекте? Пилить на микросервисы?
Вы выражаете, как мне показалось, достаточно популярное мнение (особенно, популярное оно в среде как раз питонистов), мол, если нужно более строгое соблюдение тех или иных правил, то не нужно в целом брать Пайтон. Извините, но я с этим не согласен, причем в корне. Пайтон - отличный язык, в целом, просто он слишком... слишком много позволяет своим пользователям, а те и рады стараться) Я же лично считаю, что и на Пайтоне можно писать более-менее тайп-сэйф код, также как и контролировать мутабельность во избежание сайд-эффектов, не смотря на то, что сам язык позволяет мутэйтить почти все на свете.
Ну и как ещё один аргумент "почему Пайтон" - потому что в этом языке и у меня, и у прочих ребят в команде опыта больше, чем у любом другом. Звучит банально, но это факт.
а меня новичка, до сих пор пугает
# precision error with floats
print(0.1 + 0.2)
# Output:
# 0.30000000000000004особенно когда надо точно).особенно если действие повторяется в цикле не один миллион раз)
В большинстве языков поведение для обычных вещественных чисел будет таким же. Например, double в Java тоже не гарантирует точность вычислений, особенно если сделать что-то вроде 1.0/3.0.
Но существуют особые классы/типы вроде BigDecimal; которые гарантируют точность. Уверен в питоне тоже есть подобные библотеки (хотя бы на уровне стороних open source библиотек)
Например, double в Java тоже не гарантирует точность вычислений, особенно если сделать что-то вроде 1.0/3.0.
Во-первых -- да, гарантирует для арифметических действий. И не сам язык, а процессор, выполняющий эти арифметические действия.
Во-вторых, 0.30000000000000004 получается именно благодаря этой гарантии: это ближайшая к точному значению двоичная дробь, точнее в double просто невозможно.
Оно во многих языках так и это грех не только Питона. Но разумеется вы это знали
Это не в языках так, это так процессор работает. Особенности представления чисел в виде конечной двоичной дроби. Ну не возможно в таком виде представить число 0.3 или 0.7...
Можно создать специальный тип и хранить в нём дроби (но, скорость вычислений упадёт).
Можно. Логичнее взять библиотеку, в которой будет реализовано нужное представление. Но для чисел с плавающей точкой так делают видимо достаточно редко. Есть ли языки, в которых по умолчанию используется не то, что поддерживает процессор?
Странный вопрос, языков программирования многие тысячи и в каком-то может встретиться очень странные возможности.
Если язык предназначен для денежных расчетов, то любые потери точности недопустимы, поэтому там могут использоватся вот такие библиотеки изначально. То что это будет дольше - может быть несущественным.
Для денежных расчётов используются типы Decimal, в которых, как и при ручных расчётах на бумаге, вместо двоичной системы используется десятичная, что отражается и на результатах деления и на результатах округления чисел.
Мне странно слышать исходный посыл, что в этом языки виноваты. В этом смысл моего комментария.
Языков много, да, в том числе странных, именно поэтому я не стал писать что вообще все используют стандартную плавающую точку по умолчанию, но видимо большинство распространенных так делают.
В Python, кстати, такая либа уже есть из коробки:
>>> from fractions import Fraction
>>> Fraction(1, 10) + Fraction(2, 10)
Fraction(3, 10)
>>> Fraction('0.1') + Fraction('0.2')
Fraction(3, 10)
>>> float(Fraction(1, 10) + Fraction(2, 10))
0.3
Все можно. Например, хранить дроби в виде огромного целочисленного числа и смещения. То есть 11.3333333333333 превратиться в 113333333333333 и смещение 2. Тогда все вычисления будут производится с нужной точностью, но все это будет работать значительно дольше, потому что нужно будет реализовать арифмитические операции не на уровне процессора, а на уровне сложных алгоритмов. Это причина почему такие типы не используются в языках по-умолчанию.
Да, теперь то я знаю и надо было бы уточнить, чтоб не минусовали, что двоичную алгебру, способы представления вещественных чисел в памяти через преобразование в двоичную счистему с мантиссой и прочими прелестями , я особо не проходил (не программист) и такое поведение,несколько сбивает с толку.Особенно в условиях
(0.1+0.2) is 0.3
Falseнадо было бы уточнить, чтоб не минусовали, что двоичную алгебру, способы представления вещественных чисел в памяти через преобразование в двоичную счистему с мантиссой и прочими прелестями , я особо не проходил (не программист)
Чтоб не минусовали, лучше не писать на темы, про которые вы заранее знаете, что не разбираетесь.
Я, например, знаю, что не разбираюсь в астрофизике, и если стану комментировать хабрапосты по этой теме -- меня заминусуют, и правильно сделают.
Не надо оператор is использовать для сравнения чисел, это не проверка на равенство, а проверка идентичности (т.е. что объект один и тот же) ((0.1+0.2) == 0.3 тоже выведет False).
Вот пример, почему такое его использование приведет к проблемам:
Заголовок спойлера
x = 100
y = 100
print(x is y) # Output: True
print(id(x))
print(id(y))
x += 100
y += 100
print(x is y) # Output: True
print(id(x))
print(id(y))
x += 100
y += 100
print(x is y) # Output: False
print(id(x))
print(id(y))
Неизвествность всегда пугает, это нормально. Узнаете как это работает внутри, бояться перестанете. Задача хранить число с неограниченной точностью в ограниченном размере памяти, не решается. Значит надо чем-то жертвовать. Попробуйте найти удобный для вас матерьял на эту тему. Знания не критически важные, но полезные.
IEEE 754 наглядно, вообще плохая идея сравнивать числа с плавающей точкой
Golang по быстродействию как С++, спасибо, заставили улыбнуться )
Язык, на котором нужно генерить тонну бойлерплейта, и топорный настолько, будто его разработали в 70-х, ммм, дайте два)
Было больно читать. Автор - делайте вычитку перед публикацией. Жаль, минусы ставить не могу)
Блин, а вот раньше на PHP куда профессиональнее накидывали на вентилятор. Слабовато)
Да, это правильно, но теперь вы ошибились в коде и почему-то в переменную а передаете не число(изначальное), а строку:
Садись, два. В языке Python нет переменных, есть имена. Поэтому они ведут себя таким образом. Можно ещё найти пару примеров интересных эффектов этого, в комментариях выше уже набросали.
Это одна из базовых особенностей языка, которые надо изучить в самом начале, чтобы понимать, что вообще происходит. Все концепции имеют свои последствия, в том числе способные нас иногда удивлять. В другом языке будут другие особенности, что-то будет логичнее, что-то нет. В Python достаточно простой в этом плане язык, его сюрпризы можно достаточно просто объяснить.
Я считаю что Python достаточно хороший язык для начальных курсов программирования, и я его преподавал как первый язык программирования несколько лет. Потом С++. Сам я изучал сначала С, это достаточно больно, потому что там очень много нетривиальных технических деталей, которые позволяют выстрелить себе в ногу совершенно нетривиальными способом, так что потом и эксперт будет неделю разбираться, не то что новичок. Python позволяет сосредоточиться на изучении основных конструкций языка, не отвлекаясь на понимание того, почему нельзя на сделать оператор присваивания в классе если у него есть деструктор, например. И в Python можно всё легко вести последовательно, сначала просто что-то посчитать, потом функции, потом классы, можно и функциональное программирование маленько потрогать. И по сфере применения почти никаких границ нет, можно что угодно потрогать.
И не надо нагромождать всё эти слова как в примере на С#, да, IDE может это и рисует, но новичку надо понять что вообще происходит и зачем всё это.
Pascal? Спасибо, но я не люблю когда на меня кричат. Это не вежливо. И это имело очень мало практического смысла в дальнейшей жизни даже когда я учился в университете в начале 90ых. Зачем?...
У любого языка есть своя область применения. Да, из-за отсутствия каких-либо проверок типа в Python неудобно писать большие проекты (ну и мелкие тоже). Но, с другой стороны, благодаря этому можно собрать вместе совершенно разнородные библиотеки, одна из которых например скачет картинку по сети, другая её как-то обработает, а третья обучит нейронную сеть. И не надо париться что они все используют разные классы для предоставления матриц, например. Python это клей.
С другой стороны, даже в С++ можно собрать багов из-за "неожиданной" работы автоматического преобразования типов.
Скорость? Ха-ха, весь data science работает на python. Данные крутят либы, написанные на С или даже Fortran, а Python это всё склеивает. И это правильный способ, потому что когда люди пишут обработку данных на С это кончается тем, что фигачат три вложенных цикла не задумываясь, так как язык "быстрый". А потом всё тормозит. Когда такое начинают делать на Python, то сразу понимают, что делают что-то не то.
Существенный недостаток Python - отсутствие поддержки вытесняющей многопоточности. Но это а) не про введение в программирование б) убивает очень злые возможности выстрелить себе в ногу в) уже идут работы по внесению этой поддержки.
Уровень аналитики и аргументации, я извиняюсь, крайне низкий. Уровень "нормальности" языков определен некорректно. Статья просто ни о чем. Хотя было бы не плохо, если бы новички слезли с питона, ибо всякие онлайн школы их толпами гонят учить именно этот язык, в итоге стадо плохо подготовленных вкатунов разрывают hh.
Полностью согласен с названием статьи, но содержание разочаровало. Гораздо полезнее для новичков было бы понять, почему лучше стартовать с языка со строгой типизацией и иммутабельностью, типа Go, Kotlin или Swift
Лучший языки для начинающих это сначала Си без плюсов, потом с плюсами, потом Python. Из графических фремворков лучше начинать с Qt.
Причём вся эта четверка хороша и с академической и с прикладной точек зрения. Включая программирование как вспомогательных инструмент в других видах деятельности.
С языками имеющими проблемы с кроссплатформенностью, если Вы входите в программирование здесь и сейчас, лучше не заморачиватся.
Лучший языки для начинающих это сначала Си без плюсов
Это чтобы сразу отсечь как профнепригодных и бесперсективных тех, кто не разобрался с указателями и malloc? :-)
Си без плюсов простейший по синтаксису из живых и востребованных языков высокого уровня, сразу учитывающий базовые особенности работы с аппартной частью. Питон язык более абстракный.
сразу учитывающий базовые особенности работы с аппартной частью
Чтобы научиться водить, по-вашему, нужно быть автомехаником?
Чтобы, хорошо, в том числе проффессианально максимально безопасно, водить автомобиль безусловно да надо разбиратся в его матчасти, а быть механиком это другая профессия. Например понимать, как и почему входить в упраляемый занос, делать полицейский разворот, и много чего еще требующего понимания матчасти.
Чтобы водить просто на уровне продвинутой блондинки, есть неотключаемаяя ABS, коробка автомат, без возможности ручного переключения передач, и прочие уровни абстракции, снижающие порог вхождения, но не выходя за которые, вы теряете в управляемости авто.
Не вижу ничего плохого ни в ABS, ни в АКПП, ни в прочих уровнях абстракции, снижающих порог вхождения: каскадёрские трюки и сишное байтоёбство понадобятся только тому, кто базового уровня уже достиг, а вы с этого "максимально профессионального" уровня предлагаете начинать обучение?!
"Не вижу ничего плохого ни в ABS, ни в АКПП" спорить на эту тему, столь же бессодержательно, как например, "что лучше Си или Питон".
Так же замечу, что ни одна серьезная методическая программа не предусматривает для новичка освоение теоретической части сразу(до первой практики, и даже первого трудоустройства) на уровне Марка Лутца и Бьярне Страуструпа. Хоть для одного языка хоть для нескольких. Не вдавайтесь в демагогию.
Но если вы метите именно в профессиональные водители(а не только проехать по мегаполису от дома до работы), нужно то знать и понимать матчасть, разные уровни абстракции, и т.д. Практическое поэтапное изучение живых и востребованных языков с разной парадигмой, на мой скромный взгляд, лучший способ стать высококвалифицированным профессионалом.
Если возвратиться к вашей аналогии, то заниматься автокаскадерством, для проффесионального водителя, это возможное хобби, а вот, например навыки контраварийного вождения(и не только), это необходимая часть профессинальных навыков профессионального водителя, без которых изрядная, и наиболее оплачиваема, доля вакансий на рынке труда ему будет недоступна.
Это чтобы сразу отсечь как профнепригодных и бесперсективных тех, кто не разобрался с указателями и malloc? :-)
Кто не способен понять концепцию памяти как ленты с адресами, у которой вот там - стек, а вот там - куча.. Может действительно, зачем ему эти компуктеры, можно же нормальную работу найти.
Прочитал заголовок, зашел статью лайкнуть, а тут и лайкать нечего..
Причем здесь веб-разработка?
несмотря на то, что имеет СТАТИЧЕСКУЮ типизацию и ООПшный стиль
Может процедурный всё таки?|
А ведь он по быстродействию как C++
Нет
Python несмотря на условную скорость написания кода не настолько удобен и быстр, как, например, Golang
возможно кому то if err != nil будет удобным, но не мне
В Python вообще то можно указать тип переменной:
a: int = 5
Это называют аннотациями. На код они не влияют, а другому человеку будет понятнее.
Новичкам нужно C# или Java давать и не морочить голову. Классика ООП на пару со статической типизацией. Кроме того, там и стек устоявшийся по всем направлениям и хороший материал для обучения есть. Популярность этих языков тоже отличная. Не вижу смысла в выборе между Java и Python выбирать второй. После того как "прохавают" базу, пусть уже переходят осознанно к тому или иному языку. Если конечно их чем-то всё-же не устроит жаба/шарпы.
Проблема питона в высокой конкуренции за рабочее место среди новичков.
> Сказ о Python или почему его лучше не выбирать новичкам
Я бы вообще так вопрос не ставил. Новичок должен выбирать язык программирования исходя из своих планов на будущую карьеру.
Одно дело, если он собирается быть профессионалом в системах разработки, а другое, если для него это просто хобби.
Если второе, то можно учить любой язык, который нравится, даже ассемблер. А если для использования в своей будущей работе, то, сначала, нужно определиться с желаемой специализацией. Это может быть разработка игр, создание прикладных баз данных, веб-программирование, мобильное программирование и т.д. и т.п.
Если подходить к вопросу фундаментально, нужно ориентироваться на высшее образование, в области точных наук и работе с современной техникой и технологиями. Учить математику, поскольку она развивает абстрактное мышление, что весьма полезно (хотя и не обязательно) для хорошего программиста. Учить программирование не только в ВУЗе (там преподают плохо, сужу по техническому ВУЗу и мехмату МГУ, в которых я учился десять лет, очно), но и самостоятельно. Скажем у Ильфака Гильфанова – автора широко известного, в узких кругах, «народного» дизассемблера «IdaPro» и у меня был общий научный руководитель из лаборатории системного программирования МГУ. Но, он, как и я, основы программирования изучал, в основном, самостоятельно.
Программист ценен, если он полезен для высокотехнологичного предприятия (космос, оборона, ИИ, экспериментальная физика, и т.д. и т.п.). Тогда у него и зарплата будет хорошая и карьера. Мне светила сногсшибательная карьера, когда я после второго ВУЗа – МГУ, устроился в очень привилегированное, научно-производственное объединение, шеф которого буквально носил меня на руках. Однако, чтобы моя карьера не состоялась, высшие силы решили уничтожить СССР :) . Тем не менее, удалось выжить, практически без зарплаты, в «лихие 90-тые».
Сейчас ситуация явно лучше. Даже с теми потенциалом и возрастом, я бы и сейчас был бы «обречен на успех».
Теперь о моем скромном опыте по языкам программирования.
Мой самый любимый язык – С++ с использованием легкого фреймворка WTL. Специализация – разработка десктопных приложений, ориентированных на пользовательский интерфейс (который традиционно разрабатывается по остаточному принципу). Второй мой любимый язык – Питон (хотя очень много времени я программировал на Visual FoxPro).
Здесь надо сказать, что С++ - фундаментальный язык программирования, любой вундеркинд в программировании должен знать его как «облупленного». А Питон это язык обработки данных, в этом его самая сильная сторона. Причем, скорость работы для этого совершенно не нужна, главное удобство работы с данными, поскольку, их, обычно, готовят разово.
И в С++ и в Питон очень удобно и выгодно иметь дело с Sqlite.
Тем не менее, так получилось, что платят мне не за эти навыки, а за разработку собственной системы учета на 1С77, которая кормит меня уже почти двадцать лет.
Да я могу работать и в «восьмерке» (1С8х) и писать собственные конфигурации там. Тем не менее, возиться с чужими конфигурациями мне не нравится (которые обычно делаются по принципу: «Нам с ними не работать!»). Сколько бы не хаяли «семерку», но я от нее (плюс мои собственные внешние компоненты) без ума, до сих пор, при всех ее ограничениях и моральном устаревании). Если нужно внедрить собственный учет на среднем предприятии (до пары тысяч человек), то я бы и сейчас предпочел разработать собственную конфигурацию на 1С77, с использованием дешевого терминал-сервера (у нас подобный, с двумя гектарами памяти, работает 20 лет, ну и зачем нам «восьмерка»?).
Что же, до хобби, то разрабатываю собственную программу и данные для
изучения иностранного языка, но это уже отдельный разговор.
Новичок должен выбирать язык программирования исходя из своих планов на будущую карьеру.
А если это школьник, который ни с карьерой, ни с профессией ещё не определился? Должна быть возможность, просто ознакомиться с программированием, чтобы решить подходит ли эта профессия , а не так что "родители сказали я пошёл учится на программиста, и уже в ВУЗе понял, что это не моё".
Питон - это прежде всего библиотеки, каа и любой язык. Что с библиотеками в голанде?
Уважаемый автор, python имеет не статическую, а динамическую типизацию, странно предъявлять сразу же таковым обозначенным языку за это. Да и не думаю, что новичку будет сильно проще, если ему дать язык с статической типизацией.
Да и мне кажется, что новичку как раз будет проще разобраться в вполне лаконичном синтаксисе питона(не в обиду пользователям других языков сказано) , нежели импортировать несколько библиотек и делать классы ради "хеллоу-ворлд".
Да и причём, казалось бы, тут скорость? Новичку, скорее всего, важен сам результат, а не скорость его выполнения да и питон никогда не указывался как особо быстрый. Если же у новичка возникнет надобность в скорости, то он может взять, в случае чисел, библиотеку numpy, которая, если не ошибаюсь, почти что обёртка над С.
Слишком бережное отношение к новичкам. Это как ребенка с раннего детства оберегать - не давать ему упасть, заболеть, ошибиться... Вырастет ничего не могущий и всего боящийся человек. Другое дело - научить, дать возможность попробовать свои силы, разрешить ошибаться и дать пофрустрировать для осознования и мотивации сделать по-другому.
Сказ о Python или почему его лучше не выбирать новичкам