Местный корпоративный жаргон, привык уже.

Почему? Там очень хороший код имхо: понятный, читаемый, расширяемый.

Возможно. Но логов почти нет, и чтобы найти причину неработы, приходится нырять в код. Примерно так я себе представляю будни ассенизатора-1с'ника, так что от otrs не в восторге

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

Знаю таких.

А, это да, отладка принтами на продакшене :(

Я использовал Perl в ~1990-2001 гг. Ушёл на PHP :)

Подозреваю, что ты больше работал с perl и прав.

Хотя возможно мы смотрим с разных точек зрения. Я пишу не сайты, а скрипты ( да, иногда они постепенно перерастали в информационные системы ), от < 1кб до ~ 80 кб. Интерпретатор переваривал мой говнокод за доли секунды, а т.к. мне нужен был один одновременный запуск ( а не спавн на каждый запрос ), то я оценивал скорость по скорости работы кода, а не задержке на интерпретацию. Т.е. мне гораздо важнее было, как быстро скрипт перелопатит гигабайт данных. Тут пока мои питоньи поделки, кхм, немного медленнее :)

Так что пока я останусь при своём мнении ( «для скриптов, но не крупных проектов» ), но уже буду валить не только на ооп, а и на отсутствие типизации и слабую многопоточность :D

Спасибо за дополнительные агрументы ;)

А рубчик как и перл стух давным-давно.

https://octoverse.github.com/

Ты тут Perl видишь? А вот Ruby там 4-й.

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

Думаю, что в базовой поставки Ruby нет из-за хаоса с обратной совместимостью в пакетах. Каждое обновление Ruby-инфраструктуры — это лотерея с невысоким шансом мягкого обновления. Сколько было Ruby-приложений, каждый раз с обновлением что-то ломается и нужно пилить. Поэтому на нём так мало и пишут всякой скриптоты. И поэтому его мало используют в системном программировнии. Т.е. это минус, уже являющийся второй производной.

Интерпретатор переваривал мой говнокод за доли секунды

Э... Единственный мне известный массовый сегодня системный интрпретатор — это bash.

Perl (о нём речь?), Python, PHP, Ruby — все их популярные реализации являются компиляторами в байткод.

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

А рубчик как и перл стух давным-давно.

Ну и пусть. Мы же о скриптоте в одно рыло, а не о найме пионэров.

Думаю, что в базовой поставки Ruby нет из-за хаоса с обратной совместимостью в пакетах.

Так никакие пакеты и не нужны, нужен просто интерпретатор. То, что одни пионэры понаписали приложений на скриптах, а другие запаковали это в дистры, это не вина интерпретатора скриптов.

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

Так никакие пакеты и не нужны, нужен просто интерпретатор

Ruby — компилятор. Уже много-много лет. Только первые версии были интерпретирующими.

Я, например, испытываю боль от перловских представлений переменных. То она скаляр, то она же массив, то хеш... И функции, при объявлении sub name {...} даже не понятно сколько аргументов в нее следует передавать.

Отрой для себя указатели. Это в детских книгах пишут, что в perl 3 типа данных ( скаляр, массив, хэш ). В взрослых рассказывают, что их несколько больше ( + указатель, файл, функция, объект )

Нечитаемо. Именно синтаксис кошмарный.

На вкус и цвет все фломастеры разные. perl golf приводит в ужас, но нормальные люди пишут так, чтобы можно было читать. Синтаксис, по секрету, унаследован от Си ;) Хорошо читается, отлично видны границы блоков ( и удобно с ними работать в vim ). Встроенные регулярки - вообще прекрасно, на порядки удобнее чем какой-нибудь поиск по строке или работа с регекспами как с объектами.

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

И нет особых проблем с обратной совместимостью в рубях.

Не в самом Ruby. А в его инфраструктуре. В его библиотеках.

По-крайней мере эти проблемы точно не запущенней, чем в питоне или там луа (где вообще маразм).

Про Lua я ничего не говорю. А вот у Питона с этим всё на порядок лучше. Обновление типичного приложения на Питоне проблемы иногда вызывает, но редко. У Ruby — почти всегда.

нормальные люди пишут так, чтобы можно было читать

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

Perl — это w/o язык.

