Perl-Conf.Ru/25

Ну, кобол, положим, еще где-то. А родной брат форта ну буквально в каждом принтере. Постскрипт называется. Оба языка (или один?) одни и те же люди делали.

> А можно узнать, где, по-вашему, FORTH?..

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

Ну не только там, ещё есть всякие микроконтроллеры и т.п. Но как аргумент для изучения языка это так себе — «сынок, не валяй дурака, учи форт, будешь с принтером на равных разговаривать».

Каждую минорную версию питона по полгода приходится мариновать в unstable, потому как куча софта не может с ней работать. Как недавно, например. В итоге у меня на gentoo почти всегда стоит два питона, так как часть софта уже перешла на 3.13, а часть ещё может работать только с 3.12. Причём то, что переписали под 3.13, нельзя было пускать под 3.12, так как в обратную совместимость питон не умеет. Сейчас вот 3.14 на подходе и снова будут те же пляски с двумя версиями.

Напиши квайн на постскрипте :)

Да ничего ты не говоришь. Ты нЭрвно «набрасываешь», похоже, не имея что сказать по существу. Поясни, пожалуйста...

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

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

По существу — нишевое применение, малоизвестны ширнармассам.

А что в прямой совместимости-то ломается?

Я регулярно большие кодовые базы обновляю до более новых версий Python: 3.7 -> 3.8 -> 3.9 -> 3.10 и т.д., иногда перескакивая через несколько, и проблем почти не бывает.

Проблемы бывают, например, при использовании менеджера зависимостей типа poetry, и когда автор какой-нибудь библиотеки указал в зависимостях что-нибудь типа python <= 3.11. Но это, всё-таки, не проблема Python как такового.

Исправил — «Плохие сам напишу» :)

Про принтеры я знаю и знал ( только не слыхал никогда, что Чак Мур имеет какoе-то отношение к PostScript), но ответ «мимо», как мне кажется...

Мне было интересно, куда человек «поместил» FORTH, заявляя «там же, где и»... :)

Весь список не помню. Последний раз точно были проблемы с dev-python/bcrypt.

я там замораживаю питон и версии пакетов

Это следствие того, что нет нормальной совместимости, да. И это общий подход для питона, потому что иначе ничего работать не будет.

Понятно, спасибо за ответ.

Откуда я знаю, что там ломалось? Я не программист. Мантейнеры пакета написали, что версии несовместимы, ждите обновлений.

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

Не встречался, баг миловал... :))

У меня в 1990-х на F-PC под ДОС «было модно» писать кросс-ассемблер для PIC16C84 на «писюке» и софт для управления «железом» программатора на этот же чип...

Когда-то я слышал историю, что Чак Мур с коллегами работали астрономами, а потом их пути разошлись. Коллеги добавили к форту графический словарь и обосновали фирму Adobe systems. Но, вроде, это не так. Связь Чака Мура с постскриптом только концептуальная. Предшественники постскипта были сильно похожи на форт. Ну и сам постскрипт, тащемта...

Откуда я знаю, что там ломалось? Я не программист. Мантейнеры пакета написали, что версии несовместимы, ждите обновлений.

Подозреваю, что речь шла именно о формальной несовместимости версий библиотек.

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

Но в целом, при обновлении на более новую версию не представляю, что может сломаться. Сам с таким не сталкивался, у других не видел.

Связь Чака Мура с постскриптом только концептуальная

Именно так.

Ну и сам постскрипт, тащемта...

100%

способствовать обмену опытом и лучшими практиками

Автор программы из одной строчки придёт?

Как-то мы в Джете устроили конкурс по-приколу на самую короткую программу, которая меняет последовательность байт входного потока на обратную. Победил перл примерно так:

#!/usr/bin/perl
while(<>) {
      print scalar reverse ;
}

