Предварительный релиз Ruby 1.9.0

>>А вот придерживаться _устоявшейся_ терминологии при разговоре о Ruby смысл есть.

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

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

Ну называются, например, в C++ абстрактные методы pure virtual methods. Новый термин, зато очень необходимый в C++.

Точно так же и с методами кода.

> Точно так же и с методами кода.

s/методами/блоками/

> Когда ты проектируешь библиотеку, тебе безразличен синтаксис языка и его особенности.

Конечно.

> Когда проектируешь internal DSL, то ты вынужден уделять этому певостепенное внимание

Ни разу. То, что ты (и Фаулер) называешь internal DSL - это всего лишь тонкая обертка вокруг библиотеки, спроектированной совершенно традиционным образом. Добавим к этому то, что синтаксис этой обертки совпадает с синтаксисом хост-языка, и получим вопрос - почему это всё подается как новый -язык_?

Блин, реализация каналов Occam есть для Java и Си++, но (не перевелись еще честные люди 8)) их никто не называет "parallel programming DSL".

> LOR вообще единственное из известных мне мест, где Rubyist-ы с Python-щиками воюют

Это же ЛОР, арена междоусобных войн линупсоидофф, в которые почему-то норовят встрять залетные вендузятнеги :D

>>Тем, что базируется на второстепенных особенностях языка. Таких, например, как необязательность скобок при вызове метода, необязательность скобок при объявлении Hash-литералов, специальном приведении набора аргументов к экземпляру Array и пр.

>В вышеупомянутотй статье Файлер делает его на жабе.

>Дальше что?

Вот что:

"It's formatted oddly, and uses some _unusual programming conventions_,"

Для того, чтобы на Java создать какое-то подобие декларативности и привязанного к предметной области потока описаний пришлось применять специальные приемы и специальным образом проектировать классы/методы. Только тогда появилось хоть какое-то приближение к тому, что можно было бы сделать на external DSL.

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

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

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

:)

>> Когда проектируешь internal DSL, то ты вынужден уделять этому певостепенное внимание

> Ни разу. То, что ты (и Фаулер) называешь internal DSL - это всего лишь тонкая обертка вокруг библиотеки, спроектированной совершенно традиционным образом.

В случае Ruby (да и Scala, если взглянуть на Actor Library) это далеко не так. Библиотека создается таким образом, что последующее ее использование _традиционным_ образом может быть вообще невозможно.

> Добавим к этому то, что синтаксис этой обертки совпадает с синтаксисом хост-языка, и получим вопрос - почему это всё подается как новый -язык_?

Потому, что "язык" -- это слишком общее понятие. Языком может быть и C++ и язык регулярных выражений. Поэтому и говорят не "язык", а DSL. Что можно, в большинстве случаев, переводить как "недоязычок". :)

> Другая особенность в том, что когда блок кода передается неявным аргументом в метод, то тогда можно использовать специальные языковые конструкции: проверку block_given? и yield для передачи управления этому блоку.

IMHO, это излишний синтаксический сахар и пара магических заклинаний впридачу. Гораздо более логичный, понятный и гибкий подход - передавать анонимную функцию обычным образом в списке аргументов и вызывать её как обычную функцию. Но это не ruby-way. ибо слишком банально :)

> Одна из особенностей Proc-объекта в том, что по умолчанию он сохраняет связь с контекстом, в котором создан. Но, при необходимости, этот контекст можно сменить при помощи Object#instance_eval (http://www.ruby-doc.org/core/classes/Object.html#M000336)

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

>> То, что ты (и Фаулер) называешь internal DSL - это всего лишь тонкая обертка вокруг библиотеки, спроектированной совершенно традиционным образом.

> В случае Ruby (да и Scala, если взглянуть на Actor Library) это далеко не так. Библиотека создается таким образом, что последующее ее использование _традиционным_ образом может быть вообще невозможно.

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

Кроме того, как мы выяснили, в Руби и Скале всегда ипользуется обычный синтаксис этих языков. Это ли не "традиционный образ"?

>> Добавим к этому то, что синтаксис этой обертки совпадает с синтаксисом хост-языка, и получим вопрос - почему это всё подается как новый -язык_?

