Как жить с синтаксическим сахаром like Ruby

[AmdY]

Сегодня, то есть вчера, прослушал парочку докладов по руби, даже скорее больше по ROR.
Они не используют IDE, так как это не имеет особого смысла.
Реализовать полноценный автокомплит там нельзя. Передача параметров в методы имеет несколько вариантов, только недавно появилась возможность указывать параметры по умолчанию. Интерфейсов и тайпхинтинг соответственное отсутствуют.
Класс можно обвесить методами или переопределить в любом месте (здравствуй #define TRUE FALSE). Вроде есть rdoc, но не понятно кто и как им пользуется, они против чёрных ящиков и знают свой код!!!!
Синтаксический сахар делает код непредсказуемым, интерфейс можно узнать только из доки/ читать код библиотек по их же уверением - "может это сразу и не очень понятно".
Прочитали доклад по тому как писать API, я бы сам уволился за такой подход, а там этим гордятся. Главное код получается коротким и красивым, а то что библиотекой не сможет пользоваться даже сам разработчик месяца через два - не важно. И это при принципе "явное важнее неявного".

Приятная игрушка для школьника и студента, ну ещё блог написать за 15 минут, не больше. Как осуществлять поддержку такого кода, если его становится вдруг много? Как писать на нём в команде.

Я уже раза три видел, как переписываются проекты с ROR на PHP, кстати DiMA упоминал о том же. Сам даже переписывал небольшую бухгалтерскую системку. Не хотел судить, пока достаточно близко не познакомлюсь с предметом и не поговорю с их разработчиками . Может я что-то пропустил? Или там действительно такой ад, что php-шный говнокод покажется раем?

Ответы:
1. не использовать синтаксический сахар, там где его проблемы нельзя закрыть RDOC
2. использования соглашений
3. проблемы автокомпита для популярных библиотек, того же ROR довольно здорово решается специальными плагинами для IDE.

 

[Ragazzo]

А мне нравиться, но я не работаю в RubY- team, и к тому же на нем есть много больших проектов, по крайней мере не нам решать имеет ли он право на жизнь, так можно наплодить еще кучу флуда и тредов похожих про другие языки. И пишут люди в команде нормально, просто щас интерес к RubY немного поугас, но з/п и работа в Москве рубистов значительно оправдывают "право на существование"...

 

[pilot911]

что там руби, кто-то до сих пор пишет на MUMPS ) .. если это за 30 лет не умерло, то руби тоже, скорее всего, будет жить

cm(idm,s,l1,l2,l3,l4,l5,l6,l7,l8,l9) ;сформировать пункт меню (максимум 8 уровней)
 n st s st=$$NORM^bsfun("",4)  
 i $g(l9)'="" s cmenu(l1,l2,l3,l4,l5,l6,l7,l8,l9,st)=idm_"~"_s q
 i $g(l8)'="" s cmenu(l1,l2,l3,l4,l5,l6,l7,l8,st)=idm_"~"_s q
 i $g(l7)'="" s cmenu(l1,l2,l3,l4,l5,l6,l7,st)=idm_"~"_s q
 i $g(l6)'="" s cmenu(l1,l2,l3,l4,l5,l6,st)=idm_"~"_s q
 i $g(l5)'="" s cmenu(l1,l2,l3,l4,l5,st)=idm_"~"_s q
 i $g(l4)'="" s cmenu(l1,l2,l3,l4,st)=idm_"~"_s q
 i $g(l3)'="" s cmenu(l1,l2,l3,st)=idm_"~"_s q
 i $g(l2)'="" s cmenu(l1,l2,st)=idm_"~"_s q 
 i $g(l1)'="" s cmenu(l1,st)=idm_"~"_s q
 i $g(l1)="" s cmenu(st)=idm_"~"_s q
 q
cmEnd ;вывод в поток контекстного меню
 n n s n=$$getParamConfig^bscito("-MainConfig","CustomContextMenu") i n'="" d @n
