Вышел Ruby 1.8.7

>>> Гг. А на Питоне и долгоживущие программы пишут :D

>> Ты не поверишь, но "долгоживущие" программы пишут и на [...]

>Это не вопрос "веры" o_O знаю, пишутся, и что? Каким образом это делает Руби лучше?

А ты докажи обратное: каким образом это делается на Python-е лучше?

Пока есть только следствие того, что на Западе Python стал распространеннее гораздо раньше, чем Ruby. Поэтому на Python-е просто написано больше кода о котором известно. Но это вовсе не следствие того, что Python лучше.

> можно ли заменять метод не всего класса, а только одного объекта?

Да.

2eao197 (*) (03.06.2008 0:26:43):

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

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

А я, например, удивлён, почему в Ruby такой убогий механизм импорта
модулей в сравнении с Python, и отсутствует такая полезнейшая вещь,
как list comprehensions. Так что теперь?

>> можно ли заменять метод не всего класса, а только одного объекта?

> Да.

Если вопрос про питон был - то не знаю ))

2eao197 (*) (03.06.2008 0:30:19):

> Пока есть только следствие того, что на Западе Python стал
> распространеннее гораздо раньше, чем Ruby.

Это верно.

> Поэтому на Python-е просто написано больше кода о котором известно.
> Но это вовсе не следствие того, что Python лучше.

Не совсем поэтому. Потому что Python, действительно, лучше.
Это язык более высокого уровня, чем Ruby и лучше масштабируемый.
Возьмите хотя бы web frameworks для Ruby и Python. Пока на Ruby рожали
Ruby on Rails, который дышал в значительной степени благодаря мощной
маркетинговой компании, на Python сделали сразу несколько достойных
frameworks вроде Django, TurboGears, Pylons, в которых не было
подобного вливания денег, и которые тем не менее получились лучше,
ну во всяком случае быстрее, тот же Django, например.

Тот же Twisted. Если Ruby такой супер-дупер крутой язык, что мешает
сделать Twisted аналог? На Ruby, кстати, Twisted вышел бы куда
естественней с вашими любимыми блоками. Так где же он?

Mercurial? Есть желание написать подобное на Ruby или нет?

>> Вместо лямбды можно поставить имя функции.

> А пример можно?

Ы. Можно, конечно:

def over_foo(a): print a, "overridden foo"

class A:
        def foo(self): print self, "native foo"

a1 = A()
a2 = A()

a1.foo()
a2.foo()

native_foo = A.foo
A.foo = over_foo

a1.foo()
a2.foo()

Вывод:

<__main__.A instance at 0xb7f11f0c> native foo
<__main__.A instance at 0xb7f11d0c> native foo
<__main__.A instance at 0xb7f11f0c> overridden foo
<__main__.A instance at 0xb7f11d0c> overridden foo

> И можно ли заменять метод не всего класса, а только одного объекта?

Евгений, ваши намерения меня, блин, пугают o_O
Да, можно:


A.foo = native_foo

print
# способ 1, идеологически неверный
a2.foo = lambda: over_foo(a2)
a1.foo()
a2.foo()

# способ 2, совсем уж некошерный
a2.foo.im_func = over_foo
a1.foo()
a2.foo()

# способ 3, кошерный чуть менее, чем полностью
A.fff = over_foo # здесь происходит магия
a2.foo = a2.fff
a1.foo()
a2.foo()

Вывод:

<__main__.A instance at 0xb7f11f0c> native foo
<__main__.A instance at 0xb7f11d0c> overridden foo
<__main__.A instance at 0xb7f11f0c> native foo
<__main__.A instance at 0xb7f11d0c> overridden foo
<__main__.A instance at 0xb7f11f0c> native foo
<__main__.A instance at 0xb7f11d0c> overridden foo

>>> Ты не поверишь, но "долгоживущие" программы пишут и на [...]

>> Это не вопрос "веры" o_O знаю, пишутся, и что? Каким образом это делает Руби лучше?

> А ты докажи обратное: каким образом это делается на Python-е лучше?

Ы? Я ничуть не против Руби (я даже вижу его преимущества перед Питоном, но стратежно молчу о них - они не решающие). Проблема в том, что мне нужны ответы человека, одинаково хорошо владеющего и Руби, и Питоном. Похоже, нет такого в нашем треде :/