А какая разница как часто я обновляюсь? Почему вообще мне каждый раз приходится что-то делать, что бы скрипт заработал? Я сейчас не про синтаксис языка, там почти во всех языках периодически что-то меняется. Но почему скрипт на перле написаный/установленый 20 лет назад без проблем запускается сейчас, а скрипт на питоне написаный/установленый год назад врятли запустится? Я про ситуацию когда это один сервер.

Есть у меня рация китайская, на которой написано «Kenwood», ну так на заборе и не то пишут. Что у нее внутри я так и не понял. Все подходящие по парамерам Joker'ы и TYTы оказались несовместимы по прошивкам. К ней прилагалась виндовая софтина, которая умеет эту рацию программировать, ну так она ж виндовая. Есть софт для прошивки офердофига раций для линуха, только он на втором питоне писан. Так я замумукался его править для питона третьего.

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

Подозреваю, что речь шла именно о формальной несовместимости версий библиотек.

Не думаю. Это системные библиотеки в основном и проверяются они тщательно. Левых библиотек в репах нет, так как «Идите в pyenv».

Но в целом, при обновлении на более новую версию не представляю, что может сломаться. Сам с таким не сталкивался, у других не видел.

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

В рабочих проектах - да. Прибивается гвоздями как версия интерпретатора, так и библиотек. Потому что иначе нельзя.

Допустим, у меня минута простоя прода стоит миллионы. И если у меня при выкатке на прод может измениться хоть версия Python, хоть версия какой-нибудь библиотеки - это может привести к простою. Потому что есть библиотеки, которые даже при смене минорной версии ломают совместимость. Увы, за всеми не уследишь.

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

В общем виде, эта проблема нерешаема. Я периодически вижу, что на эту тему дискутируют разработчики дистрибутивов, но не погружался.

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

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

наверное, потому что перл перестал развиваться 20 лет назад

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

Но почему-то пляшем на гряблях мы всё время именно с питоном. Ну, сейчас ещё потихоньку начинаем с rust, но там пока софта мало, так что не сильно заметно.

Но почему-то пляшем на гряблях мы всё время именно с питоном. Ну, сейчас ещё потихоньку начинаем с rust, но там пока софта мало, так что не сильно заметно.

Потому что это один из немногих популярных скриптовых языков, на котором в дистрибутивах написано многое.

А что там ещё может быть?

На Perl уже почти ничего нет. На Javascript всё бандлится в бандл вместе Electron.

Компилируемые современные языки, такие как Go и Rust, бандлят всё на этапе компиляции, поэтому у них нет проблем с распространением - если бинарник сбилдился, то везде, где мы его устанавливаем, ему зависимости не нужны. Проблема зависимостей у пользователя полностью отпадает.

Причём проблема с Python решаемая. Но почему-то разработчики дистрибутивов, видимо, не хотят или не спешат её решать.

Ну или как-то решают. У меня в Arch установлено несколько пакетов на Python, и ни разу не помню проблем с ними. Хотя они идут либо по пути упихивания всех зависимостей в пакеты дистрибутива, либо гибрид (часть зависимостей всё же костылится внутрь пакета с программой).

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

2017 это прям легаси? )) Каждый год переписываем на модном молодежном? )) У меня клиент один, я с ним уже 12 лет работаю…. вот лет 5 назад он продал свой сервис который как раз в 2011 начинали… Банку из топ 5. Легаси… ))

Сколько то лет назад (наверно где то в районе 10). Коллеги писавшие поиск решили половыми органами померяться…. На тему языков конечно… Одна из номинаций была минимальное количество слов в коде, пробелы табы не счетаются. Победил perl…. однострочник переписывал код в последовательность табов и пробелов, при запуске обратно…. )) Порвало всех… ))

Пора воскресить известный перловый однострочник, который maxcom лично вынес с ЛОРа в году этак 2003м вместе с предложением его запустить от рута и проверить что он делает. :) Надо сказать под дружное одобрение всех присутствующих при этом.

