LINUX.ORG.RU

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

 


0

2

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

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

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

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

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

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

Оно бы удалось во всех (ну почти) языках.

Пример ниже не понял.

Это тот же руби. Показывает проблему без циклов. Замыкание делается не на значение, а на символ в конкретной области видимости. Как заметил tailgunner, это присуще многим языкам (большинству?).

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

Мутабельность в питоне... В F# с этим все хорошо:

Microsoft (R) F# 2.0 Interactive build 4.0.30319.1
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> open System.Collections.Generic;;
> let closures = List<unit -> unit> ();;

val closures : List<(unit -> unit)>

> for x in [0..10] do closures.Add(fun () -> printf "%i" x);;
val it : unit = ()
> for c in closures do c ();;
012345678910val it : unit = ()
>
dave ★★★★★
()
Ответ на: комментарий от baverman

Понятно, просто, скажем js проблема не только в значении: `x' может быть вообще недоступна (если верить /usr/bin/js).

Впрочем, вероятно, я не то обратил внимание.

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

Мутабельность в питоне

Скорее интерпретируемость. code object создается на этапе парсинга, и замыкания в нем прописываются как ссылки на имена в родительском скоупе.

Хотя… Нет, думать уже не могу. Поздно.

baverman ★★★
()

Мне нравится то ООП, что есть в Смолтолке и CLOS. Оно весьма интересно в своём первоначальном предназначении как попытка программирования на естественном языке (объекты - существительные, сообщения - глаголы), но в качестве способа организации кода, на мой взгляд, представляет собой лишнюю сущность и тупиковую ветку в эволюции языков. Грамотное программирование Кнута - куда интереснее, но весьма непросто в освоении, хотя бы потому, что нужно неплохо знать английский язык. Так что я возлагаю большие надежды на cweb.

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

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


Убийственная аргументация.

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

А, хаскель же еще есть, в нем так не получится напороться:

t :: [IO ()]
t = do x <- [1..10]
       return $ print x

main :: IO ()
main = sequence_ t

Только это, конечно, не цикл, и `x' не переменная. Половина бед от этой мутабельности: http://www.haskell.org/haskellwiki/Why_Haskell_just_works

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

Вот, еще пример до кучи на скале. Там тоже все хорошо:

