Rails 0.10.0

номер версии программы доверия не внушает

Прошлая версия была 0.9.5 :)

WEB приложение для коллективного написания книг написанное на базе Rails.Hieraki
Демонстрацию можно увидеть здесь http://demo.hieraki.org/

"Приезжай ко мне на БАМ я тебе на rails дам" - НАРОДНЫЙ ФОЛЬКЛЕР. :))))

ты просто мало опенсорс софта видел. вот взять к примеру transcode. или mplayer. или mozilla... можно бесконечно продолжать.

Почему? Или можно только с 1.0.0?

Реально клёвый фреймворк,
Один ORM (ActiveRecord) из набора чего только стоит.

сорри за оффтопик, но объясните человеку который плохо знает руби но хорошо знает питон - в чём преимущества руби ?

интересуют и функциональные и лицензионные и опыт развития - если есть профи, поделитесь плиз !

> сорри за оффтопик, но объясните человеку который плохо знает руби но хорошо знает питон - в чём преимущества руби ?

Более мощные языковые конструкции. Например, в ruby есть полноценные closures, причем они
активно используются в стандартной библиотеке. Скажем, получить массив квадратов можно так:

  squares = (1..10).collect {|i| i*i}

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

  File.open("foo.bar") do |file|
    file.each {|line| print line.upcase}
  end

Аналогичным образом отрабатываются соединения с БД, транзакции etc.

Прочие приятные языковые фичи: модули и mixin, компенсирующие отсутствие множественного наследования;
полноценное скрытие данных (в отличие от питона, где с полями объекта может работать кто угодно);
более удобный перловый синтаксис для регэкспов; более "чистая" объектная модель (без необходимости
явно объявлять self, отсутсвия __ в именах функций и т.п. питоновским хакам).



 

  

Да нету преимуществ.
perl, ruby, python, tcl - равнозначные языки, имхо. Тут уже дело привычки и религии

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

> а как дело обстоит с эффективностью реализации в плане скорости исполнения, сабж тут с перлом может тягаться?

Смотря в чем. Работа со строками вроде бы по скорости соответствует. Как числодробилка - нет. ООП - быстрее чем в перле. В целом - скорее нет, чем да.

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

Можно, причем их намного легче писать - см. http://www.rubycentral.com/book/ext_ruby.html

хороший бук "Programming Ruby: The Pragmatic Programmer's Guide" - добавил в закладки :)

реальный конкурент питона, только пока на порядок (те в ~10 раз менее популярный) если судить по чилу проектов http://sourceforge.net/softwaremap/trove_list.php?form_cat=160

полезный тул вот имеется - Ruby плагин для Eclipse platform

http://rubyeclipse.sourceforge.net/

> Features supported are syntax highlighting, on the fly syntax check, graphical outline, Test::Unit view/runner, Ruby application launching, content assist, source formatter, and a Ruby debugger. A regular expression plugin is also available (Thanks to the EPIC project).

> реальный конкурент питона

Не совсем; разве что в том же смысле, что питон - конкурент тикля =) Идеология у них разная...

> (те в ~10 раз менее популярный) если судить по чилу проектов http://sourceforge.net/softwaremap/trove_list.php?form_cat=160

Есть более простой критерий популярности (он же один из основных критериев выбора) - наличие библиотек. Вот с этим у ruby пока не особо хорошо - до питона и тем более CPAN еще далеко.

Еще там юникод кривовато сделан. Он в принципе есть (в виде UTF-8), но сделан непрозрачно - нужно подключать модуль jcode, после чего пользоваться объявленными в нем Unicode-specific методами (типа String#jlength для длины).

более простой критерий тогда тоже должен давать цифру на выходе, иначе он не простой количественный, а качественный и оценочный :)

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

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

Когда я был совсем молодым и зелёным, я тоже тянулся к девушкам, с которыми "по-проще".

> более простой критерий тогда тоже должен давать цифру на выходе, иначе он не простой количественный, а качественный и оценочный :)

Количество либ тоже можно посчитать =)

