[newbie]Расскажите пожалуйста про perl и php
лучше ruby
лишп - лучший яжык шпишков
на лишпе напишан емакш, а емакш рулеж
я пишал cgi на лишпе
на лишпе напишан емакш, а емакш рулеж
я пишал cgi на лишпе
лучше чем?
Какого типа работа с текстом?
1) красивый язык
2) относительно новый язык
3) язык хорошо работает и с базами данных и с вебом
4) простой язык
перл тебе точно не подходит - это слишком "муторный" язык
перл тоже красивый язык, но там красота в вычурности а не в простоте
пхп очень простой язык, но и очень "тупой"
о красоте речи не идет
по работе со строками - все языки одинаковые
2) относительно новый язык
3) язык хорошо работает и с базами данных и с вебом
4) простой язык
перл тебе точно не подходит - это слишком "муторный" язык
перл тоже красивый язык, но там красота в вычурности а не в простоте
пхп очень простой язык, но и очень "тупой"
о красоте речи не идет
по работе со строками - все языки одинаковые
1) красивый языкА уникод там уже есть? Год назад там ещё вроде проблемы были с utf8.
2) относительно новый язык
3) язык хорошо работает и с базами данных и с вебом
4) простой язык
use perl
А уникод там уже есть? Год назад там ещё вроде проблемы были с utf8.первая ссылка с гугла говорит что вроде все ок
От первого ноября прошлого года:
Регекспы держит юникодные уже или надо "включить"?
P.s. Даешь холивор питонорубистов! Again!
Все это чудо работает при одном условии, если ваш Ruby-интерпретатор поддерживает юникод. Даже если ваш Ruby-интерпретатор поддерживает юникод, по умолчанию он запускается без его поддержки. Для того чтобы включить поддержку юникода надо передать параметр интерпретатору “-Ku”.
Регекспы держит юникодные уже или надо "включить"?
P.s. Даешь холивор питонорубистов! Again!
У тебя всего два выбора и это не пых с перлом
Python vs Ruby. И то и другое легко учится и достаточно просто без advanced features. И то и другое достаточно универсально, молодо и модно
Выбираешь просто: смотришь синтаксис или тыкаешь пальцем наугад
Python vs Ruby. И то и другое легко учится и достаточно просто без advanced features. И то и другое достаточно универсально, молодо и модно
Выбираешь просто: смотришь синтаксис или тыкаешь пальцем наугад
у нас есть вменяемые хостеры, которые предлагают питон и руби?
Хз, после VPS любой шаред хостинг у меня автоматом считается невменяемым, но это уже спор о другом. Поищи в гугле. Хостеры были, но с мощной поддержкой (вплоть до джанги или рора) питонов и рубинов обычно некрупные.
да я не из практического интереса спрашиваю. но вообще да, под более-менее серьезное что-то покупать vps или collocation оправдано, а если надо сделать что-то несложное и так, чтобы его было просто поставить произвольному человеку на произвольном хостинге, то, пожалуй, руби не самый удачный выбор at the moment.
я вообще perl люблю, я предвзят и необъективен
я вообще perl люблю, я предвзят и необъективен
я вообще perl люблюну из всего перечисленного я перл тоже больше всего люблю (после лиспа естессно)
но советовать его новичку не буду
да и вообще для веба не буду советовать
А что сложного в перле для новичков?
И заодно - что плохого в перле для веба по сравнению с питоном или руби?
(чур если python+django, то perl хотя бы +template toolkit, а лучше сразу catalyst)
(да, хочу похоливорить. давно хотел написать длинный пост о perl vs python.)
И заодно - что плохого в перле для веба по сравнению с питоном или руби?
(чур если python+django, то perl хотя бы +template toolkit, а лучше сразу catalyst
)(да, хочу похоливорить. давно хотел написать длинный пост о perl vs python.)
Я бы порекомендовал Perl (+ HTML::Mason в качестве темплейт движка для сайта). Тоже ничего сложного в нем для новичка не вижу. Мне лично PHP было тяжелее освоить
(+ HTML::Mason в качестве темплейт движка для сайта)крутые пацаны выбирают ctpp2.
ctpp2
В CTPP2, в отличие от первой версии, стадии синтаксического разбора текста шаблона и наложения параметров разнесены в две независимых библиотеки. Первая, парзер, выполняет синтаксический разбор текста шаблона и генерацию промежуточного байткода для виртуальной машины шаблонизатора. Предполагается, что реализация первой библиотеки зависит от конкретного языка шаблонов и, в общем случае, является произвольной.
Вторая библиотека реализует виртуальную машину с RISC-подобным набором инструкций.
Виртуальная машина имеет 25 команд, сгруппированных по производимым действиям. Длина инструкций фиксирована, каждая инструкция имеет один аргумент.
Виртуальная машина имеет 8 регистров общего назначения (AR, BR, CR, DR, ER, FR, GR, HR) и один регистр флагов, указывающий текущее состояние машины. Кроме регистров в виртуальной машине есть два стека: стек данных и стек адресов.
Чумааа!
Ну, это старый спор Учитывая нынешние цены, юр лицо может себе позволить впс, а веб-программер может позволить себе песочницу, где он сможет поднять несколько своих несерьезных проектов и не зависеть от саппортов хостера.
ЗЫ Хех, я даже не знал, что на форуме столько фанатов перла
Учитывая нынешние цены, юр лицо может себе позволить впс, а веб-программер может позволить себе песочницу, где он сможет поднять несколько своих несерьезных проектов и не зависеть от саппортов хостера.ЗЫ Хех, я даже не знал, что на форуме столько фанатов перла
ага, аффтар — аццкий сотона.
He now thought Python was a much better language for readability, maintainability, and modifiability.Cry havoc and let slip the dogs of war!
This attitude is pretty much in accord with what I saw in a long-running ``Perl vs. Python'' thread in comp.lang.python.
Perl tends to be cryptic and hard to read. Of course a good programmer will write more legible code than a bad one, but Perl's power is reflected in its complex syntax and many operator symbols, while Python has a simple, elegant base language, and the power resides in its library.
От себя - ООП пятого перла меня убивает.
Какого типа работа с текстом?Взять текст (небольшая статья, от 4 до 10 страниц засунуть в бд для первоначального удобства использования. Потом изъять из бд, автоматически сделать краткое описание о чём она (если уже есть abstract, то взять его изъять из текста все используемые ссылки, картинки.
Вторая часть — по запросу пользователя вывести всё это дело на страничку в удобочитаемом виде (если ключевых картинок в тексте нет — то не выводить и предусмотретЬ, чтобы всё равно было красиво, но это уже скорее проблема вёрстки а не программирования).
Не знаю, будет ли на хостинге достаточное количество процессорного времени для первой части (дёрганья текстов и создания описаний). Возможно создание базы автор\готовое описание\картинки можно сделать на другом языке, не "сайтостроительном", если это будет работать быстрее (и удобней в разработке
).да, верно. Пёрл сосёт. Особенно когда изучаешь после язычков вроде бедона.
Возможно создание базы автор\готовое описание\картинки можно сделать на другом языке, не "сайтостроительном", если это будет работать быстрее (и удобней в разработкеНу дык, классика жанра - прототипирование на высокоуровневом языке - последовательная замена модулей на низкоуровневые. Тот же питон+плюсы/си.
Таки фы фанад?
Нет, перл не сосет. Это язык со своей нишей и своими недостатками-достоинствами. Как впрочем и любой более-менее популярный язык.
Нет, перл не сосет. Это язык со своей нишей и своими недостатками-достоинствами. Как впрочем и любой более-менее популярный язык.
Таки я плеваться начинаю, когда не могу без гемора ввести хеш из строк в хеш списков строк (т.е. (string -> hash (list (string
смысла в прототипировании на питоне, имхо, нет никакого. Гораздо больший смысл имеет прототипирование на функциональных языках. Точнее, даже не имхо, а реальный опыт - на питоне императивный код за счёт всякого сахара вроде list comprehensions, кортежей, лямбд и прочего выходит сильно отличающимся от того, что будет на языках более низкого уровня.
Ты собрался переводить из языка в язык построчно? Так у тебя везде будут проблемы. Ну если ты за собой следить не будешь, естественно. А если будешь, то и питоновские сахарные конструкции не помеха.
Да и вообще на правах оффтопа, может, окажется проще воспользоваться авто генерацией в си код.
Да и вообще на правах оффтопа, может, окажется проще воспользоваться авто генерацией в си код.
нет, мне нужно было перевести в паскаль (не спрашивайте зачем )
)> От себя - ООП пятого перла меня убивает.
Чем именно (по сравнению с питоном)?
Из продолжения того же текста:
> He replied that Perl was fine up to a hundred lines or so, but beyond that he sort of ``hit a wall,'' as he put it, and it got hard to manage the complexity.
У меня вот такое же случилось с питоном, а с перлом почему-то нет (предметные области несколько отличались, но не сильно). Вечером набросаю общие претензии, на работу опаздываю (хотя перл тоже не без греха, конечно).
Чем именно (по сравнению с питоном)?
Из продолжения того же текста:
> He replied that Perl was fine up to a hundred lines or so, but beyond that he sort of ``hit a wall,'' as he put it, and it got hard to manage the complexity.
У меня вот такое же случилось с питоном, а с перлом почему-то нет (предметные области несколько отличались, но не сильно). Вечером набросаю общие претензии, на работу опаздываю (хотя перл тоже не без греха, конечно).
предлагаю сойтись на мысли, что всё - говно.
Таки я плеваться начинаю, когда не могу без гемора ввести хеш из строк в хеш списков строк (т.е. (string -> hash (list (stringТы про такое?
%hash = (
key1 => 'value1',
key2 => 'value2',
);
%newhash = map {$_ => [$hash{$_}] } keys %hash;
Субъективно: по-моему, не слишком сложно. Покажи аналогичный код на питоне?
предлагаю сойтись на мысли, что всё - говно.True. Но приятнее думать, что "some languages sucks less".
ООП:
Мне очень понравилось, когда на доске наши перлисты нарисовали два что ли варианта описания "
"класса".
В языке Perl нет специального синтаксиса для описания классов, объектов или методов. Для их реализации используются уже знакомые нам синтаксические конструкции.
Мне очень понравилось, когда на доске наши перлисты нарисовали два что ли варианта описания "
"класса".
Наследование в Perl отличается от наследования в других объектно-ориентированных языках программирования тем, что наследуются только методы. Наследование данных реализуется программистом самостоятельно.Ну, собственно, мне этого достаточно.
ждем Perl 6 с вожделением!
что нисколько не мешает решать актуальные задачи с Perl 5 =)
Ну дык, классика жанра - прототипирование на высокоуровневом языке - последовательная замена модулей на низкоуровневые. Тот же питон+плюсы/си.Ниасилил
Что ты имел в виду? =)
Пример:
пишешь базовый функционал на высокоуровневом языке. Запускаешь бету в открытый доступ (спорный пункт). Оттачиваешь архитектуру-связи-модульность. Получаешь то, что нужно, на требуемом прямо сейчас уровне. После этого выводишь все что надо на требуемую производительность, то есть берешь некий модуль и переписываешь его на низкоуровневом языке-заменяешь на новый модуль и так в цикле, пока не останется узких мест.
В итоге, скорость разработки и подгонки архитектуры-логики происходит очень быстро за счет высокоуровневости языка. После чего ты уже проверенную логику начинаешь переводить на другой более производительный язык. При этом все продолжает работать. Все быстрее и быстрее.
пишешь базовый функционал на высокоуровневом языке. Запускаешь бету в открытый доступ (спорный пункт). Оттачиваешь архитектуру-связи-модульность. Получаешь то, что нужно, на требуемом прямо сейчас уровне. После этого выводишь все что надо на требуемую производительность, то есть берешь некий модуль и переписываешь его на низкоуровневом языке-заменяешь на новый модуль и так в цикле, пока не останется узких мест.
В итоге, скорость разработки и подгонки архитектуры-логики происходит очень быстро за счет высокоуровневости языка. После чего ты уже проверенную логику начинаешь переводить на другой более производительный язык. При этом все продолжает работать. Все быстрее и быстрее.
это круто, но у подхода есть один минус. называется "чудеса похапэшной мысли".
хотя с питоном может и меньше влияние этого фактора.
хотя с питоном может и меньше влияние этого фактора.
В языке Perl нет специального синтаксиса для описания классов, объектов или методов. Для их реализации используются уже знакомые нам синтаксические конструкции.Само по себе это не выглядит недостатком, правда?
Наследование в Perl отличается от наследования в других объектно-ориентированных языках программирования тем, что наследуются только методы. Наследование данных реализуется программистом самостоятельно.То ли я фундаментально не понимаю ООП, то ли тут написана чушь.
Да, в перле классы объявляются не одним блоком, а отдельными функциями внутри одного package'а. Но лишних действий для объявления данных это не означает - все данные, определенные в базовом классе, присутствуют в унаследованном.
> Ну, собственно, мне этого достаточно.
Ты знаешь perl только по таким обзорам, или ты его смотрел сам?
Ответные нападки на питон
1) отсутствие аналога перлового my: если я опечатаюсь в присваивании переменной, то могу этого не заметить.
2) отсутствие perl -c: нет возможности осуществить первичную проверку синтаксиса, не запуская код.
3) отсутствие неявных преобразований int <=> str и unicode_str <=> str. Привыкнуть можно, конечно, но много раз уже наступал на это.
хы)
вопрос ещё возник — в MySQL при компиляции есть флаг perl. Что имели в виду?
вопрос ещё возник — в MySQL при компиляции есть флаг perl. Что имели в виду?
открываешь ебилд и читаешь
бенчмарки ставит
бенчмарки ставит
Ты знаешь perl только по таким обзорам, или ты его смотрел сам?Я общаюсь с перловиками по работе, а так да, мне проще обзор найти, чем лишний раз их теребить. С ООП постоянное веселье у нас, когда перловики начинают писать на доске
При этом даже яростные фанаты перла у нас признают, что да, ООП тут несколько "прилеплено".
Далее, ну на это отвечу, а дальше влом. Потому что дальше будет драка за пустяки, а мне неинтересно. Глобальное недовольство у меня вызывает синтаксис, помешанный на операторах и "странное" ООП. На все остальное пох. А ну разве что опять же по работе постоянно натыкаемся на то, что очень многие цпан модули не проработаны до конца. Ну например базовую спеку сделали, а на остальное забили. Хз, может это у нас область такая.
По нападкам:
1) Учитывая, что в Perl все переменные глобальны, если не указано иное, кичиться my я бы не стал
2) Нах какой-то ключ? Проверка синтаксиса пройдет на первом импорте модуля. Потому что в питоне есть байткод
Либо я тебя не понял. А учитывая стандартные утилиты проверки питоновского кода, которые еще только ленивый не повставлял в идеешки, проблемы в принципе нет.3) Это следствие строгой типизации. Это плюс вообще-то
> При этом даже яростные фанаты перла у нас признают, что да, ООП тут несколько "прилеплено".
Ну в общем-то да, но я не настолько фанат блюдения чистоты ООП, чтобы это мне хоть сколько-нибудь мешало.
> синтаксис, помешанный на операторах
Ну согласись, это вопрос вкуса? К этому довольно быстро привыкаешь и становится наоборот удобно, потому что можешь выразить мысль минимальным числом символов.
> очень многие цпан модули не проработаны до конца
Бывает, да. Надо тщательнее выбирать. С другой стороны, их *много*, обычно подходящий все равно найдется. Ну не меньше, чем в питоне.
1) Учитывая, что в Perl все переменные глобальны, если не указано иное, кичиться my я бы не стал
use strict зря не включен по умолчанию. Ну и что? А в питоне в каждом файле приходится
# -*- coding: utf-8 -*-
дописывать, например.
2) Дело в том, что многие идиотские ошибки можно проверить, не запуская программу. Это как раз то, для чего мне нужен my, собственно. А в питоне можно получить из кода байткод, не исполняя полученный байткод? Я вот не умею.
IDE бы тут помогла, но вот для перла IDE бы как раз делала perl -c (все мечтаю это прикрутить к vim'у и никак не соберусь.)
3) Хм. Иногда может быть и плюс, может, если бы я чаще писал на питоне, никогда бы не забывал это сделать. Но почему-то регулярно забываю.
Ну в общем-то да, но я не настолько фанат блюдения чистоты ООП, чтобы это мне хоть сколько-нибудь мешало.
> синтаксис, помешанный на операторах
Ну согласись, это вопрос вкуса? К этому довольно быстро привыкаешь и становится наоборот удобно, потому что можешь выразить мысль минимальным числом символов.
> очень многие цпан модули не проработаны до конца
Бывает, да. Надо тщательнее выбирать. С другой стороны, их *много*, обычно подходящий все равно найдется. Ну не меньше, чем в питоне.
1) Учитывая, что в Perl все переменные глобальны, если не указано иное, кичиться my я бы не стал
use strict зря не включен по умолчанию. Ну и что? А в питоне в каждом файле приходится
# -*- coding: utf-8 -*-
дописывать, например.
2) Дело в том, что многие идиотские ошибки можно проверить, не запуская программу. Это как раз то, для чего мне нужен my, собственно. А в питоне можно получить из кода байткод, не исполняя полученный байткод? Я вот не умею.
IDE бы тут помогла, но вот для перла IDE бы как раз делала perl -c
(все мечтаю это прикрутить к vim'у и никак не соберусь.)3) Хм. Иногда может быть и плюс, может, если бы я чаще писал на питоне, никогда бы не забывал это сделать. Но почему-то регулярно забываю.
1) Учитывая, что в Perl все переменные глобальны, если не указано иное, кичиться my я бы не сталне думаю, что ты говоришь про код с use strict, а его отсутствие является скорее исключением для любого скрипта длинне пяти строк
1)
Кстати, а у вас не так?
2) Типа байт код генерируется до исполнения всегда и так. А исполняется именно байткод, поэтому первый импорт модуля достаточно громоздок - генерируются pyc/pyo файлы.
3) Ну тут спорный момент, конечно. Спор, что лучше, нестрогая типизация или строгая.
# -*- coding: utf-8 -*-Ты как раз можешь не писать, но тогда весь исходник будет в латин1 по умолчанию. Это единственный минус в подходе к кодировке исходников, обусловленный поддержкой старого кода. В питрика уже везде 8 утф по умолчанию.
Кстати, а у вас не так?
use utf8;
2) Типа байт код генерируется до исполнения всегда и так. А исполняется именно байткод, поэтому первый импорт модуля достаточно громоздок - генерируются pyc/pyo файлы.
3) Ну тут спорный момент, конечно. Спор, что лучше, нестрогая типизация или строгая.
1) Да, так. Я не собирался спорить про юникод, вообще-то, потому что считаю, что его поддержка везде отвратительна.
(то есть во всех языках, появившихся до юникода - php, python, perl... Наверное, в py3k и perl6 это все исправят как-нибудь).
Аргумент про строчку был только к тому, чтобы показать, что use strict; везде - это просто стандартный заголовок.
А про юникод - да, use utf8 - это аналог, но я его в перле никогда не использую. Потому что стоит сконкатенировать строку байт и строку символов, и кранты. В перле кодировка бьется, в питоне исключение, но в любом случае кранты.
Если надо посчитать длину строки, то в юникод, length, и обратно в байты.
2) Ты на что-то не на что ответил, как байткод генерируется, я примерно представляю. А как мне его сгенерировать, не запуская код?
3) Я бы тут расширил тему и разделил сопоставление по трем направлениям - а) строгая/нестрогая типизация, б) раннее/позднее связывание и в) необходимость объявления переменных (тот самый my, к отсутствию которого я придрался).
Мне кажется естественным утверждение, что строгая типизация лучше нестрогой, раннее связывание лучше позднего, и явное объявление переменных лучше неявного, если это не мешает скорости написания кода и удобству его рефакторинга. Потому что и работает быстрее, и fast fail тоже никогда не лишний.
И тут мне перл куда больше нравится:
А про строгую типизацию вот что хочу сказать. В питоне существования методов с подходящими наборами параметров достаточно для того, чтобы использовать объект, реализующий известный интерфейс, и это совершенно правильно для скриптового языка. И операторы, вроде, переопределять можно. Так почему же нельзя сложить число и строку? Даже в Java, которая казалось бы куда более строго типизирована, это разрешено.
(то есть во всех языках, появившихся до юникода - php, python, perl... Наверное, в py3k и perl6 это все исправят как-нибудь).
Аргумент про строчку был только к тому, чтобы показать, что use strict; везде - это просто стандартный заголовок.
А про юникод - да, use utf8 - это аналог, но я его в перле никогда не использую. Потому что стоит сконкатенировать строку байт и строку символов, и кранты. В перле кодировка бьется, в питоне исключение, но в любом случае кранты.
Если надо посчитать длину строки, то в юникод, length, и обратно в байты.
2) Ты на что-то не на что ответил, как байткод генерируется, я примерно представляю. А как мне его сгенерировать, не запуская код?
3) Я бы тут расширил тему и разделил сопоставление по трем направлениям - а) строгая/нестрогая типизация, б) раннее/позднее связывание и в) необходимость объявления переменных (тот самый my, к отсутствию которого я придрался).
Мне кажется естественным утверждение, что строгая типизация лучше нестрогой, раннее связывание лучше позднего, и явное объявление переменных лучше неявного, если это не мешает скорости написания кода и удобству его рефакторинга. Потому что и работает быстрее, и fast fail тоже никогда не лишний.
И тут мне перл куда больше нравится:
mmcleric-desktop:~$ cat | python
myvar = 5
print "hi"
print mywar
hi
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
NameError: name 'mywar' is not defined
mmcleric-desktop:~$ cat | perl
use strict; use warnings;
my $myvar = 5;
print "hi\n";
print $mywar, "\n";
Global symbol "$mywar" requires explicit package name at - line 4.
Execution of - aborted due to compilation errors.
А про строгую типизацию вот что хочу сказать. В питоне существования методов с подходящими наборами параметров достаточно для того, чтобы использовать объект, реализующий известный интерфейс, и это совершенно правильно для скриптового языка. И операторы, вроде, переопределять можно. Так почему же нельзя сложить число и строку? Даже в Java, которая казалось бы куда более строго типизирована, это разрешено.
ы на что-то не на что ответил, как байткод генерируется, я примерно представляю. А как мне его сгенерировать, не запуская код?$python module.py
Я действительно не понимаю в чем проблема-то, а так, еще раз повторяю есть "стандартная" утилита pylint. Она не только синтаксис проверит, но и чуть ли не рантайм предскажет, выдавая ворнинги.Я бы тут расширил тему и разделил сопоставление по трем направлениям - а) строгая/нестрогая типизация, б) раннее/позднее связывание и в) необходимость объявления переменных (тот самый my, к отсутствию которого я придрался).
Мне кажется естественным утверждение, что строгая типизация лучше нестрогой, раннее связывание лучше позднего, и явное объявление переменных лучше неявного, если это не мешает скорости написания кода и удобству его рефакторинга. Потому что и работает быстрее, и fast fail тоже никогда не лишний.
Гм, может я дурной, но динамически типизированный язык всегда имеет позднее связывание, нет? И пункт в) перлу тоже не подходит, ибо _необходимости_ объявлять нет?
Честно, из примера я только лишний раз убедился, что питон прозрачнее и поддается отладке лучше
А про строгую типизацию вот что хочу сказать. В питоне существования методов с подходящими наборами параметров достаточно для того, чтобы использовать объект, реализующий известный интерфейс, и это совершенно правильно для скриптового языка. И операторы, вроде, переопределять можно. Так почему же нельзя сложить число и строку? Даже в Java, которая казалось бы куда более строго типизирована, это разрешено.Имхо, тут как раз сработал принцип "не усложняй", а питон делался максимально простым по своей идеологии. Чтобы нормально сделать такое неявное приведение, нужно знать порядок его совершения или приоритеты приведения, ведь в общем случае совершенно непонятно к кому что приводить + шанс на плохо отлавливаемую ошибку и тыды.. Вообще, для тех, кто не противник питоновской форматной строки этой проблемы в принципе не существует.
> Я действительно не понимаю в чем проблема-то, а так, еще раз повторяю есть "стандартная" утилита pylint.
О, спасибо! (хотя она далека от стандартной - потянула за собой много чего, включая tk, и на ворнинги внутри самой себя жалуется, но вроде работает).
> Гм, может я дурной, но динамически типизированный язык всегда имеет позднее связывание, нет?
Вот в том и дело, что перл при включенном use strict все использования локальных переменных связывает прямо при компиляции. А я например часто пишу одноразовые скрипты, которые работают подолгу. И бывает обидно на третий час ожидания узнать, что опечатался во второй половине кода.
Под ранним связыванием я имею в виду то, что при компиляции в байткод упоминания локальных переменных заменяются на их адреса. Проверка типа или наличия методов у объектов, конечно, осуществляется в рантайме (хотя в мифическом perl6 хотят добавить опциональную проверку на ранних этапах).
> И пункт в) перлу тоже не подходит, ибо _необходимости_ объявлять нет?
Ну ее же всё равно все включают первым делом
PS. Похоже, то, что мне кажется плюсами, тебе кажется минусами, и наоборот, так что предлагаю на этом остановиться. Трепаться про то, что в перле регэкспы круче, зато треды сосут, например, как-то неинтересно
О, спасибо! (хотя она далека от стандартной - потянула за собой много чего, включая tk, и на ворнинги внутри самой себя жалуется, но вроде работает).
> Гм, может я дурной, но динамически типизированный язык всегда имеет позднее связывание, нет?
Вот в том и дело, что перл при включенном use strict все использования локальных переменных связывает прямо при компиляции. А я например часто пишу одноразовые скрипты, которые работают подолгу. И бывает обидно на третий час ожидания узнать, что опечатался во второй половине кода.
Под ранним связыванием я имею в виду то, что при компиляции в байткод упоминания локальных переменных заменяются на их адреса. Проверка типа или наличия методов у объектов, конечно, осуществляется в рантайме (хотя в мифическом perl6 хотят добавить опциональную проверку на ранних этапах).
> И пункт в) перлу тоже не подходит, ибо _необходимости_ объявлять нет?
Ну ее же всё равно все включают первым делом
PS. Похоже, то, что мне кажется плюсами, тебе кажется минусами, и наоборот, так что предлагаю на этом остановиться. Трепаться про то, что в перле регэкспы круче, зато треды сосут, например, как-то неинтересно
Похоже на то
У меня еще только одна претензия осталась. Мне настолько непривычно использовать массив аргументов функции и не видеть нормальной сигнатуры, что мне это очень неудобно. А так все, вроде.
На самом деле, имхо, если бы в перле было чуть меньше свободы и строже синтаксис и чуть раньше появился бы общепринятый "свод правил", вышел бы неплохой даже для меня язык
У меня еще только одна претензия осталась. Мне настолько непривычно использовать массив аргументов функции и не видеть нормальной сигнатуры, что мне это очень неудобно. А так все, вроде.
На самом деле, имхо, если бы в перле было чуть меньше свободы и строже синтаксис и чуть раньше появился бы общепринятый "свод правил", вышел бы неплохой даже для меня язык
О, спасибо! (хотя она далека от стандартной - потянула за собой много чего, включая tk, и на ворнинги внутри самой себя жалуется, но вроде работает).Она "стандартная"
То есть де-факто она внедрена почти повсеместно, но в сам дистрибутив, конечно, не входит.Забавно, что пых никто не толкает тут. Странно
У меня еще только одна претензия осталась. Мне настолько непривычно использовать массив аргументов функции и не видеть нормальной сигнатуры, что мне это очень неудобно. А так все, вроде.Для этого есть стандартный способ написания функций в перле:
sub xxx($$\@@) {
my ($var1, $var2, $arrayref, @rest) = @_;
...
}
Так что жить можно, просто сигнатура во второй строке.
Про pylint - я бы больше доверял подобной утилите, если бы она пользовалась стандартным парсером языка, а не была бы прилеплена сбоку и написана с использованием какого-то другого скриптового языка (хотя все равно пользоваться наверное буду, питон разбирать все же проще, чем перл, авось не ошибется
).Конвей рекомендует НЕ использовать прототипы:
Subroutine prototypes allow you to make use of more sophisticated argument-passing mechanisms than Perl's "usual list-of-aliases" behaviour. For example:
The problem is that anyone who uses swap_arrays( and anyone who subsequently has to maintain that code, has to know about that subroutine's special magic. Otherwise, they will quite naturally assume that the two arrays will be flattened into a single list and slurped up by the subroutine's @_, because that's what happens in just about every other subroutine they ever use.
Using prototypes makes it impossible to deduce the argument-passing behaviour of a subroutine call simply by looking at the call. They also make it impossible to deduce the context in which particular arguments are evaluated.
Subroutine prototypes allow you to make use of more sophisticated argument-passing mechanisms than Perl's "usual list-of-aliases" behaviour. For example:
sub swap_arrays (\@\@) {
my ($array1_ref, $array2_ref) = @_;
my @temp_array = @{$array1_ref};
@{$array1_ref} = @{$array2_ref};
@{$array2_ref} = @temp_array;
return;
}
# and later...
swap_arrays(@sheep, @goats); # Implicitly pass references
The problem is that anyone who uses swap_arrays( and anyone who subsequently has to maintain that code, has to know about that subroutine's special magic. Otherwise, they will quite naturally assume that the two arrays will be flattened into a single list and slurped up by the subroutine's @_, because that's what happens in just about every other subroutine they ever use.
Using prototypes makes it impossible to deduce the argument-passing behaviour of a subroutine call simply by looking at the call. They also make it impossible to deduce the context in which particular arguments are evaluated.
Ох, если бы он был стандартным.
Да и выглядит ужасно Ну ладно, я типа не привык.
Пилинт написан на питоне, насколько я вижу и пользуется многими встроенными модулями для разбора питона. Конкретнее не скажу, далеко не глядел. Зачем у него зависимость - хз. Мб для гуевой модификации скрипта.
Да и выглядит ужасно
Ну ладно, я типа не привык.Пилинт написан на питоне, насколько я вижу и пользуется многими встроенными модулями для разбора питона. Конкретнее не скажу, далеко не глядел. Зачем у него зависимость - хз. Мб для гуевой модификации скрипта.
Это проблема не с прототипами, а именно с \@. Я ее тоже стараюсь не использовать, просто пример общий хотел написать. Можно заменить \@ на $ и заставить пользователей вызывать функцию через swap_arrays(\@sheep, \@goats в этом случае не вижу, чем прототипы - зло.
в этой главе есть еще пример того, как это скрытое поведение может осложнить жизнь:
So a subroutine that used to be defined:
use List::Util qw( min max );
sub clip_to_range {
my ($min, $max, @data) = @_;
return map { max( $min, min($max, $_) ) } @data;
}
is updated to:
sub clip_to_range($$@) { # takes two scalars and an array
my ($min, $max, @data) = @_;
return map { max($min, min($max, $_ } @data;
}
The problem is that clip_to_range( ) was being used with an elegant table-lookup scheme:
my %range = (
normalized => [-0.5,0.5],
greyscale => [0,255],
percentage => [0,100],
weighted => [0,1],
);
# and later...
my $range_ref = $range{$curr_range};
@samples = clip_to_range( @{$range_ref}, @samples);
The $range{$curr_range} hash look-up returns a reference to a two-element array corresponding to the range that's currently selected. That array reference is then dereferenced by putting a @{...} around it. Previously, when clip_to_range( ) was an ordinary subroutine, that dereferenced array found itself in the list context, so it flattened into a list, producing the required minimum and maximum values for the subroutine's first two arguments.
But now that clip_to_range( ) has a prototype, things go very wrong. The prototype starts with a $, which looks like it's telling Perl that the first argument must be a scalar. But that's not what prototypes do at all.
What that $ prototype does is tell Perl that the first argument must be evaluated in a scalar context. And what is the first argument? It's the array produced by @{$range{$curr_range}}. And what do you get when an array is evaluated in a scalar context? The size of the array, which is 2, no matter which entry in %range was actually selected.
в общем, как я понимаю, преимущества от использования весьма сомнительны, а непредсказуемость поведения может порождать проблемы
So a subroutine that used to be defined:
use List::Util qw( min max );
sub clip_to_range {
my ($min, $max, @data) = @_;
return map { max( $min, min($max, $_) ) } @data;
}
is updated to:
sub clip_to_range($$@) { # takes two scalars and an array
my ($min, $max, @data) = @_;
return map { max($min, min($max, $_ } @data;
}
The problem is that clip_to_range( ) was being used with an elegant table-lookup scheme:
my %range = (
normalized => [-0.5,0.5],
greyscale => [0,255],
percentage => [0,100],
weighted => [0,1],
);
# and later...
my $range_ref = $range{$curr_range};
@samples = clip_to_range( @{$range_ref}, @samples);
The $range{$curr_range} hash look-up returns a reference to a two-element array corresponding to the range that's currently selected. That array reference is then dereferenced by putting a @{...} around it. Previously, when clip_to_range( ) was an ordinary subroutine, that dereferenced array found itself in the list context, so it flattened into a list, producing the required minimum and maximum values for the subroutine's first two arguments.
But now that clip_to_range( ) has a prototype, things go very wrong. The prototype starts with a $, which looks like it's telling Perl that the first argument must be a scalar. But that's not what prototypes do at all.
What that $ prototype does is tell Perl that the first argument must be evaluated in a scalar context. And what is the first argument? It's the array produced by @{$range{$curr_range}}. And what do you get when an array is evaluated in a scalar context? The size of the array, which is 2, no matter which entry in %range was actually selected.
в общем, как я понимаю, преимущества от использования весьма сомнительны, а непредсказуемость поведения может порождать проблемы
Опять, это проблема преобразований в зависимости от контекста, а не прототипов.
Конечно, каждому свое, но мне лично прототипы только помогают.
И поскольку я их использую, то мне и в голову не придет передавать в функцию, ожидающую два скаляра, список из двух элементов, рассчитывая, что он развернется в два скаляра. Кстати, я вообще редко передаю в функции списки, чаще ссылку на массив.
Ага, в перле много способов прострелить себе ногу
Вот например:
Известно, что функции, ожидающие список, забирают свои аргументы "жадно". И если этого не понимать, можно остаться инвалидом совсем без ног. Так вот поэтому иногда советуют писать скобки всегда. Или например интерполяцию запрещают.
Пример:
А можно было бы:
Это я к тому, что не стоит отказываться от фич языка только потому, что они иногда неожиданно работают. Если особенности какой-то фичи знаешь, то бояться уже нечего.
Конечно, каждому свое, но мне лично прототипы только помогают.
И поскольку я их использую, то мне и в голову не придет передавать в функцию, ожидающую два скаляра, список из двух элементов, рассчитывая, что он развернется в два скаляра. Кстати, я вообще редко передаю в функции списки, чаще ссылку на массив.
Ага, в перле много способов прострелить себе ногу
Вот например:
Известно, что функции, ожидающие список, забирают свои аргументы "жадно". И если этого не понимать, можно остаться инвалидом совсем без ног. Так вот поэтому иногда советуют писать скобки всегда. Или например интерполяцию запрещают.
Пример:
LOG("Values: ", join(',', map( {"[".$_."]"}, $self->get_values;А можно было бы:
LOG "Values: ", join ',', map {"[$_]"} $self->get_values;Это я к тому, что не стоит отказываться от фич языка только потому, что они иногда неожиданно работают. Если особенности какой-то фичи знаешь, то бояться уже нечего.
Превед вызывали?
Оставить комментарий
Dmitry08
Вот надо выполнить проект, в процессе которого будет много работы с текстом, базой данных и некоторая веб-оболочка (типа электронной библиотеки). Соответственно думаю, на чём это дело написать.Пока знаю только, что "пых-пых — это язык, помогающий ламерам делать красивые сайты (с)", а "perl — язык для обработки текста, но его дао надо понять (с)".
С текстом придётся работать много, и на странички его выводить надо (а ещё быстро к MySQL обращаться). Посему просьба рассказать некоторые плюсы и минусы обоих языков в данном контексте.
П.С. к перлу больше склоняюсь, т.к. он вроде уже установлен в системе (генту).