C# vs Ruby

Только заметил, в C# коде в комментах указано, что не показан дополнительный код для сеттеров/геттеров :)

Несерьёзно это. При чём тут Struct? Хотя и настоящий класс в руби конечно не намного длиннее будет, но сам подход жульнический.

Ну стракт.нью возвращает же класс, типа метакласс и всё такое. Можно потом расширить легко..

Но согласись выглядит жульнически? Я правда сишарпа не знаю...

> Но согласись выглядит жульнически? Я правда сишарпа не знаю...

Это тока с первого взгляда. Но ведь дальше можно расширть как угодно.

Person = Struct.new(:name, :birthday, :children)

а поотм

class Person # Добавляем нужные методы end

В принципе конструкции слева и справа идентичны, обе задают класс Person с нужными свойствами и методами

1. типы данных в руби не проверяются, а в с# занимают много места.

2. Безымянный тип - ужоснахъ.

3. длина определений не очень существенна.

ЗЫ (defstruct person () :name :birthday :children)

Я в курсе. :) Просто пример несколько искусственный. Вряд ли на таком маленьком примере можно судить о многословности языка в обычных случаях.

Похоже ребята гонят (честно говоря я не знаю руби. с виду похоже на JScript).

Все три ctor'a в шарпе объявлять не обязательно. Акцессоры тоже.

Непонятки со средой, без интеллисенса работать трудно с CLR, особенно когда объем текста большой.

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

> типы данных в руби не проверяются

это религиозный вопрос :)

> Безымянный тип - ужоснахъ.

не нравится - не ешь. :) вон по ссылке его сразу присвоили Person и всё в ажуре.

> длина определений не очень существенна.

длина всегда существенна, если только это не приходится очень редко писать.

ну это да) нужно было что нить типа этого сравнить с C#:


class Post < ActiveRecord::Base
  belongs_to :topic
  belongs_to :user
  belongs_to :parent, :class_name => 'Post', :foreign_key => 'parent_id'
  has_many :children, :class_name => 'Post', :foreign_key => 'parent_id'
  has_many :post_votes, :dependent => true
  has_one :search_index_item, :dependent => true
  has_many :attachments, :dependent => true
  composed_of :guest, :mapping => [ %w(guest_name guest_name), %w(guest_email guest_email) ]

  validates_length_of :text, :within => 3..50000,
    :too_short => 'formerror_text_short', :too_long => 'formerror_text_long'
  validates_length_of :subject, :within => 3..60,
    :too_short => 'formerror_subject_short', :too_long => 'formerror_subject_long'

  validates_uniqueness_of :messageid

  cattr_accessor :indexing_disabled
  @@indexing_disabled = false
  cattr_accessor :search_handler
  @@search_handler = self.const_get(RForum::CONFIG[:search_handler]).new

Во, вот это я понимаю. :)

А пример вызова CLR из рубика можете привести?

>> типы данных в руби не проверяются

> это религиозный вопрос :)

Я знаю. И я не делал утверждений относительно того, хшё это или плохо. Но при сравнении размеров кода это нужно учитывать тем не менее.

>> Безымянный тип - ужоснахъ.

> не нравится - не ешь. :)

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

> вон по ссылке его сразу присвоили Person и всё в ажуре.

А спустя пару тыщ операторов думают, что в этой переменной и в каком количестве. Нунахъ. А так (person-p somevar) и фсе дела.

>> длина определений не очень существенна.

> длина всегда существенна, если только это не приходится очень редко писать.

ИМХО длина весьма существенна там, где многословнось влияет на понимание работы. А так - да, неприятно но некритично. Луче бы реализацию какого-нибудь quicksort туда впечатали. Впрчем, есть в примере по ссыле некая сермяжная правда. Эта рекламка ращитана на быдлокодерофф, а им кроме определений мало чего приходится печятать.

>(person-p somevar)

somevar.class == Person

гм в чём разница?

> А пример вызова CLR из рубика можете привести?

Не занимался этим...

> ИМХО длина весьма существенна там, где многословнось влияет на понимание работы.

Правильно.

При работе с CLR есть одна особенность: большинство функций - библиотечные. Может быть 50% программы - именно вызовы. Именно ради этого (imho) и затеваются все проекты "X for Net".

А библиотеки CLR уже имеют структуру.

Потому интересно посмотреть как вызывать классы CLR и, наоборот, как из других Net языков вызывать то что производит этот ruby.Net

> Но при сравнении размеров кода это нужно учитывать тем не менее.

В общем, согласен. И это ещё один аргумент за языки без строгой типизации. :)

> А спустя пару тыщ операторов думают, что в этой переменной и в каком количестве.

Если ты про Person - то это константа, а не переменная. Потому что с большой буквы начинается. :) Такая вот у них система. Разницы с class Person и так далее - вообще никакой.

> ИМХО длина весьма существенна там, где многословнось влияет на понимание работы.

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

мож пофлеймим lisp vs ruby, такого помойму ещё всерьёз не было:))

В тему: http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp :)

> гм в чём разница?

Возможно в том, что

> class Person # Добавляем нужные методы end

И в конечном итоге непонятно, сколько там методов и полей накоплено.

> мож пофлеймим lisp vs ruby, такого помойму ещё всерьёз не было:))

Я бы с радостью, но я руби не знаю совсем.

> И в конечном итоге непонятно, сколько там методов и полей накоплено.

Person.public_methods, Person.private_methods, для полей тоже что-то в этом духе есть.

> Я бы с радостью, но я руби не знаю совсем.

Жаль, на самом деле было бы интересно твоё мнение.

