Хаскель, OCAML или что?
Feb. 25th, 2025 01:36 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerЧто-то очень много накопилось претензий к питону как к языку для более крупных проектов чем осмысленно писать на шелловских скриптах.
Вот на что бы такое перейти?
Чтобы оно было действительно высокоуровневое, не rust и не go.
По хорошему счету бы чтобы оно было не менее высокоуровневым чем традиционный shell.
Основные задачи - это управление кучей внешних командно-сторочных утилит, вклчюая парсинг их вывода, прогулки по файловым иерархиям и немножко всего того же самого не из командной строке, по http.
При этом хочется типизированности и компилируемости.
Переносимость в общем не шибко нужна. Debian stable (в смысле уже trixie к тому времени как соберусь что-то внеднять). На эльбрусах, пожалуй, шеллом обойдутсь, так что компилируемость вне основного набора платформ (x86_64, arm64, s390x, riscv64) не принципиальна.
X-Post to LJ
no subject
Date: 2025-02-25 12:40 pm (UTC)90% претензий к питону (за вычетом одной категории), которые я видел, сводились к тому, что питон дает писать плохо. Но никто ж не заставляет писать плохо. Та самая категория, за вычетом которой, это производительность и всякий там GIL. В описанных вами задачах я не вижу высоких требований к производительности.
Типизированность у вас есть, если вы не ленитесь делать type hinting. Да, это не дает жесткой типизации, но вы и в Си можете что угодно кастануть к void*, а оттуда в что угодно. Что до компилируемости, ну, интерпретатор же при запуске компилирует в байткод, так что ошибки, которые поймал бы компилятор, поймает и интерпретатор до этапа исполнения. К тестированию питон более требователен, чем компилируемые языки, но так что ж.
И еще два соображения.
1. Питон обходит все прочие популярные языки по скорости разработки, а уж особенно в описанной вами области. Если вам надо фигачить большой объем функционала в фатально недостаточное время, альтернатив попросту нет. Я не припомню за последние лет пять ситуации, когда у меня было больше времени, чем функционала к реализации.
2. Вы когда-нибудь покинете текущую работу, все мы, в конце концов, смертны. Баш и питон найдется кому разобрать, поддерживать и дописывать, равно как джаву, голанг или даже си с крестами или без. Уже грувиста найти будет сложно, а если мы говорим о чем-то более экзотическом, то первое, что сделает ваш сменщик - это вместо дописывания будет писать обвязку вашего кода на понятном ему языке, а второе - будет полностью выкидывать ваш код в мусор, как только получит возможность.
no subject
Date: 2025-02-25 05:45 pm (UTC)Питон не просто дает писать плохз. Perl тоже дает писать плохо. Тем не менее средний модуль на CPAN обычно куда более грамотный, чтем средний модууль на pypi.
Насчетт скорости разработки не соглашусь актегорическаи. У него скорость разработки примерно как у С или java.
ОПять же с тестами все плохо - есть целыых два примерн равномощных фреймворка, unittest и pytest ми оба хуже.
no subject
Date: 2025-02-25 06:01 pm (UTC)Нужны структуры данных - так возьмите плюсы с STL, никто не заставляет использовать Boost. Библиотеки для JSON есть. Для HTTP(S) можно на curl завязаться.
Но не берете. Значит, все-таки что-то тут такое у питона есть.
no subject
Date: 2025-02-25 06:45 pm (UTC)curl это очень хитрый предмет. Я и из шелла стараюсь его не использовать. Хотя интерфейс там погибче чем у wget. Дело в том, что там стремились поддержать столько протоколов сколько получится, и натащили с проект дырявых by design бибилотек, вроед libssh2.
Спасает только то, что во всех дистрбибутивха curl из коробеки, так что дыры в нем не моя проблема, а проблеыаы авторов дестрибтвивов (но это пока я его не использую, а поставляю софт, его использующий. Начну использовать - будет моя).
no subject
Date: 2025-02-25 03:41 pm (UTC)no subject
Date: 2025-02-25 06:50 pm (UTC)Лучше уж perl.
no subject
Date: 2025-02-25 08:39 pm (UTC)no subject
Date: 2025-02-25 04:28 pm (UTC)Python всегда вызывает проблемы переносимости.
Если хочется компилируемости, то я для себя решил, что это должен быть rust. Хотя вариант Go тоже допустим, но это для слабаков.
no subject
Date: 2025-02-25 06:50 pm (UTC)На мой взгляд, верхний размер проекта на shell (хотя я обычно старнаюсь писакть скрипты не на bash, а на posix shel) это около 500 строк. Ну с shellcheck-ом можжет быть можно 750. А если гнадо большле, то надо уже что-то другое брать. Сильно динамичепская природа шелла начинает выходить боком в проектах такого размера.
А с awk история такая ятчо есть nawk, mawk, gawk и еще чертова уйаа диалектов. Причем в отличие от версий компилятора C они все есть в одном дистрибутиве, и который из них сегодня на данной машине представеляет собой просто awk - совершенно непредсказуемо. Вот напишешь в скриепте gsub, ав он попытается выполиться на мшаине. где установлен awk, в котором этой функции нет.
no subject
Date: 2025-02-27 11:58 am (UTC)Был опыт успешной разработки на них? Выбор действительно довольно нишевый
no subject
Date: 2025-02-27 12:50 pm (UTC)Ну по крайней мере среди программ которыми я регулярно полльзуюсь есть pandoc (нааисан на haskel) и одно время был mldonkey (написан на Ocaml). То есть опыт использования программ, успешно разработанных на этих языках - есть.
no subject
Date: 2025-03-12 03:55 pm (UTC)no subject
Date: 2025-03-12 04:43 pm (UTC)Ни к какому не пришли пока. Нам непкогда мы очередные минонрные релизы постгреса выпускаем.