Welcome to Scala version 2.8.1.final (Java HotSpot(TM) Client VM, Java 1.6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import scala.collection.mutable.ArrayBuffer
import scala.collection.mutable.ArrayBuffer

scala> val closures: ArrayBuffer[() => Unit] = ArrayBuffer()
closures: scala.collection.mutable.ArrayBuffer[() => Unit] = ArrayBuffer()

scala> for (x <- 0 to 10) closures += (() => { print(x) })

scala> for (c <- closures) c()
012345678910
scala>
dave ★★★★★
()
Ответ на: комментарий от geekless

>Это не аргументация
Ну и ненадо такого писать.

а примеры

На каждый твой пример можно привести контрпример.

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

Только это, конечно, не цикл, и `x' не переменная.

Вот вот.

Половина бед от этой мутабельности

А вторая половина — от ее отсутствия :)

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

Бревно в глазу смотрящего. Ты еще скажи, что в Io «всё выглядит некрасиво и неуклюже», где точно так же «всё есть объект», но только никакого сахара не требуется вообще:

numbers select(isOdd)
people select(age < 30)
people map(name)

Если есть какие-то конкретные претензии, то давай их и обсудим. А не про «дико и неуклюже».

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

Если есть какие-то конкретные претензии

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

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

До нормальной функциональной парадигмы, что питону, что руби — как до Китая раком. А ты опять занимаешься словоблудием, вместо того, чтобы указать на реальные недостатки. Попробуй, например, формально изъяснить разницу между «метод как сообщение» и «метод как функция».

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

Ну тут тред про неосиливание перла. Такчто...

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

Какое словоблудие? Ты отрицаешь, что в руби нет единообразного способа передать кусок кода на выполнение в другом месте? Меня, лично меня, это напрягает. В демагогию я пускаться не собираюсь.

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

>Если брать изучение с нуля связки C+Lua, то в лучшем случае только через неделю осилишь написание более-менее полезных программ.

Можно сначала изучить Lua без связки с С и писать полезные программы сразу ;)

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

> Грамотное программирование Кнута - куда интереснее, но весьма непросто в освоении, хотя бы потому, что нужно неплохо знать английский язык. Так что я возлагаю большие надежды на cweb.
Еще есть noweb: не привязан к ЯП, легко прикрутить Xelatex.

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

> Ты отрицаешь, что в руби нет единообразного способа передать кусок кода на выполнение в другом месте?

«Кусок кода» передаётся при помощи объекта класса Proc. Я не понимаю, в чем у тебя затруднение. В том, что Proc имеет два типа поведения, в зависимости от значения его метода lambda? Или в том, что экземпляр Proc может быть описан несколькими разными синтаксическими способами? Ну так это для удобства программиста сделано. Ты вот не ценишь, что автор языка о твоем удобстве при наборе и чтении кода позаботился. (Не то что Гвидо, который однострочные лямбды починить не может. :D )

Тебе надо надо, чтобы было «безобразно, зато единообразно»? Так это в JS тогда, где единый function(){...; return blabla;} на все use cases. Пофиг, что неудобно, ага.

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

Ну и еще. Я правильно понимаю, что ты не можешь объяснить разницу между «метод как сообщение» и «метод как функция»? Так зачем ты тогда про них говоришь, и кто тут занимается демагогией?

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

Хех. Боюсь, я выучил перл и писал на нём коммерческие проекты, когда некоторых нынешних посетителей ЛОРа не было ещё и в проекте ;) Гугль даже отыскивает результаты той деятельности.

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

Ну и да, несмотря на то, что я отчётливо понимаю разницу между $a, $a[....], $a{....} и $a->[....], в настоящее время я не полагаю такой синтаксис удобным для разработки в команде. Более того, я полагаю, что девелопер, пишущий код «как короче», а не «как понятно» и «как поддерживаемо», должен получать по рукам и кошельку.

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

Насчёт «не было в проекте» - пожалуй, я подзагнул. Но не очень сильно :)

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

> Хех. Боюсь, я выучил перл и писал на нём коммерческие проекты, когда некоторых нынешних посетителей ЛОРа не было ещё и в проекте ;) Гугль даже отыскивает результаты той деятельности.

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

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

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

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

> я даже не знаю, насколько надо быть неосилятором.

Ты бредешь по колено в неосиляторах. Тяжело тебе, наверное.

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

У меня нема таких. Вот на ЛОРе встречаются, да.

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

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

Дак вот, повторяю медленнее, для Осилятора: человеку уже не понравился перл. Вникать в его тонкости - тоже не будет. Совать ему на этой волне руби - м-м-м, неумно... Впрочем, конечно, Вам виднее, из своего руби-танка.

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

> Можно сначала изучить Lua без связки с С и писать полезные программы сразу ;)

Абсолютно правильно. Никаких возражений. Я сам на Lua первый полезный скриптик написал после пары часов ознакомления с синтаксисом. :)

Вот только в данном конкретном случае ТС сравнивал сложность изучения Perl-а именно со сложностью изучения _связки_ C+Lua. Потому я так и написал. Если сравнивать время и трудозатраты на изучение _с_нуля_ первого и второго.

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

Надеетесь убедить всех в том, что вот она, серебряная пуля?

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

Или что ruby ничего, ну ничегошеньки общего не имеет с синтаксисом перла?

Мы ведь взрослые люди, давайте достанем и сравним.

Вы опять что-то своё читаете в моих постах. Утверждать про руби, что он «ничегошеньки общего не имеет с синтаксисом перла» — довольно наивно, потому что при желании общие элементы можно отыскать где угодно. (Взять хотя бы постфиксные if, unless.) Завязывали бы с приписыванием мне своих странных догадок.

Но если вам так хочется сравнить, то давайте сравним.

  • В руби преводы строк используются как разделители операторов. В перл — нет.
  • В руби составные операторы имеют вид keyword ... keyword ... end. В перле используются Си-подобный синтаксис.
  • В перле используются префиксы типа данных. В руби — нет.
  • В руби все типы данных — это классы, происходящие от Object. В перле — система независимых типов, характерная для процедурных языков.
  • Руби — полностью ОО язык. В перл элементы ОО прикручены при помощи скотча и такой-то матери.

Ну и т.п. Всерьёз утверждать о сильной похожести этих языков можно только если вы с одним из этих языков не знакомы.

geekless ★★
()

Я не осилил Perl :(

Позор!

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

В перле используются префиксы типа данных. В руби — нет.

в руби эти префиксы ответственны за скоуп. ТСу понравится ага.

В руби все типы данных — это классы, происходящие от Object. В перле — система независимых типов, характерная для процедурных языков.

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

В перл элементы ОО прикручены при помощи скотча и такой-то матери.

(пожимая плечами) ну, возможность прямого манипулирования /таблицей виртуальных функций/ (я не знаю лучшего термина для того, что лежит под @ISA) - это, конечно, хороший способ отстрелить себе пейсы. Как и всякая павер-фича. А так, вообще, повторюсь, на CPAN-е сейчас довольно много модулей, написанных в ОО-парадигме, и, что более важно, использующих общий ОО-базис, который скрывает большую часть кровавых подробностей перлячьего ОО.

Всерьёз утверждать о сильной похожести этих языков можно только если вы с одним из этих языков не знакомы.

Если бы Вы внимательно читали то, что пишут Вам Ваши собеседники, то увидели бы, что я писал только о «знаках препинания», имея в виду $, @ и прочие $@.

Ну а если Вы твёрдо уверены в полной непохожести этих языков - я думаю, Вам стоит известить об этом мир. Начать, например, с педивикии, а то там какая-то фигня на страничке про руби написана ;)

AlexM ★★★★★
()

Раз такая пьянка и было несколько предложений в направлении tcl, хотелось бы узнать: у одного ли меня вызывает диссонанс нагромождение eval?

Почти весь синтаксис можно переделать, это же ядренее lisp. Как предвидеть, что будет делать код? Может есть рецепты.

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

да ладно

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

перл меня уничтожил синтаксисом(хотя бы знаменитая обфусцированная строка убийства всего)

пайтон убил tab'ами, количеством разнообразных списков и писанием справо-налево

а синтаксис руби я понял с полувзгляда и нежно полюбил

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

>Раз такая пьянка и было несколько предложений в направлении tcl, хотелось бы узнать: у одного ли меня вызывает диссонанс нагромождение eval?

не только. Еще при вычислениях нагромождение expr.) Вообще, возникает ощущение что синтаксис усложнён на пустом месте.

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

>пайтон убил tab'ами

омайнгот)

количеством разнообразных списков


и после этого ты полюбил руби с возможностью сделать один шаг тысячью способами?

писанием справо-налево


писал справа-налево с использованием tab'ов?))

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

пайтон убил...писанием справо-налево

Это про лист компрехеншинз & Co, чо ль? Дык, не они (в смысле, не Гвидо & Co) это придумали :) Но конструкция такая... да... Ничем не лучше @$_->[$`]. Особенно, когда навёрнута в три этажа :)

p.s. перлолюбителям: я в курсе про use English; не надо.

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

> Это тот же руби. Показывает проблему без циклов. Замыкание делается не на значение, а на символ в конкретной области видимости. Как заметил tailgunner, это присуще многим языкам (большинству?).

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

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

> Неосилятор что ли?

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

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

У тебя всегда такая примитивная защитная реакция?

anonymous
()

Идиосинкразии тред :)

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

вся проблема в том, как реализованы циклы

Проблема не в циклах, а в общих правилах видимости.

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

blocks.each do | it |
    it.call
end
geekless ★★
()
Ответ на: комментарий от anonymous

> А как же пример без циклов?

А пример без циклов работает как, как он и должен везде работать. Проблема именно в семантике циклов.

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