А слышать от сторонника Руби то, что Руби подходит только для одноразовых скриптов, прикольно :) На Питоне действительно пишут долгоживущие _программы_ - тот же Mercurial, которым я пользуюсь.

Ну что, подытожим, почему надо переходить с Ruby на Python?

1. Перегруженный синтаксис, тяжёлое наследие Perl.
(Уже начали избавляться, радует. Посмотрим, к чему приведёт.)

2. Тормознутая реализация интерпретатора Ruby. (Тоже начали
избавляться от этой болезни)

3. Отсутствие стандарта на язык. (Воз и ныне там)

4. Бедноватая и незрелая стандартная библиотека. К тому же плохо
документированная. (Улучшается, растёт малыш Ruby)

5. Плохая масштабируемость кода в силу "фокусов", которые можно
вытворять с классами и модулями. (фундаметальная особенность, которая,
похоже, загнала Ruby навсегда в нишу языков для мелких скриптов и
небольших проектов).

Что ещё? Ну вот, кстати, общеизвестный баг в реализации regexps на
Ruby. Позорище какое. Вот вам и синтаксическая конструкция,
языковая особенность Ruby, казалось бы. Однако, в Perl и Python
всё в порядке, только в Ruby 1.8 криво.

Резюмируя: у кого есть желание ждать взросления Ruby, ради бога,
кому же надо сейчас писать серьёзные вещи, то лучше Python.

> "фокусов", которые можно вытворять с классами и модулями

Ну, это несправедливо. В Питоне тоже можно напридумывать килограммы фокусов.

2tailgunner ** (*) (03.06.2008 1:41:40):

>> "фокусов", которые можно вытворять с классами и модулями

> Ну, это несправедливо. В Питоне тоже можно напридумывать килограммы фокусов.

Везде можно, но в Ruby они blessed. It's the way to go in that language.
Скажем, где проще изменить фундаметальное поведение стандартных классов,
в Ruby или Python? А потом трахаться, бегать по всему проекту и удивляться,
почему вдруг стандартный класс даёт такие неожиданные результаты.

2tailgunner ** (*) (03.06.2008 1:41:40):

>> "фокусов", которые можно вытворять с классами и модулями

> Ну, это несправедливо. В Питоне тоже можно напридумывать килограммы фокусов.

Вот, очень подробно написано небезызвестным Alex Martelli:

http://groups.google.com/group/comp.lang.python/msg/28422d707512283

> if I was computing the minimum spanning tree among just about any set of languages, I'm pretty sure Python and Ruby would be the first two leaves to coalesce into an intermediate node:-).

Отлично сказано :) Двачую, как говорится :D

Но то, что он рассказывает о динамичности Руби, просто пугает o_O

2tailgunner ** (*) (03.06.2008 2:08:20):

> Отлично сказано :) Двачую, как говорится :D

Да, ну он довольно вменяемый взрослый дяденька :-)

> Но то, что он рассказывает о динамичности Руби, просто пугает o_O

Ага, о том и речь :-)

>> Поэтому на Python-е просто написано больше кода о котором известно.
>> Но это вовсе не следствие того, что Python лучше.

>Не совсем поэтому. Потому что Python, действительно, лучше.
>Это язык более высокого уровня, чем Ruby и лучше масштабируемый.
>Возьмите хотя бы web frameworks для Ruby и Python. Пока на Ruby рожали
>Ruby on Rails, который дышал в значительной степени благодаря мощной
>маркетинговой компании,

Примеры этой маркетинговой компании очень хотелось бы увидеть.

> на Python сделали сразу несколько достойных
> frameworks вроде Django, TurboGears, Pylons, в которых не было
> подобного вливания денег, и которые тем не менее получились лучше,
> ну во всяком случае быстрее, тот же Django, например.

До RubyOnRails для Ruby были Web-фреймворки, например iowa. И после RoR создаются. Те же Merb и Nitro.

А вот информацию о вливании денег в RoR, благодоря которым он стал популярным, надо бы подтвердить.

> Тот же Twisted. Если Ruby такой супер-дупер крутой язык, что мешает
> сделать Twisted аналог? На Ruby, кстати, Twisted вышел бы куда
> естественней с вашими любимыми блоками. Так где же он?

Не знаю, чем Twisted так крут, но в Ruby есть разные штуки, вроде net и open-uri.

> Mercurial? Есть желание написать подобное на Ruby или нет?