Синтаксис, по секрету, унаследован от Си ;)

Не синтаксис, а грамматика, тогда уже. Это ни о чём. Сравни синтаксис Perl и Java :) И тот, и другой — наследники Си. Но синтаксис качественно разный. На Java труднее писать, но намного проще читать и поддерживать. На Perl легко писать, но много сложнее читать и поддерживать. Поэтому Perl и потерял свои позиции, хотя когда-то был первым номером в списке системных языков.

Не в самом Ruby. А в его инфраструктуре. В его библиотеках.

Ну, о чем я и говорю. Все проблемы в сторонних либах, которые 1) не сильно то нужны, 2) если нужны, подключаются через rubygems. Т.е. полная аналогия с перлом. Не нужно только пытаться паковать в дистре все на свете, и не нужно писать приложения на скриптовом языке.

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

Да ладно, можно же просто

package MyClass;
sub new {
  bless {@[1..$#_]}, $_[0]
}

А потом

#package main;

my $obj=new MyClass(option=>$value, ya_option=>$ya_value);

И всё! Готовый шаблон класса, осталось методы добавить.

Вообще хотя на Perl есть 1001 способ понагенерировать акцессоров - реальной пользы от этого немного. Куда чаще нужно не получать/менять свойства объекта, а принуждать оный объект сделать что-то полезное Родине.

А в чём принципиальная проблема писать приложения на не скриптовом, а интерпретируемом языке? Кстати, не стоит эти два понятия путать: скриптовый язык - встраиваемый язык, преимущественно оперирующий готовыми элементами своего окружения и отдающий результат тоже готовым элементам окружения. Интерпретируемый язык - это инструкции для исполнителя-интепретатора, он может быть каким угодно. Например, R - интерпретируемый язык, но ни разу не скриптовый. Python, PHP - интерпретируемые языки, но не скриптовые. А вот Lua в Redis - встроенный скриптовый язык сценариев.

А в чём принципиальная проблема писать приложения на не скриптовом, а интерпретируемом языке?

В динамической и зачастую еще и слабой типизации.

Кстати, не стоит эти два понятия путать

Да, ты прав. Просто под скриптовым здесь я имел ввиду язык сценариев типа шелла.

Да ладно, можно же просто

Можно. Только зачем писать bless, если в других языках это делается автоматически?

Потом в методах нужно вручную доставать $self из @_

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

Много мелочей, но всё вместе раздражает - нужно помнить об этих мелочах, вместо того, чтобы решать свою задачу

А машкод сам по себе интерпретируемый? Кто знает, что там в черном ящике происходит...

В какие гоо-рода-ааа Наверна в край чудесный Где каждый день еда Они уйдут неслышно Пока весь город спи-ит Им письма не напишут Никто им не звани-и-и-ит

В динамической и зачастую еще и слабой типизации.

Я не вижу никаких объективных преимуществ написания «типизированного» кода, кроме того факта, что типизация облегчает проверку аргументов, несколько снижая накал тотальной паранои.

Вот с точки зрения производительности да, типы данных критичны. Но как бы далеко не всегда нужны супер-показатели производительности, а гораздо чаще - нужны показатели скорости наращивания функционала, а здесь-то как раз у perl'а мало конкурентов, поскольку это язык, на котором реально пишется легко и быстро. В том числе и потому что система типов не стреляет тебе постоянно в ноги, вынуждая задумываться над тем, будет ли у тебя вот тут целое-целое или целое-плавающее или ещё какая галиматья, которую нужно преобразовывать по 10 раз.

ну наверное да.

Парсер на регулярках — это вообще треш одноразовый. Из тех времен, когда админ трясся над аптаймом сервера и очень боялся того, что вдруг прийдется ПЕРЕУСТАНАВЛИВАТЬ!

ruby вообще почти не используется для приложений. Только платформа для создания веб-сервисов

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

+1

Я не вижу никаких объективных преимуществ написания «типизированного» кода

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

Т.е. полная аналогия с перлом

Не-а. Не полная. В Perl-архитектуре такого хаоса не было. Обновления очень редко что-то ломали.

И, поскольку тенденция общая, то дело не в конкретных разработчикам, а в чём-то более общем. Кроме самого языка больше ничего в голову не приходит :)

Python, PHP - интерпретируемые языки

Все популярные сегодня реализации — не интерпретируемые, а компилируемые.

А машкод сам по себе интерпретируемый?

Зависит от условий исполнения. Если это современный x86, то там интерпретация в микрокод, насколько я понимаю.

Ещё хитрее, например, байткод JVM. На Java-процессорах от обрабатывается сразу. На x86 он сперва JIT-компилируется в нативный код, который уже интерпретируется в микрокоды процессором...

А в потоке сознания компилических погромистов разбираться не нужно что ли? Они всегда пишут кристально ясный код? Мне кажется, как раз когда кода хотя бы по объёму меньше, он таргетирован на функциональных задачах, а не на мышиной возне, понять-то его как минимум проще. Ну и сдаётся мне, что все эти ошибки типов и прочее подобное - это мизерный процент от куда более серьёзных логических и алгоритмических ошибок.

Полно приложений написано и на Perl'е, а уж сайтов типа Booking'а или LiveJournal'а - просто несметное количество было в 2000-е, и до сих пор многие работают.

У Perl'а есть совершенно определённая проблема: производительность. На фоне того, что количество потребителей интернет-трафика (выраженное в виде числа соединений в единицу времени) растёт темпами, несоизмеримыми с темпами роста числа его производителей - нагрузка на каждого конкретного производителя - растёт. При этом доля полезной нагрузки снижается, а это значит, что с увеличившейся нагрузкой необходимо справляться при том же бюджете, что и раньше, а иногда (РФ, КрышНам...) и при меньшем.

Соответственно, становятся всё более популярными бинарные протоколы и «бинарные» же (компилируемые) языки.

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

Тем не менее, слухи о смерти Perl'а сильно преувеличены: просто зарабатывать деньги с его помощью будут всё реже и реже, но использовать для решения повседневных задач «пятой линии коммерческого фронта» - не перестанут ещё, может, и 10 лет, и 20, пока живы люди, хорошо владеющие языком.

Ну уж, PHP 7-то с какой стати вдруг компилироваться стал?

Потом в методах нужно вручную доставать $self из @_

Можно не доставать, пользоваться $_[0].

Вопрос в другом: а что делать, если метод некоего класса вызван как нечто вроде MyClass->method, &MyClass::method() а не $obj->method() ?

Вот это несколько выводит из себя, потому что нельзя сказать просто, что вот это - метод объекта и пусть только попробует кто его использовать как нечто иное. Perl не в состоянии гарантировать, что первый параметр метода - это именно инстанс объекта, а не что угодно ещё. И тут уже вопрос стоит не о том, что можно юзать $_[0], а о том, что первый параметр по-хорошему нужно проверить чем-то вроде ref и/или blessed... И тут в силу вступает негласное соглашение: «используйте пакет правильно или вы сами выиноваты», т.е. никто конечно же не проверяет, что у него в $_[0] лежит именно благословенная ссылка, а не кусок чего-нибудь несусветного.

Ну уж, PHP 7-то с какой стати вдруг компилироваться стал?

PHP — компилятор, ЕМНИП, с 3-й версии.

Hint: не нужно путать трансляцию исходников и трансляцию виртуальной машины. PHP (как и Perl, Python, Ruby) — это компилятор в байткод + интерпретатор байткода.

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

- как уже написали, сигнатуры функций таки допилили (и емнп в новой версии они уже не experimental)

- на счет обращения к элементам структур(если я правильно понял в чём боль), ну да, наверное это читается не так легко как хотелось бы и требует определенной привычки. Хотя надо отметить, что у этого есть вполне понятная и описанная логика. (Кстати вроде в Perl6 это пофиксили и sigil-ы больше не изменяются для элемента).
Как альтернатива - можно использовать ссылки с постфиксным разыменованием %-)

  $sref->$*;  # same as  ${ $sref }
  $aref->@*;  # same as  @{ $aref }
  $aref->$#*; # same as $#{ $aref }
  $href->%*;  # same as  %{ $href }
  $cref->&*;  # same as  &{ $cref }
  $gref->**;  # same as  *{ $gref }

