ruby vs python vs perl

Т.е. по существу претензий нет? Отлично.

Если ровесник динозавров perl так хорош, то почему на нём так никто и не сделал библиотеки для анализа и визуализации данных, типа numpy/scipy/matplotlib?

PDL

http://habrahabr.ru/post/143127/ альтернатива и можно запросто реализовать с помощью - мягко говоря, разные вещи (к тому же я полагал речь идет о декораторах специфичного назначения). И что, можно подумать, кто-то этим стал пользоваться..

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

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

а зачем придумали все эти модные ruby и python-ы, раз уже есть прекрасный perl?

Руби более практичен.

какие альтернативы декораторам в руби?

Более мощной альтернативой являются блоки.

Более мощной альтернативой являются блоки.

Это с передачей данных с yield? Или есть еще какая магия? Твою статью с хабра завтра прочту - сейчас сонный я.

P.S. Что-то гугл не пашет, ни почта, ни ридер к тому же. Это только у меня проблемы?

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

пс
гугл работает.

Во-первых, когда руби появлялся, перл не был таким

Современный перл (perl5) появился практически одновременно с руби. Правда руби тогда не был таким как сейчас и, в значительной степени, был основан на возможностях перла. Возможно, если бы perl5 появился на пару лет раньше и к 1995 году были бы накоплены всякие плюшки типа Moose, то Мацумото и не взялся бы за руби, а пилил бы перл в этом направлении.

Во-вторых перл похож только внешне

Я бы сказал это руби похож на перл, т.к. автор руби брал возможности перла как образец. Чего он и сам не скрывает: Then, I reorganized the features in Perl into class library, and implemented them. I posted Ruby 0.95 to the Japanese domestic newsgroups in Dec. 1995.

Куда более интересный вопрос, нафига надо было закашивать перл под руби, когда уже был руби (раз уж речь зашла о целесообразности).

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

руби содержит огромное количество инструментов делающих разработку удобной и эффективной

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

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

А за пивом не бегает? Вы тут приводили пример создания простого класса. Что-то я там не увидел как автоматически создаются аксессоры для полей. Или вы какие-то другие задачи имеете в виду?

А то что руби повлиял на программирование в целом - да, это так

На программирование в целом повлияли Fortran, Lisp, Algol, C, Smaltalk, и да, Perl который своим появлением и развитием повлиял на становление скриптовых языков общего назначения как таковых.

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

Возможно, если бы perl5 появился на пару лет раньше и к 1995 году были бы накоплены всякие плюшки типа Moose.

Что-то ты совсем фантазируешь. Moose появился в 2006 г, а Ruby on Rails, до появления которого на руби никто особо не смотрел, появился в 2004. С тех самых пор, перл, да и не только перл, стали закашивать под руби. И тут неплохо бы задаться вопросом, а нужно ли это было в 2006-то году..

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

Или вы какие-то другие задачи имеете в виду?

В первую очередь установку различных версий библиотек и интерпретаторов руби, автоматическое разрешение зависимостей, наличие утилит типа thor, rake, rspec, документирующих утилит типа yard, rdoc и т.д. Это признаю даже заклятые питонщики: «детский сад, хорошо автоматизированный инструментами вроде bundler». Ситуация уже на столько отличается от других платформ, что рубистами их проблемы просто не воспринимаются.

Moose появился в 2006 г, а Ruby on Rails, до появления которого на руби никто особо не смотрел, появился в 2004. С тех самых пор, перл, да и не только перл, стали закашивать под руби.

Не будьте голословны (как обычно) — что перенял Perl из Ruby, начиная с 5.8 версии (благо, этот период развития Perl я наблюдал)? Тут как раз ситуация обратная (что печально) — разработчики perl живут в своём розовом мире и редко смотрят по сторонам, что не есть благо (это, зачастую, компенсируется писателями модулей).

Если вы имеете ввиду coroutines и take/gather разные, то Ruby отнюдь не первый, кто их ввёл (далеко, далеко не первый).

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