> Потому, что "язык" -- это слишком общее понятие. Языком может быть и C++ и язык регулярных выражений. Поэтому и говорят не "язык", а DSL.

Это объяснило бы использование термина "язык", но не термина "создать/разработать язык".

>>> То, что ты (и Фаулер) называешь internal DSL - это всего лишь
>>> тонкая обертка вокруг библиотеки, спроектированной совершенно
>>> традиционным образом. 

>> В случае Ruby (да и Scala, если взглянуть на Actor Library) это
>>далеко не так. Библиотека создается таким образом, что последующее ее
>> использование _традиционным_ образом может быть вообще невозможно. 

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

Как обычно. Только тестовые примеры сразу в DSL набираются.

> Кроме того, как мы выяснили, в Руби и Скале всегда ипользуется
> обычный синтаксис этих языков. Это ли не "традиционный образ"?

Последняя попытка объяснить на пальцах. Не получится -- все, сдаюсь.

Итак, в "традиционном подходе" мы имеем код вида:

  defines = []
  defines << { 'EXPORT_SPEC' => 'C' }
  defines << { 'EXPORT_CLASS(C)' => 'C' }
  doxygen = new DoxygenTask
  doxygen.include_path( 'my_prj' )
  doxygen.include_samples( 'my_samples' )
  doxygen.defines( defines )
  define_new_task( doxygen )

Мы можем его переписать как угодно. Например, так:

  doxygen = new DoxygenTask
  doxygen.include_path( 'my_prj' )
  doxygen.include_samples( 'my_samples' )
  defines = []
  defines << { 'EXPORT_SPEC' => 'C' }
  defines << { 'EXPORT_CLASS(C)' => 'C' }
  doxygen.defines( defines )
  define_new_task( doxygen )

Или так:

  def make_initial_doxygen
    doxygen = new DoxygenTask
    doxygen.include_path( 'my_prj' )
    doxygen.include_samples( 'my_samples' )
    doxygen
  end

  def add_defines( doxygen )
    defines = []
    defines << { 'EXPORT_SPEC' => 'C' }
    defines << { 'EXPORT_CLASS(C)' => 'C' }
    doxygen.defines( defines )
  end

  doxygen = make_initial_doxygen
  add_defines( doxygen )
  define_new_task( doxygen )

Можем еще как-то поизгаляться. Но:
- мы должны полностью сформировать doxygen до обращения к
define_new_task, и
- мы должны точно знать, какими объектами мы манипулируем во время
формирования объекта.

В случае же internal DSL (или называй это DSLibrary, суть не изменится),
тебе диктуется порядок действий:

  task :doxygen { |t|
    t.include_path 'my_prj'
    t.include_samples 'my_samples'
    t.defines { |d|
      d << 'EXPORT_SPEC' => ''
      d << 'EXPORT_CLASS(C)' => 'C'
    }
  }

т.е. ты ничего не можешь сделать до вызова task -- все только внутри.

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

> yk4ever (*) (26.12.2007 2:27:23)

без этого тролля ни одна новость про скриптовый язык не проходит :)

А без нас вообще ничто не обходится :)

> Так мне кажется было бы лучше:

> f = (a, b) -> { a + b }

Меня глючит, или это Perl6?

>что-то купил я книжку по рубби читаю и не нравится он мне. жуткая ориентация на ООП что аж тошновато

Унера, так фишка руби именно в том что он насквозь ООП. Если не нравится ООП - есть перл %) Вот меня тоже от ООП тошнит, не знаю зачем его суют кругом, но в сайтостроительстве ООП вполне возможно уместен, как считаешь ?

> Python + Pyrex + Psyco = непобедимая связка!

Угу, дающая прирост производительности только на x86_32. ;-)

erlang + hipe + smp = наше всё.

>> Python + Pyrex + Psyco = непобедимая связка!

> Угу, дающая прирост производительности только на x86_32. ;-)

Pyrex даст прирост на любой архитектуре.