mEnd w "[ "_t n i1,i2,i3,i4,coma,i5 ;,t ;s t="" 
 k ^mtempCurMenu m ^mtempCurMenu=cmenu ;массив для отладки
 S i1="" F   S i1=$O(cmenu(i1)) Q:i1=""  d
 .i $d(coma) w ","
 .w $p(cmenu(i1),"~",2,99)_t s coma=1
 .i $o(cmenu(i1,""))'="" d  w "]]"_t q
 ..n coma S i2="" F   S i2=$O(cmenu(i1,i2)) Q:i2=""  d
 ...i $d(coma) w ","
 ...w $p(cmenu(i1,i2),"~",2,99)_t s coma=1
 ...i $o(cmenu(i1,i2,""))'="" d  w "]]"_t q
 ....n coma S i3="" F   S i3=$O(cmenu(i1,i2,i3)) Q:i3=""  d
 .....i $d(coma) w ","
 .....w $p(cmenu(i1,i2,i3),"~",2,99)_t s coma=1
 .....i $o(cmenu(i1,i2,i3,""))'="" d  w "]]"_t q
 ......n coma S i4="" F   S i4=$O(cmenu(i1,i2,i3,i4)) Q:i4=""  d
 .......i $d(coma) w ","
 .......w $p(cmenu(i1,i2,i3,i4),"~",2,99)_t s coma=1
 .......i $o(cmenu(i1,i2,i3,i4,""))'="" d  w "]]"_t q
 ........n coma S i5="" F   S i5=$O(cmenu(i1,i2,i3,i4,i5)) Q:i5=""  d
 .........i $d(coma) w ","
 .........w $p(cmenu(i1,i2,i3,i4,i5),"~",2,99)_t s coma=1
 .........i $o(cmenu(i1,i2,i3,i4,i5,""))'="" d  w "]]"_t q 
 ..........n coma S i6="" F   S i6=$O(cmenu(i1,i2,i3,i4,i5,i6)) Q:i6=""  d
 ...........i $d(coma) w ","
 ...........w $p(cmenu(i1,i2,i3,i4,i5,i6),"~",2,99)_t s coma=1
 ...........i $o(cmenu(i1,i2,i3,i4,i5,i6,""))'="" d  w "]]"_t q
 ............n coma S i7="" F   S i7=$O(cmenu(i1,i2,i3,i4,i5,i6,i7)) Q:i7=""  d
 .............i $d(coma) w ","
 .............w $p(cmenu(i1,i2,i3,i4,i5,i6,i7),"~",2,99)_t s coma=1
 .............i $o(cmenu(i1,i2,i3,i4,i5,i6,i7,""))'="" d  w "]]"_t q 
 ..............n coma S i8="" F   S i8=$O(cmenu(i1,i2,i3,i4,i5,i6,i7,i8)) Q:i8=""  d
 ...............i $d(coma) w ","
 ...............w $p(cmenu(i1,i2,i3,i4,i5,i6,i7,i8),"~",2,99)_t s coma=1
 ...............i $o(cmenu(i1,i2,i3,i4,i5,i6,i7,i8,""))'="" d  w "]]"_t q
 ................n coma S i9="" F   S i9=$O(cmenu(i1,i2,i3,i4,i5,i6,i7,i8,i9)) Q:i9=""  d
 .................i $d(coma) w ","
 .................w $p(cmenu(i1,i2,i3,i4,i5,i6,i7,i8,i9),"~",2,99)_t s coma=1
 .................i $o(cmenu(i1,i2,i3,i4,i5,i6,i7,i8,i9,""))'="" d  w "]]"_t q  ;пока хватит уровне
 ...............i $l($g(cmenu(i1,i2,i3,i4,i5,i6,i7,i8)),"[")'=$l($g(cmenu(i1,i2,i3,i4,i5,i6,i7,i8)),"]") w "]]"_t q
 .............i $l($g(cmenu(i1,i2,i3,i4,i5,i6,i7)),"[")'=$l($g(cmenu(i1,i2,i3,i4,i5,i6,i7)),"]") w "]]"_t q
 ...........i $l($g(cmenu(i1,i2,i3,i4,i5,i6)),"[")'=$l($g(cmenu(i1,i2,i3,i4,i5,i6)),"]") w "]]"_t q
 .........i $l($g(cmenu(i1,i2,i3,i4,i5)),"[")'=$l($g(cmenu(i1,i2,i3,i4,i5)),"]") w "]]"_t q
 .......i $l($g(cmenu(i1,i2,i3,i4)),"[")'=$l($g(cmenu(i1,i2,i3,i4)),"]") w "]]"_t q
 .....i $l($g(cmenu(i1,i2,i3)),"[")'=$l($g(cmenu(i1,i2,i3)),"]") w "]]"_t q
 ...i $l($g(cmenu(i1,i2)),"[")'=$l($g(cmenu(i1,i2)),"]") w "]]"_t q
 .i $l($g(cmenu(i1)),"[")'=$l($g(cmenu(i1)),"]") w "]]"_t q
 w "]"_t 
 q

 

[Ragazzo]

pilot911
Что за заразу ты принес?)

 

[AmdY]

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

 

[pilot911]

pilot911
Что за заразу ты принес?)

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

ПС. да.. еще представь, что нет фигурных скобок для блоков IF WHILE, а глубина вложенности определяется количеством точек перед оператором

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

 

[Ragazzo]

AmdY
Прошу прощения за дерзость, но почему бы не сходить напрямую к рубистам...или в хабре..их там куча, прям полк целый)некоторые даже солижные места занимают в Москве, плюс у создателй Рубиниуса можно что-нибудь дельное подчерпнуть

