Основы Perl - 4 урока

>Обычно люди, которые переходят на питон, радуются как дети - всё начинает адекватно работать и перестаёт глючить.

Нет, всё перестаёт глючить при переходе на Haskell. Или на любой другой язык со статической типизацией.

> Как сейчас помню, в документации было написано, что, если аргумент один, то скобки можно опустить.

Память вас подвела. Учите матчасть, прежде чем на форумах бухтеть.

Да хотя бы sort.

sort не возвращает копию аргумента. Учите матчасть.

Или lower.

lower возвращает изменённую строку. А оригинал не меняет. Потому что строки иммутабельны. Это чистая функция. У вас какие-то проблемы с чистыми функциями?

Я же говорил, что с высоты моего происхождения разницы между Perl и Python не видно.

Потому что вы питон, как видим, не знаете.

Тем, что в производном классе используется значение class variable, взятое из класса-родителя. Но если попытаться присвоить ему значение, у производного класса тут же появится своя копия class variable. После этого изменение значения переменной в классе-родителе уже не изменит значения этой переменной в потомке.

Разумеется. Так работают практически все скриптовые языки. И?!

Вот-вот. А в голове-то это держать надо.

Нет, не надо. Это оооочень редкий случай. Вы лучше в голове базовые вещи держите, а то у вас с ними проблемы.

Только урезана по самое не могу.

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

> Нет, всё перестаёт глючить при переходе на Haskell. Или на любой другой язык со статической типизацией.

Согласен. Но это уже следующий этап.

Главное - сбежать из хаоса перла.

>TCL прост как три копейки.

В общем, это верно, хотя и традиционно поверхностно.
Там где преподают изучение костылей как особую науку
в перл, в tcl аналогичные места оставляют для игры воображения из-за самоочевидности и прозрачности.
Как показывает история, средствами tcl можно создать ООП раширения языка и до которых перлу будет далеко по ясности и выразительности.
Хотя все это забьют тоннами макулатуры с бережным преподаванием костылей.

Имхо, Отсуствие изобилия штатных далондонов-толкователей в языке Tcl сыграло злую шутку c ним.
1,5 ... 2 года пребывания Tcl под крышей Sun оставили заметный вклад в развитие языка.

Самая засада была в скорости обработки текстовой информации. Что программа на перле делала 20 сек, на Tcl занимало 3 минуты.

Как-то странно, что язык с строками в базе своей (и как один из первых поддерживающий нативно юникод) малопригоден для обработки текстов? ))
Я на днях перепроверял былинные нападки одного фана перла на tcl:
http://www.perl.com/doc/FMTEYEWTK/versus/asherman-on-tcl.html

Он тоже приводил подобный порядок расхождения в быстродействии.
А я не смог получить хуже чем двукратное превосходство перл над tcl8.4 в нынешнем виде.
Хотя и большего утонченного вздора о tcl в исполнении гуру перл Tom Christiansen будет трудно найти в тырнете:
http://www.perl.com/doc/FMTEYEWTK/versus/tcl-discussion.html
Хотя он и указывал около 20 раз.
Отметим, что эти перлы объективности и здравомыслия скромно хранятся на http://www.perl.com как некая истина в последней инстанции для потомков.
А есть и ответ на все это от членов tcl core tim:
http://wiki.tcl.tk/12366

В общем, в tcl нет смысла стремится все реализовать средствами самого языка.
Можно быстро прописать прототип программы и заменить критические места их реализацией на С или готовыми либами. (Как пример: сервер AOL
~ три месяца работ по реализации, месяц на создание рабочего прототипа)

Далее, можно найти более десятка примеров IDE и редакторов на tcl
и совсем не тормознутых.
А на перл почему-то их в природе есть 1 или 2 (и притом таки тормознутые). Забавно ?))
tcl это в некой мере антиперл и антипитон, имеет лучшее соотношение по отдаче кода на одну кодирующую персону. Хотя и никогда tcl не был лидером в быстродействии.


Еще, связка tcl/tk до сих пор остается укором проектировщикам уродливых биндингов к либам GUI , и не превзойдена никем по ясности и лаконичности, а все утверждающие иное просто не знают tcl/tk.))
И в аналогичном ключе ведутся работы в gnocl (биндинг tcl к gtk).
В общем, достаточно тяжело на tcl написать вагон трудно читаемой муры
требующей программистов-казуистов в сопровождении .
Нынешний патрон tcl - Activestate, приторговывает закрытыми средствами разработки и отладки для tcl. Это как своеобразная жертва за поддержку и развитие языка от Activestate.
Хотя часто вполне хватает и нативных средств tcl для отладки.
-----
сорри, что-то много букв вышло.)

В Perl 6 будет и статическая типизация.

Сбежать - это не самая лучшая из альтернатив. TMTOWTDI же. Достаточно следовать perlstyle.

Нет, всё перестаёт глючить при переходе на Haskell. Или на любой другой язык со статической типизацией.