Мне хватило такой фигни, как SCons, чтобы не связываться с Python-ом вообще.

>> А пример можно?

>Ы. Можно, конечно:

>def over_foo(a): print a, "overridden foo"

А вот этот over_foo -- это чей метод? Или это свободная функция,
которая ни к чему не привязана?

>Евгений, ваши намерения меня, блин, пугают o_O

Это удобный способ реализации т.н. once методов, когда метод один
раз должен что-нибудь высчитать, а затем возвращать именно это
значение.

>Да, можно:

Так я не понял, это все стандартные способы переопределения
метода или таки некошерные?
И можно ли заменить метод внутри самого метода. Например, в Ruby:

class A
  def demo
    puts "hello"
    def self.demo
      puts "bye"
    end
  end
end

a = A.new
a.demo   # => hello
a.demo   # => bye

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

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

И наконец вопрос, почему же решения на питоне выглядят ну просто не плохо, а на руби сереьзные вещи это уже вполне себе DSL, которые не стыдно показать. Хотя я подозреваю что и на питоне так можно писать. Так почему же не пишут?

К руби у меня одна претензия - на кой хрен у него есть классы, если все равно это объекты. Сделали б уже его ООС прототипно-ориентированной, т.е. по типу Self, а не Smalltalk.

> А слышать от сторонника Руби то, что Руби подходит только для одноразовых скриптов, прикольно :)

Сколько людей, столько и мнений. Да и не я это говорил.

> На Питоне действительно пишут долгоживущие _программы_ - тот же Mercurial, которым я пользуюсь.

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

Такое мнение будет учитываться?

> 5. Плохая масштабируемость кода в силу "фокусов", которые можно > вытворять с классами и модулями. (фундаметальная особенность, которая, > похоже, загнала Ruby навсегда в нишу языков для мелких скриптов и > небольших проектов).

Можно ли узнать, с проектами какого объема на Python-е лично вам приходилось иметь дело (в смысле участвовать в разработке)?

>def over_foo(a): print a, "overridden foo"

А вот этот over_foo -- это чей метод? Или это свободная функция, которая ни к чему не привязана?

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

В Питоне методов, можно сказать, нет (они создаются из функций "на ходу", как в присваивании fff в способе 3).

>>Евгений, ваши намерения меня, блин, пугают o_O

>Это удобный способ реализации т.н. once методов, когда метод один раз должен что-нибудь высчитать, а затем возвращать именно это значение.

Это называется memoization, в Питоне делается с помощью декоратора. Кстати, есть ли в Руби декораторы?

> Так я не понял, это все стандартные способы переопределения метода или таки некошерные?

Способы 1 и 3 - абсолютно стандартные, насчет способа 2 - не до конца уверен, что присваивание атрибутам метода одобряется :)

> И можно ли заменить метод внутри самого метода.

Конечно. self.foo = blahbla

>> А вот этот over_foo -- это чей метод? Или это свободная функция, которая ни к чему не привязана?

> Свободная функция. Впрочем, здесь на месте over_foo мог быть и метод.

Ну, собственно, вот и одно из отличий. В Ruby нет свободных функции. Даже когда в программе написано:

def f; puts "hello"; end

то это определяется метод объекта, который сейчас является контекстом. Соответственно, после этого можно написать его вызов через self:

self.f

> Это называется memoization, в Питоне делается с помощью декоратора. Кстати, есть ли в Руби декораторы?

Если ты мне на пальцах объяснишь, что это, то я расскажу.

> В Питоне методов, можно сказать, нет (они создаются из функций "на ходу", как в присваивании fff в способе 3).

Я что-то не понял, если написано:

a.search = some_search_method

то как по коду понять, создается ли это новый метод в объекте a или устанавливается значение атрибута search?

Для memoization в Ruby даже специальные библиотеки были сделаны (http://raa.ruby-lang.org/project/memoize/). Но, если тебе нужен один once-метод на проект, тянуть для него внешнюю библиотеку не очень разумно, имхо.

>> Это называется memoization, в Питоне делается с помощью декоратора. Кстати, есть ли в Руби декораторы?

> Если ты мне на пальцах объяснишь, что это, то я расскажу. 

Запись:

@decoratorfn
def foo():
    # ....

Означает, что транслятор при обработке этого определения вызовет 
функцию (callable в общем случае) decoratorfn, передав ей функцию foo 
как аргумент, и то, что вернула decoratorfn, будет сохранено под 
именем foo. Короче говоря, декоратор - такое средство 
метапрограммирования, срабатывающее во время компиляции (как и 
положено приличному средству метапрограммирования :)).