Сегодня упало на почту письмо (не спам )
------
I have a couple of Ruby on Rails Developer position in Minneapolis,it's a full time on-site position for at least a 6 month period depending on the client, if you interested what is your rate and availability. Please send your update resume. If you have any questions feel free to contact me.

thanks

--
Adam Haris
*************************
*************************
*************************
------

Ты хвастаешься или жалуешься?

В любом случае, я тебя ненавижу.

Вот вам еще пример Ruby DSL, в данном случае это фреймворк для тестирования (rspec):


describe User do
  it "should be in any roles assigned to it" do
    user = User.new
    user.assign_role("assigned role")
    user.should be_in_role("assigned role")
  end

  it "should NOT be in any roles not assigned to it" do
    user = User.new
    user.should_not be_in_role("unassigned role")
  end
end



DSL в данном случае в конструкциях it, describe, should, should_not, be_* ...

Надо заметить, что, например should* подмешивается (mixin) в класс Object. 
При этом нет необходимости переписывать весь исходник так, 
что бы классы в системе наследовались от некого MyObject.

Кому хочется еще примеров -- http://rspec.info/examples.html и google в зубы.


P.S. господа, если и тут вы не видете DSL, то мне вас просто жаль...

Я тут вижу только тормозной спутниковый интернет.

> def str.bye > "Пока!" > end

> Простой, лаконичный и понятный код!

Нихрена тут не понятно. Что эта функция возвращает? Как это указано? Какие у неё параметры? Или это процедура/макрос? Похоже что любители Руби при его отсутствии на Бэйсике бы строчили.

> def str.bye
>     "Пока!"
> end

> Простой, лаконичный и понятный код!

Нихрена тут не понятно.
Что эта функция возвращает? Как это указано?
Какие у неё параметры? Или это процедура/макрос?
Похоже что любители Руби при его отсутствии на Бэйсике бы строчили.

Скажите, а насколько хорош Rubinius VM?

> yk4ever, каждую новость о каком-либо языке, который не является пистоном, ты воспринимаешь как личное оскорбление,

Ничего подобного. Я просто обсуждаю их недостатки. Веду, тскзть, разъяснительную работу среди молодёжи.

> За всё своё недолгое присутсвие на ЛОРе ты не произвёл ниодного осмысленного объективного аргумента за или против

Плохо читаете.

>Если человек любит ООП и не любит руби, то мне его жаль... Это к психиатору.... :-D

>Если человек любит ООП ... то мне его жаль... Это к психиатору.... :-D
Если этот человек любит психиатора... то мне жаль его ООП... Ж :-D

> Перл-то тут причем?

Потому что я отвечал на пост, в котором упоминался перл.

> Ничего удобней перла для обработки текстовых данных так и не было придумано, причем питон там и рядом не валялся, да и не будет никогда :)

Есть мнение, что перл не нужен - для простых случаев есть sed/awk, а сложные гораздо логичнее оформить на питоне. Для лучшей поддерживаемости.

> Да и вообще, хватит уже троллить,

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

> Что такое ковбойский язык ?

Это язык, который побуждает писать заковыристый заумный код, который потом будет тяжело поддерживать. Есть языки ковбойские и фермерские. Например, кобол и жаба - типично фермерские.

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

> И всетаки непонятны нападки сторонников Питона на строронников Руби ?

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

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

Например?

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

Ути бедненький! Хочешь, я тебе свой старый винт на сорок гигов подарю?

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

Перефразируем: табы НАДО настраивать, а пробелы - НЕ НАДО.

Успокойтесь уже. Я тоже в детстве табами отступал. Потом вырос, и понял что четыре пробела - удобнее по совокупности параметров. Это стандарт. Придерживайтесь.

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

> Перефразируем: табы НАДО настраивать, а пробелы - НЕ НАДО.

Не-а. Перефразируем так: табы МОЖНО настраивать, а пробелы - НЕЛЬЗЯ.

Изнасилованный Перл версии 1.9.0 - пререлиз (порнушка).

> Некотоые редаткоры конвертируют табы в пробелы или наоборот АВТОМАТИЧЕСКИ.

Пробелы в табы АВТОМАТИЧЕСКИ?! Убивать таких.

> Пусть форматированием занимается indent, astyle или IDE, а не человек