> именно наличие CPAN-а да еще вкупе с замечательной производительностью делают позиции перла такими прочными

Имхо скорость в таких языках не принципиальна. Было бы оно быстрее sh, и ладно =) Все равно все time-critical на C писать...

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

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

А что Перл 6 уже вышел? Насколько я знаю он уже 3 года в разработке и конца пока не видно.

> А что Перл 6 уже вышел? Насколько я знаю он уже 3 года в разработке и конца пока не видно.

Нет, но Ларри регулярно выкладывает отчеты о своих жестоких экспериментах над несчастным верблюдом - http://dev.perl.org/perl6/apocalypse/

При всем уважении к Ларри - лучше бы он выложил дату (хотя бы приблизительную), когда закончаться эксперименты :-) и нарисуется собственной персоной Перл6. Помниться года два назад я был уверен, что - вот вот, еще немного и вуаля! Ан нет...

Насчет библиотек - посмотрите на JPython или Boo или Groovy. Есть все что нужно.

Кто знает есть аналог Ruby под .NET (MS/Mono)?

> Насчет библиотек - посмотрите на JPython

Который все еще отражает Python 2.1 (при том что главная ветка - 2.4, и изменений за это время накопилось ой как немало)... нет уж, спасибо.

> Кто знает есть аналог Ruby под .NET (MS/Mono)?

Вот нечто в гугле вылезло:

http://www.saltypickle.com/RubyDotNet

Вроде бы это не генерация кода под .NET, но позволяет с ним работать - т.е. полный доступ к BCL и всяким там WinForms обеспечен.

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

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

>Скажем, получить массив квадратов можно так: squares = (1..10).collect {|i| i*i}

мне кажется что на питоне это красивее получается:
[x*x for x in range(1,10)]


>в то время как в питоне есть только убогая lambda.

помимо "убогой" лямбды в питоне есть много интересных функций (filter, reduce), но как правило лучше применять lists comprehension которые смотрятся читаются очень даже понятно


>File.open("foo.bar") do |file|
> file.each {|line| print line.upcase}
> end

на мой взгляд на питоне более удобочитаемо:
for i in [line.upper() for line in open('foo.bar').readlines()
]: print i


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

self.__name


>mixin, компенсирующие отсутствие множественного наследования

есть огромный класс задач где требуется полноценное множественное наследование - в руби реально меньше работы с миксинами вместо class Apple(Fruit, Green, Sweet, South) ?

>более "чистая" объектная модель
это может быть

///
вы не могли бы ещё ответить как в руби с отладкой ? как с лицензией ?

A чего нибудь типа Zope есть для Ruby ?

> Мне кажется что на питоне это красивее получается:

> [x*x for x in range(1,10)]

Это действительно хорошо, хотя мне больше нравится синтаксис хаскеля =) Но list comprehensions - это частный случай, решение _одной_ проблемы. Это не полноценная замена closures (так же, как и lambda).

> помимо "убогой" лямбды в питоне есть много интересных функций (filter, reduce)

В ruby аналогично. А убогость lambda заключается в том, что в нее нельзя: 1) запихать несколько выражений, 2) запихать условный оператор без написания функции-обертки.

> на мой взгляд на питоне более удобочитаемо

Ты не просек фишку =) В питоне, for..in и list comprehensions - это _встроенные_ в язык средства. Они не расширяемы. В ruby, each - это _метод_. Ты сам можешь написать такой же. Т.е. имеем возможность расширять конструкции языка.

> self.__name

См. доки. Это грязные хак, ибо про это можно просто не знать, или можно не пользоваться, в то время как ruby _заставляет_ прятать данные); да и сама реализация - просто прикрутить имя класса в качестве префикса - попахивает чуть ли не сишным препроцессором...

> есть огромный класс задач где требуется полноценное множественное наследование - в руби реально меньше работы с миксинами вместо class Apple(Fruit, Green, Sweet, South) ?