>> В Питоне методов, можно сказать, нет (они создаются из функций "на 
>> ходу", как в присваивании fff в способе 3).

>Я что-то не понял, если написано:

>a.search = some_search_method

>то как по коду понять, создается ли это новый метод в объекте a или 
> устанавливается значение атрибута search? 

Установка атрибута search объекта a происходит в любом случае; если a 
является значением типа "класс", то, если значение some_search_method 
является функцией, она преобразуется в unbound method и присваивается 
search (и при вызове search на любом объекте этого класса будет 
вызываться some_search_method). Если же a - это экземпляр, то его 
атрибуту a присваивается значение some_search_method, без 
преобразования.

>И наконец вопрос, почему же решения на питоне выглядят ну просто не плохо, а на руби сереьзные вещи это уже вполне себе DSL, которые не стыдно показать. Хотя я подозреваю что и на питоне так можно писать. Так почему же не пишут?

Посмотрите на DSL в Django

И кстати, все эти "а как, а почему", говорят о том, что одни не знают питон, другие руби, но при этом что-то пытаются кому-то доказать. Бред.

>> Если ты мне на пальцах объяснишь, что это, то я расскажу. 

>Запись:

>@decoratorfn
>def foo():
    # ....

>Означает, что транслятор при обработке этого определения вызовет 
>функцию (callable в общем случае) decoratorfn, передав ей функцию foo 
>как аргумент, и то, что вернула decoratorfn, будет сохранено под 
>именем foo. Короче говоря, декоратор - такое средство 
>метапрограммирования, срабатывающее во время компиляции (как и 
>положено приличному средству метапрограммирования :)).

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

class Demo
  def foo; ...; end
  call_once :foo
end

Здесь call_once -- это статический метод класса, который вызывается
с передачей имени метода foo. Этот метод выполняет какие-то действия
и заменяет foo другим методом.

>>то как по коду понять, создается ли это новый метод в объекте a или 
>> устанавливается значение атрибута search? 

>Установка атрибута search объекта a происходит в любом случае; если a 
>является значением типа "класс", то, если значение some_search_method 
>является функцией, она преобразуется в unbound method и присваивается 
>search (и при вызове search на любом объекте этого класса будет 
>вызываться some_search_method). Если же a - это экземпляр, то его 
>атрибуту a присваивается значение some_search_method, без 
преобразования.

Ну теперь понятно, почему Python-исты так ругают динамическое изменение
классов/объектов -- по коду хрен разберешься, что происходит.
Тогда как в Ruby это наглядно выделено синтаксисом языка.

> В Ruby тело класса -- это обычный код, который может содержать любые инструкции (в том числе if-ы и циклы)

В Питоне - тоже :D

> Ну теперь понятно, почему Python-исты так ругают динамическое изменение классов/объектов -- по коду хрен разберешься, что происходит

Если поставить себе цель запутать читающего код - конечно. Кстати, что будет в Ruby при выполнении a.foo, если a имеет значение "класс"?

> Тогда как в Ruby это наглядно выделено синтаксисом языка.

Дело не в синтаксисе, а в последствиях.

>> Ну теперь понятно, почему Python-исты так ругают динамическое изменение классов/объектов -- по коду хрен разберешься, что происходит

>Если поставить себе цель запутать читающего код - конечно. Кстати, что будет в Ruby при выполнении a.foo, если a имеет значение "класс"?

Попытка вызова статического метода foo того класса, на который ссылается a (или его базового класса). Конструкция вида a.b в Ruby всегда означает вызов b для объекта a.

>> Тогда как в Ruby это наглядно выделено синтаксисом языка.

> Дело не в синтаксисе, а в последствиях.

А что последствия?

Вот SmallTalk-еры рассказывают, что с помощью динамической модификации объектов они умудрялись править баги в third-party библиотеках при старте системы.

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

Так что дело не в возможностях, а в программистах.

>> Если поставить себе цель запутать читающего код - конечно. Кстати, что будет в Ruby при выполнении a.foo, если a имеет значение "класс"?

> Попытка вызова статического метода foo

