Coverity известна так же тем, что её инструмент не редко выдаёт false positives. Но раз разработчики сказали "мы уже всё исправили", то "true positives" там не много и было :)
> Perl сейчас практически не используется для веб (исключая уже готовые > скрипты, которые были написан до широкой популярности PHP и т. д.)
PHP инструмент для ленивых, поскольку он сразу решает типичные задачи. Но при этом решения жестко прописаны - практически не регулируются. У неискушенного программиста нет понимания как это работает и какие риски несет то или иное решение. В итоге большое количество проектов на PHP имеют неисчислимое количество уязвимостей. Ладно open source. Но то что пишется "профессионалами" на продажу, тоже имеет дырки. Причина заключается в том, что в веб пришло большое количество начинающих программистов - дилетантов. А большинство определяет тенденции независимо право оно или нет. Лучший это путь или самый легкий. Perl заставляет программиста думать и искать решение. Точнее не искать и выбирать подходящее из имеющихся множества решений. Легкость PHP это иллюзия, которая быстро испаряется при: - создании серьезных больших проектов - создании высокопроизводительных приложений - необходимости создания безопасных приложений - попытке реализовать нестандартную задачу PHP можно назвать подобием BASIC, на нем легко начать, но сложно с ним работать профессионально.
Ну конечно, ситуации, когда для обработки 26Мб письма не хватает 900Мб такая система не отловит, т.к. ее корректно зарезервируют, проконтролируют, что за пределы выделенного ни чего не вылазит, и что все что нужно освободиться. А двойное резервирование в "x" operator просто даже описано вроде. То, что эту память до завершения программы даже не освободить -- так мелочи. То, что расчет 10х на использование памяти всего лишь рекомендация для боольшого класса задачь, а реально 100х, 1000х не исключено на определенных операциях, и реально не прогнозируемо...
Perl - это и идея хорошая и реализация.
Вот только нынешняя тенденция к удешевлению производства (софта в т.ч) привела к уходу Перла на второй (третий и т.д) план. Это естественно, так как програмист ПХП (к примеру) стоит заметно дешевле (его легче выучить), и их гораздо больше - им и достается львиная доля проектов. А Перл - сложный язык, требующий достаточного времени на изучение.
Перл остается языком либо для серьезных проектов (наряду с Java, ASP/.Net), либо для задач для которых PHP просто совсем не подходит. Такие вещи как IPC, threads, fork, command line tools и т.д реализуются крайне криво в PHP если вообще реализуются. Вот это и есть ниша Перл в настоящее время, причем тут его активно теснят Python/Ruby.
Слава Ларри Уоллу!
Отродясь не читал более интересной/дельной/понятной/занимательной книги по программированию, чем его Programming Perl (все издания, особенно 3).
Ничего против этого языка не имею, сам на нем пишу, но скажем для создания сложных проектов перл уже не так хорош как раньше.. Изменились задачи. Для примера - попробуйте на перле с помошью модулей с CPAN сделать преобразование файлов разных текстовых форматов... Например rtf to doc или rtf to html... Да ещё так что бы прям из любого в любой.
Сразу окажется, что под перл есть куча разношерстных модулей, но местами заброшеных.. которые друг с другом и кирилицей очень странно взаимодействуют. Как решение - можно это дело взвалить на опенофис.. Только есть модули взаимодействия с опенофисом для питона, для жабы (ну само собой) и для других языков. А под перл - нет. И так со некоторыми другими вещами...
Такое чувство что перл 5 остановился в своем развитии.. А 6 ещё ждать и ждать.
И из-за этого, и из-за других причин о которых ме писать лень. В последнее время часто сталкиваюсь с тем, что что-то нужно, а в перле либо нет готовых модулей, либо есть, но жутко устарели... Не писать же их все самому, я например не осилю биндинг к oo uno для перла.
Чего не скажешь о других языках. Странно но почему-то запомнилось, что во всех случаях когде не хватало компоентов на перле они были на питоне. Из чего делаю вывод... пятый перл тихонько остановился и не равивается, для него не пишут новых модулей.
Видимо в силу самодостаточности в своей нише, из которой я похоже вырос.
Биндинг к OO это бред. Только OLE-OLE-OLE нам не хватало. Если в OO конверсия файлов не реализована как отдельная библиотека, то это просто нужно сделать. С вордовскими форматами работает libwv, например, к ней можно делать биндинг, можно wvConvert через трубу звать. С кодировками проблем нет.
> Странно но почему-то запомнилось, что во всех случаях когде не хватало компоентов на перле они были на питоне. Из чего делаю вывод... пятый перл тихонько остановился и не равивается
Такое ощущение, что Вы говорите о какой то одной узкоспециализированной области. В свое время мне нужен был специально заточенный стеммер, ничего подходящего в CPAN, да и не только там не нашлось, пришлось писать самому, но это отнюдь не значит что перл в целом остановился в развитии, достаточно посмотреть на http://search.cpan.org/recent
ну гостевух конечно не так много как на php, но вот сперктр охвата задач модулями гораздо более впечатляющий, мало кто из имевших опыт программирования на python будет спорить что питон "with batteries included"
>Биндинг к OO это бред. Только OLE-OLE-OLE нам не хватало. Если в OO конверсия файлов не реализована как отдельная библиотека, то это просто нужно сделать. С вордовскими форматами работает libwv, например, к ней можно делать биндинг, можно wvConvert через трубу звать. С кодировками проблем нет.
Да, ну? :))) Нет проблем с кодировками говорите? Если не сталкивались с этими проблемами это не означает их нет. doc - хитрый документ.