Да, теперь представь как все эти годы оно зарастало мхом и костылями. Понадобится, перепишем, или возьмём что-нибудь более совместимое вместо CPython. Это было 10 лет и что день когда его окончательно выкинут придёт, знали все. Сейчас приходится писать так, чтобы было совместимо, благо 27 этому способствует. Постоянно приходится отказываться от интересных фич 3 ветки, но однако вполне работает. В принципе всё там нормально с совместимостью: 27 поддерживать куда проще 26 и основные проблемы возникают когда хочешь помимо этого ещё и поддержку венды. Вот выкинут 2 и можно будет забыть про всё это дерьмо, привязаться к 37+ и перестать распыляться.

Знакомый перловик сказал, что седьмой пых быстрее с текстом работает, и типа привычно - синтаксис похож.

На хаскеле легко писать парсеры, но по скорости ничего не скажу

Для регэкспа можно pcre.c с биндингами куда угодно. Думаю, ТСу нужно что-то большее.

Всем спасибо за ответы.

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

Отметил тему как решённую, но если у кого ещё есть что сказать по делу — с интересом почитаю.

Попробуй rust.

Жабаскриптеры, например, уверены, что давно появился.

Глянь, что есть в lua. Я сам не трогал, но вроде правильный язык.

В луа есть нечего. Ты должен сам написать ему библиотеку и потом уже комфортно (на самом деле нет) решать задачу. В жабаскрипте ты сначала качаешь полгига пакетов с нескучными именами, и потом пытаешься как то решить задачу и не свихнуться.

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

Собственно, кроме того, что

некоторые (в т.ч. на ЛОРе) считают, что Перл мёртв

в перле что не устраивает-то?

Они это как-то аргументируют?

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

Там же регулярки, часть языка, как и в перле, если не путаю.

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

Касаемо быстрого regexp https://github.com/google/re2

Синтаксис руби слаще питоновского на мой вкус.
Да и однострочники на руби читабельнее, чем на питоне.
Так что я за руби.

Синтаксис руби слаще питоновского на мой вкус.

Ну, это не штука. Почти у чего угодно синтаксис слаще питоновского.

Ничего.
Нет.

Для себя сделал вывод, что вероятно, стоит попробовать найти время и осилить Ruby

Хреноватый вывод. Ruby может поприятнее, ООП... все дела... Но он тормоз, даже вот так ТОРМОЗ. Причем с каждой версией типа на каких-то синтетических тестах он стал быстрее, но в повседневных задачах он тормозит еще больше. Если тебе большие объемы молотить, то лучше повтыкай Go и смотри в сторону параллельной обработки, а в остальных случаях быстрее перловки вряд ли что-то есть.

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

Сейчас еще прийдут жабоскрипторы

Думаешь? Я уже давно хочу развести js-срач, но ничего не выходит.

Думаешь? Я уже давно хочу развести js-срач, но ничего не выходит.

А смысл. Я так понял ТС-у просто хочется поипстись. Как в анекдоте со студентом, курсовой и феей.

Руби тормоз по сравнению с чем? С другой скриптотой?

Как проверить у себя?

А смысл.

Разводить js-срач? Узнать чем живут js-еры и какие у них отмазки.

Я так понял ТС-у

Да причём тут ТС? (ТС, ничего личного)

Как проверить у себя?

тестами

И почему-то в контексте скриптописания и обработки строк никто не вспомнил про Tcl.
Хотя тиклевские пакеты отваливаются гораздо реже Ruby-Gems, живость разработки примерно одинаковая, инфраструктура сравнимая, PCRE и unicode от рождения, возможности связывания фильтров лучше, чем в bash/zsh, а c Expect - намного лучше. Конечно, несколько многословнее Perl или sh, но гораздо лаконичнее питона.

И почему-то в контексте скриптописания и обработки строк никто не вспомнил про Tcl.

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

Я конечно не эксперт с мировым именем, но утверждаю, что все показанные мне примеры плохого кода на Perl, были плохи из-за не знания автором элементарных правил хорошего стиля (Различные варианты записи имён переменных и просто шизофазия в названиях идентификаторов. Разные отступы, подпрограммы на over 300 строк и т.п.). Перекатившегося в разработку сисадмина/манагера видно невооруженным глазом. Специальное образование не просто так придумали. Народ даже книжки не читает и «программирует» по примерам со stackoverflow. Такие «специалисты» посмотрели в интернете как делать CRUD к базе данных, но ничего не знают о проектировании. Получаются безумные конструкции которые эксплуатировать сложно, не то что расширять. Но мы же не говорим что это СУБД кривая?

P.S. Руби интересен и сообщество там хорошее.

Т.е. если дёргать в bash-цикле вызов скрипта, то

может оказаться, что на bash-е и быстрее получится.

Ocaml

Можно попробовать D и запускать его посредством rdmd, #!/usr/bin/env rdmd
Можно Racket взять, если допустима схема и довольно неторопливое исполнение.

[Нескучные конкурсы] Python 3.