Ну а в чем проблема то <=3.11 я бы спросил еще в чем проблема с <=2.7 ну написали что то 10 или 15 лет назад, править с каждым обновлением? ладно, меняли 2 на 3, поломали кардинально, фиг с ним в 3 ветке при обновлениях какого ломается при через раз?

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

что предпочтительно использовать в 2025 году в качестве быстрой строкодробилки для админских и не только админских нужд

awk

Но я не хейтер перла

awk это вещь, тут соглашусь. Но для молодежи это как для меня клинопись из междуречья…. Свое предназначение выполняет, но нифига не понятно ))

Ну а в чем проблема то <=3.11 я бы спросил еще в чем проблема с <=2.7 ну написали что то 10 или 15 лет назад, править с каждым обновлением? ладно, меняли 2 на 3, поломали кардинально, фиг с ним в 3 ветке при обновлениях какого ломается при через раз?

В этом потоке сознания я так и не понял, что именно ломается. Нет примеров.

Что ломалось при переходе с 2 на 3 все прекрасно знают. И потому уже давно принято решение таких переходов больше не делать.

Но Python 3.0 появился в 2008 году. Можно уже забыть эту травматичную историю.

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

Многие инфраструктурные проблемы там давно решены. Проблема в том, что люди, не знающие python, не знают и этих решений.

Около 300 строк в мане версии Plan 9 описывают самые общие и полезные случаи использования. В мане версии OpenBSD текста побольше, но дух тот же. Проблемы, вызванные стандартизацией, увеличивают ман в десять раз в версии POSIX, но версия GNU (gnu.org), не изменяя традициям GNU, в сотни раз больше. Мне кажется, цель GNU — сделать из любого инструмента Perl. Bash и gawk очевидные экземпляры. И всё ради чего? Чтобы аккуратно покрыть какой-нибудь очередной малюсенький частный случай.

И всё ради чего?

По моему Столлман отвечал на это, что бы труднее было заменить GNU утилиты.

блин, ссылка на OpenBSD сломалась: http://man.openbsd.org/awk

Нет примеров.

Можно сколько угодно повторять мантру в стиле УМВР, но первая ссылка в гугле, с тобой поспорит.

https://askubuntu.com/questions/1502827/the-issue-caused-by-changing-python-v...

Выше я уже говорил, что были проблемы как минимум в bcrypt при переходе 3.12->3.13. Когда 3.14 вынесут из unstable, более чем уверен, что смогу ещё примеров принести, потому как каждый раз при смене версии питона вылетают одни и те же проблемы с его модулями и софтом на нём.

Многие инфраструктурные проблемы там давно решены. Проблема в том, что люди, не знающие python, не знают и этих решений.

Заморозка модулей и версий - это не решение, а костыль. И с какого перепуга я должен знать python, когда мне просто нужно установить и использовать программу?

Я не программист, но на питоне пишу. И сейчас в любой непонятной ситуации рекомендуется всё оборачивать в pyenv, куда тащить нужную версию интерпретатора и нужные версии модулей, а потом носить это всё с собой, не забывая дёрнуть activate перед запуском. Что интересно, этим приходится заниматься даже внутри докера, потому как в pip запретили устанавливать сторонние модули на уровне системы(есть способы обойти, конечно, но это снова костыли). Даже если она в контейнере.

Как-то так получилось, что я с perl познакомился раньше, чем с awk. И после простого и удобного perl'а мне уже тяжело писать на awk. Кстати, ходят легенды, что Ларри решил написать perl как раз, намучавшись с awk, не знаю, насколько правдивые.

Можно сколько угодно повторять мантру в стиле УМВР, но первая ссылка в гугле, с тобой поспорит.

По этой ссылке, человек не обновил python в системе. Человек сломал систему зависимостей дистрибутива, удалив системный пакет python, и установив вместо него свой.