> Person.public_methods, Person.private_methods, для полей тоже что-то в этом духе есть.

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

> Жаль, на самом деле было бы интересно твоё мнение.

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

> Тем не менее когда определение размазано по коду

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

> и так

"и так" неинтересно. :)

http://www.dzone.com/rsslinks/groovy_visitor_pattern.html гораздо нагляднее для коммьюнити

> Если для чего-то есть средство, то это ещё не значит, что это надо пользовать на каждом шагу.

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

>> и так

> "и так" неинтересно. :)

Ну тогда может быть кто-то из знающих руби перечислит его _принципиальные_ отличия от например питона или васика какого-нибудь и мы будем их обсуждать. Я просто сомневаюсь что таковые _принципиальные_ различия сыщутся. А непринципиальные, как например использование } вместо end и наоборот, обсуждать попросту нейнтересно.

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

я понимаю, что это оффтопик, но: каковы принципиальные отличия Питона от Лиспа? (кроме синтаксиса и недоделанной лямбды в Питоне).

> ... ещё одна неудачная попытка использовать мешанину из разнообразно *фиксных операторов и функций ...

А что ты хотел от императивных языков? Они без синтаксического сахара хиреют.

В Лиспе все регулярно - все есть либо атом, либо список атомов. А уж как дальше, разбереться eval.

Проблемы у лиспа только:

1. Отсутствие нормальной реализации за которую не пришлось бы платить килобаксы

2. Отсутствие огромного количества более-менее стандартных библиотек на все случае жизни (как, например, в Питоне)

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

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

А какой из упомянутых здесь языков - декларативный?

Лисп - декларативный

> И в конечном итоге непонятно, сколько там методов и полей накоплено.

ага а в лиспе (defmethod kill ((p person)) ....) и тоже самое. Только не понятно почему это плохо?

> Я бы с радостью, но я руби не знаю совсем.

Жаль...

> Лисп - декларативный

За что люблю ЛОР - постоянно узнаю что-то новое :D

> Тем не менее когда определение размазано по коду - получается каша,

Ну и в лиспе это есть.

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

Да не в руби тоже можно всё зделать труъ:

123.+(10.*(55))./5

Здесь + * / - это названия методов

один фиг ООП мощнее чем в перле нет нигде

> один фиг ООП мощнее чем в перле нет нигде

и кривее)) В самом деле в Common Lispе мощнее ооп чем в перле

>и кривее))

кривые только руки бывают :)

Тру ООП - это только смоллтолк! Остальное - от лукавого!

>один фиг ООП мощнее чем в перле нет нигде

Чем оно там такое мощное? Что даже исключений нет?

>В самом деле в Common Lispе мощнее ооп чем в перле

пример объекта на ЛИСпе меняющего иерархию наследования рантайм.

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

> Тру ООП - это только смоллтолк!

аха, причем Smalltalk-72 :D

>Что даже исключений нет?

как это нет? всю жизть были и есть

> я понимаю, что это оффтопик, но: каковы принципиальные отличия Питона от Лиспа?

Разве ты сам не ведаеш?

> (кроме синтаксиса и недоделанной лямбды в Питоне).

Семантика и синтаксис неразрывно связаны, как ты знаеш. Если есть семантически эквивалентные наречия с разным синтаксисом, то наречий с одинаковым синтаксисом но разной семантикой просто нету. В питоне большие идеологические заимствования из whitespace, такие как наличие некоей смысловой нагрузки, отличной от функции разделения, на символы-разделители, и он одновременно весьма нерегулярен, труден для изучения, и ограничен, труден для работы. Ноги всего этого лежат именно в принятой модели синтаксиса и без упоминания синтаксиса вообще различия перечислять безмысленно.

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

У объекта можно вызвать change-class чтобы изменить класс, а класс можно сгенерить налету. У класса предков тоже можно налету изменить.

>как это нет? всю жизть были и есть

eval и die? Или уже что-то помощнее придумали?

И они хоть в одной стандартной библиотеке используются?

>> я понимаю, что это оффтопик, но: каковы принципиальные отличия Питона от Лиспа?

>Разве ты сам не ведаеш?

Честно говоря, я _принципиальных_ отличий просто не вижу. Да и вообще - интересно именно твое мнение.

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

>eval и die? Или уже что-то помощнее придумали?

куда уж мощнее? хотя есть и помощнее, но то уже модули.

>И они хоть в одной стандартной библиотеке используются?

да, в практически любой либе с cpan :)

>У объекта можно вызвать change-class чтобы изменить класс, а класс можно сгенерить налету. У класса предков тоже можно налету изменить.

то есть осталось приделать к Лиспу нормальные регвыражения и станет приличным языком :) прогресс однака

Кстати как в перле просто сделать так как указано на картинке.

Т.е. одной строчкой (через какой-нибудь генератор классов) создать класс сразу с набором методов и задать (без всякого наследования).

А вообще да в перле ООП очень мощное, но тока потому что очень низкоуровнее можно как хочешь извртится. Но в перле чё плохо что стандартные типы не объекты т.е. Почему когда мне нужно узнать длинну массива я должен извращаться типа scalar @{$blah->list} вместо $blah->list->lenght ?

> Лисп при желании может быть декларативным несомненно.

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

http://en.wikipedia.org/wiki/Declarative_programming_language

http://en.wikipedia.org/wiki/Category:Declarative_programming_languages

> куда уж мощнее? хотя есть и помощнее, но то уже модули.

Не стандартизированные эксепшены это очень хорошая вещь бы была. Как нормально тип эксепшены узнать парсить регекспом $@ это ваще хреново. А либ с эксепшеными много, по этому каждый юзает своё и получается каша((