pilot911
>>ПС. да.. еще представь, что нет фигурных скобок для блоков IF WHILE
этому обучен в питоне отчасти

 

[Вурдалак]

А по делу пока ничего...

 

[AmdY]

Ragazzo
в том то и дело, только оттуда, слушал про ruby и python.

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

ROR-вцы напоминают айГопников, главное чтобы было красиво, получать удовольствие, красивые листинги, рассказывают только о лучшем (ROR), сам же Ruby для них загадка похлеще SPL для наших. О ООП они знают по наслышке, инкапсуляция их враг.

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

 

[Ragazzo]

>>Они не используют IDE, так как это не имеет особого смысла.
А я использую RadRails, немного кривая но все же...

 

[AmdY]

Ragazzo
как ты справляешься с отстутвием подсказок для динамических методов, параметров методов, передача объекта в метод без возможности проверки типа....
как ты браузишь по коде, чтобы узнать, как у тебя работает метод, если он может быть переопределён или определён сразу в нескольких местах, те же mixin, proxy object.
это злостная рефлекси, позволяющая переобределить super или вызвать метод в контексте другого.....

надо где-то добыть пленного толкового рубиста и активно пытать его с помощью пальника. слишком много проблем я вижу, а они даже о таком не задумываются. о вещах стандартных для цикла разработки в php, java и т.д., которые годами упрощали разработку.

 

[fixxxer]

Язык как язык, со своими достоинствами и недостатками. Кругом динамика, да, ну так это и в Python и в том же Javascript то же самое (Perl я даже вспоминать не буду, хе-хе); Ruby при всем при том целостнее и последовательнее как язык, чем php, кстати говоря (другое дело, что это само по себе не показатель - целостен и Brainfuck по-своему =). Имеет на право на жизнь все, что позволяет решить задачу в заданный срок с заданным качеством. А фанатиков слушать никогда не надо

 

[tz-lom]

а JavaScript вас не пугает?
там тоже можно все такие приколы организовывать , плюс слабое связывание (уж не знаю как там с этим в руби)
питон я вижу тоже не пугает,хотя ИМХО тот ещё залёт,и лютых бешенных питонистов вполне достаточное количество
право на жизнь имеет
но никто вас не заставляет на нём писать

 

[AmdY]

fixxxer, tz-lom вопсрос в том есть ли озвученные проблемы и как их решают. на том же meetup назвали perl write only языком. опять же озвучили массу проблем библиотек питона, ruby я сам испугался. у нас сейчас появляется тот же функционал: замыкания, лямбда функции, traits - меня это пугает больше чем проблемы других языков, но они их как то решают же.

 

[fixxxer]

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

я тебе тот же monkey patching могу и на php изобразить через замыкания, __call и такую то матерь, ну и сам дурак буду.

 

[AmdY]

fixxxer
приведём твой ответ к форме - не использовать синтаксический сахар, там где его проблемы нельзя закрыть RDOC. а как быть с готовым кодом, тот же ROR как бы навязывает магию?

кстати, в руби планируется ввести контекст, чтобы monkey patching можно было производить лишь в определённых классах, недавно korchasa предлагал подобный вариант для реализации реестра. на хабре недавно активно муссировалась тем mixin в php и есть готовые решения, так что не надо ничего дополнительно изобретать, яд уже готов.

 

[tz-lom]

AmdY
а почему тебя так напрягает расширение интерфейса?
может я чего то не понимаю и это большое зло ?

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

 

[AmdY]

tz-lom
меня не напрягает сама возможность использовать, это клёво, это упрощает разработку. меня интересует как эти не сломать архитектуру, как это поддерживать, как НЕ получать код write only.

 

[korchasa]

Тут я побуду адвокатом дьявола, видимо. Дело в следующем: вся эта "магия", основанная на соглашениях, ускоряет разработку. Обратной ее стороной, является высокий порог входа. На выходе имеем большее количество необходимых знаний в голове, при меньшем количестве клиентского кода. Перестараться с магией можно очень легко, поэтому приходится себя контролировать. Как определить грань? Хз. Точных критериев не знаю. Например, я за использование аналога mixin'ов в lmbToolkit, но против его использования в моделях.

 

[DYPA]

...

мне это напоминает ситуацию с фреймворками под php - каждый разработчик считает что больше кода = лучше и проще разрабатывать... вот взял тут yii для решения одной из поставленных задач, заюзал кодогенерацию, написал нужный php код и начал его интегрировать в фреймворк... тут то и начинается: "а какой класс фреймворка за это отвечает? о! есть такой, смотрим 300 методов на все случаи жизни, не находим нужного, ругаемся и материмся комбинируя 3-4 метода в классе для реализации своего кода"

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

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

<?php
$govnokod = 1;
// через кучу строк...
$Govnokod = 2;
// через кучу строк...
var_dump($govnokod);