Блин. Твой же пример: a.search = some_search_method, что будет, если 1) a - это экземпляр 2) a - это класс?

>> Дело не в синтаксисе, а в последствиях.

>А что последствия?

А последствия - нельзя понять, что вызывается вместо a.foo, пока не просмотришь _всю_ систему. То есть проигрыш понятен, выигрыш - нет.

>Вот SmallTalk-еры рассказывают [...]

>В Erlang-е динамическая загрузка [..]

А в ядре Linux используется самомодифицирующийся ассемблерный код. И что? Замену методов и прочие трюки нужно использовать, когда без них - вообще труба (наверное, так было в том примере со Смолтоком). В Эрланге, кстати, "горячая" замена кода - процедура редкая, нетривиальная и тщательно описанная.

>>> Если поставить себе цель запутать читающего код - конечно. Кстати, что будет в Ruby при выполнении a.foo, если a имеет значение "класс"?

>> Попытка вызова статического метода foo

>Блин. Твой же пример: a.search = some_search_method, что будет, если 1) a - это экземпляр 2) a - это класс?

Это будет попыка вызова метода 'search=' для:

1) экземпляра

2) для класса (т.е. статического метода 'search=').

> В Эрланге, кстати, "горячая" замена кода - процедура редкая, нетривиальная и тщательно описанная.

А что мешает придерживаться такой же политики в случае с Ruby?

>> Блин. Твой же пример: a.search = some_search_method, что будет, если 1) a - это экземпляр 2) a - это класс?

> Это будет попыка вызова метода 'search='

Ыыы. Что значит:

def a.search

blahblah

end

в случае, если a - экземпляр? класс?

>> В Эрланге, кстати, "горячая" замена кода - процедура редкая, нетривиальная и тщательно описанная.

>А что мешает придерживаться такой же политики в случае с Ruby?

Ты мне скажи :D Зачем реализовывать call once путем динамической подмены метода?

>>> Блин. Твой же пример: a.search = some_search_method, что будет, если 1) a - это экземпляр 2) a - это класс?

>> Это будет попыка вызова метода 'search='

>Ыыы. Что значит:

>def a.search

>blahblah

>end

>в случае, если a - экземпляр? класс?

Если экземпляр -- то это определение метода экземпляра. Если класс -- то определение статического метода класса. Поэтому-то в Ruby используются другие термины: instance method (метод принадлежащий экземпляру-объекту), class instance method (метод принадлежащий экземпляру-классу (где класс -- это так же объект)). Аналогично instance variable и class instance variable.

>>> В Эрланге, кстати, "горячая" замена кода - процедура редкая, нетривиальная и тщательно описанная.

>>А что мешает придерживаться такой же политики в случае с Ruby?

>Ты мне скажи :D Зачем реализовывать call once путем динамической подмены метода?

Хотя бы потому, что это самый эфективный способ. А разве декораторы в Python-е делают что-нибудь другое?

> Если экземпляр -- то это определение метода экземпляра. Если класс -- то определение статического метода класса.

То есть заменить метод сразу у всех экземпляров класса нельзя? o_O

>>Ты мне скажи :D Зачем реализовывать call once путем динамической подмены метода?

>Хотя бы потому, что это самый эфективный способ.

С точки зрения расходов на этапе выполнения? Ну смешно же :) Или с какой точки зрения?

> А разве декораторы в Python-е делают что-нибудь другое?

Вообще-то да - там нет _динамической_ подмены метода, всё ясно из определения класса и происходит на этапе компиляции.

Точнее, на этапе выполнения определения класса.

>> Если экземпляр -- то это определение метода экземпляра.
>>Если класс -- то определение статического метода класса. 

> То есть заменить метод сразу у всех экземпляров класса нельзя? o_O 

Можно:

irb(main):001:0> class Demo
irb(main):002:1> def f; :hello; end
irb(main):003:1> end
=> nil
irb(main):004:0> a = Demo.new
=> #<Demo:0x2ba63d0>
irb(main):005:0> a.f
=> :hello
irb(main):006:0> class Demo
irb(main):007:1> def f; :bye; end
irb(main):008:1> end
=> nil
irb(main):009:0> a.f
=> :bye

>>>Ты мне скажи :D Зачем реализовывать call once путем
> динамической подмены метода? 

>>Хотя бы потому, что это самый эфективный способ. 