https://perldoc.perl.org/perlref.html#Postfix-Dereference-Syntax

Нетипизированный код слишком хрупкий.

Sad but true

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

Там IDE помогает. А в динамике ты один на один с кодом, где не сразу даже можно просечь, а что же ожидает вот эта функция. Перл особенно запущенный в этом плане. Рефакторинг динамического кода без тестов? Да нунах, лучше уволиться сразу.

Indirect Object Syntax

btw

new MyClass(..

Так кстати делать не рекомендуют.
https://perldoc.perl.org/perlobj.html#Invoking-Class-Methods
Видел как-то как товарищь на такие грабли наступил

Производительности сильно не прибавилось

А производительность не имеет прямого отношения к методу трансляции.

проверок времени компиляции тоже

Ну, попробуй исполнить код, например, с синтаксической ошибкой в конце. А вот интерпретатор честно исполнит файл до места с ошибкой и только там обломается. Как, например, bash.

Короче, вердикт - динамическое говно на свалку истории

А это, кстати, вообще третья классификация, ортогональная и к компиляции/интерпретации, и к производительности.

И, да, на счёт производительности — это ты очень сильно промахнулся. PHP работает порядка на два-три быстрее интерпретаторов.

Пусть уж будет питон, раз прижился

У него другие ниши.

Я в курсе :) Сам так не делаю, просто для наглядности показал.