В силу того, что в ruby (как и в питоне) используется ad-hoc полиморфизм, mixins в принципе могут реализовать все, что можно сделать через MI. Причем синтаксис там тоже будет не сильно нагруженный. Другой вопрос - а ты реально часто MI применяешь в продакшен коде? Как-то кроме Eiffel (где оно очень тщательно продумано) я его особо не видел нигде...

> вы не могли бы ещё ответить как в руби с отладкой ?

Есть =)

> как с лицензией ?

http://www.ruby-lang.org/en/LICENSE.txt

В двух словах: не GPL.

И вообще, чем тут постить вопросы, проще сходить почитать FAQ (http://www.rubygarden.org/faq/dispatch.cgi?controller=main&action=index) и книгу (http://www.rubycentral.com/book/index.html), хотя бы поверхностно. А потом уже делать выводы.

> A чего нибудь типа Zope есть для Ruby ?

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

>A чего нибудь типа Zope есть для Ruby ?

А о чём по-твоему новость?

Так на питоне дофига разных веб фреймворк только до функйиональности Zope никто не дорос - вот и вопрос о Rails - с чем это можно сравнить ( в смысле веб аапл на питоне)

язык интересный, но бенчмарки не радуют http://shootout.alioth.debian.org/

> язык интересный, но бенчмарки не радуют http://shootout.alioth.debian.org/

Здесь надо отметить, что автор вовсю работает над новой версией языка (и, соответственно, интерпретатора), которая обещает исправить все существующие недостатки (тот же юникод), в том числе и скорость

у крутого OO руби вызов методов обьектов идет на уровне перла, в котором OO прикручено как неродное http://shootout.alioth.debian.org/benchmark.php?test=methcall&lang=all&am...

создание обьектов где то между питоном и перлом - тоже позорно для 100% обьектного языка http://shootout.alioth.debian.org/benchmark.php?test=objinst&lang=all&...

в регулярных выражениях Ruby обошел даже PHP, только тормоз Tcl и калека C# Mono имеют худшие результаты, зато Perl молодцом - даже C gcc натянул :) http://shootout.alioth.debian.org/benchmark.php?test=regexmatch&lang=all&...

при генерации случайных дробных чисел перл впереди скриптовой братии, питон тоже молодцом, а несчастный Руби опять в обнимку с Tсl и PHP ползает .. бедный Руби http://shootout.alioth.debian.org/benchmark.php?test=random&lang=all&...

смотрим рекурсии - опять Руби внизу болтается вместе с Tcl/PHP, зато Python молодцом - даже перл уделал в полтора раза http://shootout.alioth.debian.org/benchmark.php?test=fibo&lang=all&so...

крутим матрицы - тут руби просто избивают ногами ВСЕ, разница с питоном/перлом в 3-4(!) раза http://shootout.alioth.debian.org/benchmark.php?test=matrix&lang=all&...

читаем, парсим текст, суммируем целые числа - актуальный для веба тест, тут Руби опять позорится вместе с C# Mono/Tcl/PHP, а вот Perl/Python уже работают вплотную с компилируемыми языками и джавой, обходя Руби в 3(!) раза http://shootout.alioth.debian.org/benchmark.php?test=sumcol&lang=all&...

мда ..

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

зато Python неожиданно хорошо себя показал, честно говоря я думал о нем хуже или просто смотрел старые бенчи.. а открытием оказался Eiffel - очень солидно держится, даже рядом с gcc/Intel С/C++

> впрочем я не драматизирую - скорость можно интеграцией с C наверстать

О чем и речь =)

> а открытием оказался Eiffel - очень солидно держится, даже рядом с gcc/Intel С/C++

А почему бы ему и не держаться? Там же компилятор, причем он генерит сишный код, так что все стандартные оптимизации сишного компилятора применимы =) Сверх того, там очень строгая типизация, т.е. опять же простор для оптимизатора, и есть возможность пихать объекты напрямую на стек (expanded class).

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

Eiffel надо будет при случае рассмотреть поближе, к тому же лучший компилятор для него SmartEiffel идет под GNU