Во-первых, предсказуемое поведение, в том числе и для win32.

У питона свои заморочки. Не наброса ради, предположите вывод скриптов:

1.

def ConditionHell(a,b):
    e = '({0} and {1}) == {2}'.format(repr(a), repr(b), repr((a and b)))

    if a and b:
        print('{0:30} THEN'.format(e))
    else:
        print('{0:30} ELSE'.format(e))

def test_ConditionHell():
    l = ((False,True),(True,True),('a','b'),("a",""),("","b"),(0,1),(1,0),(1,2),(2,1),(True,1),("0",1))
    for a,b in l:
        ConditionHell(a,b)

test_ConditionHell()

(False and True) == 
(True and True) == 
('a' and 'b') == 
('a' and '') == 
('' and 'b') == 
(0 and 1) == 
(1 and 0) == 
(1 and 2) == 
(2 and 1) == 
(True and 1) == 
('0' and 1) == 

2.

import sys

def ArithmeticHell(b):
    print('{0} ** {1} = '.format(b, sys.maxsize),end='')
    try:
        r = (b ** sys.maxsize)
        print ("Ok")
        return r
    except OverflowError as e:
        print ('Exception')
        return e
        
ArithmeticHell(1)
ArithmeticHell(4/2)
ArithmeticHell(2)

1 ** 9223372036854775807 = 
2.0 ** 9223372036854775807 = 
2 ** 9223372036854775807 = 

1. Использовать логические операторы для небулевых операндов.

2. Удивляться.

Конечно, несколько многословнее Perl или sh, но гораздо лаконичнее питона.

Тикль лаконичнее питона? Что-то новенькое. Как буратина много писавший на тикле скажу: он дико неудобен за пределами ниши описания гуи. Хотя кому-то и лисп как родной, тут уж как у кого мозги вывернуты. Но в мейнстрим тикль не взлетел, и не мог бы. Чтобы писать скрипты на НЁХ нужно быть очень самоуверенным типом.

test_ConditionHell()

Здесь всё логично. Если ложен, возвращает его, иначе возвращает второй. Под «ложен» понимается False, 0, ".

ArithmeticHell(1)

1 ** 2147483647 = 1

ArithmeticHell(4/2)

виснет

Тоже вроде всё логично.

Но в мейнстрим тикль не взлетел, и не мог бы. Чтобы писать скрипты на НЁХ нужно быть очень самоуверенным типом.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/configuration/15-mt...

Артефакты древних. Лампово...

1.

Хоть и прочитал только туториал по питону, угадал все, очень логично. Что не так?

Хоть и прочитал только туториал по питону, угадал все, очень логично. Что не так?

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

У него просто проблемы с логикой, от языка это не зависит. Кстати, сколько памяти надо для 2 ** 9223372036854775807? Не то чтобы кто-нибудь увидит такие числа когда-нибудь, конечно.

bool(0)==bool(") но это не серьёзно — такие ошибки делать в принципе невозможно

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

$ python3
Python 3.6.5 (default, Apr  1 2018, 05:46:30) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 
>>> def ArithmeticHell(b):
...     print('{0} ** {1} = '.format(b, sys.maxsize),end='')
...     try:
...         r = (b ** sys.maxsize)
...         print ("Ok")
...         return r
...     except Exception as e:
...         print ('Exception')
...         return e
... 
>>> ArithmeticHell(1)
1 ** 9223372036854775807 = Ok
1
>>> ArithmeticHell(4/2)
2.0 ** 9223372036854775807 = Exception
OverflowError(34, 'Numerical result out of range')
>>> ArithmeticHell(2)
Killed
$

bool(0)==bool(") но это не серьёзно — такие ошибки делать в принципе невозможно

При написании не writeonly-кода обвешаться проверками типов?

Так он не дохнет. Это у тебя памяти мало.

Спор, конечно, чисто теоретический, но всё же. Когда его просят что-то сделать тяжёлое (пусть и малополезное) с вещественным числом - то пожалуйста, 'Numerical result out of range'. А когда то же, но с целым, то кинуть переполнение или out of memory exception - это уже выше его сил.

Собственно, у меня к питону хорошее отношение, хотя переход от 2 к 3 был не очень бесшовным.

пиши на С - очень быстро обрабатывает текст

Потому что вещественные это вещественные? А тут он честно пытается посчитать, что ты его просишь.

кинуть out of memory exception - это уже выше его сил

вносите царя

кинуть out of memory exception - это уже выше его сил

вносите царя

Знаешь как правильно? Расскажи.

как правильно выделять память эксабайтами? не, не знаю

Тогда или питон, или g++

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

Вот Война и Мир, скопированная раз 600 в txt файл. Считаем количество слов, используя Си, Perl, питон, руби, awk и т.д. Файл получился 900Мб, почти 40 млн слов. Открывать gedit/etc не советую. Вот что у меня:

medov@~: time wc -w v_i_m.txt              
38652894 v_i_m.txt

real	0m49,054s
user	0m48,236s
sys	0m0,202s