perlbrew, cpanplus, pip.

документирующих утилит

pod2html, Doxygen::Filter::Perl, naturaldocs.

Если я что-то упустил — говори — будем работать над этим :)

Что-то ты совсем фантазируешь. Moose появился в 2006 г, а Ruby on Rails, до появления которого на руби никто особо не смотрел, появился в 2004.

Я понимаю почему некоторым сложно читать программы на перле - они и родной язык читают с трудом. Что во фразе «Если... к 1995 были БЫ... плюшки Moose» вам не понятно? Основная претензия к перлу была в этом - нет ООП.

С тех самых пор, перл, да и не только перл, стали закашивать под руби. И тут неплохо бы задаться вопросом, а нужно ли это было в 2006-то году...

А нужен ли был руби в 95 году когда есть smalltalk с 80 года?

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

Там речь идет о том, о чем идет. Мацумото не нравился перл т.к. он не имел поддержку ООП и модулей в те времена, но функциональность-то нужно было откуда-то стащить чтобы не велосипедить.

ну как еще объяснить программисту на java, что руби на java не похож

А вы таки думаете, что java-программисты дебилы? Смотря по их зарплатам, я бы так не сказал.

В первую очередь установку различных версий библиотек и интерпретаторов руби, автоматическое разрешение зависимостей, наличие утилит типа thor, rake, rspec, документирующих утилит типа yard, rdoc и т.д.

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

Для этого есть perlbrew и cpanm

утилит типа thor, rake, rspec,

Cpan::App, MakeMaker, Test::More - горы подобной дребедени на CPAN

документирующих утилит типа yard, rdoc и т.д.

pod и иже с ним, App::Perlanalyst, Doxygen::Filter::perl, Devel::Cover, Perl::Critic и т.п. для статического анализа кода

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

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

Это признаю даже заклятые питонщики: «детский сад, хорошо автоматизированный инструментами вроде bundler

Боюсь, что вы не уловили в этой фразе сарказма.

Если вы имеете ввиду coroutines и take/gather разные, то Ruby отнюдь не первый, кто их ввёл (далеко, далеко не первый).

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

perlbrew, cpanplus, pip

Про pip у меня уже были здесь беседы, разглядывали его, если коротко - сильно недотягивает до gem. Но даже большая проблема в том, что им просто не принято пользоваться, точно так же как у рубистов не принято без gem обходиться. Полагаю остальные инструменты так же сильно не дотягивают до их аналогов на руби. Да и показ инструментов, стоило бы начать с аналога bundler. Я прекрасно понимаю, что утилиты документирования и пр. вещи придуманы первыми не для руби, и в др. языках они есть, просто _сейчас_ _реализация_ для руби объективно лучше (и даже имеет место быть некий системный подход, когда все объединено, яркий пример rubygems.org), а следовательно, использование руби более практично.

Если... к 1995 были БЫ... плюшки Moose

Ахах) а что же не сразу к 85?) Ок, тогда бы я, наверное, программировал не перле (не опоздай они на 11 лет).

Основная претензия к перлу была в этом - нет ООП.

У меня нет претензий к перлу.

Но даже большая проблема в том, что им просто не принято пользоваться

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

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

вещи придуманы первыми не для руби, и в др. языках они есть, просто _сейчас_ _реализация_ для руби объективно лучше

И чем лучше? Что, работает в 10 раз быстрее, или нужно писать в 10 раз меньше?

и даже имеет место быть некий системный подход, когда все объединено, яркий пример rubygems.org

Системный подход, это когда я ставлю модуль с помощью apt-get и использую его во всех программах в системе. А когда каждая программа тянет себе одни и те же модули с rubygems, то это какой-то каменный век.

Ахах) а что же не сразу к 85?)

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

У меня нет претензий к перлу.

Ну так вы и не Мацумото.

большинство необходимых модулей в любом дистрибутиве есть из коробки