Python тут не при чём, если начать так жёстко издеваться над системой, то она сломается, да. Менеджеры пакетов для того и придуманы, чтобы все изменения происходили согласованно. Если пытаться их обойти, всё может неожиданно сломаться.

Заморозка модулей и версий - это не решение, а костыль.

Иначе никак. У каждой программы на Python сейчас десятки, сотни зависимостей. Допустим, reflector зависит от python-toml==1.0.1, а meld от python-toml==1.3.0 (примеры зависимостей сейчас с потолка взял). Как установить их в одну систему? Просто никак, без заморозки модулей и версий для каждой программы в отдельности.

И с какого перепуга я должен знать python, когда мне просто нужно установить и использовать программу?

Не должен. Должны знать те, кто её распространяет.

И сейчас в любой непонятной ситуации рекомендуется всё оборачивать в pyenv, куда тащить нужную версию интерпретатора и нужные версии модулей, а потом носить это всё с собой, не забывая дёрнуть activate перед запуском.

Да, иначе все зависимости перемешаются между собой, и поломаются все программы на Python, причём совершенно неожиданным и неочевидным способом. Потому что зависимости разных программ будут иметь одно и то же название, но разные версии.

В смысле хвост виляет собакой? тоесть разработчики дистров обязанны на каждое обновление питона перелопачивать все пакеты с его использованием? )) Вообще подозреваю если бы не докер то питон бы уже умер…. Естественной смертью.

Ну в принципе это похоже на правду…. На нем и в правду тяжело писать.. Но для простых однострочников вполне нормально.

Ну вот а на perl perl-Hash-Merge зависит от Perl-Clone-Choose >= 0.08(это из недавнего). Не ==, а >=. С полной обратной совместимостью. И если кому-то нужен Perl-Clone-Choose-0.010(который и стоит у меня в текущей системе), я спокойно могу его поставить и использовать, не опасаясь, что у меня сломается perl-Hash-Merge и другие зависимые от него пакеты.

По этой ссылке, человек не обновил python в системе. Человек сломал систему зависимостей дистрибутива, удалив системный пакет python, и установив вместо него свой.

Установить новую версию Python это поломать систему? Проблема именно в Python, что установка новой версии обязательно оборачивается неработоспособностью кучи Python-программ. А то что проекты на нем представляют собой npm-помойку это отдельная тема.

Ну так дистры не обновляют Python каждый день, вообще-то. Даже в rolling дистрах, версия Python меняется не сразу.

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

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

Есть библиотеки типа icu которые ломают каждую версию ABI, и требуется либо хранить набор старых icu, либо пересобирать приложения, но обычно все же можно установить самый новый gtk, и ничего не пересобирать.

тоесть разработчики дистров обязанны на каждое обновление питона перелопачивать все пакеты с его использованием?

Именно так.

Установить новую версию Python это поломать систему? Проблема именно в Python, что установка новой версии обязательно оборачивается неработоспособностью кучи Python-программ. А то что проекты на нем представляют собой npm-помойку это отдельная тема.

В дистрибутиве а-ля Ubuntu, про который шла речь, Python идёт из пакета. Вплетённый в сеть зависимостей. Сам Python зависит от одних версий пакетов, и от конкретной версии Python зависят другие пакеты. Потому, что, например, они устанавливаются в /usr/lib/python3.7/site-packages, а там пользователь Python 3.7 просто выкинул насильно, вкрячив Python 3.8. Который ищет зависимости в /usr/lib/python3.8/site-packages и не находит то, что было установлено из дистрибутивных пакетов.

Соотв-но, сломалась не совместимость между 3.7 и 3.8. Сломалась система управления пакетами, из-за насильного разрушения кривыми руками пользователя.

Если бы этот пользователь запустил что-то типа apt-get remove --force --nodeps libc (точные аргументы не помню), у него тоже бы сломалась система, но вовсе не потому, что C плохой или libc плохая.