Статическая типизация это, конечно, хорошо. Но функциональщина для скриптового языка однозначно плохо. Пусть тогда уж будет перл :)

> Как показывает история, средствами tcl можно создать ООП раширения языка и до которых перлу будет далеко по ясности и выразительности.

Спору нет, мне попадалось, выглядело неплохо.

Как-то странно, что язык с строками в базе своей (и как один из первых поддерживающий нативно юникод) малопригоден для обработки текстов?

Я не смогу уже повторить код, который писал примерно в 1999 году, мне надо было парсить бинарные данные с междугородней АТС. Я когда столкнулся с проблемой быстродействия, я в точности воспроизвёл код на перл и на tcl совершенно одинаково, почему так медленно, не понял. Никакая оптимизация не помогала, да там и нечего особо было, формат разбирался совершенно однозначно. Драйвера для коннекта к Oracle тогда или не было, или он только-только появлялся, на ум приходит «neosoft», но я уже не помню что это. Модуля для FTP не было совсем, я тогда спросил «у тех, кто знает», у Тоботраса, он сказал: «возьми программу ftp, да сделай с ней диалог». Это работало, пока не добавилась вторая программа «sqlplus». Переход на Perl решил три проблемы сразу: быстродействие, DBD::oracle, Net::FTP.

Хочу добавить, что ничего не имею против Tcl/Tk, и даже иногда использовал с тех пор, поскольку связка действительно гениальная. Особенно приятно получить PS из canvas. Но ей сильно (раньше по крайней мере) не хватало приличного Look. Виджеты из 80х годов смотрелись не круто уже в 90х. Слышал, что пытались что-то сделать с этим, судьбы попыток не знаю.

> Слышал, что пытались что-то сделать с этим, судьбы попыток не знаю.

Так ведь сделали. Теперь native look and feel.

> Теперь native look and feel.

Надо будет посмотреть. Редко пишу юзерские приложения ;)

А делали подхват тем gtk в git tile для tk , выглядело весьма недурственно.
Хотя gnocl.org уже и лучше будет.

Хм,neosoft - это прежде всего Karl Lehenbauer и его интернет проекты для tcl:
http://en.wikipedia.org/wiki/File:Karl_Lehenbauer_headshot.jpg

Но ей сильно (раньше по крайней мере) не хватало приличного Look.

ДА, есть такое под линем.
Хотя tkpath + tile во многом исправляют ситуацию

>Далее, можно найти более десятка примеров IDE и редакторов на tcl
и совсем не тормознутых.

А на перл почему-то их в природе есть 1 или 2 (и притом таки тормознутые). Забавно ?))

Ну для перл есть несколько IDE. есть и своя полностью перловая и кроссплатформенная - Padre . Вот кстати мой доклад по этому поводу http://onperl.ru/onperl/2009/10/naim-shafiev-pro-ide-padre.html

P.S книжку по Tcl какую можешь посоветовать,я реально хочу его серьезно посмотреть

> P.S книжку по Tcl какую можешь посоветовать,я реально хочу его серьезно посмотреть

Серьёзно - не надо. RMS не одобряет :-)

> TMTOWTDI же.

TMTOWTDI + большой проект = каша.

Вы не задумывались, почему инженеры делают чертежи согласно стандартам?

Угу,знаю, и Padre таки тормозит под linux.


ну есть классика:
http://www.ozon.ru/context/detail/id/1820838/
и не всегда хороша для первого чтения.

Это перевод с оригинала:
http://www.amazon.com/Practical-Programming-Tcl-Tk-4th/dp/0130385603/ref=pd_s...

Начинать можно с:
http://www.amazon.com/Tcl-Second-Developers-Engineering-Programming/dp/155860...

А основной источник инфы по текущему tcl - http://wiki.tcl.tk

> TMTOWTDI + большой проект = каша.

Есть много путей, но ничто не мешает выбрать один. Принять стандарты кодирования, настроить параметры Perl::Critic и perltidy, и вот уже при отклонении от выбранного way на вас посыплются страшные warning'и. :-)

Еще:
http://www.linuxshare.ru/docs/devel/languages/tcltk/index.html

> Угу,знаю, и Padre таки тормозит под linux.

vim - наше всё.

>Угу,знаю, и Padre таки тормозит под linux.

Тормозит???В чем?
Он у меня раза в три меньше памяти чем eclipse + epic.Ну и работает быстрее.Там правда есть довольно жирные модули. Но в последнее время оно стало намного стабильнее чем было

P.S За ссылки спасибо

> Он у меня раза в три меньше памяти чем eclipse + epic.Ну и работает быстрее.
ну нашел с чем сравнивать ))

Тормозит???В чем?

Я сейчас не за своим компом. Вечером могут быть подробности.

Там правда есть довольно жирные модули.

Возможно и это тоже.

http://livejournal.com/ http://www.bbc.co.uk/ http://www.imdb.com/ http://slashdot.com/

> есть и своя полностью перловая и кроссплатформенная - Padre

