Я знаю. И я не делал утверждений относительно того, хшё это или плохо. Но при сравнении размеров кода это нужно учитывать тем не менее.
>> Безымянный тип - ужоснахъ.
> не нравится - не ешь. :)
Спасибо что разрешил! Сожалею что делал это ранее без всякого разрешения и чьего-либо согласия, претерпевая при этом тягчяйшие муки совести.
> вон по ссылке его сразу присвоили Person и всё в ажуре.
А спустя пару тыщ операторов думают, что в этой переменной и в каком количестве. Нунахъ. А так (person-p somevar) и фсе дела.
>> длина определений не очень существенна.
> длина всегда существенна, если только это не приходится очень редко писать.
ИМХО длина весьма существенна там, где многословнось влияет на понимание работы. А так - да, неприятно но некритично. Луче бы реализацию какого-нибудь quicksort туда впечатали. Впрчем, есть в примере по ссыле некая сермяжная правда. Эта рекламка ращитана на быдлокодерофф, а им кроме определений мало чего приходится печятать.
> ИМХО длина весьма существенна там, где многословнось влияет на понимание работы.
Правильно.
При работе с CLR есть одна особенность: большинство функций - библиотечные. Может быть 50% программы - именно вызовы. Именно ради этого (imho) и затеваются все проекты "X for Net".
А библиотеки CLR уже имеют структуру.
Потому интересно посмотреть как вызывать классы CLR и, наоборот, как из других Net языков вызывать то что производит этот ruby.Net
> Но при сравнении размеров кода это нужно учитывать тем не менее.
В общем, согласен. И это ещё один аргумент за языки без строгой типизации. :)
> А спустя пару тыщ операторов думают, что в этой переменной и в каком количестве.
Если ты про Person - то это константа, а не переменная. Потому что с большой буквы начинается. :) Такая вот у них система. Разницы с class Person и так далее - вообще никакой.
> ИМХО длина весьма существенна там, где многословнось влияет на понимание работы.
Чем больше надо ввести буковок, тем больше вероятность ошибиться, не говоря о потраченном впустую времени, которое к тому же сбивает с мыслей о задаче. Ещё хуже, если эти лишние буковки вполне глупые, повторяющиеся и бессмысленные. И вообще, как мы с тобой уже выяснили, я - строчкофил. :)
> Person.public_methods, Person.private_methods, для полей тоже что-то в этом духе есть.
Тем не менее когда определение размазано по коду - получается каша, а средства перечисления методов и полей есть много где, даже в жабе, тем не менее в реальном коде я их почти нигде не видел.
> Жаль, на самом деле было бы интересно твоё мнение.
Я его и так могу высказать. Руби - ещё одна неудачная попытка использовать мешанину из разнообразно *фиксных операторов и функций, которая хотя и выглядит для необученного более привычно, но по сути атавизм и зело неудобно. В результате - толпа и мешанина ненужных и излишне разнообразных символов, операторов и ключевых слов, затрудняющих и написание и понимание структуры и смысла написаного. Во многих естественных языках также было понапихано излишней информации и условностей, но со временем всё это поотвалилось.
> Если для чего-то есть средство, то это ещё не значит, что это надо пользовать на каждом шагу.
"Если что-то может быть употреблено неправильно, обязательно найдётся кто-нибудь, кто будет употреблять это неправильно" (С) самизнаетечей.
>> и так
> "и так" неинтересно. :)
Ну тогда может быть кто-то из знающих руби перечислит его _принципиальные_ отличия от например питона или васика какого-нибудь и мы будем их обсуждать. Я просто сомневаюсь что таковые _принципиальные_ различия сыщутся. А непринципиальные, как например использование } вместо end и наоборот, обсуждать попросту нейнтересно.
> я понимаю, что это оффтопик, но: каковы принципиальные отличия Питона от Лиспа?
Разве ты сам не ведаеш?
> (кроме синтаксиса и недоделанной лямбды в Питоне).
Семантика и синтаксис неразрывно связаны, как ты знаеш. Если есть семантически эквивалентные наречия с разным синтаксисом, то наречий с одинаковым синтаксисом но разной семантикой просто нету. В питоне большие идеологические заимствования из whitespace, такие как наличие некоей смысловой нагрузки, отличной от функции разделения, на символы-разделители, и он одновременно весьма нерегулярен, труден для изучения, и ограничен, труден для работы. Ноги всего этого лежат именно в принятой модели синтаксиса и без упоминания синтаксиса вообще различия перечислять безмысленно.
Лисп при желании может быть декларативным несомненно. Называют же его функциональным, хотя он настолько же функционален, насколько и декларативен, и ничего...
Кстати как в перле просто сделать так как указано на картинке.
Т.е. одной строчкой (через какой-нибудь генератор классов) создать класс сразу с набором методов и задать (без всякого наследования).
А вообще да в перле ООП очень мощное, но тока потому что очень низкоуровнее можно как хочешь извртится. Но в перле чё плохо что стандартные типы не объекты т.е. Почему когда мне нужно узнать длинну массива я должен извращаться типа scalar @{$blah->list} вместо $blah->list->lenght ?
> куда уж мощнее? хотя есть и помощнее, но то уже модули.
Не стандартизированные эксепшены это очень хорошая вещь бы была. Как нормально тип эксепшены узнать парсить регекспом $@ это ваще хреново. А либ с эксепшеными много, по этому каждый юзает своё и получается каша((