> С точки зрения расходов на этапе выполнения?
> Ну смешно же :)

Почему смешно?

>> А разве декораторы в Python-е делают что-нибудь другое? 

>Вообще-то да - там нет _динамической_ подмены метода, всё ясно из 
>определения класса и происходит на этапе компиляции.

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

>> С точки зрения расходов на этапе выполнения? Ну смешно же :)

> Почему смешно?

1) Руби до 1.9.0 - известный тормоз 2) ты мерял выигрыш?

>>> А разве декораторы в Python-е делают что-нибудь другое?

>> Вообще-то да - там нет _динамической_ подмены метода, всё ясно из определения класса и происходит на этапе компиляции.

> Т.е. если компилятор может что-то заменять, не показывая это программисту -- то это нормально.

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

> А когда то же самое делает сам разработчик -- это уже проблема?

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

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

Они (то есть мы) обычно говорят что динамическая типизация говно с точки зрения перекладывания работы с компилятора на мозг.

>Так что все ваши страхи с "наворотить фокусов" это просто страхи.

Библиотека руби - это пример такого ужаса. Достаточно посмотреть на реализацию вебсервисов. Если посмотреть как поверх них реализуется всякие ebay4r и прочиее блабла4r - возникает подозрение что у того кто это писал мозг свернулся в творог от супердинамики руби если он не осиливает на лету объект строить в динамическом языке.

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

Хера с 2.

def m(x)

x.

end

нажми таб.

>не лезть с головой в документацию

Это в ту где в 90% кода возле каждого метода стоит :nodoc:? Да действительно в нее лезть практически бесполезно.

>а на руби сереьзные вещи это уже вполне себе DSL, которые не стыдно показать.

У меня стало возникать подозрение что после начавшегося hype на DSL в руби - исказили само понятие DSL - один клиент тут даже говорил что DSL возможности в руби по причине мегасинтаксиса без скобок и разделителей. Покажи хоть один DSL? Почему они все выглядят как списки пар ключ-значение и "xxxx do end"?

>>> С точки зрения расходов на этапе выполнения? Ну смешно же :)

>> Почему смешно?

>1) Руби до 1.9.0 - известный тормоз 2) ты мерял выигрыш?

1) Зачем же делать его еще тормознее.

2) Да. Конкретных цифр не сохранилось.

>> Т.е. если компилятор может что-то заменять, не показывая это программисту -- то это нормально.

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

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

>> А когда то же самое делает сам разработчик -- это уже проблема?

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

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

Кроме того, почему все думают, что в Ruby каждый программист считает своим долгом что-нибудь поменять в динамике? Я, например, могу вспомнить всего несколько случаев, когда мне это потребовалось за 4-ре года работы на Ruby.

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

>Ну, собственно, вот и одно из отличий. В Ruby нет свободных функции.

Не факт что это хорошо. 2 стринга сравнить - чей метод? А если первый nil? Начинаем вводить статические методы (методы класса) (к стати тоже звездец синтаксис статический метод описывается как def self.xxx ... end). Понятное дело что это ход конем - но его конем можно было в компиляторе сделать, а не в ручную.

>то как по коду понять, создается ли это новый метод в объекте a или устанавливается значение атрибута search?

А какая тебе разница в динамическом языке который понимает контекст вызова и передачу this?

> Конкретных цифр не сохранилось.

8)

> если человеку потребовался call_once, ему нужно ждать изменений в компиляторе?

Ы? Механизм декораторов расширяем, можно написать свой. Я прикола ради написал реализацию множественной диспетчеризации на декораторах :)

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

С другой стороны, зачем усложнять ему задачу? ;)

> Я, например, могу вспомнить всего несколько случаев, когда мне это потребовалось за 4-ре года работы

Это обнадеживает :D

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

ХЗ, я читал, что Руби типа поощряет использование таких фишек.

>> если человеку потребовался call_once, ему нужно ждать изменений в компиляторе?

> Ы? Механизм декораторов расширяем, можно написать свой. Я прикола ради написал реализацию множественной диспетчеризации на декораторах :)

Ну в Ruby бы ты сделал то же самое на переопределении методов.

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

>ХЗ, я читал, что Руби типа поощряет использование таких фишек.

Не поощряет. Но при разумном использовании позволяет получать удобные решения. Просто Ruby не органичивает разработчика.