У меня редактор в питоновском коде автоматически отступы ставит.

> К тому же я например ставлю 2 пробела,

Ставьте четыре.

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

Чистый код и без камментов хорошо читается.

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

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

> yk4ever'a закопать нах вместе с пистоном

Встретимся, мальчег? Лопату с собой приноси. Только бери ту, у которой ручка поменьше диаметром и полированная. А то больно будет.

> Поэтому в питоновскую лямбду нельза впихнуть if, for, def и проч.

if -> or
for -> [...]
def -> не помню; когда возился с питоном пытался писать в нём в функ.
стиле, если память не изменяет, кроме обработки ошибок всё остальное
можно и функциями...

> Кто-то любит выставлять ширину в 2 пробела, а кто-то в 4,

Не надо "любить". Надо привыкать к стандартам.

> Если ставить таб _никаких_ проблем нет.

Во-первых, в большинстве редакторов отступы по дефолту настроены в 8 пробелов - что неудобно. Во-вторых, при вставке кода в посты на форумах/блогах, табы обычно теряются.

По этим причинам, от четырёх пробелов сложностей меньше.

> Есть мнение, что перл не нужен - для простых случаев есть sed/awk, а сложные гораздо логичнее оформить на питоне. Для лучшей поддерживаемости.
Есть мнение что питон не нужен - как для простых случаев, так и для сложнх можно и нужно использовать перл. Для большей скорости разработки и лучшей поддерживаемости.

Не люблю Руби, Моно, ПХП. Но давайте вместе валить M$.

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

есть мнение что и то и другое гавно и ни для простых и ни для сложных вещей не подходит. Для этого есть С#

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

Для сложных случаев использовать перл невозможно. Он отвратительно масштабируется по сложности, а принцип TIMTOWTDI предельно затрудняет совместную работу.

> Для большей скорости разработки и лучшей поддерживаемости.

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

Оно ещё не сдохло?

offtop:
В традиционном "ООП" подходе, такое
task :doxygen { |t|
    t.include_path 'my_prj'
    t.include_samples 'my_samples'
    t.defines { |d|
      d << 'EXPORT_SPEC' => ''
      d << 'EXPORT_CLASS(C)' => 'C'
    }
  }

обычно выглядит так:

addTask( new DoxygenTask() {
       public String getIncludePath() {
         return "my_proj";
       }
      public List<String> getIncludeSamples() {
        return Arrays.asList(new String[] {"my_sample"});
      }
      public Map<String, String> getDefines() {
        final Map<String, String> def = new Map<String, String>;
        def.put("EXPORT_SPEC", "");
        def.put("EXPORT_CLASS(C)", "C");
        return def;
      }
    });

:)

В голове у вас грязная каша, это точно :)

>offtop:
>В традиционном "ООП" подходе, такое
Это в традиционной жабе такой подход.

>> if -> or
for -> [...]
def -> не помню; когда возился с питоном пытался писать в нём в функ.
стиле, если память не изменяет, кроме обработки ошибок всё остальное
можно и функциями...

Можно конечно, однако это не способствует читабельности кода, имхо проще не парится и создать нормальную функцию :)))

Напрмер банальное:
if x > 10:
    print 'more'
else:
    print 'less'

Не так уж тривиально закодить в ляибду, хотя конечно можно :))) :

lambda x: sys.stdout.write((x>10 and 'more') or 'less')

И еще: http://www.p-nand-q.com/python/stupid_lambda_tricks.html

Мда, фукциональщина одна....

Ну и где решение красивей как ты думаешь?

>> Поэтому надо писать через четыре пробела.

> я вот через 2 всю жизнь пишу, и у меня все хорошо.

При Сталине таких отправляли лес рубить за вредительство, и правильно делали.

А что, typedef в Яве так до сих пор и нет? O_O

>Ну и где решение красивей как ты думаешь?

Я не знаю, чего такое для вас "красивей". У меня критерия три: расширяемость + читаемость/понятность + скорость работы. Про Руби я мало могу сказать (писал на нём мало), но данный пример на java всем трём критерям удовлетворяет в нормальной степени.