Python — вновь занял топ в TIOBE
TIOBE — рейтинг самых популярных языков мира. В августе 2023 года Python ворвался в топ-1 индекса, опередив C и C++
Источник:https://t.me/pyth0n_er
TIOBE — рейтинг самых популярных языков мира. В августе 2023 года Python ворвался в топ-1 индекса, опередив C и C++
Источник:https://t.me/pyth0n_er
sh — это полноценный интерфейс, как альтернатива subprocess, который позволяет вызывать любую программу, как если бы это была обычная функция.
Все запускаемые команды импортируются, как обычные функции, но функциями не являются, а лишь динамически обращаются к командам системы. Таким образом мы можем по сути обратиться к любой программе в системе.
sh полагается на системные вызовы Unix и работает только в Unix-подобных операционных системах, т.е. данный модуль не подойдет для работы с Windows.
Для обращения к командам программы и передать набор аргументов команды, мы можем передать их как обычные аргументы функции.
Также в модуле реализована функция which, которая находит полный путь до программы либо возвращает None, если программа не найдена.
Источник: https://t.me/pyth0n_er
В примере выше первая и вторая строчки очень похожи, но различаются видами скобок. В списковом включении они квадратные, а в генераторном выражении – круглые.
Если вывести переменные, то видим, что значением переменной l является список, а переменная g хранит в себе объект генератора. И здесь возникает вопрос, что же использовать.
Нужен результат, например в виде списка, прямо сейчас для дальнейшего выполнения программы — используйте генераторы коллекций.
А если же значения понадобятся еще не скоро или неизвестно, понадобится ли они вообще, то предпочтительнее генераторы, чтобы не занимать лишнюю память и не нагружать систему.
Источник: https://t.me/pyth0n_er/30
По умолчанию числа с плавающей точкой используют память привычным образом, то есть они хранятся в двоичном виде. Это означает, что вы обычно работаете с приблизительными значениями, а не точными.
Можно использовать тип данных Decimal, который предоставит намного большую точность, но и его может не хватить в некоторых случаях.
Поэтому для идеальных вычислений лучше использовать Fraction, который представляет и хранит число в виде рациональной дроби.
Источник: https://t.me/pyth0n_er
Подход основан на CSPRNG, что гарантирует хорошую безопасность.
Что такое CSPRNG?
Это стандарт, который расшифровывается как: Криптографически стойкий генератор псевдослучайных чисел. В отличие от обычных генераторов псевдослучайных чисел (PRNG), CSPRNG спроектированы так, чтобы быть устойчивыми к криптографическим атакам и обеспечивать высокий уровень безопасности.
Основные преимущества:
1. CSPRNG нацелен на создание выходных данных, которые статистически неотличимы от истинной случайности. Это означает, что сгенерированные числа должны обладать свойствами случайности, такими как равномерное распределение и непредсказуемость.
2. Даже если злоумышленник знает алгоритм генератора и предыдущие выходные данные, он все равно не сможет вычислять будущие значения, так как данные непредсказуемы.
3. CSPRNG защищен от попытки предсказания данных и влияния на сгенерированные числа.
Источник: https://t.me/pyth0n_er/22
Команда ученых из Массачусетского университета в Амхерсте под руководством Эмери Бергера разработала профилировщик Python с открытым исходным кодом под названием Scalene. Этот инструмент помогает значительно ускорить работу программ, написанных на языке Python, который известен своей медлительностью. Scalene эффективно определяет узкие места в коде Python и предлагает программистам способы оптимизации для повышения производительности.
Python является одним из самых популярных языков программирования в наши дни, благодаря своей простоте и удобству использования. Однако он также известен своей неэффективностью, работая в 100-1000 раз медленнее других языков программирования, а некоторые задачи в Python могут выполняться в 60 000 раз дольше. Для борьбы с этой проблемой программисты могут использовать профилировщики, которые помогают определить узкие места в коде.
Однако существующие профилировщики часто неэффективны и мало помогают программистам Python. Scalene же является первым профилировщиком, который не только точно выявляет неэффективность кода Python, но и использует искусственный интеллект для предложения способов оптимизации. Scalene фокусируется на трех ключевых областях - процессоре, графическом процессоре и использовании памяти - которые ответственны за большую часть низкой скорости Python.
С момента своего публичного представления на GitHub, Scalene уже был загружен более 750 000 раз и получил награду за лучшую статью на конференции USENIX по проектированию и внедрению операционных систем. Бергер говорит: «Компьютеры больше не становятся быстрее. Будущие улучшения скорости будут происходить не за счет лучшего оборудования, а за счет более быстрого и эффективного программирования».
Источник мой Телеграм канал: https://t.me/thefutureidol
Жизнь получилась так, что параллельно с разработкой на моём актуальном стеке Python/PHP/C++/C# + MariaDB/PostgreSQL/Oracle DB пришлось программировать в 1С.
В посте не будет поливания говном ни других языков, ни даже 1С (что само по себе удивительно).
Начнём издалека, а именно с того как вообще появляются ЯП и их цели и задачи. Это важно напомнить, для понимания принципиальных отличий 1С и других ЯП.
Начнем с введения про ЯП.
Компьютер понимает только бинарный код, но писать в двоичном стиле:
00010010 00110011 00110010
или хотя бы в 16-ричном
00 AB 9C
смогут, но только единицы на планете. Но проблема в другом - ПО требуется много, а так разрабатывать очень долго. Поэтому придумали программы, которые преобразуют условно понятный человеку язык в понятный ЭВМ бинарный код.
Но ни одна программа не может мыслить, поэтому код в редакторе должен строжайше соответствовать встроенным в него шаблонам.
На второй итерации появились конструкции, которые обычно обозначают "синтаксический сахар", когда довольно большие и сложные для понимания структуры заменяются более простыми, а потом компилятор 2-го уровня их преобразует в более примитивные, а потом и в программный код. Макросы, функции, ООП, это всё тоже "синтаксический сахар".
Второй момент - организационный. Программный код сам по себе не появится, его нужно писать. Если напрямую на бинарном коде способны писать единицы, на ассемблере - в лучшем случае тысячи разработчиков, то на современных языках высокого уровня - миллионы. 1С в этом вопросе пошло ещё дальше, хоть что-то работающее на нём способен написать почти каждый человек... У которого на это будет желание.
Но... Это прорыв или провал? Парадоксально, но одновременно и то и то.
Чтобы понять прорыв нужно вспомнить такой момент - современная банковская сфера столкнулась с тем, что разработчики основного международного финансового ПО уже практически пенсионеры, а молодежь туда не особо горит желанием идти. Поэтому ситуация там весьма печальная. Как минимум 80% задач в 1С могут решать школьники с 8 класса (по шаблонам в ИТС). То есть дефицита кадров нет и скорее всего никогда не будет.
Чтобы понять провал... Идеала не существует, поэтому достигая прорыва в чём-либо одном нужно провалиться во что-то другое. И этим провалом опять же стал сам язык. Он слишком простой и примитивный.
Давайте копнём глубже.
1С перенесло всю "тяжелую" в плане понимания и реализации часть типичного ЯП внутрь поставляемой Платформы. С одной стороны всё, что требует сильного напряжения мозгов, уже реализовано... С другой стороны то же самое, но уже в ином ключе:
Квалификация:
- выучив 1С программист получает только поверхностные знания о программировании, наиболее сложные моменты остались "за кадром", поэтому полноценным программистом разработчик 1С не является;
- программист, который работает с обычным ЯП знает довольно много трюков, когда небольшая правка "верхнего уровня" (базовых классов) способна сильно упростить код "внизу"... Но не в 1С. Писать тонны кода, когда вопрос можно было решить буквально парой строк в базовом классе... Можно, но психологически напрягает.
Структура кода:
- язык 1С в плане структуры максимально однозначен и примитивен. Это позволяет учить его легко, при этом избежать 90% ошибок (мы помним, что порог вхождения почти отсутствует), из оставшихся в 90% довольно легко понять где возникла проблема и как её решать;
- но всё это делает код крайне раздутым. Я решал одни и те же задачи на разных ЯП и в 1С код спокойно может быть в десятки раз больше того же Python. Во сколько раз нужно быть умнее
Организация работы:
- программисты 1С работают в жестко сформированной среде. Тот же code-style придумывать не нужно, он вшит в язык. Многие вопросы организации проекта так же уже вшиты в синтаксис. По сути для решения задачи из материалов ИТС (или аналогичных ресурсов) нужно либо копипастить код, либо проходить "мастера" написания кода, при этом подставлять в него свои элементы. Любой другой подход скорее всего просто не будет работать;
- программисты других ЯП в этом вопросе очень свободны. В принципе на любом языке 2 и последующих поколений можно писать в почти бесконечном количестве стилей... Что на порядки повышает эффективность одного разработчика, но приводит к тому, что до 90% времени работы над проектом зачастую тратятся на то, чтобы одни программисты понимали написанное другими программистами.
Надежность:
- все наиболее сложные моменты уже вписаны в 1С, поэтому рядовой разработчик про них ничего не знает, не понимает и главное - в них не ошибается. При этом в самой 1С вшито довольно много проверок, что сильно повышает надежность приложения;
- но если программисты самой 1С где-то накосячили, сделали слабое или не оптимальное место (а этого более чем хватает), то это вообще никак не поправить и остается только смириться. Если проблема критична для проекта, то остается только писать внешнее решение и делать интеграцию, тут без вариантов. Для "только 1С" разработчиков - доводить информацию до руководства о необходимости внешнего решения.
Общий вывод:
1С является прекрасным (не рискну сказать, что лучшим, но всё возможно) решением, где недостатки платформы не настолько существенны, как её плюсы. Эта сфера - построение бизнес-решений по модели CRUD (C - create - создание, R - read - чтение, U - update - обновление, D - delete - удаление) средствами слабо квалифицированных, но при этом сравнительно легко обучаемых разработчиков.
С позиции типовых требований бизнеса 1С - наилучшее известное мне на сегодня решение.
В этой сфере 1С настолько хороша, что в других сферах её применение объективно является терминальным идиотизмом. И попытки 1С дальше двигаться в направлении расширения сфер применения - изначально тупиковые. Да, за счёт большого числа кадров можно количественно сделать много решений, но вот получаемые при этом продукты будут, мягко говоря, далеко не лучшие и лучшими быть принципиально не могут.
Сейчас я немного обосную вывод на нескольких обобщенных примерах:
1С заточена на работу с фиксированными шаблонами объектов. Документы, Справочники, разные регистры. В сфере учёта (в т.ч. бухгалтерского) и управления такие объекты практически идеально отображают все сущности, которыми нужно оперировать, тут всё замечательно. Если же сущности задачи не укладываются в типовые шаблоны, то строить из них нужную структуру и работать с ней... Возможно, но больно и реализация пишется гораздо дольше, чем на других ЯП.
Из-за шаблонизации и многословности кода разработка под 1С типовых задач идёт гораздо быстрее, чем в других решениях (основные классы, свойства, методы уже написаны и писать их повторно не надо), но написать что-то выходящее за встроенные шаблоны в лучшем случае просто возможно.
Из-за того, что синтаксис языка заточен под работу не квалифицированных специалистов он своим синтаксисом сразу решает многие проблемы (хоть и при этом не дает "вырасти"), но создаёт другую проблему, а именно в том, что для решения не типовой задачи кода нужно слишком много. Решение на другом ЯП потребует в разы меньше времени просто из-за того, что писать нужно в ...дцать раз меньше.
Из-за "единой" архитектуры решения 1С уже сегодня довольно сильно "растолстели". В любом ЯП если мне нужен какой-то функционал, то я просто подключаю (или пишу) библиотеку. В 1С практически все "библиотеки" уже в поставке платформы, в результате чего невозможно писать простые решения, решение под слабое железо и решения требующие действительно высокую производительность (или работу "на пределе"). Просто потому что работа приложения в любом случае идёт только внутри платформы, а она сегодня далеко не "дюймовочка".
Рекомендации разработчикам:
1С которые хотят уметь в другие ЯП - если Вы хотите дальше развиваться и заниматься разработкой на других ЯП, то начинайте учить другой ЯП и работать на нём не позже полугода от начала работы в 1С. Чем дольше вы "варитесь" в 1С, тем меньше шансов на то, что сможете оттуда вырваться и не из-за того, что Вы думаете. Над самыми сложными для понимания и реализации задачами уже подумали в самой 1С при реализации платформы, но разработчики в других ЯП над этим должны думать сами. При этом эти задачи требуют в разы больше знаний теории и умения применять её на практике, чем всё, что вложено в 1С. ИМХО раз в 5.
Других ЯП, которые хотят в 1С - наберитесь колоссального терпения и запаситесь успокоительным. Желаний типа "писать шаблонизаторы под типовые ситуации", "работа в нормальной IDE", "перестать тыкать мышкой там, где в другом месте можно было бы написать строчку кода" не пройдёт вообще никогда, поэтому нужно расслабляться (и поддерживать квалификацию) решением задач на основном ЯП.
Этот интересный факт о Python напрямую связан с предыдущим. На эмблеме Python изображены как раз таки змеи. Пресмыкающиеся образуют квадрат.
Составил лого брат Гвидо, дизайнер Юст ван Россум. Шрифт текста тоже изобрел он.
До 2006 года логотип Питона был текстовым. Но кобры всевозможных видов в книгах, журналах и на сайтах про Python подтолкнули к смене лого во избежание путаницы.
Источник: https://t.me/pyth0n_er/21