Что за необходимые модули ^_-. Ты понимаешь, что на перле нельзя написать раилс, потому что в перле нет gem и bundler, т.к. в раилс сейчас используется ~90+ библиотек на разных стадиях разработки, а твое «большинство необходимых модулей» - наивный детский лепет. Когда у тебя возникнет необходимость управлять большим количеством зависимостей, то внезапно не окажется инструмента. Потому др. ЯП не имеют такого количества библиотек и не могут ими управлять, а это накладывает серьезный отпечаток на архитектуру проектов, уменьшая модульность. Из-за неспособности (нежелания, или я не знаю чего) разработать нормальные инструменты разработки, обеспечивающие модульность, отладку, документацию и доступ к библиотекам ограничиваются потенциальные возможности ЯП, а их адепты только ноют о том, что все библиотеки должны идти в дистрибутиве, и как трудно их устанавливать, если их там внезапно не оказалось.

Ты понимаешь, что на перле нельзя написать раилс, потому что в перле нет gem и bundler, т.к. в раилс сейчас используется ~90+ библиотек на разных стадиях разработки

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

В перле не нужны рельсы в таком виде, потому что в перле есть отдельно mojo, отдельно DBI, даже Moose и тот отдельно.

Потому др. ЯП не имеют такого количества библиотек и не могут ими управлять

Вот же наивная простота. Сколько там говоришь гемов у руби?

Displaying Rubygem 1 - 30 of 3283 in total

А сколько модулей в CPAN

(CPAN) currently has 117,235 Perl modules in 26,783 distributions

И нечего, все управляется отлично и через apt-get и через cpanm, кому нужно.

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

Даже если чего-то в дистрибутиве нет, то cpanm все установит, включая зависимости. Не вижу проблемы.

Ты понимаешь, что на перле нельзя написать раилс, потому что в перле нет gem и bundler, т.к. в раилс сейчас используется ~90+ библиотек на разных стадиях разработки, а твое «большинство необходимых модулей» - наивный детский лепет.

Почему нельзя на перле написать подобие рельсов? Есть хороший пример - Mojolicious. Этот фреймворк написан только средствами батарейки перла. Сторонние модули часто тянут за собой зависимости из CPAN, которые успешно разрешаются.

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

:)

Сторонние модули часто тянут за собой зависимости из CPAN, которые успешно разрешаются.

Если все так, то это хорошо.

Очень даже хорошо. 6 лет пишу на перле промышленные решения, и знаю плюсы/минусы платформы, и эта платформа мне нравится.

Но тогда получается существует некий аналог gemfile в проекте?

Решение зависит от проекта. Встречались проекты с подобием gemfile. Сейчас проект очень специфический, и в тестовом наборе (интеграционной его части) есть скрипт, проверяющий наличие модулей определенных версий. Нужен этот скрипт только на время миграций, которые случаются раз в несколько лет. Активно (но без фанатизма) используются модули из CPAN, т.к. стараемся избегать велосипедов.

Наверное вы хотели что-то возразить, но не смогли.

а зачем придумали все эти модные ruby и python-ы, раз уже есть прекрасный perl?

Вот и я о том же.

Некропостер.

а зачем придумали все эти модные ruby и python-ы, раз уже есть прекрасный perl?

Если ты до сих пор задаёшь такие вопросы, ответ ты всё равно не поймёшь. Вот для сравнения:

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

а зачем придумали все эти модные андроиды и iOS, раз уже есть замечательные сименсы A60?

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

а затем, что прогресс. Есть нечто, есть кто-то, кого не устраивают недостатки этого нечта и он делает нечто новое, избавленное от недостатков.

До этого писал только небольшие однострочники ...... не увидел каких-то принципиальных отличий от Ruby

Плохо смотрел.

(CPAN) currently has 117,235 Perl modules in 26,783 distributions

Ага. А в дебиане 30 000 пакетов вот. А в линуксе есть всего 150-200 программ, которые и составляют 99.999 % каждого линуксового десктопа. Что остальные 29800 тысяч собой представляют - неизвестно, но хвастаться можно :)

Сударь, почините свою криокамеру.