>>> если человеку потребовался call_once, ему нужно ждать изменений в компиляторе?

>> Ы? Механизм декораторов расширяем, можно написать свой. Я прикола ради написал реализацию множественной диспетчеризации на декораторах :)

> Ну в Ruby бы ты сделал то же самое на переопределении методов.

Пойнт в том, что ждать изменений компилятора не нужно.

>>то как по коду понять, создается ли это новый метод в объекте a или устанавливается значение атрибута search?

>А какая тебе разница в динамическом языке который понимает контекст вызова и передачу this?

Понимаемость кода повышается.

А какая тебе разница, что статический метод описывается как self.name? Он может так же описываться и как ClassName.name.

>Тогда как в Ruby это наглядно выделено синтаксисом языка.

Реализацию метода call_once предоставь чтобы было понятно что такое "какие-то действия". Потому что по реализации подобных хинтов без килограмма марихуаны в контексте постоянногго :nodoc: не разберешься - достаточно посмотреть на ActiveRecord переполненую module_eval, class_eval и тд.

>>Тогда как в Ruby это наглядно выделено синтаксисом языка.

>Реализацию метода call_once предоставь чтобы было понятно что такое "какие-то действия". Потому что по реализации подобных хинтов без килограмма марихуаны в контексте постоянногго :nodoc: не разберешься - достаточно посмотреть на ActiveRecord переполненую module_eval, class_eval и тд.

Каким образом использование :nodoc: конкретными разработчиками оказывает влияние на весь язык?

>Понимаемость кода повышается.

В каком месте?

Если сама функция first-order object - какое имеет значение после 
понимания этого что ты присваиваешь стринг или функцию?

>А какая тебе разница, что статический метод описывается как self.name? 

class X
    def self.a
        puts self
    end
    def b
        puts self
    end
end

Я впечатлен детерминизмом, что такое self во всех этих случаях:)

Понимабельность кода говоришь?

>>Понимаемость кода повышается.

>В каком месте?

В месте присваивания

> Если сама функция first-order object - какое имеет значение после
> понимания этого что ты присваиваешь стринг или функцию?

Имеем:

a.f = b

Мне не так важно знать, что такое b. Но вот что такое f знать
хочется. Атрибут это? Существующий метод? Новый метод?

>>А какая тебе разница, что статический метод описывается как self.name? 

>class X
>    def self.a
>        puts self
>    end
>    def b
>        puts self
>    end

# Еще можно так:
puts self
>end

>Я впечатлен детерминизмом, что такое self во всех этих случаях:)

Незнание языка не освобождает от ответственности.
Внутри class...end текущим объектом, т.е. self -- это объект с
описанием класса. Внутри def...end self -- это экземпляр, для
которого вызывается метод.

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

> Понимабельность кода говоришь?

Да.

>Каким образом использование :nodoc: конкретными разработчиками оказывает влияние на весь язык?

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

>Атрибут это? Существующий метод? Новый метод?

Зачем? Социологическое исследование проводишь?

>Незнание языка не освобождает от ответственности.

Этим можно оправдать любую кривость в языке. Я прекрасно понимаю что я написал. Просто это не разу не облегчает чтение - а если туда накпихать еще всяких евалов - в немаленьких методах и инклудов - то вычисление контекста вообще квестом становится.

>>Каким образом использование :nodoc: конкретными разработчиками оказывает влияние на весь язык?

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

ActiveRecord, о которой шла речь, ни в коей мере не стандартная библиотека. Не нравится AR можно выбрать что-нибудь другое.

>Чем Матцу озаботится в срочно морядке надо - так это создлание стиля и культуры (если он сам конечно не такой-же двинутый).

Да, млин, совет на пять балов.

Других проблем у Ruby нет.

>>Атрибут это? Существующий метод? Новый метод?

>Зачем? Социологическое исследование проводишь?

Нет. Трындю здесь. Иногда с раздобаями.

>>Незнание языка не освобождает от ответственности.

>Этим можно оправдать любую кривость в языке. Я прекрасно понимаю что я написал. Просто это не разу не облегчает чтение - а если туда накпихать еще всяких евалов - в немаленьких методах и инклудов - то вычисление контекста вообще квестом становится.

О да. Если при этом еще и языка не знать, то вообще шанцев нет.

> Других проблем у Ruby нет.

О, кстати... какие у Руби проблемы? 8)