Botox — разгоняем лосей и мышей

[ashmind]

А мне кажется, что это доказывает, что не существует универсальных инструментов.
Perl был отличным языком, но ООП в нём выглядит странно, даже с этим пакетом (суффиксы для обозначения доступа?).

Сейчас, посмотрев на Ruby, я сомневаюсь в том что я предпочту ему Perl 6, даже если он когда-нибудь выйдет.
И для нового проекта больше чем в в два-три файла выбирать Perl я бы не стал.

[meettya]

А что странного в суффиксах для обозначения доступа? ИМХО все в одном месте, не перепутаешь и не оставишь сиротой какой-нибудь ключ в списке вызова.

Сейчас, посмотрев на Ruby, я сомневаюсь в том что я предпочту ему Perl 6, даже если он когда-нибудь выйдет.
И для нового проекта больше чем в в два-три файла выбирать Perl я бы не стал.

Нууу… Я не ресторанный критик по фломастерам :)
Git написан за неделю на Perl. И используется в разработке ядра linux, устраивая ВСЕХ в скорости. Это не холиварная затравка, просто наблюдение.

[b00taNik]

Чтобы научиться фокусу, нужна неделя, а чтобы понять как создавать фокусы, нужны годы :)

[meettya]

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

[LeNsTR]

Не за неделю, а за две. И не на перле, а на си.

[meettya]

Ну давайте линейками померяемся.

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 :)

Ладно, а по существу-то у Вас есть что сказать?

[LeNsTR]

Хорошо, не буду разводить дискуссию не по существу.
Про Botox к сожалению сказать нечего, т.к. на перле не порграммирую и надеюсь никогда этим делом заниматься не придется (:

[ashmind]

Мне кажется, что он написан на C.

[youlose]

Посмотрите Moose, в нём самое логичное и понятное описание объектов которое я видел.

[meettya]

Эммм…
Даже и не знаю что ответить. Хорошо. :)

Кроме шуток —

pure Perl на 60 строк      vs.     XS add-on & dependence в каждом из слоев

Для меня лично выбор очевиден.

[youlose]

Просто человек пишет что OOP на Perl выглядит странно, видимо он не знает что есть другие способы.

Новый подход как в botox сам по себе явление интересное, сам попробую отпишусь о впечатлениях.

Единственное что смущает — а зачем так сильно в фигурные скобки оборачивать, можно поподробнее?

[meettya]

Обертка — подсмотрена на Котерова с dklab — она предотвращает проваливание our переменных через границы пактов. Очень рекомендую.

[Bambr]

А вы не объявляйте гору пакетов в одном файле без крайней на то необходимости :) Заодно будет проще Вашему последователю, когда ему приспичит поискать, куда же вы зафигачили очередной класс.

[meettya]

Вас и в случае пары пакетов может удивить что-то «провалившееся». Лучше обернуть :)

[Bambr]

Лично меня такие вещи уже не смогут удивить.
;-)

[meettya]

ну, меня еще смогут :)
поэтому и оборачиваю.

[meettya]

А, а трижды — дабы отличить границы класса от всего остального.

[ashmind]

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

[Bambr]

Я в свое время был убежден в том, что поскольку ООП в перле кривое, не надо его использовать. Слава Богу, меня переубедили. Конечно, киты ООП слегка хромают в Perl, но если программер не пытается нарушать ту же инкапсуляцию, это компенсируется. А прочие странности только добавляют гибкости Самобытному Перловому ООП, к ним просто надо привыкнуть и Вы начнете их использовать вполне осознано :)

[ashmind]

Конечно, можно привыкнуть, но в чём смысл использования Perl там, где нужен ООП?
Важные модули CPAN, которых принципиально нет под другие языки?

[Bambr]

Да не противопоставляйте Вы Perl и ООП :) Постановка вопроса в форме «в чём смысл использования Perl там, где нужен ООП?» некорректна в принципе.
1) Если нужно программить объекты — Perl подходит, как и многие другие языки.
2) Если нужно программить на Perl — объекты помогают делать код более простым и поддерживаемым.
Остальное решать Вам.

[ashmind]

С пунктом 2 я согласен.

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