LINUX.ORG.RU

[история успеха] Я не осилил Perl :(

 


0

2

Я давно понял, что для автоматизации выполнения повседневных задач мне необходим какой-нибудь простой интерпретируемый язык с большой базой подпрограмм на все случаи жизни. В котором мне не придётся волноваться о выделении и освобождении памяти, указателях, грамотном ООП, синтаксических заморочках. Где не нужно продираться через многочисленные уровни абстракций, дабы понять в чём скрывается ошибка, насилуя трасcировщик и многократно перекомпилируя исходники.

В качестве такого языка я решил выбрать Perl. Благо, он позволяет большие вольности в оформлении программ, а книги по нему написаны простым и доступным языком. И поначалу всё было хорошо, пока я решал простенькие задачки и учебные примеры. Впрочем, никаких практических навыков подобное обучение не давало и все полученные знания быстро вылетали из головы. Тогда я решил начать делать то, ради чего и взялся за изучение Перла - решать повседневные задачи. Мне показалось, что это лучший путь для освоения нового языка.

Беда пришла оттуда, откуда я её совсем не ждал. Я решил, по старой привычке, создать несколько структур данных, исключительно в целях организации кода. Но никакой отдельной главы, им посвященной, я в книгах не нашёл. Копнув глубже, я обнаружил, что в качестве структур данных в Перле используются хеши, причём их синтаксис, применительно к сложным структурам, меня абсолютно не обрадовал. Поначалу, я решил плюнуть на структуры данных и попробовать местные объекты, благо им, таки, была посвящена отдельная глава. Но, как я и предполагал, объектами оказались те же хеши, оформленные особым образом. Возвращаясь к ним, я с ужасом, обнаружил местные ссылки и оператор разыменования. Так же я понял, что без хорошей зубрёжки и многочасового вдумчивого чтения мне никогда не понять в каких случаях этот оператор работает; когда в коде стоит употреблять фигурные, когда круглые, когда квадратные скобки, а когда ещё ставить перед ними волшебные слова; в какой ситуации вместо двойной кавычки стоит употреблять одинарную; когда перед именем хеша стоит ставить %, а когда $ и в каком случае эти два одинаковых имени будут относится к двум совершенно между собой не связанным структурам данных. В принципе - всё это в книгах описано и через недельку я, наверное, в этом бы разобрался, а через пару лет практики даже перестал бы совершать связанные с этим ошибки, но, нет уж спасибо...

Так что я решил забить на Perl т.к. перестал понимать в какой ситуации его использование будет предпочтительнее чем применение связки C+Lua, тем более, что сложность их освоения, похоже, сопоставима. Большие надежды я возлагаю на Лисп, в особенности, если научусь вызывать из него программы с аргументами и парсить их вывод. И, возможно, стоит таки попробовать Питон. Я не ругаю Perl. Просто жалко, что его изучение, поначалу напоминавшее добрую сказку, под конец превратилось в какое-то жёсткое порно.

Ответ на: комментарий от Deleted

но с более человеческим синтаксисом.

Перлистам он не нужен. Они лелеют свободу. Сюда же и отступы.

baverman ★★★
()

>Просто жалко, что его изучение, поначалу напоминавшее добрую сказку, под конец превратилось в какое-то жёсткое порно.

ИМХО это с самого начала жестокое порно... Просто жалко, что его изучение, поначалу напоминавшее добрую сказку, под конец превратилось в какое-то жёсткое порно.

drBatty ★★
()
Ответ на: комментарий от XVilka

шел?? вы бы хоть смотрели на то, что даете ссылки.

Lush is an object-oriented programming language designed for researchers, experimenters, and engineers interested in large-scale numerical and graphic applications. Lush is designed to be used in situations where one would want to combine the flexibility of a high-level, weakly-typed interpreted language, with the efficiency of a strongly-typed, natively-compiled language, and with the easy integration of code written in C, C++, or other languages.

Один из авторов lush - знаменитый Лекун(вы его, конечно, не знаете). Сейчас, кстати пилится 2я версия lush

bik ★★
()

>интерпретируемый язык

Боюсь, сегодня из распространённых это только bash.

KRoN73 ★★★★★
()
Ответ на: комментарий от baverman

У перла есть 100500 библиотек, а у петона всего лишь 10050. У перла есть xs из коробки, а для петона надо доставлять дополнительные костыли типа sip'а. У перла нормальный Си-шный синтаксис, а у петона отступы. У перла более-менее нормальные потоки, а у петона gil. .... ну и так можно продолжать до бесконечности.

Reset ★★★★★
()
Ответ на: комментарий от Reset

ну и так можно продолжать до бесконечности.

Жалкие отговорки незнающего питоновской матчасти. Похоже на твои же изречения про git.

baverman ★★★
()
Ответ на: комментарий от Reset

>У перла более-менее нормальные потоки
Недавно тема была, про «нормальность» этих самых потоков в перл.

Bad_ptr ★★★★★
()
Ответ на: комментарий от Reset

а у петона всего лишь 10050.

Давай название библиотеки которой не хватает.

У перла есть xs из коробки

ctypes

У перла нормальный Си-шный синтаксис, а у петона отступы.

duck argument

У перла более-менее нормальные потоки, а у петона gil

Не раз замечал, что gil мешает только непитонщикам. Написал кучу многопоточных программ, но ни в одной мне не помешал GIL, ЧЯДНТ?

baverman ★★★
()
Ответ на: комментарий от baverman

Давай название библиотеки которой не хватает.

Зайди на cpan и сам найди то чего нет в петоне.

ctypes

И каким образом ctypes мне завернет, например, плюсовый класс в полноценный модуль для петона?

Не раз замечал, что gil мешает только непитонщикам. Написал кучу многопоточных программ, но ни в одной мне не помешал GIL, ЧЯДНТ?

очевидно, тебе насрать было на производительность

Кстати, про очень важную вещь забыл — в петоне отсутствуют лямбды.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Зайди на cpan и сам найди то чего нет в петоне.

За пять лет еще ни разу не облизывался на содержимое cpan. И, думаю, не придется.

И каким образом ctypes мне завернет, например, плюсовый класс в полноценный модуль для петона?

Прости, подумал про другое. Но ты же понимаешь, что преимущество в изкоробочности перед сипом, абсолютно никчемное? У питона коробка всё равно больше, хоть и заполнена другими, более нужными вещами.

тебе насрать было на производительность

Это мне-то? Специально делающего редактор, за которым можно работать на нетбуке? Насмешил. Думай еще.

в петоне отсутствуют лямбды.

Отсутствует сахарок. Да, было бы неплохо, но только из-за этого выбирать кашку-малашку?

baverman ★★★
()
Ответ на: комментарий от Reset

> Зайди на cpan и сам найди то чего нет в петоне.

Это слив.

И каким образом ctypes мне завернет, например, плюсовый класс в полноценный модуль для петона?

Что-то не я увидел каких-то особых способностей XS по сравнению со SWIG.

в петоне отсутствуют лямбды

Слишком толсто, попробуй еще.

tailgunner ★★★★★
()

ты удивляешься почему объекты это хэши

Я удивляюсь не этому, а безумному синтаксису при их объявлении и обращении к ним.

За лисп лучше не берись.

За лисп я уже три года назад взялся, ибо гоняли по нему в университете бешено.

Если после связки С-<встраиваемый яп>

А вот за такое я, как раз, не брался.

У перла нормальный Си-шный синтаксис

НОРМАЛЬНЫЙ???? o_0

Вот это вот:

%HoH = (
	flinstones => {
		husband		=> "fred",
		pal		=> "barney",
	},
	jetsons => {
		husband		=> "george",
		wife		=> "jane",
		"his boy" 	=> "elroy", #Ключи должны быть в кавычках
	},
	simpsons => {
		husband		=> "homer",
		wife		=> "marge",
		kid		=> "bart",
	},
);

Состав всех семейств можно вывести путём перебора в цикле ключей внешнего хеша, а затем - перебора в цикле ключей внутреннего хеша:

for $family ( keys %HoH ) {
	print "$family: ";
	for $role ( keys %{ $HoH{$family} } ) {
		print "$role=$HoH{$family}{$role} ";
	}
	print "\n";
}

нормальный Си-шный синтаксис?

схема - это схема. Она лучше, чем лисп. С более стройным синтаксисом и т.д.

Честно говоря, при беглом взгляде не заметил различий. Она, вроде бы, задумывалась как облегчённый Лисп.

Nebuchadnezzar ★★★★
() автор топика
Ответ на: комментарий от Nebuchadnezzar

нормальный Си-шный синтаксис?


Да. Попробуй такой же перебор вложенных хэшей напиши на Си.

Bad_ptr ★★★★★
()
Ответ на: комментарий от Nebuchadnezzar

не облегченный, но с более «строгим» и правильным синтаксисом.

XVilka ★★★★★
()
Ответ на: комментарий от tailgunner

Что-то не я увидел каких-то особых способностей XS по сравнению со SWIG.

дело не в способностях, а в том, что XS есть из коробки

Слишком толсто, попробуй еще.

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

Reset ★★★★★
()
Ответ на: комментарий от Nebuchadnezzar

нормальный Си-шный синтаксис?

да

Reset ★★★★★
()

Простыню целиком не читал, но

для автоматизации выполнения повседневных задач мне необходим какой-нибудь простой интерпретируемый язык с большой базой подпрограмм на все случаи жизни. В котором мне не придётся волноваться о выделении и освобождении памяти, указателях, грамотном ООП, синтаксических заморочках. Где не нужно продираться через многочисленные уровни абстракций, дабы понять в чём скрывается ошибка, насилуя трасcировщик и многократно перекомпилируя исходники.

Ruby же. Ну или Питон, для людей с альтернативным понимаем простоты и удобства.

geekless ★★
()
Ответ на: комментарий от Reset

а в том, что XS есть из коробки

Про коробку уже говорил. Перл, по сравнению с питоном — гол, как сокол.

недоразумение которое в петоне называется лямбдами и есть лямбды

Однако его хватает в *подавляющем большинстве* случаев.

baverman ★★★
()
Ответ на: комментарий от Reset

>> Что-то не я увидел каких-то особых способностей XS по сравнению со SWIG.

дело не в способностях, а в том, что XS есть из коробки

У меня и SWIG из коробки: sudo apt-get install swig. Если у тебя нет ни apt-get, ни аналога - это не проблема Питона.

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от geekless

в Виллабаджо уже всё давно написали на блоках и теперь пьют пиво

~$ yaourt -Ss python | wc -l
4710
~$ yaourt -Ss ruby | wc -l
996

То то и оно. Хватит бухать, бездельники.

baverman ★★★
()
Ответ на: комментарий от baverman

Что поделать, людям так нравится ходить по граблям.

Windows популярнее Linux.
Гибрид популярнее микроядра.
JS популярнее Питона.
Питон популярнее Руби.

geekless ★★
()
Ответ на: комментарий от Nebuchadnezzar

>Приходится так:

open(INPUT_FILE, $input_file) || die «Cannot open file: $!»;

дык это же круто! Я даже в шелле постоянно использую конструкции подобного вида - гораздо лаконичнее всяких if

lazyklimm ★★★★★
()
Ответ на: комментарий от tailgunner

там есть гораздо более неприятная вещь со связыванием переменных

Питон в этом не одинок. Например груви:

closures = []
for(x in 0..10) {
	closures.add({println x})
}

for(c in closures) {
	c()
}

Тоже напечатает последнее значение x.

Кстати, а в каких языках интуитивно понятный захват?

baverman ★★★
()
Ответ на: комментарий от geekless

Если бы руби не игрался в смолток (заигрывания с перлом можно оставить), из него бы вышел замечательный язык.

baverman ★★★
()
Ответ на: комментарий от geekless

Идея «всё объект, объекты обмениваются сообщениями» — глупая, доводящая до маразмов в виде необходимости оборачивать в блок вызов метода, чтобы его куда-нибудь передать.

baverman ★★★
()
Ответ на: комментарий от baverman

> Кстати, а в каких языках интуитивно понятный захват?

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

tailgunner ★★★★★
()
Ответ на: комментарий от baverman

> Кстати, а в каких языках интуитивно понятный захват?

Во всех, где есть полноценные лямбды?

anonymous
()
Ответ на: комментарий от Nebuchadnezzar

if !(open(INPUT_FILE, $input_file)) die «Cannot open file: $!»;
unless (open(INPUT_FILE, $input_file)) {die «Cannot open file: $!»}

слишком многословно и думать надо когда видишь такую конструкцию

open(INPUT_FILE, $input_file) || die «Cannot open file: $!»;

А вот это лаконично и понято — «открой или умри». Даже ни на секунду не задумываешься когда видишь такую конструкцию.

Еще мне нравятся в перле ||= и «0 but true». Это архиудобно, читабельно и приводит к сокращению кода.

Reset ★★★★★
()

>да

Понятно.

Ruby же. Ну или Питон, для людей с альтернативным понимаем простоты и удобства.


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

Nebuchadnezzar ★★★★
() автор топика
Ответ на: комментарий от beka

Ой, только не надо тут великомученника мейнстрима делать.

baverman ★★★
()
Ответ на: комментарий от XVilka

> Она лучше, чем лисп. С более стройным синтаксисом и т.д.

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

anonymous
()
Ответ на: комментарий от aedeph

> Схема - это лисп.

Открещивающиеся лисперы - не редкость. Это лишь вопрос определений («лисп», как и «unix» - перегруженное слово).

anonymous
()
Ответ на: комментарий от anonymous

Во всех, где есть полноценные лямбды?

4.2 Про груви я уже сказал.

baverman ★★★
()
Ответ на: комментарий от anonymous

Во всех, где есть полноценные лямбды?

blocks = []
for x in 1..10
    blocks.push proc { puts x }
end

blocks.each do | it |
    it.call
end

Ок. В руби лямбды не полноценные. Так и запишем.

baverman ★★★
()
Ответ на: комментарий от baverman

> for(x in 0..10) {

Наверное в таких (если они вообще есть), где `for' вводит дополнительное пространство имен.

anonymous
()

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

Нет такого. К каждой задаче нужно подходить отдельно и объективно определять наиболее подходящий язык. Пишешь парсер для какой-нибудь текстовой базы данных — перл. Пишешь супермасштабируемый и легкоподдерживаемый проект — тогда ruby с его тру ООП (а не сбоку приделанный, как в большинстве остальных языков). Пишешь оболочку над множеством unix-way программулин — sh. Нужно быстрое ядро для программы — Си. GUI интерфейс к программе — tcl/tk. Выполнить сложную мат. обработку данных с последующим представлением в виде графиков и т.п. — mathematica. И т.д.

Не зря столько разных языков существует. У меня вот, к примеру, валяется вечно-сырой проект — каталогизатор книг; так он выполнен (like git) как множество крохотных unix-way программ, причём каждая написана на наиболее подходящем языке (Tcl и Ruby приемущественно, ядро работы с БД на Сях), а всё это вместо собирается абстрагированной оболочкой в 100 строк на баше. К последней же имеется GUI интерфейс на Tcl/Tk.
И вообще все свои проекты стараюсь писать в таком же стиле. Можно и на пиле лунную сонату сыграть, но зачем, если рядом стоит пианина.

toady2
()
Ответ на: комментарий от toady2

> Пишешь супермасштабируемый и легкоподдерживаемый проект — тогда ruby с его тру ООП

Бгг.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

`for' вводит дополнительное пространство имен.

Ты о чем? Какое дополнительное пространство имен?

x = 1
b1 = proc {puts x}

x = 2
b2 = proc {puts x}

b1.call
b2.call
baverman ★★★
()
Ответ на: комментарий от toady2

> тру ООП

Ви так говорите, как будто это что-то хорошее.

anonymous
()
Ответ на: комментарий от baverman

> Ты о чем? Какое дополнительное пространство имен?

Если вместо `for' была был функция, которой передается х - в некоторых языках замыкание бы удалось.

Пример ниже не понял. Если это тикль, то почему «=»?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.