В таком случае и Perl - компилятор, у него тоже есть промежуточный байт-код.

...сорри, не дочитал до конца.

Я всё-таки считаю компиляторами только то, что создаёт исполняемые файлы для целевой архитектуры.

По теме топика: помимо Julia, которую, в силу ограниченных возможностей работы с привычными мне вещами осваиваю помаленьку, собственно в качестве замены Perl'у «в лоб» буду использовать PHP 7. Я долго относился к этому языку с некоторым скепсисом - главным образом, из-за странных имён стандартных функций вкупе с откровенно маразматическим порядком следования аргументов в них. Плюс переход с PHP 5.2 на 5.3 был просто каким-то трешем, когда огромное количество приложений были «поломаны» в угоду каким-то невнятным эстетическим воззрениям разработчиков.

Но после выхода 7-й версии я вижу, что разработчиков сильно тряхануло, мозги встали на место и они неожиданно начали развивать язык в абсолютно верном направлении. На фоне откровенного застоя Perl'а это действительно приятно: не зря всё-таки в PHP избежали 6-й версии. А то бы тоже превратились в какое-нибудь Паскудо.

Работаю на перле до сих пор. Альтернативы ему не вижу.

Единственная проблема перла это потоки, если их много. Тогда плюсы.

Я всё-таки считаю компиляторами только то, что создаёт исполняемые файлы для целевой архитектуры.

Это узкая прослойка компиляторов под конкретную архитектуру :) При возникает много неоднозначностей. Скажем, как в таком случае ты Java характеризуешь? Баткод JVM не может прямо исполняться на x86.

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

Да сейчас понятие об интерпретируемых языках плавно перекатилось в понятие о скриптовых языках.

Интересно, а Форт до сих пор жив?

Когда-то школьником я сильно им увлекался. Даже баловался на ДВК-2 (там был ФигФорт) и немного на БК-0010 (там был Форт-83, но реализация появилась уж очень поздно для меня). Было дело даже ядро сварганил на PDP-11, благо это очень просто сделать

Да сейчас понятие об интерпретируемых языках плавно перекатилось в понятие о скриптовых языках.

И снова ортогональные понятия :) Есть скриптовые реализации вполне себе компилирующихся языков. Начиная от всяких tcc, кончая golang.

«Скриптовый язык» — это, скорее, не классификация языков, а способ их использования.

Интересно, а Форт до сих пор жив?

Я в своих проектах последний раз в 2007 использовал. Самописную реализацию под Java (JBForth). С тех пор пока задач нет. Сейчас снова есть очень интересная область, где его можно применить — в голосовом управлении умным домом. Форт — практически единственный язык, программировать который можно одними словами без озвучивания знаков препинания, что очень здорово для программирования с голоса. Но тут конь не валялся, при чём в первую очередь начиная с самого распознавания. Так что пока очень далёкие перспективы.

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

Вотъ.