О! За Padre спасибо. Действительно очень шустрая. По сравнению с eclipse+epic, так просто самолёт. Но! Не обнаружил интеграции с SVN. Ещё, когда в epic становишься на переменную, слово и подобное, он выделяет подсветкой его, и все другие встречающиеся такие же слова в тексте. Padre тоже так делает по выделению. Но! В Epic оно ещё рядом со скроллером отмечает все места где встретилось это слово, или выделение, а в Padre нет. А мне очень удобно. Если б были эти два момента, выкинул бы эклипс без сожаления особого.

>О! За Padre спасибо. Действительно очень шустрая. По сравнению с eclipse+epic, так просто самолёт. Но! Не обнаружил интеграции с SVN.
Ну посравнению с Emacs мега тормоз :).
для svn есть Padre::Plugin::SVN ( http://search.cpan.org/~plaven/Padre-Plugin-SVN-0.05/lib/Padre/Plugin/SVN.pm )

а вообще есть страницка всяких дополнений
http://cpan.uwinnipeg.ca/search?query=Padre%3A%3APlugin%3A%3A&mode=dist

>> Как сейчас помню, в документации было написано, что, если аргумент один, то скобки можно опустить.

Так и написано. Правда, только про generator expressions :)

Да хотя бы sort.

sorted.

lower возвращает изменённую строку. А оригинал не меняет. Потому что строки иммутабельны. Это чистая функция. У вас какие-то проблемы с чистыми функциями?

Нет, это у Питона проблемы с тем, что половина функций меняет аргумент, а половина нет.

Разумеется.Так работают практически все скриптовые языки. И?!

Бред.

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

А давайте ограничим функции одной строкой, тоже для читабельности.

> Есть много путей, но ничто не мешает выбрать один.

В теории - конечно не мешает.

> Так и написано. Правда, только про generator expressions :)

Ну вот видите. У вас просто дислексия - проблемы с чтением. Лечитесь.

Нет, это у Питона проблемы с тем, что половина функций меняет аргумент, а половина нет.

Я вас удивлю: такая «проблема» имеет место у ВСЕХ ЯП, кроме чисто-функциональных.

Вы что, с Луны свалились?

Бред.

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

А давайте ограничим функции одной строкой, тоже для читабельности.

Определения именованнах функций, видите ли, не встраиваются в другие выражения.

Поэтому их совсем не обязательно ограничивать.

> В теории - конечно не мешает.

На практике тоже не мешает. «Perl Best Practices» от Дамиана Конвея можете почитать.

> Я вас удивлю: такая «проблема» имеет место у ВСЕХ ЯП, кроме чисто-функциональных.

Нет. То есть, естественно, функциональные удобнее, но и в нормальных императивных языках интуитивно понятно, что будет делать функция. В том же Tcl все, что может обойтись без изменения аргумента, обходится (lsort, lappend, lreplace) А в Питоне так просто не угадаешь.

Переменные класса во всех языках с прототипной типизацией работают примерно так же, как и в питоне. И это правильно и удобно.

Правильно и удобно, когда унаследованную статическую переменную можно изменять, меняя ее в суперклассе, но *только* до тех пор, пока не изменишь ее в субклассе? Нет уж. Посмотрите, что ли, на Groovy. Там унаследованная статическая переменнная действительно одна на всю иерархию классов. Вот это правильно и удобно.

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

В случаях, когда лямбда вставляется в другие выражения (хотя это не единственный способ ее использовать), настоящим ограничителем в Питоне являются отступы. Отнимите у них синтаксическое значение, и пользоваться нормальной лямбдой будет так же легко, как в Scheme.

> То есть, естественно, функциональные удобнее, но и в нормальных императивных языках интуитивно понятно, что будет делать функция.

Так и в питоне понятно. Любому человеку, знающему английский.

В том же Tcl все, что может обойтись без изменения аргумента, обходится

А как в Perl? Тема была про Perl. Причём тут Tcl?

Правильно и удобно, когда унаследованную статическую переменную можно изменять, меняя ее в суперклассе, но *только* до тех пор, пока не изменишь ее в субклассе?

А зачем вам вообще менять статическую переменную в субклассе? Глобальные переменные вообще зло, пользуйтесь ими поменьше.

Посмотрите, что ли, на Groovy.

А как в Perl? Тема была про Perl. Причём тут Groovy?

Отнимите у них синтаксическое значение,

Здрасьте. Зачем портить самую лучшую идею питона?

и пользоваться нормальной лямбдой будет так же легко, как в Scheme.

А как в Perl? Тема была про Perl. Причём тут Scheme?

> А как в Perl? Тема была про Perl. Причём тут *?

Вы же ссылались на другие скриптовые языки, что, мол, везде так. Вот я и привел примеры языков, где лучше, чем в Python.

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

Спасибо за статьи! Интересно и понятно расписано=))

Лол, сами начали говорить про «все скриптовые» язки, а когда нос утерли - жалуйтесь.