В общем случае - скриптовые языки - это те, которые создавались в расчёте на быстрое написание скриптов - небольших программ, не рассчитанных на долговременную поддежку. Соответственно, в них мало или нет фич, рассчитанных на формализацию и поддержание структуры кода, но замедляющих написание - статической типизации, явного преобразования типов, модулей, интерфейсов и так далее.>Да, средства метапрограммирования через кодогенерацию в Perl традиционно неразвиты, а те что есть - лучше без _крайней_ необходимости не трогать. Но и необходимости в них особой нет.
Ну вот и я о том. К таким штукам надо вообще относиться с осторожностью.
>И чем они более подходящие?
Тем, что меньше шансов нарваться на мину в большом проекте, разумеется. Ну просто в силу внутренней структуры, когда, к примеру, в строковую переменную ты не сунешь float (или - ещё круче - наоборот). Тем, что есть структуры, которым компилятор не даст присвоить частично. И так далее, и тому подобное.
>Или Mouse. Или Moo. Или не брать вообще.
Moose и Moo оба давят производительность примерно на порядок по сравнению с чистым перлом, который по нынешним временам и так не быстр. Почему нельзя не брать ничего - я выше отписал. Слишком много шансов потом нарваться в проекте на десяток вариантов самопального ООП разной степени кривости.
>А в Си этого делать не надо?
>И Си, конечно, отличный пример такого языка. С развитой системой type inference.
В си своих граблей хватает, и больше чем хотелось бы - но нет, в нём нельзя присвоить указателю на массив указатель на инт, к примеру. По сравнению с перлом в плане типизации он великолепен. А что лучше те же плюсы - я ж сказал. Или Java/C#. Или Go/Rust/D.
>И это, вероятно, чем-то плохо. Тем, видимо, что в кучу они будут слеплены, видимо, криво. А вот если сишные библиотеки неделю по сети искать, и в кучу собирать, то выйдет, видимо, не криво. Магические свойства Си, видимо, тому причиной.
Ты эти CPAN'овские модули внутри не ковырял, видать. Как ни смешно - но рандомная сишная библиотека в среднем куда лучше качеством, чем рандомный перловый модуль. Особенно если говорить об обработке ошибок, мемори ликах и подобном - что почти не играет роли вскриптах, а в продакшне - очень даже. Я не помню случая, чтобы я что-то незнакомое с CPAN взял и не пришлось разбираться, что там внутре за неонка, в каких случаях она гаснет и почему.
>В других-то языках всё не так, очевидно. Там ведь есть общепринятые средства проверки покрытия кода тестами, всегда можно посмотреть на каких платформах и компиляторах тесты прошли. И только Perl не повезло.
А в других языках обычно имеется какой-то набор билиотек с репутацией, как boost или Qt в плюсах, плюс обычно есть возможность глянуть, что использутеся в мастодонтах вроде какого-нибудь libreoffice или apache. На перле готовых больших ропетов меньше - меньше мест, где можно глянуть. заодно такие проекты, как правило, имеют приличную документацию.
Вообще - чем не устраивате идея, что для промышленных задач надо брать соответствующие инструменты? Одну ямку для саженца можно и ножжом выкопать, для пары сотен - лучше всё же лопата и некоторое планирование, а если многими тысячами - нужна сельхозтехника, договоры на обслуживание, бизнес-планы и т.д.
