Comments 23
А мне кажется, что это доказывает, что не существует универсальных инструментов.
Perl был отличным языком, но ООП в нём выглядит странно, даже с этим пакетом (суффиксы для обозначения доступа?).
Сейчас, посмотрев на Ruby, я сомневаюсь в том что я предпочту ему Perl 6, даже если он когда-нибудь выйдет.
И для нового проекта больше чем в в два-три файла выбирать Perl я бы не стал.
Perl был отличным языком, но ООП в нём выглядит странно, даже с этим пакетом (суффиксы для обозначения доступа?).
Сейчас, посмотрев на Ruby, я сомневаюсь в том что я предпочту ему Perl 6, даже если он когда-нибудь выйдет.
И для нового проекта больше чем в в два-три файла выбирать Perl я бы не стал.
А что странного в суффиксах для обозначения доступа? ИМХО все в одном месте, не перепутаешь и не оставишь сиротой какой-нибудь ключ в списке вызова.
Нууу… Я не ресторанный критик по фломастерам :)
Git написан за неделю на Perl. И используется в разработке ядра linux, устраивая ВСЕХ в скорости. Это не холиварная затравка, просто наблюдение.
Сейчас, посмотрев на Ruby, я сомневаюсь в том что я предпочту ему Perl 6, даже если он когда-нибудь выйдет.
И для нового проекта больше чем в в два-три файла выбирать Perl я бы не стал.
Нууу… Я не ресторанный критик по фломастерам :)
Git написан за неделю на Perl. И используется в разработке ядра linux, устраивая ВСЕХ в скорости. Это не холиварная затравка, просто наблюдение.
Не за неделю, а за две. И не на перле, а на си.
Ну давайте линейками померяемся.
ИМХО с 3 по 7 был сделан работоспособный продукт.
А про perl где-то было в описании git, типа «это всего лишь набор perl-скриптов». Да в общем-то использование си-библиотек никто не запрещал из-под perl :)
Ладно, а по существу-то у Вас есть что сказать?
The development of Git began on April 3, 2005.[10] The project was announced on April 6,[11] and became self-hosting as of April 7.[10] The first merge of multiple branches was done on April 18.[12]
ИМХО с 3 по 7 был сделан работоспособный продукт.
А про perl где-то было в описании git, типа «это всего лишь набор perl-скриптов». Да в общем-то использование си-библиотек никто не запрещал из-под perl :)
Ладно, а по существу-то у Вас есть что сказать?
Мне кажется, что он написан на C.
Посмотрите Moose, в нём самое логичное и понятное описание объектов которое я видел.
Эммм…
Даже и не знаю что ответить. Хорошо. :)
Кроме шуток —
pure Perl на 60 строк vs. XS add-on & dependence в каждом из слоев
Для меня лично выбор очевиден.
Даже и не знаю что ответить. Хорошо. :)
Кроме шуток —
pure Perl на 60 строк vs. XS add-on & dependence в каждом из слоев
Для меня лично выбор очевиден.
Просто человек пишет что OOP на Perl выглядит странно, видимо он не знает что есть другие способы.
Новый подход как в botox сам по себе явление интересное, сам попробую отпишусь о впечатлениях.
Единственное что смущает — а зачем так сильно в фигурные скобки оборачивать, можно поподробнее?
Новый подход как в botox сам по себе явление интересное, сам попробую отпишусь о впечатлениях.
Единственное что смущает — а зачем так сильно в фигурные скобки оборачивать, можно поподробнее?
Обертка — подсмотрена на Котерова с dklab — она предотвращает проваливание our переменных через границы пактов. Очень рекомендую.
А, а трижды — дабы отличить границы класса от всего остального.
Самое логичное для Perl. И это требует модуля из 40+ файлов.
И всё равно, если сравнивать с любым языком со встроенной поддержкой классов, это выглядит на порядки сложнее.
И всё равно, если сравнивать с любым языком со встроенной поддержкой классов, это выглядит на порядки сложнее.
Я в свое время был убежден в том, что поскольку ООП в перле кривое, не надо его использовать. Слава Богу, меня переубедили. Конечно, киты ООП слегка хромают в Perl, но если программер не пытается нарушать ту же инкапсуляцию, это компенсируется. А прочие странности только добавляют гибкости Самобытному Перловому ООП, к ним просто надо привыкнуть и Вы начнете их использовать вполне осознано :)
Конечно, можно привыкнуть, но в чём смысл использования Perl там, где нужен ООП?
Важные модули CPAN, которых принципиально нет под другие языки?
Важные модули CPAN, которых принципиально нет под другие языки?
Да не противопоставляйте Вы Perl и ООП :) Постановка вопроса в форме «в чём смысл использования Perl там, где нужен ООП?» некорректна в принципе.
1) Если нужно программить объекты — Perl подходит, как и многие другие языки.
2) Если нужно программить на Perl — объекты помогают делать код более простым и поддерживаемым.
Остальное решать Вам.
1) Если нужно программить объекты — Perl подходит, как и многие другие языки.
2) Если нужно программить на Perl — объекты помогают делать код более простым и поддерживаемым.
Остальное решать Вам.
Sign up to leave a comment.
Botox — разгоняем лосей и мышей